64-bits vs 32-bits

[blackrg]

I am from an underdeveloped part of the world I guess (North Ogden UT) but I have no interest in Linux. It may become the industry standard and then I will move over but for now I will stay with my windows box.
I have a friend in Texas that lives and breaths OS2 - He really loves it and usings it everyday. I don't see these as reasons to move to OS2. I am sure that there are Mac users that would love to see the whole thing more to that. Those of us that are not greatly trained on computers (I have only been using them since the mid 70s) might find Linux and OS2 or the Mac OS as more than we are interested in learning on top of just tryiing to do a good job as STS.

Now 64 vs 32 is more interesting.

In some ways, I think that kind of highlights the real problem. In a perfect world, a STS wouldn't have any real need to understand the underlying OS. The real job of your OS is to run your software and be as invisible (transparent) as possible - if people don't even realize it's there, then it's doing it's job well. I see the real need for a STS in hardware maintenance (something breaks, needs to be identified and replaced) and in training on APPLICATION (not OS) use. The application deployment for the most part would hopefully be a pretty standardized affair - if things are regularly needed the church isn't deploying then things need to be reviewed and possible changes made. Now I can hear the thought banging around in everyone's head right now - "But you have to know the OS to in case of a software failure of some sort" or possibly "But you have to know the OS for basic maintenance - installing software, printers, etc." Well if complete backups are kept both locally and remotely (network backup) of important data then in case of failure you could fall back to the "insert CD, press a key" scenario as the pc is completely reimaged and ready for use again. Now this naturally requires the hardware element be standardized and/or controlled to be successful, but I think the church is largely already doing that anyway. In terms of the OS interface - it needs to be simplified as much as possible. Particular OS familiarity doesn't necessarily mandate use of a particular OS as the interface and the OS are two elements that are much more loosely coupled than one might think - the host of "Windows like" interfaces available for X-Windows demonstrate this pretty well. Yes, there are some differences, but they could be minimized and overcome - after all, the goal here isn't to spend time in the OS interface, it's to spend time in your application.

All of this would naturally require very careful planning and testing up front - but that always pays off anyway as you lower your help desk requirements (and expenses as a result), and increase the satisfaction of the user experience as they don't find themselves calling for support as often (No one ever wants to call support - they just want it to work).

[russellhltn]

In a perfect world, a STS wouldn't have any real need to understand the underlying OS.

In a perfect world, the STS position itself would be unnecessary.

No one ever wants to call support - they just want it to work).

And that's how I know I'm doing my job right - I've set up the systems so they don't break. I work hard to enjoy being lazy.

[thedqs]

I work hard to enjoy being lazy.

And then you spend the rest of your time on LDS Tech.

[russellhltn]

And then you spend the rest of your time on LDS Tech.

The point is to have the free time to do what I want.

[vernondcole]

Hold on, there... MLS requires that the clerk be logged in to an administrator account. That is the same thing as root on linux. As a systems administrator (professionally) and as the "Technology Specialist" hereabouts, I don't want any of the clerks to have that kind of power. Yes, they could kill linux with the command you suggest. They could just as easily kill Windows with the authority they have now. As for finding Windows experts around the neighborhood, I would much rather they call me than muck around with the clerk computer trying to figure out how to fix it themselves. If there were any way I could turn off that ability, I would.
The protocol is: First, call the Stake Technology Specialist. Second: Call Salt Lake support. No number of linux or Windows experts scattered around the area should change that.

[vernondcole]

That same Windows code "to send/receive information" needs to be reworked anyway. If I remember correctly, that code is the reason clerks must be logged in with administrator privileges. I would sleep more soundly if only I (the local "tech specialist") and the Church Staff knew an administrator password for the clerk's computers. Then we would not need directives sent out from Salt Lake telling the clerks things like "Do not change the date on your system clock."
As for training, of course you are correct. I suspect, however that the announcement that the Church was going to start using Linux would create a surge of self-training among those of us in the trenches. (I didn't know Open Office until it showed up on a Church CD. Now I use it everyday.) The thing is that our existing machines run Windows XP poorly, and could not run Vista at all. I'm sure that we will be able to keep using XP for many years, but someday an upgrade will be in order. It would be nice if we were not, at that time, "locked in" to the commercial vendor.

[russellhltn]

That same Windows code "to send/receive information" needs to be reworked anyway. If I remember correctly, that code is the reason clerks must be logged in with administrator privileges.

I'm not sure is it's the package that needs it or the fact that at any time SLC might push down a new package that needs to be installed that requires it. I have successfully made software run under "user" rights that claimed they must have admin to do it. But it was the latter issue that made me decide not to even try that on the church computers.

Then we would not need directives sent out from Salt Lake telling the clerks things like "Do not change the date on your system clock."

Well, Power Users (the normal user level) still has rights to mess up the clock. I don't remember if just "User" (aka Restricted User) can do it. But just because someone is part of the Admin group doesn't mean you can't take away some rights. <evil grin> I've set the clerk to not have the ability to change the date/time. Solved that problem. (If they really need to, they can change the date/time in the BIOS before booting Windows.)

someday an upgrade will be in order. It would be nice if we were not, at that time, "locked in" to the commercial vendor.

You say that like it would be a good thing. Would it really? The Church is no more locked in then 99% of the business out there.

[thedqs]

You say that like it would be a good thing. Would it really? The Church is no more locked in then 99% of the business out there.

And of course the church would just be paying a Linux distributor to keep everything automated on Linux. It just changes who gets the money.

[rmrichesjr]

And of course the church would just be paying a Linux distributor to keep everything automated on Linux. It just changes who gets the money.

Paying a Linux distributor would be one of the options the Church could choose. The point is the Church would have the power of choice in the matter. Also, done right, the amount of money changing hands would undoubtedly be a whole lot less.

[thedqs]

Also, done right, the amount of money changing hands would undoubtedly be a whole lot less.

Hopefully, I've seen it go both ways (to paying more than paying less). I am sure though whatever the church decides it will have done quite a bit of research beforehand.