Rebooting is for Windows
zdnet.co.uk
zdnet.co.uk
The last time I used a MS web-server was ~10 years ago. I have almost exclusively used debian/ubuntu servers most of the time. Apart from the Linux fanboyism, what advantages does MSFT have as a server OS?
I would say support for enterprise apps. A lot of enterprise software vendors still target their development for Windows, and don't support Linux well or fail to test with Linux.
And that's even before worrying about interoperability with database servers (i.e. testing on outdated *nix ODBC drivers, etc.)
Where you really run into problems is selling a weak Unix version into a Windows-hating shops. It ends up being more of a problem than if the vendor just told the customer "you're better off using Windows with our product".
I still pipe logs to a separate process that checks if the logfile is deleted and reopens/creates the logfile, its just easier.
This is actually a feature, because it makes secure temp files possible.
> I still pipe logs to a separate process that ...
Note that logging is usually done in a separate process anyway, using the Syslog facility.
cat /dev/null > /path/to/logfile
Your command will make /path/to/logfile fill up all available space on the disk. To truncate that file, which is probably what you wanted to do, you should
`echo > /path/to/logfile`
It's insane.
They cost a lot, but they deliver a lot of confidence too.
Rebooting makes sure the filesystem is properly scrubbed, temporary files are removed and any stale data in memory gets removed.
Uptime competitions are pointless.
But forced downtime (Windows Update-style) is unacceptable.
While uptime competitions don't indicate availability very well, they do show how much time happened since the last kernel crash or the last kernel security hole that required a kernel upgrade and thus a reboot.
(Unless, of course, someone is trading security for uptime, which is luckily the exception rather the norm, at least among responsible admins.)
It appears that neither Windows nor Linux work particularly well here, but the BSD systems are quite impressive in that regard, especially OpenBSD.
Availablity is also somewhat overrated. Like I said, it's not the downtime that kills you, but the forced, unpredicted downtime.
From my experience with OpenBSD, this appears to be quite simply because things have been pruned so well, there's nothing to fail. What is there is well-designed, and IIRC my general purpose install was ~200MB.
The insanely lightweight and simple nature of OpenBSD is one of my favorite things about it, and probably one of the biggest contributing factors to its strengths.
The various Unix-likes have a variety of filesystems with a lot of innovation going on. Windows basically just has NTFS, which while ok for the desktop is only going to serve well for some types of servers.
http://www.microsoft.com/whdc/devtools/ifskit/default.mspx http://www.microsoft.com/whdc/devtools/IFSKit/ifskit_about.m... http://www.fs-driver.org/ http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx http://www.acc.umu.se/~bosse/ http://www.osr.com/seminars.html
Linux, by contrast, has a variety of filesystems that are as stable if not more so than NTFS, and ready for production use on your root partition.
Linux probably has some catching up to do with respect to Solaris and the BSDs, but it has a good cut above desktop class filesystem support.
Obviously I don't know your use scenarios, but I can think of 2 Linux filesystems that I'd trust to varying extents and they both begin with "ext".
That said, I use the right tool for the right job. Much of the time it's Linux, and sometimes it's Windows 2008. Thank FSM the VMS boxes are gone.Platform agnosticism is a valuable trait to have.
Professionally, I haven't had a real use for anything other than NTFS on a wide variety of Windows servers, all the way up to double-digit TBs of data. What situations have you found NTFS inadequate for your needs?
My desktop has no direct need to handle millions of database transactions and terabytes of data, but it's nice that it can with NTFS.
My focus as a Sysadmin is Linux, purely by nature of the type of work I'm in, so I tend to keep up only with the benchmarks relevant to me.
If you're only seeing ext2 & 3 as mature and stable you've missed great file systems like XFS.
ext2 & 3 are great all-rounders, but XFS will knock them into a top hat when it comes to larger files, with lower CPU usage and disk ops. It'll also beat ext2 and ext3 if you're creating and deleting lots of small files (like on an e-mail server) as the delete will take place in the background without impacting the front end systems. It's nice and mature too (16 years old). ext2 & 3 have slightly better error recovery though. XFS is journalled so very little should go wrong that would impact it.
JFS has strengths when large files are moved around on it, extremely low sector overhead (less than 1%) and very low CPU usage, amongst the lowest of any of the main Linux ones.
NTFS has no knowledge of checksumming, something ZFS, ext4 and btrfs handle (the latter two I wouldn't trust yet in production environments), but it does have integrated snapshots, something you generally have to use LVM for under Linux, and native encryption, and from Vista/2003 onwards supports shrinking and expansion directly on the fly (again LVM is necessary to do this under linux, and is best done with filesystem offline).
You chose your operating system and file system to suit the task (for example I'd use OpenBSD on a gateway machine instead of Linux as it's more suited to the role).
It's such a simple concept, like how you wouldn't use a hammer to crack an egg. You could, but you might find the edge of a knife or a spoon a lot easier and neater.
Ultimately it comes down to lack of having "no reboots" as a clear goal. SQL Server has a pretty strong goal of being able to patch a running server without rebooting and they do a good job meeting that goal. For Windows OS it comes down to programmer laziness winning over in the absence of a directive to avoid reboots.