To add to your comment, as coming from both your perspective (developer) and a Slackware users' perspective... As a software development major in college, I also like Slackware because, well, let's face it... a development box sometimes takes a beating. I need something reliable that if I accidentally blow something up, I know it will at least come back up to a working bash prompt. Also, I can't stand chasing down libraries and Slackware has just about every library under the sun already in the system. Finally, for testing, Slackware makes an awesome 'vanilla' base for a virtual machine. Every other distro that I've tried to use for making a generic testing machine base, has given me the option (in anaconda) to remove the packages I wouldn't be using, and then adds them back in during install to satisfy RPM dependencies. I should be able to take all the packages out of KDE so that I only have a desktop environment, and still have all my libraries installed.
I've worked as a sysadmin and software engineer with a UNIX specialization for seventeen years, and while I would agree that for most computer-illiterates Ubuntu is acceptable, for a professional Slack, Debian, or *BSD is the way.
Tell that to Linus (who uses Fedora last I heard, and SuSE before that). SuSE is derived from Slackware;). I think Linus is running Ubuntu or another Debian derived distro on his Mac, but he also distro hops a bit, IIRC.
Slackware was my first distro, and I can vouch for what you say; I learned more in my first week with Slackware, during which time I hosed my system about 3 times. Everyone laughs when I say that, but it's true. I always wondered why everyone thought that Linux was so 'fragile', as it took a pounding and then some for me to hose the thing. I later found out that you can't screw up a dozen compile and install cycles on most distros and expect them to keep running. I literally learned more about Linux during the install where I was dropped to a command line with the instruction 'use fdisk or cfdisk', than most people ever get on a modern distro.
At the time, I literally knew 'cd', 'ls', 'man', 'pine' and 'vi' from SSHing to a Solaris box for school - start with this tools, they're all you need to get started! Since I refused to look anything up online and didn't know that KDE existed (that was the coolest pleasant surprise ever!), I bumbled around the file system hierarchy for about three days trying to figure out how it worked, noticing the subtle nuances of the tree, trying to figure out where all my compiled programs installed to (I didn't know/usr/local,/usr and / were almost identical, it wasn't until I was looking for a library that I realized I kept tripping over different similarly looking trees) when I did 'make install'. Just that period of exposure as I got comfortable with Linux has really defined the difference between myself and most Linux users I know. Now, years later (I got Slackware-10.2 the week it came out... October or November three years ago), I run two Slackware boxes, a sabayon, BSD, and OSX at home, Redhat at work, and Solaris at school without ever having more troubles than remember which are BSD inits and which are SysV... just use/etc/rc.d/ and hit tab to find out;).
Fortunately Slackware has a GCC on board, and almost every library you could wish for. No one is stopping you from compiling it, using an RPM, or a deb, a slackscript, using makepkg and installpkg, a bitrock installer, yum, or apt. It's your OS; treat it as such.
How is slamd64? I run Slackware on my 32 bit server, and BlueWhite64 on my 64 bit. The toss up was between slamd64/bluewhite64 and, IIRC, bluewhite had more seeds. FWIW, they've been less than a day behind Kurt, releasing an RC right after each Slackware RC (you can see them trail each other by hours on distrowatch.com, these guys must have concurrent rsyncs running to the compiler!). I've only had one issue with bw64, a bad obscure header file of all things... their 64 bit version of the library had some stupid typo in it or something. Other than that, it's been almost as good as Slack.
But, you gave the 65536th ip a free pass? I'll let the off-by-one error slide since I thought that the command for iptables used a lowercase 'a' for the add flag... I alway forget that the first command is uppercase with iptables!
What can you do with Linux that you can't do with Windows, and how can they interface it? Well... I'm still waiting for someone to actually _FIGURE OUT_ and then program a comprehensive interface to 'tc' and 'ip'. I'd hate to be the microsoftie assigned to those two! You could probably quite literally spend months just becoming familiar with all the various flags and options for both of them. Seriously, check out man tc and man ip. After the part about the six or seven balancing _OPTIONS_, they lead you in to ingress filtering for traffic control. I think MS is biting off more than it can chew, again.
You know...
I thought I was being witty, and then you had to bother me facts!
I'm not sure why I thought that Eclipse was swing based... I guess it wouldn't make sense unless they were really careful about threading it. Thanks for the info, though, I've been assuming that Eclipse used Swing for like 3 years now. D'oh!
Would this help at all? I don't really know anything about it, but I've been wanting to give it a whir for a few months now; it's got an open source API, and built in LDAP server and authenticates to gmail... it's at least centralized.
GCALDaemon
The thing I like about Eclipse (on top of what you've said... portable... I'm between: Solaris SPARC, X86_SMP Windows XP, X86 WinXP, X86_SMP Gentoo, X86_64 Slackware, X86 Slackware, and a Mac G3 on any given moment of the day; eclipse runs on them all (haven't actually tested the G3 TBH)), being a software development major, and interning writing various code for work, I can use Eclipse for about 12 different languages and switch between workbenches and languages with the click of a JButton! From ADA to Flex2, perl, Java, I've always got the same IDE, and it all stays in a single folder that I can zip and throw on a jump drive. The icing on the cake is that I can keep all the code in my subversion repo and with subclipse I have my SCM integrated to all my projects. Just today I wanted to mock up a GUI real quick... no problem, JBuilder is based on eclipse now and installing an update is just unzipping a folder, or using the built in update site feature. I've also got Yoxos service (it's free) that lets me browse a good couple hundred of extensions and install them and their dependencies automatically, and update plugins and their dependencies in the background at the click of a button. I also love every summer when they release 14 or 15 projects simultaneously as a single release. Did I mention multithread capable debugging inside the IDE? Stop any thread at any moment and see its stack while the others run. Ant build scripts are nice, too.
Actually, I've seen telnet still alive and well for printers and other various appliances that need a maintenance interface, where having a web interface is overkill. I think telnetd is part of the legacy packages on RHEL and is dependent on xinetd for operation. At least according to its RPM... it might just be a lib dependency.
Disregard that last not-so-witty comment. I read your post as "train a dog and learn to use a gun safely and effectively", or something to that effect. I need to cut back on the caffeine.
Good point, but, like you said, you drop into a chroot after binding. Also, if you're facing the web, you probably have xinetd and/or tcp/ip wrappers between the firewall and the less privileged service threads. You can even chroot an entire set of services together away from your OS. But, you are correct, you have to be root to start the service, and you can also mirror the port. I think you can even redirect the connection with the 'tc' or 'ip' commands. Anyways, I stand corrected;).
Touche. Got me there. However, you drop privileges after the port binding, otherwise httpd wouldn't run as apache:apache or nobody:nobody on port 80! Sometimes with xinetd and/or tcp/ip wrappers between the two.
You make a good point. That's why you have to hit them where it hurts; their reputation/pride. If losing money doesn't make them flinch, how does the RIAA take to being publicly humiliated to the point that they can no continue to be powerful on the basis of 'We say we are, therefore, we are'? If they aren't careful picking their battles, everyone might realize that they actually don't have any real power... ironically, this is much of the model of the Supreme Court.
If the supreme court said tomorrow that jaywalking is a criminal offense, and no one enforced it, knowing it to be insane, then the perception of power that the SC has would be drastically lowered. So it is for the RIAA. You can't beat them by bankrupting them, you have to make them take every win at a marginalized victory or openly show that they have no real power. If they had no credibility in a court room, for numerous reasons, and you rip through their 'expert witnesses' like a hot knife through butter, they'll start losing every bit of steam they've built up.
The RIAA only survives so long as they seem scary enough to make people settle out of court and keep the heat off the labels. You take that from them, and the funding will dry up on its own for lack of interest and marginalized returns on investment. Keep up the great work, Ray! God bless!
The message pump is simply carries two arbitrary 32-bit payloads. If one of those happens to be a callback, so be it. The message pump is not is charge of stopping the kernel component from calling the code that the callback references, the Windows memory model does that. Since Windows 95 and since the conception of Windows NT, the kernel component would have to specifically map memory from the application's address space to call it, this couldn't be used as a code injection vector.
I was referring to a
Shatter attack. Although I don't know the least bit about it to speak with any kind of authority whatsoever, so it may be a non-issue.
That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account.
How exactly are *nix'es very, very specific about least priveliges? Admins are taught this, major packages in big distributions follow this rule. But, *nix'es don't enforce it, they only suggest it in the documentation. Any user that runs a personal *nix desktop that they installed themselves is not going to do it right. UAC was Microsoft's attempt to enforce good behaviors for people who don't know any better. Of course it was only partially successful because it is impossible to force people not to compromise their own systems.
I meant that the file system hierarchy is split up in such a way that it makes running services with limited credentials easier (i.e. chroot), the UIDs and GIDs are specifically marked such that the first 100 are reserved for services (although, as you pointed out, that doesn't mean that people will follow this convention, but it is explicit, nonetheless), and you have things like the wheel group for power users that allows a midway escalation of powers without having to be a root user. Also, there is the ability to allow sudo or setUID; Windows has a form of this, "Run As", but that requires you to store the password for that user on that computer. You were quite right, however, you can't keep someone who doesn't know better from compromising their own system. I fear for my 56 year dad who just got a Vista laptop, I can't be there every time someone tries to scam him, and if I've almost fell for a few things out there, he'll be compromised eventually.
In Windows, you've only got about 3 accounts, Local System, Network Service, and Everyone group.
Everyone isn't an account that can be compromised, it's a group and it has very few permissions. You forgot LocalService, Guest, and any other account that may be created for this purpose. There is no reason why a Windows system can't run each service as a dedicated account with the minimum permission to do the job it needs to do, and it is not Microsoft's fault if someone runs a service as LocalSystem.
Yeah, I missed a bunch there. But, it is Microsoft's fault if they ship a computer where the Theme Manager (as well as every other service on the box) runs as Local System. Does that really need to ship stock with the same permissions as the Security Center service?
If a single service gets owned, it's running rogue at the same level of permissions, system wide, as root.
That's only if it runs as LocalSystem or Administrator. If someone is stupid enough to run services as those accounts, then they get what they deserve. How would that be any different from running a daemon as root in Linux?
How many Linux distros come with services running as root? How many Windows flavors ship with services running as Local System? In Microsofts' defense, IIS has gotten MUCH better about this over the years, and Microsoft also can't control HP writing drivers that run as a system account, or any other user land application. I guess I meant to say that they could do a lot to discourage these things, and
Yeah, but I think the win32 API's message pump is probably the Achilles heal... I've heard that it's been redesigned so that you can't pierce it by getting kernel space threads to execute your program with a callback in the messaging interfaces, but any time that you have a secure system, that front end and the back end should be fairly tight together. If they could intercept the messaging between front end and back end, I'd hazard a guess that the interfaces weren't snug enough. Then again, given 'physical' (if we will allow software to be considered physical for a moment) access to *any* machine, it's no longer yours. That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account.
Unfortunately, tying the desktop environment, window manager, and kernel together into a tightly integrated package will increase the damage per amount of attack vector surface area, should a single link in the armor be broken. In Windows, you've only got about 3 accounts, Local System, Network Service, and Everyone group. If a single service gets owned, it's running rogue at the same level of permissions, system wide, as root. Regardless if it's a crappy HP driver service, a hypervisor, or explorer. All that to say, the design is flawed such that not only are these things possible, but they have greater consequences than they would under other OSes.
How is the pricing? I'd check the site, but I'd like to know from an actual user of said service... It's like asking for the pricing on a cell phone plan at Radio Shack and then asking people who use that plan... iTunes has been nice for me, but lately, I'm running more an more Linux/BSD boxes, and cutting my iTunes habit earlier than later would be great (that, and they bricked my iPod with a firmware update I didn't really want).
So long as all my hard drives are the same size and I've got all the drivers I'll ever need already installed!:-) And, one should use ddrescue to skip over bad blocks!;)
At work I've got 10mbit fiber, so the last time I had to download them all wasn't that bad (I didn't have my image updated, and I only need to do one box, so I just went from the Dell cd w/ base SP2), but I think it took about 5 reboots. Is that still accurate? I think this was about 6 months ago, maybe more.
I've now made it my personal policy to install bootvis right after the install finishes, because the only thing less fun than watching a bar cross the screen (if you don't watch, you'll come back in an hour to find a modal dialog with an 'OK' option for installing IE 7 or something, and it hasn't done anything until you acknowledge it - I was furious!) is watching a box reboot, install a handful of patches and then reboot again.
Slashdot Mirror
Dude... Harrison Ford is Han Solo... you can't, in good conscience, put Richard Dean Anderson up against that. It's just not fair.
To add to your comment, as coming from both your perspective (developer) and a Slackware users' perspective... As a software development major in college, I also like Slackware because, well, let's face it... a development box sometimes takes a beating. I need something reliable that if I accidentally blow something up, I know it will at least come back up to a working bash prompt. Also, I can't stand chasing down libraries and Slackware has just about every library under the sun already in the system. Finally, for testing, Slackware makes an awesome 'vanilla' base for a virtual machine. Every other distro that I've tried to use for making a generic testing machine base, has given me the option (in anaconda) to remove the packages I wouldn't be using, and then adds them back in during install to satisfy RPM dependencies. I should be able to take all the packages out of KDE so that I only have a desktop environment, and still have all my libraries installed.
Slackware was my first distro, and I can vouch for what you say; I learned more in my first week with Slackware, during which time I hosed my system about 3 times. Everyone laughs when I say that, but it's true. I always wondered why everyone thought that Linux was so 'fragile', as it took a pounding and then some for me to hose the thing. I later found out that you can't screw up a dozen compile and install cycles on most distros and expect them to keep running. I literally learned more about Linux during the install where I was dropped to a command line with the instruction 'use fdisk or cfdisk', than most people ever get on a modern distro.
/usr/local, /usr and / were almost identical, it wasn't until I was looking for a library that I realized I kept tripping over different similarly looking trees) when I did 'make install'. Just that period of exposure as I got comfortable with Linux has really defined the difference between myself and most Linux users I know. Now, years later (I got Slackware-10.2 the week it came out... October or November three years ago), I run two Slackware boxes, a sabayon, BSD, and OSX at home, Redhat at work, and Solaris at school without ever having more troubles than remember which are BSD inits and which are SysV... just use /etc/rc.d/ and hit tab to find out ;).
At the time, I literally knew 'cd', 'ls', 'man', 'pine' and 'vi' from SSHing to a Solaris box for school - start with this tools, they're all you need to get started! Since I refused to look anything up online and didn't know that KDE existed (that was the coolest pleasant surprise ever!), I bumbled around the file system hierarchy for about three days trying to figure out how it worked, noticing the subtle nuances of the tree, trying to figure out where all my compiled programs installed to (I didn't know
HUA?
Fortunately Slackware has a GCC on board, and almost every library you could wish for. No one is stopping you from compiling it, using an RPM, or a deb, a slackscript, using makepkg and installpkg, a bitrock installer, yum, or apt. It's your OS; treat it as such.
How is slamd64? I run Slackware on my 32 bit server, and BlueWhite64 on my 64 bit. The toss up was between slamd64/bluewhite64 and, IIRC, bluewhite had more seeds. FWIW, they've been less than a day behind Kurt, releasing an RC right after each Slackware RC (you can see them trail each other by hours on distrowatch.com, these guys must have concurrent rsyncs running to the compiler!). I've only had one issue with bw64, a bad obscure header file of all things... their 64 bit version of the library had some stupid typo in it or something. Other than that, it's been almost as good as Slack.
Best. Post. EVER.
*Sorry, I'm not an orator such as Brutus... he's the honorable man*
But, you gave the 65536th ip a free pass? I'll let the off-by-one error slide since I thought that the command for iptables used a lowercase 'a' for the add flag... I alway forget that the first command is uppercase with iptables!
What can you do with Linux that you can't do with Windows, and how can they interface it? Well... I'm still waiting for someone to actually _FIGURE OUT_ and then program a comprehensive interface to 'tc' and 'ip'. I'd hate to be the microsoftie assigned to those two! You could probably quite literally spend months just becoming familiar with all the various flags and options for both of them. Seriously, check out man tc and man ip. After the part about the six or seven balancing _OPTIONS_, they lead you in to ingress filtering for traffic control. I think MS is biting off more than it can chew, again.
You know...
I thought I was being witty, and then you had to bother me facts!
I'm not sure why I thought that Eclipse was swing based... I guess it wouldn't make sense unless they were really careful about threading it. Thanks for the info, though, I've been assuming that Eclipse used Swing for like 3 years now. D'oh!
Would this help at all? I don't really know anything about it, but I've been wanting to give it a whir for a few months now; it's got an open source API, and built in LDAP server and authenticates to gmail... it's at least centralized.
GCALDaemon
The thing I like about Eclipse (on top of what you've said... portable... I'm between: Solaris SPARC, X86_SMP Windows XP, X86 WinXP, X86_SMP Gentoo, X86_64 Slackware, X86 Slackware, and a Mac G3 on any given moment of the day; eclipse runs on them all (haven't actually tested the G3 TBH)), being a software development major, and interning writing various code for work, I can use Eclipse for about 12 different languages and switch between workbenches and languages with the click of a JButton! From ADA to Flex2, perl, Java, I've always got the same IDE, and it all stays in a single folder that I can zip and throw on a jump drive. The icing on the cake is that I can keep all the code in my subversion repo and with subclipse I have my SCM integrated to all my projects. Just today I wanted to mock up a GUI real quick... no problem, JBuilder is based on eclipse now and installing an update is just unzipping a folder, or using the built in update site feature. I've also got Yoxos service (it's free) that lets me browse a good couple hundred of extensions and install them and their dependencies automatically, and update plugins and their dependencies in the background at the click of a button. I also love every summer when they release 14 or 15 projects simultaneously as a single release. Did I mention multithread capable debugging inside the IDE? Stop any thread at any moment and see its stack while the others run. Ant build scripts are nice, too.
Actually, I've seen telnet still alive and well for printers and other various appliances that need a maintenance interface, where having a web interface is overkill. I think telnetd is part of the legacy packages on RHEL and is dependent on xinetd for operation. At least according to its RPM... it might just be a lib dependency.
Disregard that last not-so-witty comment. I read your post as "train a dog and learn to use a gun safely and effectively", or something to that effect. I need to cut back on the caffeine.
That solution won't save money. Do you have any idea how much it costs to train a dog to safely and effectively handle a firearm?
Ah, but you can lower the total cost if you multitask and do them both at the same time!Good point, but, like you said, you drop into a chroot after binding. Also, if you're facing the web, you probably have xinetd and/or tcp/ip wrappers between the firewall and the less privileged service threads. You can even chroot an entire set of services together away from your OS. But, you are correct, you have to be root to start the service, and you can also mirror the port. I think you can even redirect the connection with the 'tc' or 'ip' commands. Anyways, I stand corrected ;).
Touche. Got me there. However, you drop privileges after the port binding, otherwise httpd wouldn't run as apache:apache or nobody:nobody on port 80! Sometimes with xinetd and/or tcp/ip wrappers between the two.
You make a good point. That's why you have to hit them where it hurts; their reputation/pride. If losing money doesn't make them flinch, how does the RIAA take to being publicly humiliated to the point that they can no continue to be powerful on the basis of 'We say we are, therefore, we are'? If they aren't careful picking their battles, everyone might realize that they actually don't have any real power... ironically, this is much of the model of the Supreme Court.
If the supreme court said tomorrow that jaywalking is a criminal offense, and no one enforced it, knowing it to be insane, then the perception of power that the SC has would be drastically lowered. So it is for the RIAA. You can't beat them by bankrupting them, you have to make them take every win at a marginalized victory or openly show that they have no real power. If they had no credibility in a court room, for numerous reasons, and you rip through their 'expert witnesses' like a hot knife through butter, they'll start losing every bit of steam they've built up.
The RIAA only survives so long as they seem scary enough to make people settle out of court and keep the heat off the labels. You take that from them, and the funding will dry up on its own for lack of interest and marginalized returns on investment. Keep up the great work, Ray! God bless!
The message pump is simply carries two arbitrary 32-bit payloads. If one of those happens to be a callback, so be it. The message pump is not is charge of stopping the kernel component from calling the code that the callback references, the Windows memory model does that. Since Windows 95 and since the conception of Windows NT, the kernel component would have to specifically map memory from the application's address space to call it, this couldn't be used as a code injection vector.
I was referring to a Shatter attack. Although I don't know the least bit about it to speak with any kind of authority whatsoever, so it may be a non-issue.
That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account.
How exactly are *nix'es very, very specific about least priveliges? Admins are taught this, major packages in big distributions follow this rule. But, *nix'es don't enforce it, they only suggest it in the documentation. Any user that runs a personal *nix desktop that they installed themselves is not going to do it right. UAC was Microsoft's attempt to enforce good behaviors for people who don't know any better. Of course it was only partially successful because it is impossible to force people not to compromise their own systems.
I meant that the file system hierarchy is split up in such a way that it makes running services with limited credentials easier (i.e. chroot), the UIDs and GIDs are specifically marked such that the first 100 are reserved for services (although, as you pointed out, that doesn't mean that people will follow this convention, but it is explicit, nonetheless), and you have things like the wheel group for power users that allows a midway escalation of powers without having to be a root user. Also, there is the ability to allow sudo or setUID; Windows has a form of this, "Run As", but that requires you to store the password for that user on that computer. You were quite right, however, you can't keep someone who doesn't know better from compromising their own system. I fear for my 56 year dad who just got a Vista laptop, I can't be there every time someone tries to scam him, and if I've almost fell for a few things out there, he'll be compromised eventually.
In Windows, you've only got about 3 accounts, Local System, Network Service, and Everyone group.
Everyone isn't an account that can be compromised, it's a group and it has very few permissions. You forgot LocalService, Guest, and any other account that may be created for this purpose. There is no reason why a Windows system can't run each service as a dedicated account with the minimum permission to do the job it needs to do, and it is not Microsoft's fault if someone runs a service as LocalSystem.
Yeah, I missed a bunch there. But, it is Microsoft's fault if they ship a computer where the Theme Manager (as well as every other service on the box) runs as Local System. Does that really need to ship stock with the same permissions as the Security Center service?
If a single service gets owned, it's running rogue at the same level of permissions, system wide, as root.
That's only if it runs as LocalSystem or Administrator. If someone is stupid enough to run services as those accounts, then they get what they deserve. How would that be any different from running a daemon as root in Linux?
How many Linux distros come with services running as root? How many Windows flavors ship with services running as Local System? In Microsofts' defense, IIS has gotten MUCH better about this over the years, and Microsoft also can't control HP writing drivers that run as a system account, or any other user land application. I guess I meant to say that they could do a lot to discourage these things, and
Yeah, but I think the win32 API's message pump is probably the Achilles heal... I've heard that it's been redesigned so that you can't pierce it by getting kernel space threads to execute your program with a callback in the messaging interfaces, but any time that you have a secure system, that front end and the back end should be fairly tight together. If they could intercept the messaging between front end and back end, I'd hazard a guess that the interfaces weren't snug enough. Then again, given 'physical' (if we will allow software to be considered physical for a moment) access to *any* machine, it's no longer yours. That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account.
Unfortunately, tying the desktop environment, window manager, and kernel together into a tightly integrated package will increase the damage per amount of attack vector surface area, should a single link in the armor be broken. In Windows, you've only got about 3 accounts, Local System, Network Service, and Everyone group. If a single service gets owned, it's running rogue at the same level of permissions, system wide, as root. Regardless if it's a crappy HP driver service, a hypervisor, or explorer. All that to say, the design is flawed such that not only are these things possible, but they have greater consequences than they would under other OSes.
How is the pricing? I'd check the site, but I'd like to know from an actual user of said service... It's like asking for the pricing on a cell phone plan at Radio Shack and then asking people who use that plan... iTunes has been nice for me, but lately, I'm running more an more Linux/BSD boxes, and cutting my iTunes habit earlier than later would be great (that, and they bricked my iPod with a firmware update I didn't really want).
So long as all my hard drives are the same size and I've got all the drivers I'll ever need already installed! :-) And, one should use ddrescue to skip over bad blocks! ;)
... does "early summer" mean we have to wait until next March? No. You won't be getting it that early.At work I've got 10mbit fiber, so the last time I had to download them all wasn't that bad (I didn't have my image updated, and I only need to do one box, so I just went from the Dell cd w/ base SP2), but I think it took about 5 reboots. Is that still accurate? I think this was about 6 months ago, maybe more.
I've now made it my personal policy to install bootvis right after the install finishes, because the only thing less fun than watching a bar cross the screen (if you don't watch, you'll come back in an hour to find a modal dialog with an 'OK' option for installing IE 7 or something, and it hasn't done anything until you acknowledge it - I was furious!) is watching a box reboot, install a handful of patches and then reboot again.