Slashdot Mirror

From what I recall, it saves a memory dump to a file. That would include app state, undo, and other information that didn't need to survive, and it shoves it into semi-permanent storage.

Actually it's a "compound document" and is structured somewhat like a filesystem containing other subdocuments (more info)

Closed-source programs? Binary installations? That's what you're worried about? I might be jumping the gun a bit here, but I can't help feeling nervous about having to roast in DLL hell in Linux as well...

As if existing dependency issues weren't enough!

I'm not just talking about files. NT has fine-grained ACLs throughout the entire OS.

The flaw is that you cannot have services running as any other user. You just can't you seem unwilling to accept this is so but it is.

That's because there's no technical reason why it isn't possible and more than one web site suggests it is possible. Excerpts:

"An NT service will run with "system impersonation" by default. Any service, however, can be configured to log on as a different user via the services control panel by providing a specific user name password to be used by the service."

" -User and -Password allow you to specify the account in which the service will run. This setting overrides that provided in the Service Configuration file, and is ideal for cases where the account must vary from system to system."

"Running a service as LocalSystem is perhaps the most dangerous option from the standpoint of executing arbitrary code. [...] If the service does not require network access, you can run some services under a local account. Selecting a local account with limited rights is the safest approach. That way, if an attacker executes arbitrary code, the attack will be limited to only those resources that the local user controls. Also, if an attacker gains control of the local system, a service running under a local account gives the attacker no additional privileges."

That took me about a minute on google.

They were mostly the boot sector sort but when I was in college the lab macs were terribly infested all the time.

Highly unusual. Try an tell any Mac user that Macs are "virus infested" and you'll get laughed out of the room - even by the non-zealous ones.

But even then there are ways to limit the damage a user can do to his own computer. Take my Windows box - there's not much limit because a number of programs need me to have administrator access to run! Again, poor design.

This is not poor design of the OS, but poor design of the program. It's like calling unix badly designed because some code needs to execute as root. Even so, you should be able to run arbitrary applications as an Administrator just by using "Run As" (NT equivalent of sudo).

Design is when you say "Services can't run as other users, user accounts are only for users and not for services".

Except that isn't true.

Look up any porgram taht runs programs in the background as services. They ALWAYS run as an administrator. That is by design.

No, it's by default. Not to mention they usually run as LocalSystem, an account that usually has higher privileges than Administrator. There's no design feature that *requires* services to be run as LocalSystem.

Besides, you're just being nitpicky.

No, I'm being accurate. You, OTOH, are being either dishonest or ignorant.

Well, except for DLL's and the occasional misbehaved uninstaller.

But, of course, that's not Microsoft's fault.

FWIW, I'm an MS Active Server Pages (ASP) developer with zero Linux experience. Read on if you still care............

About a year ago, I started working with MS Indexing Service, which is what powers the "Find..." feature in Windows 2000. It seemed like a great concept -- take a hint from the database world, create an index of document properties for files residing on that machine, and then query that index first when searching for files. MS even provided a nifty little API to allow programmatic access to this functionality . Good stuff......

However, I started encountering problems on a number of fronts. First, the number of 3rd-party COM objects that allow programmers to set/get these properties in code approaches zero: the only supported component I can find is Desaware's "File Property" component. And while that works right now, the documentation isn't as robust as I would like..... and, of course, it's proprietary. Second, Indexing Service tends to shine only when used in conjunction with files that are local to the computer where the scripts reside. Once you get into files on shared / remote boxes, you're forced to use a single, hardcoded username/password to run searches -- there's no support for delegation, or for a logged-in user's credentials to be applied when performing those searches. Finally, I'm hard-pressed to find an affordable solution for querying another box's Indexing Service catalogs (i.e. indexes)....... for that, they want you to upgrade to SharePoint Server. That comes out to $4,000 for a server license PLUS $72 per CAL, on top of the cost of Windows 2000).

NewDocMS sounds like a pretty interesting alternative to OLE Structured Storage on MS....... it may not be mature yet, but if it continues to evolve, it'll be yet another quality app for Linux to reduce the TCO for businesses, especially small- and mid-sizers that don't have the deep pockets that standardizing on an MS platform requires. And because it's OSS, it has the potential to mature faster than its proprietary siblings. This, coupled with Linux's unwillingness to foist DRM onto its users (at this time, at the software level) makes it an increasingly attractive file serving alternative.

Who knows, maybe one day soon I'll break down and start messing with Linux. For one thing, I'm loathe to return to the command-line interface, and I don't have enough time for things as-is. But I've already sworn that I won't buy any further versions of Windows beyond Win2k, nor any versions of Office beyond O2k, because they fill my needs nicely without forcing me to do too much. I've already dumped Windows Media Player in favor of Winamp 3.0 with plug-in support for WMV; DivX shows more promise as a video format anyway. And now that WinAmp supports Ogg Vorbis (as of 2.80), I'm considering converting all my Mp3s to Ogg format as well.

You must be new to UNIX like systems. You see there is a reason we don't have 50MB executables from all the static linking and DLL hell. We use shared objects between all apps to save disk space, development time, and main memory. I see you complaining about rpms, so maybe you should try a distro like Debian GNU/Linux, and expand your horizons.

For example if we did shar archives ( what you want with your 'setup.exe' ), then you'd have to install all of KDE to just get QT libs. You'd have to install all of GNOME to get gtk+. You see why that's piss poor way to do things just from a packaging standpoint even if you don't understand the techincal aspects? Also versioning would be impossible to support. Versioning is allowing multiple libs to stay on the system without conflicting, so apps can use various versions as they choose. To support versioning you'd have to have N number of KDE installs.

