why is it only MSFT IIS and MS SQL that's affected Because the code they used is based on the MS-SQL particular dialect, with some MS-SQL specific conventions.
The malware authors could have trivially used INFORMATION_SCHEMA views rather than sysobjects, and this would have been a generic attack that would have worked against most mainstream db servers.
while the flaw may not be MSFT's sole fault how could 500,00 people setup a server wrong including the DHS? This has nothing, zero, to do with server setup or configuration. This is purely and soley, only has to do with web app developers allowing uncleansed commands to be sent from a web-browser to the underlying db server.
Again, the ONLY reason this only works on MS-SQL is because the malware authors made a choice to write the attack in non-portable syntax. They could have done so, but they chose not to.
Only Microsoft servers are affected by this specific attack.
Nearly every language and/or platform in existence right now is capable of being hit by this type of automated attack.
Nearly every mainstream DB server allows things like INFORMATION_SCHEMA or similar metadata to be accessed in this way to generically hit all tables in a db/schema.
Every single web-based language that I've ever seen is quite capable (trivial even) to create sql-injection vulnerable pages.
Assuming a user runs as non-admin, how would you like something like this to work?
Because I'm unclear on what you're meaning. If you've been in this industry and done this work... then you've had to deal with non-admin users, and services, and system tray icons talking to back-end services, etc.
Can you talk about how you think it should work? Technical detail would be great.
Likewise, this is what I do for a living (or at least one of the things) and I own a business doing it as well.
Garbage. How does that make me more secure? By fucking desenitizing me from actual warnings that require my attention so I end up programmed to press "Allow" like Pavlov's dog? Listen to what you're fucking saying man! It doesn't make sense. How could that not make sense?
You're trying to do something you dont have the privs to do, so you're being prompted to either allow (admin-approve mode) or asked for credentials that can.
This is ultra basic simple stuff.
You should not be, under normal circumstances, be triggering UAC prompts. If you are, then you've either:
1. Using the file system in a way that catches you on the default ACLS. So change the ACLS. Normal 90% use-case users wouldnt ever trip over this.
2. Using software that assumes local admin privs.
It sounds like your issue is #1. You are often trying to write or modify files in directories that are SPECIFICALLY CONFIGURED TO STOP YOU FROM DOING THAT. Given that they are specifically configure to stop you from doing that, then it is absolutely correct that UAC is spawning.
If the default ACLs dont work for you, and you want to be able to do things like that, then for *(*&D's sake, change the damn ACLs.
You sound like a little kid who keeps running into the door and bloodying his nose, but who keeps crying about how the door doesnt really keep him inside, its just theatre. Well then just open the damn door, and quit beating your face against it.
Typically only one person uses a machine and has installed all the software. Occassionally there is a genuine multi-user environment on a home PC, and more commonly some work machines are shared, but for the most part this is computer security theatre at it's finest. In the home-user scenario only one person typically uses the machine (or one login, to be more specific).
But that person should _never_ be the admin on the box. Running your day to day desktop as admin is just being silly. I can definitely see running as no-prompt admin on servers or other machines where your only role is sa tasks.
But running a desktop as admin is not smart. At least not if you ever use a web-browser on it or an email client. Even in Firefox, Safari, and IE there are drive-by exploits available at various times. And if you're running as admin, you just got owned.
It's not that I don't care about security, it's that for practical everyday operation on a single user machine, constant prompts or use of pseudo is nonsense. (I assume you mean sudo, not pseudo there)
I'll try saying this one more time.
If you are getting hit with constant UAC elevation requests in your regular day to day work then:
1. Your machine is misconfigured for your particular use of it. If you're constantly tripping over file ACLs in explorer, then change the file ACLs. Tune the box to your use, rather than bitch and whine about UAC doing what its supposed to be doing.
2. You are using apps that are problematic.
The second can be harder to deal with, but it sounds like the first is what you're encountering.
Understand that this means that you are not using your machine in the typical role for which they configure the default ACLs.
So assuming you're not doing something stupid, like constantly tweaking files in All User profile, Program Files, or anything under \Windows, then just change the ACLs to suit your use. If you are doing one of those bad things, then create yourself a separate directory off the root of C: drive, call it dev or something, and then set the ACLs on that so that you have change or full privs.
Then you'll never be bothered by UAC again, and you can leave it on to let it do its job.
Bah. Basic IPC and RPC code is fairly straightforward on windows.
What was hard for these guys was:
1. It was more than they were doing before, so therefore worse from their point of view.
2. They had never done this sort of coding before on windows, so it was their first time, and they were learning, therefore it took longer than it should have under normal circumstances.
3. They obviously didnt understand the need for proper separation of systems, so they viewed the whole thing as a waste of time.
Plus there are other ways to do what they wanted to do that they didnt even try. A couple off the top of my head:
- the scheduler based approach that someone else mentioned.
-.net remoting or com+ registration, as the other very knowledgeable guy mentioned.
- moving the boot-loader mod logic to a separate executable from the system-tray app, and when a change needs to be made, have the system-tray app launch a new process on the executable, and request elevation when it does.
Until you've written IPC or RPC code on windows, you shouldnt be going around saying how bad it is. You're massively inferring from a third party, who is obviously not very knowledgeable or experienced on the platform.
Out of curiosity, why would it "likely hang"? It sounds like you presume that if iReboot is a GUI app, it must be running its GUI when it begins running and not on-demand on newly created desktop sessions. If it is (or was) doing it on-demand, then how is the program not an application with a GUI that starts on computer start? Any app that presents a dialog box when running headless will cause the app to permanently block. It will then have to be killed.
I am fairly sure that they did nothing like an on-demand systray icon/app. Based on TFA's discussion, I'm fairly sure it was a standard GUI app written to display in the system tray, nothing more.
It was clearly running on user login, not on computer start, based on TFA. Otherwise, they would have already known how to do services or headless apps through scheduler.
But, let's just presume, for the moment, that iReboot is a GUI app but it's run on user login, not system startup. Now, if a user is an Administrator, should the GUI app be able to elevate itself to SYSTEM user? The GUI app wouldnt need to elevate to system, if the person is an Adminstrators group, then thats enough perms. It can just run as-is (until/unless UAC gets involved, depending on how the machine is configured).
Wouldn't UAC be there to prevent that because pop-ups would be annoying each login and actually allowing apps to promote themselves would potentially defeat UAC entirely? UAC would be there to verify that the person wanted the process to elevate, not necessarily to prevent. I'm not sure what you mean by 'defeat UAC entirely'. If an app needs elevation and the user allows it, then that is how its supposed to work. Thats in no way 'defeating UAC entirely'.
Even in the incredibly lame case of an app starting every time the user logs in and prompting for elevation. Thats a lame scenario, but its not 'defeating UAC entirely', its just using it in a fairly stupid way.
Perhaps *the* blocking of HKCU/.../Run apps to run as SYSTEM is what iReboot is complaining about? Yeah, someone in the parent to this discussion got a little registry path happy.
The bottom line is that the way that NeoSmart was trying to do things was a pretty terrible way. It goes against all the guidance on the platform, and its poorly thought out.
There are other alternatives to what they did as well. They could have had the system-tray app run as the desktop user, and start on desktop user login.
Then when you want to modify the boot-loader, it launches a separate executable with a new process and requests elevation. The executable makes its modifications to the bootloader, and quits.
Then the UAC prompt would only launch when actual changes were being made to the boot loader. The idea of having a system tray app running as system is just.... stupid, with all due respect to the neosmart folks. But thats just bad programming.
The system tray icon is just a gui element. It should be doing nothing except presenting visual information and interacting with the user. The heavy lifting should be somewhere else.
If I've just requested a file copy in windows explorer and I still get prompted with a security warning, that's a false positive. File copy from where to where? What are the ACLs on the destination directory? What privileges do you have on your account?
If you're copying the file into a place that you dont have permissions to (ie, C:\program files\ or the all users part of the desktop or start menu), then you will get a UAC prompt.
And that is correct behavior.
And thats the way every mainstream OS works (though some just silently fail, rather than prompting for elevation).
Try copying files into/etc on linux or the OS folders in OSX and you'll get the same response.
On the other hand, if you're concerned that you're running as admin but dont want UAC prompts, then just configure the OS to operate that way.
And that means, there's no inherently obvious reason to prevent HKLM/.../Run programs from being launched under any privilege that an Admin could obtain (specifically, whatever user they were under XP), as it sounds UAC is doing under Vista. iReboot is a GUI app. There is no desktop session to run under on machine startup, so the app would likely hang.
Of course, an application that starts when the computer starts, and has no GUI, is.... wait for it... a 'service'.
And what did neosmart do to make this work? They moved the priv-requiring components into a service.
This is so pathetically non-news, based off raw ignorance of the windows platform, its just sad.
If an app tries to do something that a non-priv'd user doesnt have rights to do, UAC will be triggered. This is correct behavior.
It sounds like most of your software is just written incorrectly for the platform.
How about instead of bitching at MS for finally doing the right thing and not letting lazy ISVs get away with bad programming, how about you go back to your software vendors and tell them to learn how to develop correctly for the platform.
If and when Microsoft closes those loopholes, any software that abuses them will break. They're not loopholes. They're one of the well known ways of solving the problem the neosmart devs created for themselves.
The NeoSmart folks just were being lazy and assuming everyone was an admin, and that someone was always logged into the OS.
The article said it took an order of magnitude more code to do the IPC than to do the business logic. At the risk of repeating myself (not sure if it was you I responded to earlier about this issue):
It's easy to do things sloppy and incorrectly, and can often be done faster and with fewer LoC.
Doing things right often takes more work. This should not come as a surprise to anyone.
The NeoSmart folks (with all due respect) appear to be rank amateurs when it comes to software.
That whole problem they ran into is a total rookie mistake. They should have gone beyond requiring the user to run as admin years and years ago.
The fact that they had to actually take the time to *gasp* do things right is a good thing. Their posting just really exposes the inexperience and ignorance of developers on the platform.
It's basically a parser and message passer that runs as a kernel component. This was done primarily to have the fastest possible access to the network stack.
It's a very small amount of code. Cant remember the approx LoC, but when I saw the post way back when that this first came out, I was amazed how small that component is.
Comparatively, IIS (which IS a web/http server, amongst other things) is huge, and has no need to run as admins.
You do realize that this is exactly how windows works, right?
I have java & ruby installs on my machine (running as a non-admin) configured in the same manner as you, and I can configure them independently of stuff installed at the system level.
MSFT has turned a single user OS and tacked on multi user support, and then multi user security. Where do you come up with this? Your information is incorrect.
NT was designed from the start as a multi-user system. It's never been anything but.
You may be confusing the 9x line of operating systems, which was unrelated to what we're using today.
I not only have applications but also user specific applications stuff that only I can run, and stuff that only I can see. Yeah, you can trivially do this on windows as well.
The only qualification is that the application has to be designed to support it (ie, not rely on any registry information outside of HKCU).
These are commonly known as 'green' apps. I have a number of apps like this installed on my box. FileZilla, micro torrent, 7-zip, putty, eclipse, paint.net, etc etc etc.
You shouldn't have to be an admin to install a web browser, word processor , or spreadsheet. You dont, as long as the app developer has written the app in such a way as to support this. This isnt a windows issue, its an app developer issue.
You should only be an admin if your installing it for everyone. Yep, thats exactly how it works, and always has (in the NT line)....
Overall, I think you're confusing standard practice with inherent ability.
It's not standard practice to have per-user apps installed on windows, but the capability is surely there, and its trival to do, if the app developer supports it.
On OSX and most unices, its BOTH standard practice and inherently capable to do so.
Well sure. Thats almost always the case, regardless of platform.
Doing something sloppy and wrong is often easier and less time consuming than doing things right.
This article is just that case.
NeoSmart was getting a free ride by being bad developers, and assuming that everyone was running as admin, and that someone would always be logged into the box.
Now they're being forced to learn how to program correctly, and do things right, and yep, it takes more lines of code.
Doing things the right way almost always does, but you end up with a better product in the end.
Looks beautiful in Opera 9.27, at various zoom levels.
It looks great in FireFox too, unzoomed.
If you're using zoom levels or nonstandard font sizes in FireFox, then thats a firefox problem, its never handled that well, while browsers like Opera handle it beautifully.
I see this as a philosophic deadlock. However, there is an easy solution. There is an easy solution.
Use your freedom of choice to choose something other than Microsoft. There are several alternatives available, from free (open source) to expensive boutique (apple).
Fortunately, there's plenty of competition in the market and there are two valid alternatives that could be made to work if thats what you really want.
Large companies like MS and IBM dont generally collect patents so that they can stop other people from using or licensing them.
They collect them so that they have a weapon to use against other companies, both in offense and in defense.
There are so many nonsense patents out there that just about every product could be considered to be in infringement.
So if something comes up, and IBM says to Microsoft, you're using one of our patented ideas, you'll need to pay us. MS then comes back with, Oh but you're also using 20 of our patented concepts.
Let's negotiate a patent licensing agreement.
Whoever has the most or the best patents ends up being on the winning side of that dollar figure.
And until the patent law changes, businesses have no choice. If you dont have a patent warchest, then some other company that does have one will be able to bully you. It's a defense mechanism in that sense, and absolutely necessary for large companies like Microsoft.
I'm not saying its right or good, but in the current legal environment, it is necessary.
In the real world though not upgrading works well for an awful lot of orgs.
Does it have a cost, of course! Is it less of a cost than upgrading to the newer versions? For many orgs it must be, because thats the choice they make.
Note also that most businesses wouldnt have to upgrade when their computers die, as they dont get office with their computer, so that doesnt end up being a real issue in the real world, and only affects home users and the very smallest of businesses.
My point is that people rant and rave and alot of hand waving about the 'forced upgrade' or 'upgrade treadmill', but it doesnt in fact exist.
Many, many orgs are still using Office 2000 or older, and they're doing just fine. Office 2007 has been out for 1.5 years, and the vast majority of orgs arent using it yet.
Just because there is a nonzero cost with not upgrading doesnt mean you're forced. Thats just life, where everything has a cost, even if its only an opportunity cost. There is no free lunch though.
Even if everyone used OO with ODF, there's a cost to upgrade to newer versions of OO (ie, labor, management, etc). So I guarantee you that even in that scenario many orgs would be several versions behind, and suffering the same costs as you describe.
In the real world out there it just doesnt end up as painful as you describe. It's just another cost/benefit analysis and choice that all businesses end up having to make about everything.
... and that's a load of apologist nonsense. It's not a working standard even in the "transitional" sense and does not deserve ISO approval. I'm not sure what you're reading into that sentence you quoted. It's a fairly simple factual statement. I'm not sure what about it is 'apologist nonsense'. Since the transitional version of the ISO OOXML is almost exactly the same as what Office 2007 emits, it will be very easy to get Office inline. Thats a pretty straightforward concept.
If M$ cared about playing nice, they would have devoted their effort to ODF translators for their legacy binary formats and continued along with those formats. Microsoft's "separate purpose" of OOXML is better suited by them continuing along legacy lines. The purpose of anywhere implementable formatting is best done with ODF. I'm not sure what you mean by 'playing nice', but the idea that they should have just moved immediately to ODF is nonsense. The two formats are not isomorphic. Specifically the MS formats have a ton more features that just dont exist in ODF, and many that are implemented in completely different ways (equations, vector graphics, etc). And in any case, no one uses ODF. If you were to send ODF documents to people nowadays, the vast vast majority wouldnt be able to open them or have a clue what they were.
It would make no sense whatsoever for a business to dumb down their products to fit into ODF. Maybe one with a brand new Office suite, that doesnt have 10-15 years of features (and quirks and bugs) floating around. And it wouldnt serve their customers, except possibly in the very long run, and even that is a gamble.
M$ moved along with OOXML because the rest of the world figured out their binary formats. They don't want to use ODF for the same reason their browsers consistently fail simple W3C format tests - Thats a very questionable statement about why they moved off binary formats. I'm sure both their customers and their internal developers have been clamoring for years to do so, and they finally did.
They dont want to use ODF because it makes zero business sense for them to do so. It doesnt have to be made any more complicated than that.
they don't want to play nice, they want to continue their obscene late 80's format game. Their actions speak a different story.
OOXML is in the hands of ISO, and has already evolved to be different from what MS Office 2007 emits.
Both the OOXML and the binary versions have publicly available documentation now.
Yes, they're complicated. But despite what the M$-is-teh-devil crowd will tell you, its because they are complicated. They are basically a snapshot of the internal memory representation inside the office apps. They have evolved over 10-15 years to what they are now. There is going to naturally be alot of cruft and bloat. This should not have come as a surprise to anyone.
Both from a business and engineering standpoint, it would have been a monumentally huge task to try to convert Office to emit ODF natively. And it would have had very little return on the investment.
Slashdot Mirror
The malware authors could have trivially used INFORMATION_SCHEMA views rather than sysobjects, and this would have been a generic attack that would have worked against most mainstream db servers. while the flaw may not be MSFT's sole fault how could 500,00 people setup a server wrong including the DHS? This has nothing, zero, to do with server setup or configuration. This is purely and soley, only has to do with web app developers allowing uncleansed commands to be sent from a web-browser to the underlying db server.
Again, the ONLY reason this only works on MS-SQL is because the malware authors made a choice to write the attack in non-portable syntax. They could have done so, but they chose not to.
That is incorrect.
Only Microsoft servers are affected by this specific attack.
Nearly every language and/or platform in existence right now is capable of being hit by this type of automated attack.
Nearly every mainstream DB server allows things like INFORMATION_SCHEMA or similar metadata to be accessed in this way to generically hit all tables in a db/schema.
Every single web-based language that I've ever seen is quite capable (trivial even) to create sql-injection vulnerable pages.
Assuming a user runs as non-admin, how would you like something like this to work?
... then you've had to deal with non-admin users, and services, and system tray icons talking to back-end services, etc.
Because I'm unclear on what you're meaning. If you've been in this industry and done this work
Can you talk about how you think it should work? Technical detail would be great.
Likewise, this is what I do for a living (or at least one of the things) and I own a business doing it as well.
You're trying to do something you dont have the privs to do, so you're being prompted to either allow (admin-approve mode) or asked for credentials that can.
This is ultra basic simple stuff.
You should not be, under normal circumstances, be triggering UAC prompts. If you are, then you've either:
1. Using the file system in a way that catches you on the default ACLS. So change the ACLS. Normal 90% use-case users wouldnt ever trip over this.
2. Using software that assumes local admin privs.
It sounds like your issue is #1. You are often trying to write or modify files in directories that are SPECIFICALLY CONFIGURED TO STOP YOU FROM DOING THAT. Given that they are specifically configure to stop you from doing that, then it is absolutely correct that UAC is spawning.
If the default ACLs dont work for you, and you want to be able to do things like that, then for *(*&D's sake, change the damn ACLs.
You sound like a little kid who keeps running into the door and bloodying his nose, but who keeps crying about how the door doesnt really keep him inside, its just theatre. Well then just open the damn door, and quit beating your face against it. Typically only one person uses a machine and has installed all the software. Occassionally there is a genuine multi-user environment on a home PC, and more commonly some work machines are shared, but for the most part this is computer security theatre at it's finest. In the home-user scenario only one person typically uses the machine (or one login, to be more specific).
But that person should _never_ be the admin on the box. Running your day to day desktop as admin is just being silly. I can definitely see running as no-prompt admin on servers or other machines where your only role is sa tasks.
But running a desktop as admin is not smart. At least not if you ever use a web-browser on it or an email client. Even in Firefox, Safari, and IE there are drive-by exploits available at various times. And if you're running as admin, you just got owned. It's not that I don't care about security, it's that for practical everyday operation on a single user machine, constant prompts or use of pseudo is nonsense. (I assume you mean sudo, not pseudo there)
I'll try saying this one more time.
If you are getting hit with constant UAC elevation requests in your regular day to day work then:
1. Your machine is misconfigured for your particular use of it. If you're constantly tripping over file ACLs in explorer, then change the file ACLs. Tune the box to your use, rather than bitch and whine about UAC doing what its supposed to be doing.
2. You are using apps that are problematic.
The second can be harder to deal with, but it sounds like the first is what you're encountering.
Understand that this means that you are not using your machine in the typical role for which they configure the default ACLs.
So assuming you're not doing something stupid, like constantly tweaking files in All User profile, Program Files, or anything under \Windows, then just change the ACLs to suit your use. If you are doing one of those bad things, then create yourself a separate directory off the root of C: drive, call it dev or something, and then set the ACLs on that so that you have change or full privs.
Then you'll never be bothered by UAC again, and you can leave it on to let it do its job.
Bah. Basic IPC and RPC code is fairly straightforward on windows.
.net remoting or com+ registration, as the other very knowledgeable guy mentioned.
What was hard for these guys was:
1. It was more than they were doing before, so therefore worse from their point of view.
2. They had never done this sort of coding before on windows, so it was their first time, and they were learning, therefore it took longer than it should have under normal circumstances.
3. They obviously didnt understand the need for proper separation of systems, so they viewed the whole thing as a waste of time.
Plus there are other ways to do what they wanted to do that they didnt even try. A couple off the top of my head:
- the scheduler based approach that someone else mentioned.
-
- moving the boot-loader mod logic to a separate executable from the system-tray app, and when a change needs to be made, have the system-tray app launch a new process on the executable, and request elevation when it does.
Until you've written IPC or RPC code on windows, you shouldnt be going around saying how bad it is. You're massively inferring from a third party, who is obviously not very knowledgeable or experienced on the platform.
I am fairly sure that they did nothing like an on-demand systray icon/app. Based on TFA's discussion, I'm fairly sure it was a standard GUI app written to display in the system tray, nothing more.
It was clearly running on user login, not on computer start, based on TFA. Otherwise, they would have already known how to do services or headless apps through scheduler. But, let's just presume, for the moment, that iReboot is a GUI app but it's run on user login, not system startup. Now, if a user is an Administrator, should the GUI app be able to elevate itself to SYSTEM user? The GUI app wouldnt need to elevate to system, if the person is an Adminstrators group, then thats enough perms. It can just run as-is (until/unless UAC gets involved, depending on how the machine is configured). Wouldn't UAC be there to prevent that because pop-ups would be annoying each login and actually allowing apps to promote themselves would potentially defeat UAC entirely? UAC would be there to verify that the person wanted the process to elevate, not necessarily to prevent. I'm not sure what you mean by 'defeat UAC entirely'. If an app needs elevation and the user allows it, then that is how its supposed to work. Thats in no way 'defeating UAC entirely'.
Even in the incredibly lame case of an app starting every time the user logs in and prompting for elevation. Thats a lame scenario, but its not 'defeating UAC entirely', its just using it in a fairly stupid way. Perhaps *the* blocking of HKCU/.../Run apps to run as SYSTEM is what iReboot is complaining about? Yeah, someone in the parent to this discussion got a little registry path happy.
The bottom line is that the way that NeoSmart was trying to do things was a pretty terrible way. It goes against all the guidance on the platform, and its poorly thought out.
There are other alternatives to what they did as well. They could have had the system-tray app run as the desktop user, and start on desktop user login.
Then when you want to modify the boot-loader, it launches a separate executable with a new process and requests elevation. The executable makes its modifications to the bootloader, and quits.
Then the UAC prompt would only launch when actual changes were being made to the boot loader. The idea of having a system tray app running as system is just
The system tray icon is just a gui element. It should be doing nothing except presenting visual information and interacting with the user. The heavy lifting should be somewhere else.
If you're copying the file into a place that you dont have permissions to (ie, C:\program files\ or the all users part of the desktop or start menu), then you will get a UAC prompt.
And that is correct behavior.
And thats the way every mainstream OS works (though some just silently fail, rather than prompting for elevation).
Try copying files into
On the other hand, if you're concerned that you're running as admin but dont want UAC prompts, then just configure the OS to operate that way.
Of course, an application that starts when the computer starts, and has no GUI, is
And what did neosmart do to make this work? They moved the priv-requiring components into a service.
This is so pathetically non-news, based off raw ignorance of the windows platform, its just sad.
UAC doesnt generate false positives. Zero.
If an app tries to do something that a non-priv'd user doesnt have rights to do, UAC will be triggered. This is correct behavior.
It sounds like most of your software is just written incorrectly for the platform.
How about instead of bitching at MS for finally doing the right thing and not letting lazy ISVs get away with bad programming, how about you go back to your software vendors and tell them to learn how to develop correctly for the platform.
The NeoSmart folks just were being lazy and assuming everyone was an admin, and that someone was always logged into the OS.
It's easy to do things sloppy and incorrectly, and can often be done faster and with fewer LoC.
Doing things right often takes more work. This should not come as a surprise to anyone.
The article was lame.
The NeoSmart folks (with all due respect) appear to be rank amateurs when it comes to software.
That whole problem they ran into is a total rookie mistake. They should have gone beyond requiring the user to run as admin years and years ago.
The fact that they had to actually take the time to *gasp* do things right is a good thing. Their posting just really exposes the inexperience and ignorance of developers on the platform.
It's not an HTTP server.
It's basically a parser and message passer that runs as a kernel component. This was done primarily to have the fastest possible access to the network stack.
It's a very small amount of code. Cant remember the approx LoC, but when I saw the post way back when that this first came out, I was amazed how small that component is.
Comparatively, IIS (which IS a web/http server, amongst other things) is huge, and has no need to run as admins.
Jaime2 below answered most of your post.
Also, be aware that the 'services running as local system' problem is _precisely_ why NetworkService and LocalService was created.
It's also why nearly all competent windows sa types create separate, non-priv'd accounts for each separate service they install.
You do realize that this is exactly how windows works, right?
I have java & ruby installs on my machine (running as a non-admin) configured in the same manner as you, and I can configure them independently of stuff installed at the system level.
Thank you!
This is exactly and precisely correct.
I tried to say the same thing a little bit above, but I think you expressed it better.
I'd mod you up if I hadnt already posted.
NT was designed from the start as a multi-user system. It's never been anything but.
You may be confusing the 9x line of operating systems, which was unrelated to what we're using today. I not only have applications but also user specific applications stuff that only I can run, and stuff that only I can see. Yeah, you can trivially do this on windows as well.
The only qualification is that the application has to be designed to support it (ie, not rely on any registry information outside of HKCU).
These are commonly known as 'green' apps. I have a number of apps like this installed on my box. FileZilla, micro torrent, 7-zip, putty, eclipse, paint.net, etc etc etc. You shouldn't have to be an admin to install a web browser, word processor , or spreadsheet. You dont, as long as the app developer has written the app in such a way as to support this. This isnt a windows issue, its an app developer issue. You should only be an admin if your installing it for everyone. Yep, thats exactly how it works, and always has (in the NT line).
Overall, I think you're confusing standard practice with inherent ability.
It's not standard practice to have per-user apps installed on windows, but the capability is surely there, and its trival to do, if the app developer supports it.
On OSX and most unices, its BOTH standard practice and inherently capable to do so.
Well sure. Thats almost always the case, regardless of platform.
Doing something sloppy and wrong is often easier and less time consuming than doing things right.
This article is just that case.
NeoSmart was getting a free ride by being bad developers, and assuming that everyone was running as admin, and that someone would always be logged into the box.
Now they're being forced to learn how to program correctly, and do things right, and yep, it takes more lines of code.
Doing things the right way almost always does, but you end up with a better product in the end.
That would only affect the BIOS post time for the mainboard though, right?
You've still got SCSI card bios startups, RAID card bios startups, RAC/ILO/BMC bios startups, etc.
Those each take at least 3-4 seconds in my experience, and most servers have a few.
Looks beautiful in Opera 9.27, at various zoom levels.
It looks great in FireFox too, unzoomed.
If you're using zoom levels or nonstandard font sizes in FireFox, then thats a firefox problem, its never handled that well, while browsers like Opera handle it beautifully.
Use your freedom of choice to choose something other than Microsoft. There are several alternatives available, from free (open source) to expensive boutique (apple).
Fortunately, there's plenty of competition in the market and there are two valid alternatives that could be made to work if thats what you really want.
Large companies like MS and IBM dont generally collect patents so that they can stop other people from using or licensing them.
They collect them so that they have a weapon to use against other companies, both in offense and in defense.
There are so many nonsense patents out there that just about every product could be considered to be in infringement.
So if something comes up, and IBM says to Microsoft, you're using one of our patented ideas, you'll need to pay us. MS then comes back with, Oh but you're also using 20 of our patented concepts.
Let's negotiate a patent licensing agreement.
Whoever has the most or the best patents ends up being on the winning side of that dollar figure.
And until the patent law changes, businesses have no choice. If you dont have a patent warchest, then some other company that does have one will be able to bully you. It's a defense mechanism in that sense, and absolutely necessary for large companies like Microsoft.
I'm not saying its right or good, but in the current legal environment, it is necessary.
In the real world though not upgrading works well for an awful lot of orgs.
Does it have a cost, of course! Is it less of a cost than upgrading to the newer versions? For many orgs it must be, because thats the choice they make.
Note also that most businesses wouldnt have to upgrade when their computers die, as they dont get office with their computer, so that doesnt end up being a real issue in the real world, and only affects home users and the very smallest of businesses.
My point is that people rant and rave and alot of hand waving about the 'forced upgrade' or 'upgrade treadmill', but it doesnt in fact exist.
Many, many orgs are still using Office 2000 or older, and they're doing just fine. Office 2007 has been out for 1.5 years, and the vast majority of orgs arent using it yet.
Just because there is a nonzero cost with not upgrading doesnt mean you're forced. Thats just life, where everything has a cost, even if its only an opportunity cost. There is no free lunch though.
Even if everyone used OO with ODF, there's a cost to upgrade to newer versions of OO (ie, labor, management, etc). So I guarantee you that even in that scenario many orgs would be several versions behind, and suffering the same costs as you describe.
In the real world out there it just doesnt end up as painful as you describe. It's just another cost/benefit analysis and choice that all businesses end up having to make about everything.
... and that's a load of apologist nonsense. It's not a working standard even in the "transitional" sense and does not deserve ISO approval. I'm not sure what you're reading into that sentence you quoted. It's a fairly simple factual statement. I'm not sure what about it is 'apologist nonsense'. Since the transitional version of the ISO OOXML is almost exactly the same as what Office 2007 emits, it will be very easy to get Office inline. Thats a pretty straightforward concept. If M$ cared about playing nice, they would have devoted their effort to ODF translators for their legacy binary formats and continued along with those formats. Microsoft's "separate purpose" of OOXML is better suited by them continuing along legacy lines. The purpose of anywhere implementable formatting is best done with ODF. I'm not sure what you mean by 'playing nice', but the idea that they should have just moved immediately to ODF is nonsense. The two formats are not isomorphic. Specifically the MS formats have a ton more features that just dont exist in ODF, and many that are implemented in completely different ways (equations, vector graphics, etc). And in any case, no one uses ODF. If you were to send ODF documents to people nowadays, the vast vast majority wouldnt be able to open them or have a clue what they were.It would make no sense whatsoever for a business to dumb down their products to fit into ODF. Maybe one with a brand new Office suite, that doesnt have 10-15 years of features (and quirks and bugs) floating around. And it wouldnt serve their customers, except possibly in the very long run, and even that is a gamble. M$ moved along with OOXML because the rest of the world figured out their binary formats. They don't want to use ODF for the same reason their browsers consistently fail simple W3C format tests - Thats a very questionable statement about why they moved off binary formats. I'm sure both their customers and their internal developers have been clamoring for years to do so, and they finally did.
They dont want to use ODF because it makes zero business sense for them to do so. It doesnt have to be made any more complicated than that. they don't want to play nice, they want to continue their obscene late 80's format game. Their actions speak a different story.
OOXML is in the hands of ISO, and has already evolved to be different from what MS Office 2007 emits.
Both the OOXML and the binary versions have publicly available documentation now.
Yes, they're complicated. But despite what the M$-is-teh-devil crowd will tell you, its because they are complicated. They are basically a snapshot of the internal memory representation inside the office apps. They have evolved over 10-15 years to what they are now. There is going to naturally be alot of cruft and bloat. This should not have come as a surprise to anyone.
Both from a business and engineering standpoint, it would have been a monumentally huge task to try to convert Office to emit ODF natively. And it would have had very little return on the investment.