Bigtime.... that's what makes this "Linux is free" argument so laughable. When you're spending $30k for clustering software, another $300k for volume management & filesystem licenses (Price VxVM & VxFS for an SF15k someday...), what does that OS license cost matter?
Oh, wait, if you buy a piece of Sun/IBM/SGI/etc. hardware, they throw the OS in for free anyway...
My gawd, people have no idea what they're talking about.
First of all, the article is about an *Ultra 5*, not a SPARCstation 5 (Which is what's implied by SPARC 5).
Secondly, "old"? Geeze.
The SPARCstation 5 *still* runs the latest-n-greatest versions of Solaris (Sol 9). It's still supported and everything.
The same CD you use to load Solaris on that SPARCstation 5 will boot a Sun Fire 15k with 106 CPU's.
Now *that's* scalable.:)
I seriously can't believe people are considering the Ultra 5 as an antique.
I still have a SPARCstation 20, and consider it one of my favorite computers, ever. It's got a super-elegant design, is rock-solid, and Just Works (tm).
How anyone can "wax nostalgic" about an Ultra 5 is beyond me. They're not that old.
Maybe for you PeeCee dorks who upgrade their video boards every 14 minutes, but to those of us who actually USE our machines for something, they're fresh as a daisy.
My point here is that I'm trying to let our developers do their job, without my interference.
By letting them run their web servers on 8000, and using a load balancer to do the 80 -> 8000 redirection, then they can start/stop the app. to their hearts' content.
The only time they need me is for OS/system issues (more disk space, I/O tuning, etc.)
I'm not trying to justify my job; I'm just trying to do a good one.
a) No, we don't do development on prod machines. Dev on dev machines, prod on prod machines. Test environments in the middle.
b) Development environments should NOT be a playground. It leads to sloppiness. What happens then is that something that works in test then doesn't work in prod. And who gets blamed? The sysadmin.
Dev/test should be a mirror image of production. Same hardware, same config, same OS, etc. This way, when you migrate code to prod, you know at least that the underlying system is the same.
I'm not talking about outbound Internet access. I'm talking about the Web servers that the app. teams themselves are running. They should run on, say, port 8000, and let the front-end load balancers in front of them do the 80 -> 8000 translation.
i.e.: I have systems "foo0" and "foo1". The virtual IP on the content switch has a hostname of "foo" attached to it.
The web server software runs on port 8000 on foo0 & foo1.
When a user hits port 80 on "foo", the content switch redirects them to foo0:8000 or foo1:8000, depending on several factors (load, response time, etc.)
It's a simple thing for the app teams to do, and saves us from having them require root access.
and it makes the dev/test environment look just like production. Which is yet again, a Good Thing.
Slashdot Mirror
Amen brother.
Rock on code revealer!
Does anyone remember PointCast?
:-)
Here we go, "push" technology all over again.
Except this time, it isn't the stock feeds, but purported "geek news" sites.
Yeah, that's gonna fly.
What about if you live somewhere where there's no cable modem service, and you're too far from the CO for DSL?
... :)
There's a LOT of areas like that in the US
(Thank goodness I'm not in one of them!)
Only on a toy system.
.... :)
This is totally impractical in a real-world enterprise shop
Why do you need OpenSSL installed on the server?
:)
For SSH?
Wrong. You only need OpenSSL on the system where you compile SSH. (You don't have compilers on all the systems, do you?)
You compile SSH so the SSL libraries are included, and push the package out to all of your hosts.
Oh, and a really convenient way to turn off the r* services is to shut off inetd altogether.... who needs it?
The only port a system needs open by default is 22/TCP... the rest are just holes waiting to happen!
(Well, so is SSH, but what can ya do?)
But is anyone else thinking of Medal of Honor?
Sound zee alarm!!
Well of course, there are lots of foreign cars with trouble too.
.....
I was just using the american cars as an example
You mean the Pinto?
...
Seriously, Ford, GM, Chrysler, they've all put out some real stinkers. And yet, suckers (myself included) go back for more.
Sure, things like the tap-the-rear-end-and-we-explode Pontiac Fiero hurt the bottom line short-term, but does anyone think about that today?
Of course not
Diners ALWAYS have the best coffee.
It comes out of that horrible, nasty looking urn that hasn't been cleaned since Nixon was in office.
But it tastes the best, by far.
Oh, and get taylor ham & egg on a hard roll while you're at it.... good stuff.
A simple database that works REALLY well?
Nutshell Plus, a/k/a Ultra Plus:
http://www.fairsoft.com/
He's an ace!
.........
He's amaaazing!
He's the strongest, he's the quickest, he's the best!
Danger Mouse
Well, then I'll think about it.
....
...
I'll believe it when I see it. Same thing I've been sayinig since '95, and it's still true
I started using Linux in the 0.9 days, and I abandoned it during the 2.0.x days.
Now I've got a FreeBSD system (it's got a big picture of an Apple on the side panel...) and I couldn't be happier
No, *you* obviously don't understand where I'm coming from.
..
Management doesn't care about the "freedom" stuff, all they care about is dollars and cents.
And one of the pitches that's been thrown around for Linux is that you're unencumbered by licensing costs.
Well, it's simply Not True (tm). Read what I said above
And I don't need to read anything RMS has written; I've read it before, and written him off as a kwack.
You get what you pay for.
... that's what makes this "Linux is free" argument so laughable. When you're spending $30k for clustering software, another $300k for volume management & filesystem licenses (Price VxVM & VxFS for an SF15k someday ...), what does that OS license cost matter?
...
:)
Bigtime.
Oh, wait, if you buy a piece of Sun/IBM/SGI/etc. hardware, they throw the OS in for free anyway
Hmm, there goes *that* argument.
My gawd, people have no idea what they're talking about.
:)
First of all, the article is about an *Ultra 5*, not a SPARCstation 5 (Which is what's implied by SPARC 5).
Secondly, "old"? Geeze.
The SPARCstation 5 *still* runs the latest-n-greatest versions of Solaris (Sol 9). It's still supported and everything.
The same CD you use to load Solaris on that SPARCstation 5 will boot a Sun Fire 15k with 106 CPU's.
Now *that's* scalable.
I seriously can't believe people are considering the Ultra 5 as an antique.
I still have a SPARCstation 20, and consider it one of my favorite computers, ever. It's got a super-elegant design, is rock-solid, and Just Works (tm).
How anyone can "wax nostalgic" about an Ultra 5 is beyond me. They're not that old.
Maybe for you PeeCee dorks who upgrade their video boards every 14 minutes, but to those of us who actually USE our machines for something, they're fresh as a daisy.
Yes, I have driven them myself, and they are really nice cars...
but their mechanical reputation precedes them.....
Oh right, like the Jaguar and Triumph are such great automobiles.
....
They drive really well, to and from the mechanic's.
VCR's? Blame the Japanese for those. We don't even make TV's anymore
Mucho agreed.
.....
I'll raise you a Global Wars while I'm at it.
And maybe a "King of the Board" trivia game
Actually, I've found a much easier way.
... seems to work very well.
Just b*tch and moan that "... this is why I use a Mac" every time you fix their PC. They'll get sick of it quick.
Wow, I really wish I had moderator points right now.
:)
+750, Fantastic Reference Nobody Else Gets
This is the best Slashdot comment I've ever seen!
Good show.
Oh, so what's my B.Sc. on the wall?
.....
With the minor in mathematics?
And developers are on-call too. We have to call someone when the code sh*ts the bed at 3am
I totally agree. The webserver is only the "front door".
:)
I have a tough enough time convincing the apps teams that databases should NOT reside in the DMZ.....
Baby steps....
And they call me "their sysadmin".
It's because we work as a TEAM.
Imagine that.
My point here is that I'm trying to let our developers do their job, without my interference.
By letting them run their web servers on 8000, and using a load balancer to do the 80 -> 8000 redirection, then they can start/stop the app. to their hearts' content.
The only time they need me is for OS/system issues (more disk space, I/O tuning, etc.)
I'm not trying to justify my job; I'm just trying to do a good one.
a) No, we don't do development on prod machines. Dev on dev machines, prod on prod machines. Test environments in the middle.
b) Development environments should NOT be a playground. It leads to sloppiness. What happens then is that something that works in test then doesn't work in prod. And who gets blamed? The sysadmin.
Dev/test should be a mirror image of production. Same hardware, same config, same OS, etc. This way, when you migrate code to prod, you know at least that the underlying system is the same.
I'm not talking about outbound Internet access. I'm talking about the Web servers that the app. teams themselves are running. They should run on, say, port 8000, and let the front-end load balancers in front of them do the 80 -> 8000 translation.
i.e.: I have systems "foo0" and "foo1". The virtual IP on the content switch has a hostname of "foo" attached to it.
The web server software runs on port 8000 on foo0 & foo1.
When a user hits port 80 on "foo", the content switch redirects them to foo0:8000 or foo1:8000, depending on several factors (load, response time, etc.)
It's a simple thing for the app teams to do, and saves us from having them require root access.
and it makes the dev/test environment look just like production. Which is yet again, a Good Thing.
--DM