As much sense as some changes have made, there's been a consistent movement toward a bland homogenized, minimalistic product line.
First they take the Mac Pro and turn it into a weird little trash can that can't be expanded internally. No more jamming the bays full of big, fast drives, no more expansion or video card upgrades. The result? I either keep using my aging 2009 Mac Pro or build a hackintosh.
Then they take the MacBook Pro and take away the ability to upgrade RAM/Hard drive or do your own maintenance. The iMac is going the same way now.
Then they take away the freaking headphone jack from their phone, which many people still need. Yes, I can spend more money to work around that issue, but I shouldn't have to.
Now, the brainiacs at Apple are talking about nuking the escape key? I'm a Unix admin. I use a Mac to access my Linux server farm and pretty much live on the command line. All of my scripting is done with vi and the escape key is essential.
As much as I love using Macs, I'm getting fed up with their "have it our way" attitude. They're following in the footsteps of AOL and Blackberry with their idiotic hubris.
Ever since Jobs died, Apple has been coasting. There have been no positive innovations, just variations on a theme that ended when Steve died. No one's come up with anything good, so they decide to shake things up by making user unfriendly changes "just because".
Hint to Apple: There will be NO third coming of Steve to drag your asses out of trouble. I've already dumped 90% of my Apple stock. It's grossly overvalued and when the current asset bubble burst, the value will be in the toilet.
Awesome. Yet another way they want to screw us. While this might sound smexy-smexy to some, I don't see any upsides for consumers. We'd have to replace massive amounts of existing equipment, worry about the fragility of the new connectors and it's another opportunity for the music industry to lock down an interface with DRM.
I have a significant investment in music production equipment and ham radio equipment (both purchased and home-built). Having to worry about availability of something as simple as a set of headphones or how I'm going to get an analog signal between two points is utter BS.
Evidently, they want to keep content locked down so tightly, it will make things painful for the customer. Why not just force everyone to get a brain implant so they can bill us if one of their songs is stuck in our head?
They already screwed us over with everything else, why not this too?
There's a difference between technical work and being tech support. Usually, the latter are the ones not good enough to be systems administrators. Higher tier tech support comes close, but nearly every tech support person I've met was some drone who read solution recipes out of a book.
Submarine crews are usually very intelligent and highly skilled at their job. They can't count on outside support and have to be able to operate autonomously for weeks or months on end. When sub sailors get out of the Navy, they're usually able to find suitable employment quickly and have the mental tools to do nearly anything they like.
I was a Sonar Technician (STS1(SS)) on two 688 class attack subs for 6 years and stayed in the ASW world for a few years after getting out of the Navy, then shifted into systems engineering and Unix administration. I'm now a systems architect running large-ish distributed computational clusters. I know of guys who became electrical engineers, doctors, teachers, etc.
Aside from "trim parties" (that's what we called them), we raised the art of the prank to a fine art. Ranging from asking people to get 50 feet of shore line, a bucket of relative bearing grease or obtaining the serial numbers of "water slugs", which are nothing more than columns of water pushed out the torpedo tubes during testing. The classic prank is to get some NUB (aka Non-Useful Body) to gather outgoing mail from the crew, then don every imaginable bit of foul weather gear, life harness, helo transfer helmet, high voltage shorting probe and stand at parade rest under the bridge hatch while the boat was coming to periscope depth, ostensibly to deposit the outgoing mail in the "Mail Buoy" and retrieve mail for the crew.
Obviously, there's no such thing as a mail buoy, but it sounds credible to a new crew member and since we were the masters of a deadpan delivery, we could nearly always catch someone with that one.
I was a crew member on two 688-class attack subs. Yes, they were a bit tight but they're not especially claustrophobic. Obviously, that's subjective. While my longest stretch submerged was 61 days, I know of crews that spent over 90 days submerged. You're essentially limited by the amount of food you carry.
"Constant quiet" is relative. They don't want you banging on stuff or making excessive noise, but you can talk, laugh and listen to movies and music without issue unless the boat is rigged for ultra-quiet.
Rationing? Really? Sub crews eat better than pretty much any other branch of service. Unless the storekeepers messed up, there's plenty of food for all and some people manage to gain too much weight if they're not careful.
The biggest difference I can see between what Mr. Cousteau is doing and what we were doing is that they're exposed to ambient pressure at a fairly shallow depth while we were mostly at atmospheric pressure the entire time. And we didn't have windows to see the pretty fishies (unless you count the deadlight in the watertight door, the viewport into the reactor compartment and the window on the washing machine.
I was a crewmember on the USS Baton Route (SSN-689) and we were given a Tektronix 4051 computer to assist with SONAR range of the day predictions and whatnot. Since there was no place in SONAR to keep it, it was strapped down up forward in the SONAR Equipment Space. I spent many hours learning BASIC from the language reference manual and taught myself how to code the worlds ugliest spaghetti code ever. I did learn to write some usable programs over time that weren't so fugly and were even fairly useful.
And they're going to retrofit all of our guns how?
Geez, comrade. What should we do until then? Surrender them for 'safekeeping' while they figure out how to retrofit an old M38 Mauser or Finnish Mosin-Nagant? How long will they keep my WWI era Luger, my 1952 Russian SKS or the AR15 I use to shoot in Service Rifle competitions? What about black powder rifles and handguns? What about knives? What about blunt instruments, broken glass or even gasoline?
One of the biggest mass killings in US history was committed with a gallon of gasoline. How are they going to track that? With GPS trackers and fingerprint locks on gas containers? Perhaps they should put rubber bumpers on all the sharp corners of the world so it's impossible to get hurt. Then we'll all be safe, sound and secure, right?
Oh wait. The criminals will be the ones that have the guns without the fingerprint readers.
How about you butt out of our countries business and tend to your own feeble socialistic existence, jackass!
We're currently using the ROCKS cluster distro to run our cluster, but are finding that it's beginning to limit our ability to patch and otherwise maintain our cluster infrastructure. We've adopted cobbler and puppet for some of our HPC assets and will likely switch from ROCKS to more of a home-grown approach to manage our nodes. One thing I dearly love about ROCKS is the Avalanche Installer which uses bittorrent to distribute the image to the nodes when they do their initial build. I've
Are you using that or a similar package to do your node builds?
A majority of our IT HW budget is for High Performance Computing. We have about 10000 x86 cores running CentOS, about 100 M2070 GPUs and close to a petabyte of Isilon cluster storage in production right now and will be expanding to over 15000 cores in the next year.
If we wanted to use SPARC systems, we couldn't afford anything nearly as powerful or as painless to manage. We don't need OS support other than patches and we're not tied to any particular vendor (other than Isilon). We may implement a Gluster storage cluster to gain independence from sole-source vendors entirely.
We have a couple of Solaris bigots on the team, but they're mostly relegated to running our handful of Solaris boxes and non-cluster storage/backups.
With the advent of cluster file systems, you don't have to pay for unreasonably expensive "bulletproof" hardware anymore. You can set up a Gluster storage cluster on commodity-grade X86 hardware get all the speed and redundancy you need (and are willing to pay for) at vastly cheaper prices. For those that don't want to roll their own, you can use commercial storage clusters by Isilon or storage virtualization devices such as the F5 Acopia with pretty much any storage underneath that you like.
Our unix shop used to be primarily SPARC-based, but with limited IT budgets, we're able to do far more with much less money using HP blades running CentOS.
For most purposes, SPARC hardware is far too expensive and Oracle seems to be doing all they can to kill Solaris.
We still run a handfull of SPARC systems that run specialized applications and a few Solaris zones, but nearly all other services have been pushed to natively hosted Linux systems, or virtual machines running Windows or Linux.
CentOS is also pretty horrible for doing gaming and running it on laptops. It's an enterprise OS and doesn't have the consumer-friendly bells and whistles one sees on Ubuntu.
I run CentOS on my servers at work and Ubuntu on my linux box at home
The point of this particular thread-let is what to learn if you're after an IT career. I don't know of any respectable Unix admin that would choose Fedora over CentOS in the enterprise.
CentOS (and Scientific Linux) are both well-respected, stable OSs built from the RHEL source. It's basically Redhat without all of the licensing silliness.
As was mentioned in another thread, Unix is best learned in a VM that's regularly snapshotted. That way, if you hork things up, you can revert without a lot of pain. Having to set up a system from scratch because you broke it and keep breaking it will dissuade new users from learning essential skills.
I also suggest that if someone wants to learn to be a Unix admin, learn the vi editor. Don't use a gui-based crutch until you're proficient in vi. I know a lot of people like emacs, but vi is an essential tool.
Learning to write shell scripts is also an essential skill, but stick with a mainstream shell. Csh is godawful, and zsh is too obscure for the enterprise. Ksh implementations used to be very spotty, especially when moving scripts between Solaris and Linux.
Learn some of the other tools like awk, sed, grep, cut, sort and uniq.
There's a huge shortage of decent Unix admins and a glut of Windows admins. Most of the Unix Admins we interview can't script unless they're stealing from something someone else wrote and most don't understand the innards of how the OS even works.
It comes with a pretty recent version of SGE and openmpi installed. It's fully capable of using NFS shares and many people have used it with Infiniband. Cluster monitoring's done with ganglia. The kernel's customizable and you can add your own modules as "rolls" and can manage packages either as a post install or build it into the kickstart for each node. We use Isilon for our shared storage, but we're probably going to be setting up a gluster storage cluster too.
Rocks is a great way for an organization to get their feet wet with high performance computing, but we're beginning to find some limitations especially when it comes to security patching.
We're working on a next-gen cluster architecture where we will provide the same user interface and resources as Rocks, but will use Cobbler or something similar for provisioning, Puppet for configuration management and either SGE, OGE or Univa grid engine for the scheduler. We plan on using ganglia and nagios for monitoring and will eventually, extend our provisioning, patching and monitoring to cover the rest of the enterprise.
GPU-based computing's a great idea, but not appropriate for all problems. There's also significantly more work managing memory and all that with a GPU.
We have about 50 M2070 GPUs in production and virtually no one uses them. They depend instead on our CPU resources since they're easier to program for.
Totally agree. We had a bunch of dual dual-core server blades that were freed up and after looking at the power requirements per core for the old systems we decided it would be cheaper in the long run to retire the old servers and buy a fewer number of higher density servers.
The old blades drew 80 watts/core (320 watts) and the new ones which had dual sixteen-core Opterons drew 10 watts/core for the same amount of overall power. That's a no brainer when you consider that these systems run 24/7 with all CPUs pegged. More cores in production means your jobs finish up faster, you'll be able to have more users and more jobs running and use much less power in the long run.
You'll need to consider how you're going to provision and maintain a collection of systems.
Our company currently uses the ROCKS cluster distribution, which is a CentOS-based distribution that provisions, monitors and manages all of the compute nodes. It's very easy to have a working cluster set up in a short amount of time, but it's somewhat quirky in that you can't fully patch all pieces of the software without breaking the cluster.
One thing that I really like about ROCKS is their provisioning tool which is called the "Avalanche Installer". It uses bittorrent to load the OS and other software on each compute node as it comes online and it's exceedingly fast.
I installed ROCKS on a head node, then was able to provision 208 HP BL480c blades within an hour and a half.
The Mac Mini's more of a home/small company server, IMHO.
We have a couple of XServes in production that we saved from the scrap heap and have another 4 in reserve in case the production ones crap out. They're nice systems, but don't talk to SATA II or III drives and need to be jumpered down to 1.5GB.
When the XServes die or aren't supported by whatever OS we need, then we'll have to reassess things.
Re: windows vs Mac, I personally hate using windows as a workstation, but I have one at home for gaming. In general, it's a crufty clunky dog's breakfast of an OS that's a pain in the butt to configure and update. I've used nearly every version of DOS or Windows since the days of DOS 2.0 and Windows 2.0, so I'm familiar with its flaws and foibles. The only versions I've never used are Vista and Win 8.
MacOS used to be a crap OS. It was pretty, but didn't multitask at all and crashed far too often to trust. OS/2 was nice, but fragile and was never as popular as Windows. OS X is an awesome OS for workstations and is excellent to work with for day-to-day stuff. The only Linux I use for workstation stuff is Ubuntu. CentOS as a workstation OS is ok, but is too much of a pain to deal with for stuff like sound cards, etc.
Slashdot has a lot of different kinds of people on it. Many of them hobbyists and people who work in small *nix shops. Many are also enterprise IT types and the most popular enterprise *nix is Linux, hands down. Redhat/CentOS flavors dominate, but there are a few debian shops as well, such as Akamai.
A lot of that stuff is just holy wars, but if you look at what vendors support what OS's, You don't typically see much for BSD. Our company recently retired a BSD cluster and are in the process of decommissioning our BSD-based servers for a myriad of reasons. Juniper may use BSD in their stuff, but many more use Linux as their embedded OS.
BSD is popular with some companies and in colleges, but when you get into the real world it's either Linux or Solaris and Solaris is fading fast. Look at the job market. Linux is what most companies are looking for. I'm not dissing BSD, but I'd never recommend it for anything in the enterprise.
I used to run some SunOS (bsd-flavored) systems 'back in the day' and loved them, but when Solaris came out, pretty much everyone switched. I've used Solaris 2.5 - Solaris 10 on both SPARC and X86 and have watched it decline over the years in popularity because of hardware costs and X86 compatibility issues. Oracle has made some really dumb moves over the years regarding the stuff they purchased as part of Sun and most admins I know have given up on their stuff.
Slashdot Mirror
Caps lock is only around because the Apple honchos are getting old and THEY NEED THE CAPS LOCK SO THEY CAN READ WHAT'S ON THE SCREEN!!!
dumbasses.
Geez... WTF is Apple up to these days?
As much sense as some changes have made, there's been a consistent movement toward a bland homogenized, minimalistic product line.
First they take the Mac Pro and turn it into a weird little trash can that can't be expanded internally. No more jamming the bays full of big, fast drives, no more expansion or video card upgrades. The result? I either keep using my aging 2009 Mac Pro or build a hackintosh.
Then they take the MacBook Pro and take away the ability to upgrade RAM/Hard drive or do your own maintenance. The iMac is going the same way now.
Then they take away the freaking headphone jack from their phone, which many people still need. Yes, I can spend more money to work around that issue, but I shouldn't have to.
Now, the brainiacs at Apple are talking about nuking the escape key? I'm a Unix admin. I use a Mac to access my Linux server farm and pretty much live on the command line. All of my scripting is done with vi and the escape key is essential.
As much as I love using Macs, I'm getting fed up with their "have it our way" attitude. They're following in the footsteps of AOL and Blackberry with their idiotic hubris.
Ever since Jobs died, Apple has been coasting. There have been no positive innovations, just variations on a theme that ended when Steve died.
No one's come up with anything good, so they decide to shake things up by making user unfriendly changes "just because".
Hint to Apple: There will be NO third coming of Steve to drag your asses out of trouble. I've already dumped 90% of my Apple stock. It's grossly overvalued and when the current asset bubble burst, the value will be in the toilet.
Awesome. Yet another way they want to screw us. While this might sound smexy-smexy to some, I don't see any upsides for consumers. We'd have to replace massive amounts of existing equipment, worry about the fragility of the new connectors and it's another opportunity for the music industry to lock down an interface with DRM.
I have a significant investment in music production equipment and ham radio equipment (both purchased and home-built). Having to worry about availability of something as simple as a set of headphones or how I'm going to get an analog signal between two points is utter BS.
Evidently, they want to keep content locked down so tightly, it will make things painful for the customer. Why not just force everyone to get a brain implant so they can bill us if one of their songs is stuck in our head?
They already screwed us over with everything else, why not this too?
There's a difference between technical work and being tech support. Usually, the latter are the ones not good enough to be systems administrators. Higher tier tech support comes close, but nearly every tech support person I've met was some drone who read solution recipes out of a book.
Submarine crews are usually very intelligent and highly skilled at their job. They can't count on outside support and have to be able to operate autonomously for weeks or months on end. When sub sailors get out of the Navy, they're usually able to find suitable employment quickly and have the mental tools to do nearly anything they like.
I was a Sonar Technician (STS1(SS)) on two 688 class attack subs for 6 years and stayed in the ASW world for a few years after getting out of the Navy, then shifted into systems engineering and Unix administration. I'm now a systems architect running large-ish distributed computational clusters. I know of guys who became electrical engineers, doctors, teachers, etc.
Aside from "trim parties" (that's what we called them), we raised the art of the prank to a fine art. Ranging from asking people to get 50 feet of shore line, a bucket of relative bearing grease or obtaining the serial numbers of "water slugs", which are nothing more than columns of water pushed out the torpedo tubes during testing. The classic prank is to get some NUB (aka Non-Useful Body) to gather outgoing mail from the crew, then don every imaginable bit of foul weather gear, life harness, helo transfer helmet, high voltage shorting probe and stand at parade rest under the bridge hatch while the boat was coming to periscope depth, ostensibly to deposit the outgoing mail in the "Mail Buoy" and retrieve mail for the crew.
Obviously, there's no such thing as a mail buoy, but it sounds credible to a new crew member and since we were the masters of a deadpan delivery, we could nearly always catch someone with that one.
I was a crew member on two 688-class attack subs. Yes, they were a bit tight but they're not especially claustrophobic. Obviously, that's subjective. While my longest stretch submerged was 61 days, I know of crews that spent over 90 days submerged. You're essentially limited by the amount of food you carry.
"Constant quiet" is relative. They don't want you banging on stuff or making excessive noise, but you can talk, laugh and listen to movies and music without issue unless the boat is rigged for ultra-quiet.
Rationing? Really? Sub crews eat better than pretty much any other branch of service. Unless the storekeepers messed up, there's plenty of food for all and some people manage to gain too much weight if they're not careful.
The biggest difference I can see between what Mr. Cousteau is doing and what we were doing is that they're exposed to ambient pressure at a fairly shallow depth while we were mostly at atmospheric pressure the entire time. And we didn't have windows to see the pretty fishies (unless you count the deadlight in the watertight door, the viewport into the reactor compartment and the window on the washing machine.
I was a crewmember on the USS Baton Route (SSN-689) and we were given a Tektronix 4051 computer to assist with SONAR range of the day predictions and whatnot. Since there was no place in SONAR to keep it, it was strapped down up forward in the SONAR Equipment Space. I spent many hours learning BASIC from the language reference manual and taught myself how to code the worlds ugliest spaghetti code ever. I did learn to write some usable programs over time that weren't so fugly and were even fairly useful.
The term "Jumped The Shark" has jumped the shark as well.
And they're going to retrofit all of our guns how?
Geez, comrade. What should we do until then? Surrender them for 'safekeeping' while they figure out how to retrofit an old M38 Mauser or Finnish Mosin-Nagant? How long will they keep my WWI era Luger, my 1952 Russian SKS or the AR15 I use to shoot in Service Rifle competitions? What about black powder rifles and handguns? What about knives? What about blunt instruments, broken glass or even gasoline?
One of the biggest mass killings in US history was committed with a gallon of gasoline. How are they going to track that? With GPS trackers and fingerprint locks on gas containers? Perhaps they should put rubber bumpers on all the sharp corners of the world so it's impossible to get hurt. Then we'll all be safe, sound and secure, right?
Oh wait. The criminals will be the ones that have the guns without the fingerprint readers.
How about you butt out of our countries business and tend to your own feeble socialistic existence, jackass!
We're currently using the ROCKS cluster distro to run our cluster, but are finding that it's beginning to limit our ability to patch and otherwise maintain our cluster infrastructure. We've adopted cobbler and puppet for some of our HPC assets and will likely switch from ROCKS to more of a home-grown approach to manage our nodes. One thing I dearly love about ROCKS is the Avalanche Installer which uses bittorrent to distribute the image to the nodes when they do their initial build. I've
Are you using that or a similar package to do your node builds?
A majority of our IT HW budget is for High Performance Computing. We have about 10000 x86 cores running CentOS, about 100 M2070 GPUs and close to a petabyte of Isilon cluster storage in production right now and will be expanding to over 15000 cores in the next year.
If we wanted to use SPARC systems, we couldn't afford anything nearly as powerful or as painless to manage. We don't need OS support other than patches and we're not tied to any particular vendor (other than Isilon). We may implement a Gluster storage cluster to gain independence from sole-source vendors entirely.
We have a couple of Solaris bigots on the team, but they're mostly relegated to running our handful of Solaris boxes and non-cluster storage/backups.
With the advent of cluster file systems, you don't have to pay for unreasonably expensive "bulletproof" hardware anymore. You can set up a Gluster storage cluster on commodity-grade X86 hardware get all the speed and redundancy you need (and are willing to pay for) at vastly cheaper prices. For those that don't want to roll their own, you can use commercial storage clusters by Isilon or storage virtualization devices such as the F5 Acopia with pretty much any storage underneath that you like.
We're running away from SPARC as fast as we can.
Our unix shop used to be primarily SPARC-based, but with limited IT budgets, we're able to do far more with much less money using HP blades running CentOS.
For most purposes, SPARC hardware is far too expensive and Oracle seems to be doing all they can to kill Solaris.
We still run a handfull of SPARC systems that run specialized applications and a few Solaris zones, but nearly all other services have been pushed to natively hosted Linux systems, or virtual machines running Windows or Linux.
CentOS is also pretty horrible for doing gaming and running it on laptops. It's an enterprise OS and doesn't have the consumer-friendly bells and whistles one sees on Ubuntu.
I run CentOS on my servers at work and Ubuntu on my linux box at home
The point of this particular thread-let is what to learn if you're after an IT career. I don't know of any respectable Unix admin that would choose Fedora over CentOS in the enterprise.
CentOS (and Scientific Linux) are both well-respected, stable OSs built from the RHEL source. It's basically Redhat without all of the licensing silliness.
As was mentioned in another thread, Unix is best learned in a VM that's regularly snapshotted. That way, if you hork things up, you can revert without a lot of pain. Having to set up a system from scratch because you broke it and keep breaking it will dissuade new users from learning essential skills.
I also suggest that if someone wants to learn to be a Unix admin, learn the vi editor. Don't use a gui-based crutch until you're proficient in vi. I know a lot of people like emacs, but vi is an essential tool.
Learning to write shell scripts is also an essential skill, but stick with a mainstream shell. Csh is godawful, and zsh is too obscure for the enterprise. Ksh implementations used to be very spotty, especially when moving scripts between Solaris and Linux.
Learn some of the other tools like awk, sed, grep, cut, sort and uniq.
There's a huge shortage of decent Unix admins and a glut of Windows admins. Most of the Unix Admins we interview can't script unless they're stealing from something someone else wrote and most don't understand the innards of how the OS even works.
Unfortunately, most of our clusters are on closed networks.
It comes with a pretty recent version of SGE and openmpi installed. It's fully capable of using NFS shares and many people have used it with Infiniband. Cluster monitoring's done with ganglia. The kernel's customizable and you can add your own modules as "rolls" and can manage packages either as a post install or build it into the kickstart for each node. We use Isilon for our shared storage, but we're probably going to be setting up a gluster storage cluster too.
Rocks is a great way for an organization to get their feet wet with high performance computing, but we're beginning to find some limitations especially when it comes to security patching.
We're working on a next-gen cluster architecture where we will provide the same user interface and resources as Rocks, but will use Cobbler or something similar for provisioning, Puppet for configuration management and either SGE, OGE or Univa grid engine for the scheduler. We plan on using ganglia and nagios for monitoring and will eventually, extend our provisioning, patching and monitoring to cover the rest of the enterprise.
My bad: www.rocksclusters.org
GPU-based computing's a great idea, but not appropriate for all problems. There's also significantly more work managing memory and all that with a GPU.
We have about 50 M2070 GPUs in production and virtually no one uses them. They depend instead on our CPU resources since they're easier to program for.
Totally agree. We had a bunch of dual dual-core server blades that were freed up and after looking at the power requirements per core for the old systems we decided it would be cheaper in the long run to retire the old servers and buy a fewer number of higher density servers.
The old blades drew 80 watts/core (320 watts) and the new ones which had dual sixteen-core Opterons drew 10 watts/core for the same amount of overall power. That's a no brainer when you consider that these systems run 24/7 with all CPUs pegged. More cores in production means your jobs finish up faster, you'll be able to have more users and more jobs running and use much less power in the long run.
You'll need to consider how you're going to provision and maintain a collection of systems.
Our company currently uses the ROCKS cluster distribution, which is a CentOS-based distribution that provisions, monitors and manages all of the compute nodes. It's very easy to have a working cluster set up in a short amount of time, but it's somewhat quirky in that you can't fully patch all pieces of the software without breaking the cluster.
One thing that I really like about ROCKS is their provisioning tool which is called the "Avalanche Installer". It uses bittorrent to load the OS and other software on each compute node as it comes online and it's exceedingly fast.
I installed ROCKS on a head node, then was able to provision 208 HP BL480c blades within an hour and a half.
Check it out at www.rockclusters.org
Just another data point: http://news.slashdot.org/story/12/12/09/1726222/freebsd-project-falls-short-of-year-end-funding-target-by-nearly-50
The Mac Mini's more of a home/small company server, IMHO.
We have a couple of XServes in production that we saved from the scrap heap and have another 4 in reserve in case the production ones crap out. They're nice systems, but don't talk to SATA II or III drives and need to be jumpered down to 1.5GB.
When the XServes die or aren't supported by whatever OS we need, then we'll have to reassess things.
and they're number what now? :)
Re: windows vs Mac, I personally hate using windows as a workstation, but I have one at home for gaming. In general, it's a crufty clunky dog's breakfast of an OS that's a pain in the butt to configure and update. I've used nearly every version of DOS or Windows since the days of DOS 2.0 and Windows 2.0, so I'm familiar with its flaws and foibles. The only versions I've never used are Vista and Win 8.
MacOS used to be a crap OS. It was pretty, but didn't multitask at all and crashed far too often to trust. OS/2 was nice, but fragile and was never as popular as Windows. OS X is an awesome OS for workstations and is excellent to work with for day-to-day stuff. The only Linux I use for workstation stuff is Ubuntu. CentOS as a workstation OS is ok, but is too much of a pain to deal with for stuff like sound cards, etc.
Slashdot has a lot of different kinds of people on it. Many of them hobbyists and people who work in small *nix shops. Many are also enterprise IT types and the most popular enterprise *nix is Linux, hands down. Redhat/CentOS flavors dominate, but there are a few debian shops as well, such as Akamai.
A lot of that stuff is just holy wars, but if you look at what vendors support what OS's, You don't typically see much for BSD. Our company recently retired a BSD cluster and are in the process of decommissioning our BSD-based servers for a myriad of reasons. Juniper may use BSD in their stuff, but many more use Linux as their embedded OS.
BSD is popular with some companies and in colleges, but when you get into the real world it's either Linux or Solaris and Solaris is fading fast. Look at the job market. Linux is what most companies are looking for. I'm not dissing BSD, but I'd never recommend it for anything in the enterprise.
I used to run some SunOS (bsd-flavored) systems 'back in the day' and loved them, but when Solaris came out, pretty much everyone switched. I've used Solaris 2.5 - Solaris 10 on both SPARC and X86 and have watched it decline over the years in popularity because of hardware costs and X86 compatibility issues. Oracle has made some really dumb moves over the years regarding the stuff they purchased as part of Sun and most admins I know have given up on their stuff.