I don't see how that post go modded up, when it's so misinformed... oh this is slashdot.

That was a very, very good article by Miguel. Unfortunately the first few posts I have read are from posters who obviously didn't read it and instead are making personal attacks at Miguel.

Miguel's article is spot on. I love everything about Unix except the fact that Component Based programming is so underused. If there is only one thing Microsoft has done right, it is the way they have developed and pushed COM. With COM, I can write a piece of software that performs a task (be it a Widget or piece of middleware) and COMify it.
Once this is done, anyone can use it regardless of what language it was written in, fast XML parsers can be written in C++ and used in from Javascript or VB. This way developers of business apps do not have to make the choice between a.) putting up with a slow app or b.) writing one themselves with all the attendant bugs therein especially if they have little C++/C skills, also they can go on towards actually creating their application instead of worrying about if they malloced() enough space for their char*'s.

Lots of *nix people believe this implies laziness but fail to realize that reinventing the wheel dozens of times over is folly.

Example I:
I am currently designing and implementing a project management system on Windows(TM) for a small business with a few of my friends. two of them are *nix hackers and they balked at using an XML based protocol to transfer data between the client and server. Now instead of simply designing our protocol then using one of the dozens of available parsers to do this, they decided that we should invent our own binary protocol and write our own parser to parse it.

Our project involves code written in both C++ and Javascript/ASP. We could have used a single COM based parser to consistly interact with the data both from the C++ and the Javascript code but instead its been 2 weeks and counting and our homegrown parser is still being written, tested and debugged. In my opinion this is nothing but a waste of time. When I ask them why not just use XML and an already existing parser their replies boil down to "It just feels wrong.". The chances that a bug or two will slip through in testing or that there is a buffer overflow in our parser is not unlikely considering that most early versions of parsers written in C++ have a few bugs like this hidden somewhere. in this situation component based programming would have allowed us to focus on building and designing our actual application instead of focusing time and energy on a tangential application.

Example II:
At work a MBA intern asked me if it was possible to create an application that housed a search engine that searched a database of MBA students based on criteria like concentration, work experience, graduation date, etc. and then displayed results with links to their resumes in MSFT Word(TM) or HTML format which could be stored on a CD to give recruiters at career fairs. Their first attempt had been to use VB and Access which turned out to be a disaster because of DLL Hell based issues. My simple solution was for them to store all the students in an XML file and to write a Javascript page that used the COM based XML parser (written in C++) to perform the search. Writing this page took less than 2 hours.

Now they have this search functionality they can press on a CD and give out at career fairs which any recruiter can view without needing more than MSIE 4.0 or greater.
Without Component based programming their request would have been impossible to fill in their time frame and would have also required that the recruiters machines would need to fulfill a stricter set of requirements (like a Webserver being installed or they'd have to install an app).


In conclusion my question is "Why has it taken so long for a major *nix push towards component based technology?". After all we've had CORBA for almost a decade but there hasn't been that much a big push towards components. Frankly I am eagerly awaiting MSFT's .NET for one reason only...cross language inheritance. The thought that my C++ components can be inherited by my Perl, Java or Javascript objects makes me extremely *CENSORED*.
FOOD FOR THOUGHT

Do you even know what COM is?

I usually insert visio diagrams in my word documents, and i certainly don't expect to be able to edit those diagrams when i open it up at university with staroffice.

If you have a secret for avoiding DLL Hell, I'd sure like to know it.

You're damn right most people don't have static configurations. Software is constantly improving and upgrades are constantly needed. It's unreasonable to expect someone to keep on using Word 95 when everyone around him is using the new Word 97 file formats.

So given that most people do not live in a bubble and need to upgrade their software, let's compare Windows and Linux on the typical tasks of software installation, removal, and upgrading.

In Redhat Linux I can, with a single command, list all the files that come with StarOffice and all the dynamic libraries it depends on to run. In Windows, well, if you know a way to list all the files that come with MSOffice and all the DLLs it requires, I'd sure like to know.

In Redhat Linux a single centralized program can uninstall any software package on the computer. It knows what files to uninstall, lets you see what those files are if you want, and checks to make sure the uninstall doesn't break any dependencies. If you can get Windows to tell me the files it's about to uninstall, to check program dependencies before uninstalling, or even to present a uniform uninstallation interface instead of the hodgepodge of hundreds of different uninstall.exe's made by dozens of different companies, well, I'd sure like to know.

In Redhat Linux, if I'm about to install a package, I can list the files contained in the package, the libraries the package requires, and check that my system satisfies all the dependencies before installing the software. In Windows, well, if you know a way to get setup.exe to reveal what files it's going to install where, and what DLLs the installed program needs, I'd sure like to know.

Now you may rightly argue that grandma doesn't need to know anything about DLLs to install her software, but that's no justification for leaving out the capability entirely. System administrators use Windows too, and all the sysadmins I know would be very happy if it could be possible to have Windows make their lives easier in ways that Linux already is.

Judging from what you've said it looks like you've never been through DLL Hell.

There may be a lot of things that are easy in Windows but software installation management is definitely not one of them. Jaded Windows users may be impressed by one-click self-extracting installs and Install-Shield uninstalls, but that's only because they've never seen a real package manager like RPM or dpkg in action.

I will concede that software installation in Windows is easy if you can show me in Windows how to:

• List the files that Word97 installed on the system,
• Tell me which programs require ctl3d32.dll or any other particular dll,
• Show me what programs on my system will break if I upgrade to Office2000.