64-bits vs 32-bits

[AdrianLP-p40]

1. removal of the 4GB memory limitation of 32-bit.

Because 4GB isn't nearly enough memory for MLS ... ? <smirks>[/font][/size]

3. Windows XP Professional x64 is faster more reliable then 32-bit.

There would be very little in it. MLS is a very light-weight app. The benefits would be trivial to non-existant.[/font][/size]

4. Windows XP Professional x64 is built on Windows Server [2003 service pack 1 (SP1) This is very stable provides optimum security for business-critical desktop computing.

Optimum security? heh, you are quoting MS aren't you If you want security, run your MLS on *BSD, or Linux with properly configured iptables. Windows security is a joke.

Besides, LDS policy is to use a common unchanging password for MLS. In my opinion that is a massive security issue. I find that a breathtakingly foolish policy [/font][/size]

Adding more memory always makes a system more stable, faster running and less freeze ups and problems.

That depends on where the bottle neck is. And the first conclusion is just wrong [/font][/size]

Memory is key to making everything run better in my humble opinion. It has for all of the systems I have delt with. Memory is better to access then reading from disk.

Time for solid state disks [/font][/size]

[AdrianLP-p40]

Hold on, there... MLS requires that the clerk be logged in to an administrator account. That is the same thing as root on linux.

Not quite. In Linux they could run MLS with sudo or SETUID root privelages. Allowing MLS to run with root access, but not the user.

Of course in Linux, they would just setup a sane non-root policy allowing MLS to function without root privelages.

[AdrianLP-p40]

MLS still depends upon some Windows code to send/receive information to/from CHQ. That is one issue that would need to be resolved. Other issues include training and support for Linux by CHURCH staff and local tech specialists.Tom

Well of course it relies on Windows code to send/receive, you'd need to access a native TCP/IP stack you silly person you

But if you're using Java, the API for that is portable anyway. I see you use SSH for encryption, that was originally wrote on, I believe, BSD, then ported to Linux, then Windows, so that won't be an issue.

What are you doing that can't be rewritten in a portable fashion?

[AdrianLP-p40]

Maybe my sources are biased, but my observation seems to indicate Linux has much greater usage (on a percentage basis) in developing parts of the world than it does in the US. Not that the UK is exactly a "developing" nation, but for one example, I have heard from people in the UK who say a large fraction of households in their neighborhoods use Linux as their primary system at home.

I can't speak for households, but I'm a simulation software developer for the Department of National Defence (note that I'm Canadian, so I spell defence correctly <smiles>), and we make heavy use of Linux. Of course they bias towards Cent OS and Fedora, so it's not quite a perfect world yet

[AdrianLP-p40]

...and this is why the wifey doesn't let me out

[WelchTC]

Well of course it relies on Windows code to send/receive, you'd need to access a native TCP/IP stack you silly person you

But if you're using Java, the API for that is portable anyway. I see you use SSH for encryption, that was originally wrote on, I believe, BSD, then ported to Linux, then Windows, so that won't be an issue.

What are you doing that can't be rewritten in a portable fashion?

I think you misunderstood what I meant. MLS uses a proprietary windows application (not written in java) to talk with CHQ. This application (not written by Microsoft) manages creating the connection, transferring the data, verifying transfer status, closing the connection, etc. Yes, it could be replaced using some java code and that is what I was referring to. SO until that piece is replaced, running Linux is not a possibility unfortunately.

tom

[AdrianLP-p40]

I think you misunderstood what I meant. MLS uses a proprietary windows application (not written in java) to talk with CHQ. This application (not written by Microsoft) manages creating the connection, transferring the data, verifying transfer status, closing the connection, etc. Yes, it could be replaced using some java code and that is what I was referring to. SO until that piece is replaced, running Linux is not a possibility unfortunately.

That is very odd.

Why does everyone feel the need to roll their own parsers, and their own communicaion tools?

[rmrichesjr]

...
Besides, LDS policy is to use a common unchanging password for MLS. In my opinion that is a massive security issue. I find that a breathtakingly foolish policy

The forum is supposed to stay away from policy issues, so I won't state my agreement on that point.

However, anyone in the office has physical access to the machine, and it is generally agreed that anyone with physical access to a machine can get around any security on the machine. If nothing else, it would be physically possible to open the case, remove the hard disk, plug the hard disk into a duplicator appliance, then put it back. Short of encrypting the filesystem, that threat to confidentiality can't be removed.

[WelchTC]

That is very odd.

Why does everyone feel the need to roll their own parsers, and their own communicaion tools?

The Church did not roll their own but bought a program that would synchronize a remote database with a master database.

Tom

[AdrianLP-p40]

The Church did not roll their own but bought a program that would synchronize a remote database with a master database.

Seriously? MySQL can do that, so can RSYNC Both are free.