Re: sick of Linux bias
From: Hairy One Kenobi (abuse_at_[127.0.0.1)
Date: Wed, 14 Jan 2004 00:50:34 -0000
"Steve" <firstname.lastname@example.org> wrote in message
> Hairy One Kenobi wrote:
> | "Steve" <email@example.com> wrote in message
> | news:%YFMb.62005$IF6.firstname.lastname@example.org...
> | Hmm. Now that's an interesting statement. I'll concede that NT4's
> | lets-run-graphics-through-the-kernel decision was, for want of a better
> | word, "dumb". OTOH, I can't agree with your assertation that Windows
> | have a number of different privileges available for general use. As I've
> | said before, I'd prefer a greater & more specific set (a la VMS), but
> | they're there if a programmer is willing to use 'em.
> Well it is true that at the software level ther are a number of
> privlages the operating system will honour. The underlying problem is
> the physical layout of memory. the *inx system has a particular segment
> of kernel memory, thats kernel land, the rest is for everything else,
> ala userland. Moreover, the kernel, running in memory that can only be
> accesed via uid=0, now this memory contains the execution stack and the
> instructions of underlying kernel procceses that will govern the
> enforcement of privlages. Therefore, by smashing a userland procces, you
> can not get root unless your exploting something running as root, or
> something suided to root. and to avoid that, you can mount entire
> volumes with nosuid options. Moreover, you can mount also with the
> noexec option if you need to as well. To further secure entire areas of
> your disk.
> However, in windows, all memory is potentially kernel memory. Because
> the kernel can mallac() itself new memory. because of this a stack smash
> of a userland app, gets you root. In effect. Which is why, with tihngs
> like MSrpc (which is suppose to be userland) when you smash the stack
> (which I think we should remind ourselves, no one thought to check the
> length of file name on that one), you get SYSTEM privlages, which the
> equivilent of root.
Ahem. One thing though - everything we've been talking about so far involves
system-level stuff which is already /running/ in kernal mode.
The point I was making is that you can't get there without /already/ having
compromised the box.
Yes, *nix does is differently. All I'm saying is that the ability to
take-down anything useful on the box (but leave the kernel running) is,
IMHO, not a lot different to handing the kernel itself a banana skin and
watching what happens..
I personally don't thing that "different" necessarily means better/worse,
just.. different. OTOH, I wouldn't be sorry is we went back to the same sort
of separation that existing in NT 3.0. But it ain't gonna happen ;o)
<big snip - interesting stuff & duly noted>
> | Yes, you can do text searches on *nix. And, yes, you can do registry
> | searches on Windows. And, yes, I'd like to see a better editor provided
> | out-of-the-box.. one with FindAll would be a start. OTOH, if I /really/
> | needed it more than once, I'd either download or write one.
> True, but in *inx the main benift is that because its text, it can be
> done via virtually any internet connection. Without having to have
> something like VNC or something.
True. OTOH, TS is built-in. Horses for courses, to some extend (and not
forgetting that you can make registry mods from the command line. Seem to
remember that you have to have the CD available for that one - it's been a
long time since I've needed to do anything like that..)
> | But for a memory upgrade, my web server could probably have matched
> that ;o)
> | The only downtime was for two or three seconds, when I upgraded the web
> | server itself (I don;t use IIS ;o)
> Interesting, what version of windows, What webserver? I've never seen a
> windows box stay up for 4 months before!
> And whats wrong with IIS? Didnt like your static HTML content being
> served out of kernel? Hehe :)
Win2000, and OC://WebConnect Pro.
It was originally running on an AMD box of some description (1700+ rings a
bell) PSU blew the mobo sometime in June (fortunately the same morning that
the replacement arrived in the post). Had run 24x7 for about a year, with
reboots "only" for patches deemed critical. An Intel box blew-up a couple of
weeks before - seems to be a bad batch of PSUs (although, touch wood, the
AMD 1900+ still seems happy with its lot, running on a spare PSU from a
The TA-1 that I'm currently using is also stable - I tend to wait for
patches to prove their stability on an internal box (the backup web
server/application server) - can't remember if I applied these at the same
time or earlier than the upgrade. I have a feeling that I only put in the
upgrade when I decided to patch.. can't say.
The upshot is, like anything else, unless you have a resource leak in the
somewhere, no changes = no problems.
> | You consider this /broken/ behaviour? Hmm. I guess that we'll have to
> | disagree on this one. I'd still like to see an unloading tool, though
> - - (it
> | would also boost uptime - the box may not be good for anything during a
> | software upgrade but, heck, the kernel's running so the box is /up/,
> | ;o)
> It is broken, you can not remove a file from the file system when it is
> in use. This is broken inode behavior in the NTFS file system. You
> should have be able to have something in memory, and remove it from
> disk. In windows you have the pagefile to swap out to if you run out of
> memory, and on linux a swap partion, so there is no reason to have to go
> back to the file in the file system. Moreover, the FileDescriptors
> should keep a refernce to the physical inodes even after the file entry
> has left the directory tree. The fact that you can not delete a file in
> use is the result of broken inode behavior in the inodes. (or the ntfs
> rip off of inodes.)
Actually, it's a rip-off of Files-11.
I guess that one man's "broken" is another man's "system integrity" ;o)
Don't worry, I remember all of this from the VMS vs. Unix crusades.. suffice
to say that we each have our opinion, and are likely to stick with it!
> | <Snip useful stuff about Gentoo. Must take a look at that.. thanks>
> Gentoo.org baby....gentoo.org