And unless you are running a version of Apache from 1984 (or a version for AIX on windows), it never required cygwin... NEVER! In which case it begs the question: what the hell kind of comparison are you trying to make by comparing a recent version of IIS to a version of Apache thats 10 years old?!!
I'm sorry I ever mentioned Cygwin. The version that wastes threads is the most recent release I could find: 2.0.52, from here. Also, I'm not comparing it to IIS or any other web server. I am comparing Apache's threading model, one that is efficent on UNIX to one that would be much more efficent on Windows.
If it's that simple then why doesn't everyone do it? Hmmm? Why aren't all programs optimized for that and enabled to run at a command line? You'd think everyone would want this right? Faster apps, better functionality.
The reason is that almost all software for Windows was written for the Win32 API, which is integrated hopelessly into the GUI. The alternative is to use NT's native API. Almost nothing is written for it because Microsoft's documentation of it is poor (there are several good third party sources, however) and almost all libraries depend on Win32. If even one library or one program needs Win32, the whole GUI needs to be loaded. Using only the native API is possible, but there is so little software that only uses ntdll, it usually isn't practical to exclude Win32. Most of Windows's own components even depend on Win32, but if you don't need them it isn't a problem; such as running Apache and nothing else. XP has maybe 10MB of user mode binaries that don't depend on Win32.
Apache doesn't need cygwin. Who the hell told you that? I run an install just fine without CYGWIN; you only need CYGWIN to use system calls. If you don't use them or find an alternate method or approach (which there are several), you don't need cygwin at all.:)
And Apache does not need 100 processes. I swear you Microsofties have some sweet crack over there that you guys are smoking to keep spitting out all this bullshit.
Regardless, it's still faster and more stable on Windows than IIS anyday:)
No, you're right. Apache doesn't require Cygwin. Sorry. That's just the version I had laying around.
I never said that Apache required 100 processes. I said that it requires 100 threads to support 100 potental connections, even if nobody is connected. Did you even read the docs I quoted? On a fresh install of Apache 2.0.52 for Windows, it wants to have 250 threads by default. That's ridiculous. I start Apache, and sure enough: it has 252 threads sitting idle for no reason. Surely Apache could create new threads on demand, up to a limit rather than allocating them prematurely? Having large quantites of threads scheduled in a round-robin order is not an optomized strategy in Windows, which is was the original point. Yes, I can turn the amount of threads down, but that would leave clients with too many connections errors if I set it any lower than peak usage.
Who said anything about IIS? This is about software designed for UNIX not performing well on Windows because the architectures are different.
And just to make an additional point about memory availability.... do that control-alt-del again and take a look at physical memory and kernel memory, and look at total, available, paged, etc. Notice that the numbers are alot smaller than they should be? Go ahead. Take some time to do the math, I'll wait.
Task manager doesn't exactly have a super detailed memory report. The performance monitor is better. Available Bytes (free + zeroed + standby) 87187456 Resident kernel bytes (aka cache bytes, not to be confused with system cache) 19628032 Nonpaged kernel bytes 2404352 Total process working sets 21241856 Total process paged pools 220040 Total process nonpaged pools 274408 Total shared bytes 3261584 Total bytes accounted for 130956144 128MB = 130956144 bytes I don't see any missing memory.
The GUI is part of the Win32 subsystem. The subsystem server and video driver owns all the shared state for GUI apps. Since NT4, the Win32 subsystem server runs mostly in kernel mode from win32k.sys, so all of the GUI's memory is reflected as part of the kernel's paged pool. You can use the driver verfier's pool tracking hook to see how much memory win32k has allocated. Let's see here: win32k has 626952 paged and 6160 nonpaged bytes allocated. Can I run XF86 and a window manager with 630k of memory? ntfs.sys alone is using more than three times that.
You can't shut down the Windows in Windows my friend.
Actually, you can. The GUI is an optional environment subsystem. Unfortunately, the GUI is connected to Win32, and Apache depends on Win32. If Apache knew how to make native syscalls instead, it'd be no problem to run only Apache. Just rename it smss.exe:)
Malware can't install from a user account but it can remain in memory waiting for the opportunity.
That's bogus. Where could it possibly be hiding? All memory is contained in processes and the kernel. User processes can't write to kernel memory; there's no way for it to hide in there. NT always zeros newly allocated memory before giving it to a process, so it can't be hiding in freed memory. Winlogon kills all your processes when you log off, so that's not a usable hiding place. Processes have memory protection with ACLs guarding access to out-of-process writes, and normal users don't have permission to write to any processes that survive logoff. That doesn't leave anywhere for malware to be hiding. (short of a local vulnerability, in which case the machine is already owned)
Other than that, you're right: normal users can't infect the system.
PsExec can start a new process as admin with the password on the command line. SU/SUD is a more flexible program, including a setuid equivalent function. Also, SFU can launch Win32 processes as different users with su and can also do setuid.
I have a Windows 2000 workstation over here not doing anything at the moment. There are five processes, not including task manager to see what's running. Since Apache likes to make two processes, putting it on here would bring the total up to 7. All that's running is: The Session Manager (smss.exe): it's like the init process The Win32 subsystem server (csrss.exe): Apache would need this since cygwin uses Win32 Winlogon: so I can log on at the console The Service Control Manager, Event Log, and user mode plug+play services (services.exe): I guess I could disable these if I really wanted to, and use a different method to start and stop Apache, but they are pretty light weight. In total, they've committed 30MB of memory, and even without any memory pressure only 12MB of that is currently resident. If Apache needed that memory, what's left would be paged to disk. The only thing that can't be paged is memory in the kernel's non-paged pool, currently 2MB. This machine has 128MB, so 128-2=126 available for Apache, or anything else I decide to run. Yeah, I guess a stripped-down Linux could do a little better than this, but I consider this so low that it doesn't really matter. Cygwin will waste way more memory by not doing proper copy-on-write forks.
As for threads per child, this is ideal and is one of the reasons it IS faster! The faster you can spit out data, the less time the person will be on your system hogging resources. Would you prefer them to hang around on the system for a few seconds longer?
What does a thread per client vs non-blocking work item queue have to do with thread collection? Apache's so-called optomized design needs to have 100 threads laying around all the time if you ever expect that much peek usage. No wonder it wastes resources.
Extra processes running are extra processes running. In a windows environment, you cannot separate out certain processes that are unnecessary and they will always be running in the background.
Unnecessary processes? Like what? Besides, it doesn't even matter what processes are sitting around in the background if they aren't doing anything. By definition, they aren't using any CPU time and any memory will be paged out. These processes aren't affecting Apache, so how do they matter?
Apaches threads can be modded. The entire conf can be changed. If you think a default install is all there is to maintaining a server, I'll send you a ticket to reality so you can visit us sometime.
The amount of threads can be changed. For a heavy server, you still need a large quantity, since it represents the maximum number of concurrent connections. From the Apache 2.0 on Windows docs:
ThreadsPerChild: This directive is new. It tells the server how many threads it should use. This is the maximum number of connections the server can handle at once, so be sure to set this number high enough for your site if you get a lot of hits. The recommended default is ThreadsPerChild 50.
What can never be changed without a major rewrite is the inefficent one-thread-per-client service model that Apache uses. There's nothing in the conf files that can change this. Apache will always be slower on Windows as long as it uses a poor threading strategy for Windows. This works fine for UNIXes, but poorly on Windows, which was the original point: Apache and certain other ported UNIX software doesn't run as fast on Windows because they are designed for the wrong architecture. Windows software that used async work queues heavily would not run as well on a UNIX. The architectures are compatible enough, but optomization methods are quite different between them.
What does having a GUI idling in the background have to do with performance? It's not doing anything, so no cpu usage. It'll use a little memory for a while, until it's paged out. It's not like IP packets go through the user interface. Running an idle X server on the server will have no effect on the system's performance. Having an idle Win32 GUI server won't affect it either.
Apache's work distribution model is not well optomised for Windows. Apache creates a large amount of threads on startup, (at least 100 for a serious server) one for each potential client. This is a lot better than a seperate process per user, but when a lot of clients try to connect, this causes context thrashing. A better optomized design would take advantage of NT's asynchronus IO and work item model by creating a completion port queue for all IO and work operations with one thread per CPU that never blocks on anything in a single proc system (and only resource locks in a multiproc system). The threads are either using the CPU or waiting on all pending IO. Apache was designed to use the old UNIX process-per-client method, which translates into threads fairly easily. A unified work queue, which would be more efficent in Windows, would require a lot of changes.
Fossil fuel plants store some of their waste in the atmosphere. Can we put a coal power plant in your backyard? Coal also produces solid by-products; can we store that in your backyard too?
Both produce waste, but nuclear power produces far less waste per unit of energy. Both wastes need to be collected and stored properly or can cause pollution.
Comparing apples to apples, there is no way to run as a non-root user in windows, if you have access to the drive you have access pretty much, that is, you can't keep a user from running software that causes registry entries, and thus there is no security model, as the windows registry is pretty much the holy grail of owning the windows box.
You could run as a non-admin, non-root user since NT 3.1. Every registry key has its own ACL, with specific permissions. By default, normal users cannot write to keys for the system or access keys in the profiles of other users. I run my web browsers as the user "Internet". This user has its own profile, with its own registry section. It cannot write to things outside of its profile, registry or filesystem. The registry is not a magic doorway for local vulnerabilities.
I have the option of removing software with which there are known security issues but no patches available on an installed linux system, you have that option as well, as long as there isn't a microsoft line of bs about it being an integral part of the OS.
Not having a supported way to remove components (other than XP embedded, where everything is optional) is a problem. The marketing crap about these things being an indespensible part of the Windows Expierence (R) is annoying. Still, like you said, you don't have to use those components. Either that or mitigate the risk by not running it as admin, at least. Viruses and other malware can't affect other users without admin privileges.
Unless I was a the stupid user, doing something stupid by running windows updates and downloading hardware drivers, there was no stupid user intervention on this install.
You ran a web browser as admin. Wouldn't that be considered stupid on UNIX? The computer wouldn't be infected if you hadn't done this. I never run IE, or any other browser for that matter, as admin. I think that Microsoft makes it too easy to be an idiot on Windows, but that's where user responsibility comes in. Nobody's making you keep the defaults. Nobody's making you log on as admin: that's what RunAs is for. It's the user's fault if they don't know how to secure the machine properly.
Sitting far away across the Internet, I am better equipped to determine than anyone trusting in the security of an unpatched windows box with no anti-virus protection of the status of that box, if he believes he's "clean as a whistle".
Better equipped than anyone? Isn't that a bit presumptuous? Just what is it about Windows that makes it impossible to secure? It has protected memory, user identification, ACLs on all objects from files to events to threads, priveleges... what's missing? What makes you so sure that every Windows computer must be infected, so that it's normal to need scanners to clean it up?
Blaming the user seems to be the windows model of security, but I find this to only be reasonable if you agree that windows is insecure if you "USE" it, and thus all the problems are the "USE"rs fault.
I use Windows every day. I don't need any scanners because I don't get infected in the first place. I use proper privelege seperation; I don't log on as admin, things that require admin get it on a case by case basis. I use Software Restriction Policies to blacklist the profiles of restricted user accounts. It's like mounting their home directories as noexec.
I tend to believe that I know what I am doing and I don't find Windows to be "perfectly" anything, paticularly usable.
You're practically admitting that you don't know what you are doing. You don't even know about registry security. You apparently run everything as admin. If you are willfully
Ehm, you forgot about spy-ware, which seems to be able to install on your machine without any intervention.
We need a new operating system that operates on a higher level (e.g. don't let programs install/deinstall themselves) to get rid of those problems.
On Linux, you can mount directories writable by normal users as noexec. Files can't be executed from the only places they can make files.
On Windows, if you want to control all the binaries allowed to execute, see the execute permission and Software Restriction Policies; anyone can create files as usual but they can only be executed if they are on the whitelist and not on the blacklist, identified by path or hash. Not running as admin all the time also goes a long way.
Virus scanners and other malware removal tools try to clean up infections. Infections aren't always removable, and in the mean time they get to do whatever they want with your computer. A scanner would be unable to stop malware from deleting all your files; by the time the scanner gets involved, it's already too late. It's much better to avoid getting infected in the first place, and yes, infection is very much preventable without sacraficing usability. Even on Windows.
What OS are you running? How can you be sure it isn't infected? Is the OS too obscure for popular malware, and so security from obscurity? It is because you don't run as root normally and have proper privileges set up? The same is possible on Windows. Perhaps because you're up-to-date on your patches? Just as doable on Windows.
Maybe not being a moron to you is cutting the cable on your internet connection, but outside of that, your windows box is infected, period.
Infected or unplugged. Are those really the only choices?
I have seen clean windows 2000 installs with thier browsers hijacked, after all available updates were run before 4 manufacturers sites were reached to download drivers.
And how, prey tell, did the hijacking occur? I'm sure it's possible, but that possibility would have to be opened up by the user's negligence.
Maybe I'm a moron too, but I don't think so, I think you are simply unaware that your "clean as a whistle" pc is 0wned.
You, sitting far away across the Internet, are better equipped to detirmine that than the user sitting right in front of the computer? How could you possibly know if the machine is infected or not?
You've seen stupid users trash their Windows machines before. This does not mean that all users are idiots or that all Windows machines are trashed. Windows is perfectly usable if you know what you are doing.
You know, the Linux executable file format and syscall interface have been stable enough since version 1.0 that you can still run binaries for Linux 1.0 in 2.6.
Win 3.1 and DOS compatibility is provided by a VM with its own libraries and code. NTVDM is just a program that provides the legacy interfaces; other than the special controls for putting the CPU into V86 mode, the environment has exactly the same privileges as any other application. You can remove NTVDM at your leisure, therby breaking any compatibility and removing all the old code. NT doesn't have any code from DOS, Win3.1 or 9x in the underlying OS. NTVDM for DOS/Win3.1 on NT is like Carbon for MacOS 9 on OSX. The 64 bit CPUs that NT supports don't have a V86 mode anymore; NTVDM isn't supported, so DOS/Win3.1 compatibility is broken.
Apparently the message isn't getting through. Here's a repost of a comment I made before:
with the IE api hooks into the kernel
What are you talking about? Internet explorer is a 100% user mode shell environment. It is not, has never been, and never will be integrated into the kernel, or given special hooks or privileges. All of the entry points into the kernel are exported by ntdll.dll. Tell me which of those functions hooks IE into the kernel. The objects you would need to control to take over the system are kernel objects which IE plays no part in managing. Since the Win32 server moved into kernel mode (in NT4), it has its own system function table, and none of those functions are a part of IE either.
Show me ONE malware program that can install itself for all users when only a normal user runs it.
While Unix type systems where designed for multiuser access from the start, Dos and Windows where designed for single user systems.
DOS, DOS/Windows 3.1 and Windows 9x are single user with no security. Windows NT, not based on 9x or DOS, was multiuser and had security from the very first version, by design. All kernel objects, from files to events to threads have an ACL that controls access. Each process has a token that identifies which user it is running as. Multiple users can be using the system at the same time, each protected from interfering with each other. Remote Win32 GUI sessions require an add-on (Terminal Services or MetaFrame), but users can use other protocols, such as SSH, to connect without limitation.
...it is far easier to maintain security, since only root can do real damage on a system level.
Although NT has no exact equivalent to root, the system's design prevents you from doing any damage to the system or other users as a normal user. You'd need a vulnerability in implementation to compromise the system, just like on a UNIX.
Add to Microsofts single user workstation design the unbelievably brain dead idea of executing scripts when you only look at your mail in preview mode and directly executable scripts/execs as email attachements.
I agree with you about OE. The shell that is a part of IE4, which OE is built on, is a security nightmare. You can either not use it or run it as a different user. I tend to not use it.
Those design flaws are so gross, that it's almost impossible to patch such a system.
There's nothing wrong with the underlying system. It's not hard to use it to sandbox insecure parts of the shell.
There are cheapo and older touchpads that are pressure sensitive. It's called "resistive technology". They aren't used much on laptops anymore, but they still exist. Some types of monitor overlay pads use pressure.
I can see how saying that would be redudant, but I just wanted to add some detail. Capacitance sensing really is much better than pressure; I wanted to make it clear that there was a difference.
I actually like the touchpad in my HP laptop. It's a good Synaptics pad which uses capacitance instead of pressure. The control panel has lots of knobs, including adjustable palm check which nicely prevents movement while typing. Theres also stuff like tap zones: I have it set for tap in the upper right corner for a right click, or in the upper left for maximize. I always tap; I never use the buttons. There's even a GPL'd driver for XOrg and XF86 that has all the features.
After a little practice, I can use it just as well as a mouse for controlling a cursor. It does suck for FPSes, though.
2. So they can release patches and content quickly and effectively - or did you enjoy having to go out and download a 50+ MB patch from one of fifty mirrors at 2kb/s?
Yeah, that's about the right speed. Steam isn't a magic bandwidth machine. It'll be just as slow from steam as a ftp mirror.
It took 8 hours to download some patch that fixed a stuttering problem I wasn't even having, caused by a previous patch (one I didn't want either), all of which are mandatory to play, even in single player mode. I just wanted to play the fucking game I recently spent $50 on, but dearest Valve decided that I wasn't worthy. OH, and offline mode is br0rk3n
And when 90%+ of the Windows machines in the field are NOT managed that way, no, that isn't a matter of user incompetence.
Competence is not a deomcracy. The amount of people who are or are not competent has no effect on any single person being competent. What matters is being able to actually know what you are doing when you use something.
I never said that Windows was easy to set up correctly, or that it was appropriate for the average stupid user. It's not. This doesn't mean that the system is hopelessly broken or unusable. All the bad things you've mentioned about Windows so far are poor defaults, not design flaws. Defaults can be changed. Design flaws are unfixable without a major overhaul. I submit that the kernel and system are well designed. The shell has some ugly stuff, but nothing that can't be sandboxed or replaced if really necessary.
1. What do you want them to do? Wait until the software is provably correct? It's not like they ship it with known flaws. 2. I have a problem with this too. Still, it's just the default and can be changed. Also, Server2003 and XP SP2 are better about this (finally). Back in the old days, NT 3.51 had all that stuff optional. 3,4. Windows doesn't need extra virus or spyware protection if you know what you are doing. Still, MS markets to the general public, so there are people who need this to try and compensate for being unable to use the OS properly.
If the users have to be experts in order to use the system correctly, so be it. Do you really expect stupid users to be able to properly admin a UNIX box if they can't handle Windows?
The system defaults need to be secure enough for the way the average user will use the system.
Need? The defaults can be just about anything as long as they can be changed and as long as the audience consists of competent individuals. Secure defaults... like the everything-runs-as-root policy that Linspire has?
Remember this, the computer is there to make your job easier. Not to give you something else to worry about. Not to give you something else to become an expert at.
That's what I tell myself when I'm pulling my hair out over something that should be trivial on my debian box. I feel like I have to be an expert with it to get it to do many of the things I want it to. Still, that's half the fun sometimes.
And the corollary to that is:
Competent users leave Windows and move to Linux.
If you mean that a user that is competent to run Linux but not Windows should use Linux, then yes. The reverse is also true. A user that is competent to use both has a choice.
If by "incompetent" you mean "does not update a 3rd party app to kill viruses the the original software does not try to prevent", then you could be correct.
No, that has nothing to do with competence. Anti-virus and anti-spyware programs are band-aids after the fact. They exist to help incompetent users fix things after the fact; the point is to avoid infection. Competent users prevent the machine from becoming infected in the first place, making such tools unnecessary.
Outlook used to automatically run certain executables sent to it.
Outlook (Express) used to have some poor defaults. So? A competent user wouldn't blindly accept the defaults, but instead configure it properly. It has always been possible to disable this behavior. As if there have never been Linux distros with poor defaults.
But that leaves a LOT of machines out there that are infected because of Microsoft's decisions and will remain infected.
How would this be different than saying that a lot of rooted Linux boxes will remain rooted? What decisions has Microsoft made that would prevent me from cleaning up a machine? Besides, a competent user wouldn't leave their machine infected, assuming it even got to that point.
The security system is what prevents a minor flaw from compromising the whole system.
Windows USED to run services that the average home user would never use and it ran them as the system account and it ran them with access to everything else.
So, a flaw in DCOM resulted in your entire machine being compromised.
That is the difference between a good security model running an app with a hole and...
a bad security model running an app with a hole.
[I know <br> tags are fun and all, but do you really need two for every ~115 chars?]
Windows NT has a security system that does the same thing. How is it different? Or are you referring to poor defaults, and improper use? Kind of like the case where a certain distro *cough Redhat* used to run sendmail as root by default? Those don't have anything to do with the security system; these are problems with how it is used.
Running named in a chroot jail is an example. One flaw in one system will not result in a 100% compromised machine.
NT has no problems providing chroot in its POSIX subsystem. It's generally not needed, as NT provides a lot more privelege granularity than standard UNIX. Even better is to not give the process access to anything unnecessary, making the chroot redundant.
Sure you can. Just make the default install (stupid people always take the default, right) as secure as possible.
There's no limit to how secure a system can be, but I agree that the defaults could be better. For a user who knows what they are doing, this isn't an issue. There also isn't any limit to user stupidity; some people have sufficent levels to overcome any amount of protection.
And their recent decisions to NOT offer patches to "illegal" machines is also a problem. If they make it harder for people to get patches, more people will be running unpatched machines.
This has been threatened before, namely with XP SP2. Worst case, those people will be able to get the patches from the same place they got the original software. I think they should let everyone have the patches too.
*About Redhat and sendmail: yes, this was quite a while ago. The point is, the security system can't prevent a app flaw from becoming a system flaw if you don't use it correctly, and both OSes have been guilty of this.
Re:But what about Debian/NT?
on
Microsoft in 2008
·
· Score: 3, Interesting
That's why SFU isn't built on top of Win32, but the kernel's native API, which does fork() just fine. So does SFU; it uses the native API. The NT kernel was designed from the beginning to support different environments, including POSIX and Win32. Each environment subsystem consists of a server process that maintains common state specific to the environment, and a set of client libraries that translate the environment's API to the native API and calls to the server. Win32 is an environment subsystem and so is SFU.
For some reason, cygwin (which debian-win32 uses) insists on using only Win32, so they have to resort to kludges to make certain things like fork() work. Now that SFU is free, I don't see why debian-win32 couldn't use that instead of cygwin.
As it stands, Interop Systems has the best collection of packages for SFU. Most of the essential stuff is there, but it's still a far cry from Debian's library.
I've got a Athlon 2800, 64MB GF3Ti200 and 1GB of ram, Doom3 at 800x600 on medium gets 30fps consistently. I have to play HL2 on low at 800x600 to get the same framerate. Doom3 is also a lot more consistent in its rate; it stays at about 30 all the time whereas HL2 goes up and down a lot. I have to keep HL2 on low to help deal with the spikes. On low, Doom3's graphics look better than HL2 on low.
I never said that Apache required 100 processes. I said that it requires 100 threads to support 100 potental connections, even if nobody is connected. Did you even read the docs I quoted? On a fresh install of Apache 2.0.52 for Windows, it wants to have 250 threads by default. That's ridiculous. I start Apache, and sure enough: it has 252 threads sitting idle for no reason. Surely Apache could create new threads on demand, up to a limit rather than allocating them prematurely? Having large quantites of threads scheduled in a round-robin order is not an optomized strategy in Windows, which is was the original point. Yes, I can turn the amount of threads down, but that would leave clients with too many connections errors if I set it any lower than peak usage.
Who said anything about IIS? This is about software designed for UNIX not performing well on Windows because the architectures are different.Task manager doesn't exactly have a super detailed memory report. The performance monitor is better.
Available Bytes (free + zeroed + standby) 87187456
Resident kernel bytes (aka cache bytes, not to be confused with system cache) 19628032
Nonpaged kernel bytes 2404352
Total process working sets 21241856
Total process paged pools 220040
Total process nonpaged pools 274408
Total shared bytes 3261584
Total bytes accounted for 130956144
128MB = 130956144 bytes
I don't see any missing memory.
The GUI is part of the Win32 subsystem. The subsystem server and video driver owns all the shared state for GUI apps. Since NT4, the Win32 subsystem server runs mostly in kernel mode from win32k.sys, so all of the GUI's memory is reflected as part of the kernel's paged pool. You can use the driver verfier's pool tracking hook to see how much memory win32k has allocated. Let's see here: win32k has 626952 paged and 6160 nonpaged bytes allocated. Can I run XF86 and a window manager with 630k of memory? ntfs.sys alone is using more than three times that.Actually, you can. The GUI is an optional environment subsystem. Unfortunately, the GUI is connected to Win32, and Apache depends on Win32. If Apache knew how to make native syscalls instead, it'd be no problem to run only Apache. Just rename it smss.exe
User processes can't write to kernel memory; there's no way for it to hide in there.
NT always zeros newly allocated memory before giving it to a process, so it can't be hiding in freed memory.
Winlogon kills all your processes when you log off, so that's not a usable hiding place.
Processes have memory protection with ACLs guarding access to out-of-process writes, and normal users don't have permission to write to any processes that survive logoff.
That doesn't leave anywhere for malware to be hiding. (short of a local vulnerability, in which case the machine is already owned)
Other than that, you're right: normal users can't infect the system.
PsExec can start a new process as admin with the password on the command line.
SU/SUD is a more flexible program, including a setuid equivalent function.
Also, SFU can launch Win32 processes as different users with su and can also do setuid.
The Session Manager (smss.exe): it's like the init process
The Win32 subsystem server (csrss.exe): Apache would need this since cygwin uses Win32
Winlogon: so I can log on at the console
The Service Control Manager, Event Log, and user mode plug+play services (services.exe): I guess I could disable these if I really wanted to, and use a different method to start and stop Apache, but they are pretty light weight.
In total, they've committed 30MB of memory, and even without any memory pressure only 12MB of that is currently resident. If Apache needed that memory, what's left would be paged to disk. The only thing that can't be paged is memory in the kernel's non-paged pool, currently 2MB. This machine has 128MB, so 128-2=126 available for Apache, or anything else I decide to run.
Yeah, I guess a stripped-down Linux could do a little better than this, but I consider this so low that it doesn't really matter. Cygwin will waste way more memory by not doing proper copy-on-write forks.What does a thread per client vs non-blocking work item queue have to do with thread collection?
Apache's so-called optomized design needs to have 100 threads laying around all the time if you ever expect that much peek usage. No wonder it wastes resources.
Besides, it doesn't even matter what processes are sitting around in the background if they aren't doing anything. By definition, they aren't using any CPU time and any memory will be paged out. These processes aren't affecting Apache, so how do they matter?The amount of threads can be changed. For a heavy server, you still need a large quantity, since it represents the maximum number of concurrent connections. From the Apache 2.0 on Windows docs:What can never be changed without a major rewrite is the inefficent one-thread-per-client service model that Apache uses. There's nothing in the conf files that can change this. Apache will always be slower on Windows as long as it uses a poor threading strategy for Windows. This works fine for UNIXes, but poorly on Windows, which was the original point: Apache and certain other ported UNIX software doesn't run as fast on Windows because they are designed for the wrong architecture.
Windows software that used async work queues heavily would not run as well on a UNIX.
The architectures are compatible enough, but optomization methods are quite different between them.
What do you think this is? Open Office.org?
What does having a GUI idling in the background have to do with performance? It's not doing anything, so no cpu usage. It'll use a little memory for a while, until it's paged out. It's not like IP packets go through the user interface. Running an idle X server on the server will have no effect on the system's performance. Having an idle Win32 GUI server won't affect it either.
Apache's work distribution model is not well optomised for Windows. Apache creates a large amount of threads on startup, (at least 100 for a serious server) one for each potential client. This is a lot better than a seperate process per user, but when a lot of clients try to connect, this causes context thrashing.
A better optomized design would take advantage of NT's asynchronus IO and work item model by creating a completion port queue for all IO and work operations with one thread per CPU that never blocks on anything in a single proc system (and only resource locks in a multiproc system). The threads are either using the CPU or waiting on all pending IO.
Apache was designed to use the old UNIX process-per-client method, which translates into threads fairly easily. A unified work queue, which would be more efficent in Windows, would require a lot of changes.
Fossil fuel plants store some of their waste in the atmosphere. Can we put a coal power plant in your backyard? Coal also produces solid by-products; can we store that in your backyard too?
Both produce waste, but nuclear power produces far less waste per unit of energy. Both wastes need to be collected and stored properly or can cause pollution.
You could run as a non-admin, non-root user since NT 3.1. Every registry key has its own ACL, with specific permissions. By default, normal users cannot write to keys for the system or access keys in the profiles of other users. I run my web browsers as the user "Internet". This user has its own profile, with its own registry section. It cannot write to things outside of its profile, registry or filesystem. The registry is not a magic doorway for local vulnerabilities.
Not having a supported way to remove components (other than XP embedded, where everything is optional) is a problem. The marketing crap about these things being an indespensible part of the Windows Expierence (R) is annoying. Still, like you said, you don't have to use those components. Either that or mitigate the risk by not running it as admin, at least. Viruses and other malware can't affect other users without admin privileges.
You ran a web browser as admin. Wouldn't that be considered stupid on UNIX? The computer wouldn't be infected if you hadn't done this. I never run IE, or any other browser for that matter, as admin.
I think that Microsoft makes it too easy to be an idiot on Windows, but that's where user responsibility comes in. Nobody's making you keep the defaults. Nobody's making you log on as admin: that's what RunAs is for. It's the user's fault if they don't know how to secure the machine properly.
Better equipped than anyone? Isn't that a bit presumptuous?
Just what is it about Windows that makes it impossible to secure? It has protected memory, user identification, ACLs on all objects from files to events to threads, priveleges... what's missing? What makes you so sure that every Windows computer must be infected, so that it's normal to need scanners to clean it up?
I use Windows every day. I don't need any scanners because I don't get infected in the first place. I use proper privelege seperation; I don't log on as admin, things that require admin get it on a case by case basis. I use Software Restriction Policies to blacklist the profiles of restricted user accounts. It's like mounting their home directories as noexec.
You're practically admitting that you don't know what you are doing. You don't even know about registry security. You apparently run everything as admin. If you are willfully
On Windows, if you want to control all the binaries allowed to execute, see the execute permission and Software Restriction Policies; anyone can create files as usual but they can only be executed if they are on the whitelist and not on the blacklist, identified by path or hash. Not running as admin all the time also goes a long way.
Virus scanners and other malware removal tools try to clean up infections. Infections aren't always removable, and in the mean time they get to do whatever they want with your computer. A scanner would be unable to stop malware from deleting all your files; by the time the scanner gets involved, it's already too late.
It's much better to avoid getting infected in the first place, and yes, infection is very much preventable without sacraficing usability. Even on Windows.
It is because you don't run as root normally and have proper privileges set up? The same is possible on Windows.
Perhaps because you're up-to-date on your patches? Just as doable on Windows.Infected or unplugged. Are those really the only choices?And how, prey tell, did the hijacking occur? I'm sure it's possible, but that possibility would have to be opened up by the user's negligence.You, sitting far away across the Internet, are better equipped to detirmine that than the user sitting right in front of the computer? How could you possibly know if the machine is infected or not?
You've seen stupid users trash their Windows machines before. This does not mean that all users are idiots or that all Windows machines are trashed. Windows is perfectly usable if you know what you are doing.
You know, the Linux executable file format and syscall interface have been stable enough since version 1.0 that you can still run binaries for Linux 1.0 in 2.6.
Win 3.1 and DOS compatibility is provided by a VM with its own libraries and code. NTVDM is just a program that provides the legacy interfaces; other than the special controls for putting the CPU into V86 mode, the environment has exactly the same privileges as any other application. You can remove NTVDM at your leisure, therby breaking any compatibility and removing all the old code. NT doesn't have any code from DOS, Win3.1 or 9x in the underlying OS. NTVDM for DOS/Win3.1 on NT is like Carbon for MacOS 9 on OSX.
The 64 bit CPUs that NT supports don't have a V86 mode anymore; NTVDM isn't supported, so DOS/Win3.1 compatibility is broken.
The objects you would need to control to take over the system are kernel objects which IE plays no part in managing.
Since the Win32 server moved into kernel mode (in NT4), it has its own system function table, and none of those functions are a part of IE either.
Show me ONE malware program that can install itself for all users when only a normal user runs it.
According to the unit coversion in my HP48, one year has 365.242198781 days. Google agrees with that, albeit with less precision. So there :)
There are cheapo and older touchpads that are pressure sensitive. It's called "resistive technology". They aren't used much on laptops anymore, but they still exist. Some types of monitor overlay pads use pressure.
I can see how saying that would be redudant, but I just wanted to add some detail. Capacitance sensing really is much better than pressure; I wanted to make it clear that there was a difference.
I actually like the touchpad in my HP laptop. It's a good Synaptics pad which uses capacitance instead of pressure. The control panel has lots of knobs, including adjustable palm check which nicely prevents movement while typing. Theres also stuff like tap zones: I have it set for tap in the upper right corner for a right click, or in the upper left for maximize. I always tap; I never use the buttons. There's even a GPL'd driver for XOrg and XF86 that has all the features.
After a little practice, I can use it just as well as a mouse for controlling a cursor. It does suck for FPSes, though.
2. So they can release patches and content quickly and effectively - or did you enjoy having to go out and download a 50+ MB patch from one of fifty mirrors at 2kb/s?
Yeah, that's about the right speed. Steam isn't a magic bandwidth machine. It'll be just as slow from steam as a ftp mirror.
It took 8 hours to download some patch that fixed a stuttering problem I wasn't even having, caused by a previous patch (one I didn't want either), all of which are mandatory to play, even in single player mode. I just wanted to play the fucking game I recently spent $50 on, but dearest Valve decided that I wasn't worthy. OH, and offline mode is br0rk3n
I never said that Windows was easy to set up correctly, or that it was appropriate for the average stupid user. It's not.
This doesn't mean that the system is hopelessly broken or unusable.
All the bad things you've mentioned about Windows so far are poor defaults, not design flaws. Defaults can be changed. Design flaws are unfixable without a major overhaul.
I submit that the kernel and system are well designed. The shell has some ugly stuff, but nothing that can't be sandboxed or replaced if really necessary.
1. What do you want them to do? Wait until the software is provably correct? It's not like they ship it with known flaws.
2. I have a problem with this too. Still, it's just the default and can be changed. Also, Server2003 and XP SP2 are better about this (finally). Back in the old days, NT 3.51 had all that stuff optional.
3,4. Windows doesn't need extra virus or spyware protection if you know what you are doing. Still, MS markets to the general public, so there are people who need this to try and compensate for being unable to use the OS properly.
If the users have to be experts in order to use the system correctly, so be it. Do you really expect stupid users to be able to properly admin a UNIX box if they can't handle Windows?Need? The defaults can be just about anything as long as they can be changed and as long as the audience consists of competent individuals.
Secure defaults... like the everything-runs-as-root policy that Linspire has?That's what I tell myself when I'm pulling my hair out over something that should be trivial on my debian box. I feel like I have to be an expert with it to get it to do many of the things I want it to. Still, that's half the fun sometimes.
A user that is competent to use both has a choice.No, that has nothing to do with competence. Anti-virus and anti-spyware programs are band-aids after the fact. They exist to help incompetent users fix things after the fact; the point is to avoid infection. Competent users prevent the machine from becoming infected in the first place, making such tools unnecessary.Outlook (Express) used to have some poor defaults. So? A competent user wouldn't blindly accept the defaults, but instead configure it properly. It has always been possible to disable this behavior.
As if there have never been Linux distros with poor defaults.How would this be different than saying that a lot of rooted Linux boxes will remain rooted? What decisions has Microsoft made that would prevent me from cleaning up a machine? Besides, a competent user wouldn't leave their machine infected, assuming it even got to that point.[I know <br> tags are fun and all, but do you really need two for every ~115 chars?]
Windows NT has a security system that does the same thing. How is it different? Or are you referring to poor defaults, and improper use? Kind of like the case where a certain distro *cough Redhat* used to run sendmail as root by default? Those don't have anything to do with the security system; these are problems with how it is used. NT has no problems providing chroot in its POSIX subsystem. It's generally not needed, as NT provides a lot more privelege granularity than standard UNIX. Even better is to not give the process access to anything unnecessary, making the chroot redundant.There's no limit to how secure a system can be, but I agree that the defaults could be better. For a user who knows what they are doing, this isn't an issue.
There also isn't any limit to user stupidity; some people have sufficent levels to overcome any amount of protection.This has been threatened before, namely with XP SP2. Worst case, those people will be able to get the patches from the same place they got the original software.
I think they should let everyone have the patches too.
*About Redhat and sendmail: yes, this was quite a while ago. The point is, the security system can't prevent a app flaw from becoming a system flaw if you don't use it correctly, and both OSes have been guilty of this.
That's why SFU isn't built on top of Win32, but the kernel's native API, which does fork() just fine. So does SFU; it uses the native API.
The NT kernel was designed from the beginning to support different environments, including POSIX and Win32. Each environment subsystem consists of a server process that maintains common state specific to the environment, and a set of client libraries that translate the environment's API to the native API and calls to the server. Win32 is an environment subsystem and so is SFU.
For some reason, cygwin (which debian-win32 uses) insists on using only Win32, so they have to resort to kludges to make certain things like fork() work.
Now that SFU is free, I don't see why debian-win32 couldn't use that instead of cygwin.
As it stands, Interop Systems has the best collection of packages for SFU. Most of the essential stuff is there, but it's still a far cry from Debian's library.
I've got a Athlon 2800, 64MB GF3Ti200 and 1GB of ram, Doom3 at 800x600 on medium gets 30fps consistently. I have to play HL2 on low at 800x600 to get the same framerate. Doom3 is also a lot more consistent in its rate; it stays at about 30 all the time whereas HL2 goes up and down a lot. I have to keep HL2 on low to help deal with the spikes. On low, Doom3's graphics look better than HL2 on low.
What? My friends list is full of people ;)