Well, there is a good reason, you just don't know what it is!
I agree though, sometimes a reboot will fix problems you don't have the time, knowledge or tools to identify and resolve methodically. It's about business priorities.
I run webmail and stuff from home. I went on holiday a few weeks back - half way through the trip I went to an ISP (in Budapest, I believe they were running Windows 95 on 486s, at least it felt that way) and I couldn't access my server. This has never happened to me in several years. I thought the fan on my athlon must have given up the ghost, or my block must have burned down. I mean, I run Debian and as everyone knows, Debian never lets you down. Call me a troll, but it's true.
Got home, turned out there had been lots of electrical storms while I was away. my ADSL modem's lights were all on - not normal. A reboot (of the modem) fixed that. I'm thinking of putting it on a timer switch now, to restart at 3am every night...
You know, you can just say camp, it serves both as adjective and noun. Campy and campiness are indeed (colloquial) words but sopisticates just say camp, saving key presses, syllables and bandwidth in the process.
If it's a supply and demand thing, encouraging someone to get their dog from a shelter is going to - SURPRISE! - reduce the demand!
Or maybe you think shelters are buying dogs from breeders.
Do you really think the people who mistreat animals (and abandoning a dog is obviously mistreatment) are going to listen to someone telling them not to buy dogs?
1st two points (stable/testing/unstable) - how do you *suggest* it should work? testing is in no way as hit-or-miss as you suggest, I run a mix of testing and unstable on my desktop and laptop and never have stability issues or upgrade problems.
3rd point (dependency hell) - again, tell me the alternative? One of the big advantages of open source is that people build on other people's work - so you end up with dependencies. If we didn't have dependencies we would have duplicate effort and you'd be whinging about the slow pace of progress.
4th point (different versions of -dev packages) - if the includes conflict its for a reason. If you're doing complex dev work just get the frigging tarball.
5th point - (apt-get is one way) - sorry, it's not. apt-get install packagename/stable will take me back from a testing or unstable version.
6th point - (repository quality) - well, how the hell is that a problem with apt-get? It's a problem with your choice of repository!
DB2 client is so our scripts can have databases behind them. I'd use Postgres or MySQL but I'm in a middleware team, not DBA. I'll leave database admin to the DBAs and the strategic platform is DB2.
I see the need for backups, but it's beyond me why the strategic backup solution should dictate choice of platform.
"What-not" is WebSphere, running in a non-production capacity - for testing scripts.
We've been doing perl work on AIX for a couple of years and we always end up compiling perl modules, and we always hit problems. Undoubtedly RedHat or SuSE would be better. But I count only 25 perl modules in RHES 3.
Important apps right enough but they're not line-of-business.
Also, the IBM software I want to use is incidental to the purpose of the system. It's about fitting in to the "enterprise".
It's amazing the assumptions people will make in order to be condescending. That's not aimed only at you, there are many other posts saying things like:
If it's already working, don't fix it (this is a *new* system)
Only a crazy would run their production apps on Debian (I disagree but in any case this is NOT LOB production, it is a deployment system for development environments through to production. It's also going to be a sandbox for my team)
You can get APT for RPM (my preference for Debian is less to do with APT and more to do with the number and quality of pre-packaged debs available via apt-get
Oh well. Luckily a few people gave me notes about their experience, which is what I asked for.
We don't have a working system, this is a new system for a particular job.
The only IBM software we need to use in "production" is a DB2 client and probably a TSM agent. We could avoid the TSM agent.
We would probably want to run WebSphere on it for testing purposes - testing of scripts before they reach the environments our developers use.
My concerns are more about persuading management that an "unsupported" distribution could be a goer, and what I expect to be a small number if contacts with IBM support.
So I understand your thinking, but in this case it's misplaced.
No good reason, it just helps.
Well, there is a good reason, you just don't know what it is!
I agree though, sometimes a reboot will fix problems you don't have the time, knowledge or tools to identify and resolve methodically. It's about business priorities.
I run webmail and stuff from home. I went on holiday a few weeks back - half way through the trip I went to an ISP (in Budapest, I believe they were running Windows 95 on 486s, at least it felt that way) and I couldn't access my server. This has never happened to me in several years. I thought the fan on my athlon must have given up the ghost, or my block must have burned down. I mean, I run Debian and as everyone knows, Debian never lets you down. Call me a troll, but it's true.
Got home, turned out there had been lots of electrical storms while I was away. my ADSL modem's lights were all on - not normal. A reboot (of the modem) fixed that. I'm thinking of putting it on a timer switch now, to restart at 3am every night...
So yeah these people should basically be shot.
Ignore me, I was looking at yesterday's 18:30...
Idiot!
In fact, it's not so much a pimple as part of the evening curve. That is, it doesn't drop off from the peak, it just continues through the night.
Maybe all the Slashdotters listened on for The Archers and Front Row.
You missed the wooden ones, they're not up to much.
And the ones you get in hotels which can't be removed from the wardrobe. No good either.
particularly all the students...
Exactly, we all know how old most students are.
mplayer. But you've missed it.
It might be up on "Listen Again", though.
Yeah, I've just finished listening. It wasn't quite the same without PJ, but the overall feel was very H2G2.
I didn't like the mattress much.
Otherwise, excellent.
30'-style campiness
You know, you can just say camp, it serves both as adjective and noun. Campy and campiness are indeed (colloquial) words but sopisticates just say camp, saving key presses, syllables and bandwidth in the process.
Thank you for your co-operation.
The way to mod down a submitter is not to post comments on the story.
Given the story has generated many comments, it at least has merit as a diversion for the Slashdot hordes.
Hi, how r u?
consumer orientated (as opposed to corporation), for profit implementation of some of the neat Linux tools I read about on Slashdot all the time.
You mean something like a Tivo?
You misesd out the all important "However, for the enthusiast..." prefix to the MythTV praise.
And I think you'll find similar logic applying in the BMW/Ford comparison.
Thanks, note taken.
So they get brownie points for not breeching someone's license? How considerate of you (and the reviewer).
If it's a supply and demand thing, encouraging someone to get their dog from a shelter is going to - SURPRISE! - reduce the demand!
Or maybe you think shelters are buying dogs from breeders.
Do you really think the people who mistreat animals (and abandoning a dog is obviously mistreatment) are going to listen to someone telling them not to buy dogs?
Get real.
Yes, based on my knowledge of the circumstances I had made up my mind that Debian was the best tool for the job.
I asked for people's experiences. I mostly got people questioning my decision, which, given they didn't know the circumstances, was presumtious.
Got that?
If only there were some way to get them to read the proxy.pac file...
Interesting idea, would require a javascript interpreter somewhere though.
Failing that, why not just wget the pac file and read it to get an address, the set http_proxy and/or ftp_proxy environment variables?
And of course that could be be stuck in a script if the pac file is simple enough.
1st two points (stable/testing/unstable) - how do you *suggest* it should work? testing is in no way as hit-or-miss as you suggest, I run a mix of testing and unstable on my desktop and laptop and never have stability issues or upgrade problems.
3rd point (dependency hell) - again, tell me the alternative? One of the big advantages of open source is that people build on other people's work - so you end up with dependencies. If we didn't have dependencies we would have duplicate effort and you'd be whinging about the slow pace of progress.
4th point (different versions of -dev packages) - if the includes conflict its for a reason. If you're doing complex dev work just get the frigging tarball.
5th point - (apt-get is one way) - sorry, it's not. apt-get install packagename/stable will take me back from a testing or unstable version.
6th point - (repository quality) - well, how the hell is that a problem with apt-get? It's a problem with your choice of repository!
Basically you're a trolling whinger, please STFU.
Well done for ostracising the teetotallers, homosexuals and women on the team.
Well, it was kind of a joke based on a comment here, but thanks for taking it so seriously.
That'll be the end of OpenGL then!
Just as 2.0 came out...
I appreciate your comments, but here's how it is.
The production code running on the box will be:
* Apache
* In-house perl scripts lots of them
DB2 client is so our scripts can have databases behind them. I'd use Postgres or MySQL but I'm in a middleware team, not DBA. I'll leave database admin to the DBAs and the strategic platform is DB2.
I see the need for backups, but it's beyond me why the strategic backup solution should dictate choice of platform.
"What-not" is WebSphere, running in a non-production capacity - for testing scripts.
So, why Debian? Here's one reason:
leela% apt-cache search perl|grep -c '^lib.*-perl'
764
764 perl modules, one shell command away.
We've been doing perl work on AIX for a couple of years and we always end up compiling perl modules, and we always hit problems. Undoubtedly RedHat or SuSE would be better. But I count only 25 perl modules in RHES 3.
That's one reason.
Important apps right enough but they're not line-of-business.
Also, the IBM software I want to use is incidental to the purpose of the system. It's about fitting in to the "enterprise".
It's amazing the assumptions people will make in order to be condescending. That's not aimed only at you, there are many other posts saying things like:
Oh well. Luckily a few people gave me notes about their experience, which is what I asked for.
No, I have anecdotal evidence that the software I need to hook the system up to our enterprise will work (for backups, database access).
I have ample justification that Debian is the right technical solution for the job I am trying to do.
See, they are different things. Doing a job, and fitting in to a pre-existing infrastructure.
We don't have a working system, this is a new system for a particular job.
The only IBM software we need to use in "production" is a DB2 client and probably a TSM agent. We could avoid the TSM agent.
We would probably want to run WebSphere on it for testing purposes - testing of scripts before they reach the environments our developers use.
My concerns are more about persuading management that an "unsupported" distribution could be a goer, and what I expect to be a small number if contacts with IBM support.
So I understand your thinking, but in this case it's misplaced.