People will think one of two things: "wee", or "why". They will either giggle, and not buy it, or wonder 'why" they should part with their money, and not buy it.
The problem is that your question is a bit vague. You want help 'managing' the IP space, but you don't indicate what 'managing' means to you. If you can be clearer about exactly what you want it to do, you'll probably get more useful suggestions.
Speakers are much more complex than that. WAY more complex than that. A 'flat response' says nothing whatsoever about impulse response and transient control, plus tons of other things that I, frankly, don't understand very well.
Sounds can be described in (at least) two ways: in the frequency domain, and in the time domain. Flat-frequency-response speakers with poor abilities in the time domain will sound like crap. If it takes longer, for instance, for treble to get through the crossover than bass, things will tend to sound a little muffled. If the cabinet has a resonance at a given frequency, it'll take a short time to develop, so tuning for a 'flat frequency response' to long-term sinewaves will screw up the transient response for that frequency. Cabinet resonance can also cause 'boom', frequencies that decay too slowly, which sweeps won't detect.
On top of that, you have all the ways the different drivers can interfere with each other; the typical mid-tweeter-mid design ends up having sound 'lobes' that can cause funny results depending on where you're listening from, and what frequencies are in the music being played.
Sound reproduction is really complex. Claiming that flat frequency response is 'end of story' is among the most clueless things I've seen on Slashdot. If it were really that simple, there would be only one speaker design in the whole world.
Computer people, in general, don't know shit about sound. You're one of them. You can fix that if you want to, but at the moment you are too ignorant to make useful comments.
If you'll note: in blind testing, there is essentially never a difference. I'm aware of exactly one instance in which cabling made a real difference in a system, and that was because both sending and receiving units were out of spec. Some cables would force the pair into audible failure, where other cables would just barely allow the two to work. Audiophiles raved about the 'revealing quality' of the units in combination, when in fact what they were hearing was the failure of bits to be correctly transmitted.
With competently-designed gear (and that doesn't mean expensive), cables never matter. If it did, you'd see blind testing case studies proving that. You NEVER see those. The reason is because there is essentially no difference between competently-made audio cables, no matter how much you spend on them. It's ALL snake oil. All of it. Buy your cabling at Home Depot or Lowe's.
With visual signals, you're much closer to the limits of copper for sending bandwidth, so you can definitely see some difference between cable designs. Audio signals, however, are very low-bandwidth.
While the subwoofer is big and boxy, as most subwoofers are, the satellites are, in my opinion, dead sexy. They come with grills, but they look so hot without them on I'm not sure why anyone without toddlers would want to put them on.
And they also sounded the best. This is not a surprise. Blind testing is important. They may actually sound better to the reviewer, but blind testing is required to be certain.
When I read this earlier, as soon as I saw that he strongly preferred the look of one of the speakers, I immediately predicted that he would like its sound the best. And, of course, he did.
It's important to do blind testing in audio. People just don't hear as well as they think they do.
Also note that everyone appears to hear differently. Vision is highly specialized, and differentiation between people is fairly low. That's why it's easy to pick out 'best' monitors, for instance. But audio isn't like that; each brain appears to figure out hearing a little differently. The brain uses, relatively speaking, very few neurons on auditory signals, which leads to (relatively) wide variations.
All sound reproduction is an illusion, and all speakers make tradeoffs, especially in the low end. It's important to listen to speakers for yourself, in blind testing, to find a set that fits your particular hearing strategy well.
Because of this, speaker reviews are much less useful than other kinds. Being geeks, we're used to being able to categorize and rank things by technical merit. Speakers just don't work like that.
Unfortunately, there's also a vast number of people in the audio business selling snake oil to take advantage of the poor hearing of most humans. So you DO have to listen for yourself.... but with BLIND testing. That's the only way to find out if a given effect is real, or just psychological.
I should amend... to hold antimatter for long periods takes huge amounts of equipment. They have figured out ways to transport it for short periods (an hour or two) with less stuff... but I don't think we can launch antimatter in 100kg. We could move it to the launch pad from cryo storage in a container that big, but I don't think it would last into orbit. So it'll be more expensive than I first though to get it launched... but it's still not going to pay for the trillions to build the facilities in orbit.
There's just no _reason_ to do that... antimatter is nonpolluting.
A matter/antimatter explosion emits gamma rays, which are non-polluting. Exposure to gamma radiation can certainly kill you, but it leaves no residual radiation behind.
I don't think you understand that it's not going to 'consume everything nearby'. That's just silly. If there are 10mg of antimatter, it would make a pretty darn big explosion, but it's only going to 'consume' 10mg of positive matter. The vast majority of the time, it'll be stored and transported in very small quantities, so that any individual accident won't matter much. They'll put the factories in isolated areas.
It'll be almost exactly like a conventional weapon factory, except that it's a lot more high-tech. We know how to deal with high explosives.
Again, antimatter leaves NO RESIDUAL RADIATION. If there is an accident, there's a flash of radiation and then nothing. If you weren't there at the instant of the accident, it will be perfectly safe to go in five minutes later to rescue people. With good shielding, even if there is a big explosion that blows through that shielding, it will already have done its work... the initial gamma-ray burst will be attenuated well before the conventional shockwave destroys the containment facility. A breach of the containment walls won't matter, because by the time they're breached, they've already done their job.
Even if there's a great big mushroom-cloud style matter/antimatter explosion, it will be perfectly safe downwind... there are no residual byproducts. If you're not within range of the initial burst of radiation, you're safe.
The _only_ real issue with antimatter is that you can pack a really giant explosion into a very small space. We can already make explosions larger than anything we'd ever need, so antimatter weapons won't make _that_ much difference on the battlefield. You might think antimatter would be stealthier, but that's actually not true, because the stuff is so enormously difficult to contain. It requires massive amounts of equipment to hold the antimatter in cryogenic, magnetically-locked storage. It CAN be moved around, but doing it stealthily would be far more difficult than conventional radioactive materials.
ANTIMATTER IS NOT NUCLEAR POWER. It's safer than even fusion power. It won't solve energy problems, because it's very inefficient and expensive to make (and requires more energy than you get out of it, obviously). But it will let us store huge amounts of power in very small spaces, and it will make space travel actually possible.
Your claim that 'antimatter belongs nowhere on Earth' is hysteria based in truthiness, not facts.
You can't have antimatter pollution. All you get is an explosion, of whatever size. Energy is released (and might kill some people), but there's no residual 'pollution' whatsoever.
With reasonable care, it's not really any different than any other kind of explosives plant. Probably less dangerous, since there are no noxious chemicals involved, which CAN pollute the environment.
Antimatter has so little weight per energy unit that it doesn't matter much where it's made. We need only ten milligrams to go to Mars. Even with the containment systems, that's probably not much more than 100kg or so. That's not free to launch, but compared with the cost and energy of making that antimatter in the first place, it's inconsequential. Making orbital antimatter factories would be supremely expensive, trillions of dollars, and all we'd be saving would be a couple of hundred thousand dollars, at most, per trip.
It would require _massive_ space traffic volume to pay for itself, and would have no other benefit whatsoever.
You know, you've got a good point here, overall. But I'm not sure it's ever going to fly in the Unix world.
It is possible to restrict root with packages like SELinux... maybe someone will use that to make Idiot-Proof Linux. (well.... Idiot-Resistant Linux, anyway.:) )
Look, I haven't run ext2 in probably six years. This post was about eight years ago. (I said 10 in another post: that's an error, I got a little exuberant.) I don't know what ext2 is like now. At the time, if you LOOKED at it funny it would fall over. It was fine as long as the box stayed up, but if it didn't, you had a problem, possibly a serious one. But I'm making NO claim whatsoever about its current status.
I'm just using ext2 as an example of the rabid pro-Linux mindset. When Linux is missing a feature, the feature isn't important and the user is stupid for wanting it. If Linux then develops the feature, suddenly it's a great thing and everyone wonders how they got along without it.
Oh please, that's such a strawman. All I said was (approximately, you gotta realize this was 10 years ago): "Linux isn't ready for the enterprise yet, because the filesystem is fragile. If you take a power hit, or lose a power supply, or the machine crashes, the filesystem is VERY likely to take damage, and the machine will take a long time to come back up. NT doesn't have this problem, and it's a glaring hole in Linux's feature set at the moment. It won't really be enterprise-ready until this is fixed." And I got piled on. (it also went to +5, so I don't think it was major flamebait or being rude. It was just stating facts.)
So MANY times, I've seen a new person ask, "How do I do X?" And if X is hard in Linux, fourteen people will inevitably say, "You don't want to do X." And a lot of them won't even say, "You should do Y instead." They just stop at "don't do X."
It's not as bad as it used to be, because so many things are so much easier now than they were. But go browse hard questions on Linux fora, and watch... you will inevitably see "Doing X is stupid", or some variant, with no alternative offered.
That's what I mean by dismissing user's needs; they want to do X, X is hard in Linux. That doesn't mean X is without value.
Let me give you an example; I remember it clearly because it was me. I was posting on the OpenBSD, um, mailing list or forum, I don't remember now, probably a mailing list. And I asked, "I'd like to do something like a PIX port trigger, where an outbound request opens an inbound port from that machine for a couple of seconds. I don't see a way to do this... am I missing something?" (I wanted this for the ident requests on IRC.) And I was immediately told, "that's stupid, it's no more secure than opening the port to the whole world." "What a dumb idea." (nevermind that Cisco thought it was useful enough to include, and I found it useful enough to want to duplicate.) Now, I'm not a world-class security expert, but it sure seems to me that opening one port briefly to a machine I call is a LOT more secure than opening the port to everyone, all the time, particularly when I'm running Windows. If it wasn't, then why even have stateful inspection firewalls in the first place?
Admittedly, the OpenBSD people know a _lot_ more about security than I do. But just telling me that it was a stupid idea, when I was hoping to duplicate the functionality I already had in my existing firewall, strikes me as more than a bit counter-productive. I asked if there was another way to get ident working, without opening the port to everyone 24x7. I think the only response I got was, "If you were running a decent operating system, you wouldn't have to worry about opening the port."
I've seen that over and over... if X is hard, there will inevitably be a batch of people who always say not to do it, and that it's a dumb idea in the first place, even if it really isn't. They invalidate the need, rather than address it in any meaningful way.
See, that's kind of the whole point of Unix.... total control. You can hose the entire system with one command, if you're root. It's done that way on purpose. If you're just a normal user, it should be impossible for you to do any serious damage... wiping out your own files, perhaps, but not take the system down. (in theory.. there is a constant stream of user level exploits, but those take a great deal of knowledge to use.)
That may never change. I'm reminded of the old adage 'with great power, comes great responsibility'. You have absolute control over the system; it'll let you do ANYTHING you want, even if it will wipe out the OS. Because, after all, perhaps that's exactly what you intend to do. Unix assumes, if you're root, you know what you're doing, and it will do precisely what you ask, no matter how hideously stupid it may be.
In the GGP's case, of course, he got bitten by an ext2 bug, which was unfortunate. So it wasn't robust in that particular case. But, by and large, the kernels of that era were extremely solid; they'd run and run and NEVER fall over. ('course, we weren't loading them as heavily as we do now, so maybe that was an illusion...)
Your expectation of 'make it newbie-proof' is just completely alien to Unix. I think the Mac probably gets closest, but even there, you can sudo your way to instant system death with no difficulty whatsoever.
You gotta realize, information about filesystems was not common knowledge in 1997. You apparently came from Unix, where you'd have been exposed to higher-end ideas. Most of us came up from DOS, and DOS was safe to just power off. So was NT, by and large, although it wasn't exactly recommended practice.
Linux was being pushed by the community as an alternative to NT, but this lack of a solid filesystem was a big issue that NOBODY talked about. And when I did bring it up, in a thread about Linux being 'ready for the enterprise' or something like that, I got jumped on and told that I was doing it all wrong.
And here you are, doing it again, just in a lot of words. "It's your responsibility...". Ok, I'll grant that, but it was YOUR responsibility, and the responsibility of all the other Linux zealots at the time, to TELL me that's what I needed to do. Before it broke, not after. That information was NOT widespread. I don't think there were any pre-97 FAQs that said 'you need a UPS to run a Linux machine safely'. If it's not documented, then you can hardly blame me for not knowing it, now can you?
At any rate, I fixed the server in question, and we didn't have serious downtime, because I had the spare... I was able to extract the zone files and move them over to the secondary in just a few minutes. I was usually able to fix filesystem problems, as they were generally pretty minor, although I really struggled with my Debian workstation one time... I didn't understand Unix that well yet, and it was a slog figuring out what needed fixing. So when 'Linux in the Enterprise' came up, I chimed in to say that the filesystem was terrible. Despite all the blame-gaming, you know what?
THE FILESYSTEM WAS TERRIBLE. And Linux wasn't ready for the enterprise. You can point your finger at me all you like, and it doesn't change that in any way, shape, or form. Ultimately, you're just doing a sophisticated version of what those people did... blame the user, not the software, when the software was obviously at fault. You're holding me responsible to know things that weren't, to my knowledge, documented.
They have probably improved the code, but I'm here to tell ya... in the Redhat 4.X days, ext2 was awful.
Ext3 is very solid... I have zero complaints about it. (well, okay, I have one... I wish it supported bigger files.) And XFS seems good, at least so far, although I've never beat on it to the same degree I have ext3.
Overall, Linux filesystems these days are very good. I trust them as much as I trust NTFS, and that's really saying something. NTFS is one thing Microsoft absolutely nailed. It fragments too much, but it's incredibly robust.
You're blaming me again. You're doing the same thing. It's my fault 'for not doing research'... it's not Linux's fault for having a terrible filesystem.
There WERE NO FSCKING DOCS back then; finding Linux info was *hard*. There was no Google. Maybe you're too young to remember the early internet, but it wasn't like it is now... it took real digging to find stuff, and it was easily possible to miss huge treasure troves of info. I read Slashdot constantly, and hung out at other sites I saw mentioned, and I still found out about ext2 the hard way.
Let me emphasize this to you again: the fact that ext2 breaks is not my fscking fault. Don't blame the user for showing problems in the code.
I wasn't going here for support, I was making the observation that ext2 was fragile, and that I had lost data from it. And immediately, it was all my fault.
I was saying, and rightly so, that Linux wasn't ready for business yet, and wouldn't be until it had a better filesystem. This was approximately like pouring blood in the water; the sharks showed up minutes later.
After ext3 and Reiser went mainstream, Linux was finally ready for primetime... and then everyone agreed that ext2 was really awful. It was funny, but also rather sad.
If the user wants your software to do something it doesn't do, that does not mean the user OR the request is stupid. Dismissing needs is probably the second cardinal sin of opensource developers. If something is hard to do, there is always a chorus telling a user that they "don't want to do it that way", even if it's completely obvious that they do, and even if the chorus has no alternate suggestion.
I'm not saying we're obligated to help them; sometimes people are just rude. But I've seen a lot of insults thrown (including at me) just for being ignorant. Ignorance is curable. It doesn't mean stupidity, and an awful lot of people forget that.
Then, of course, you get guys like the Tuttle City Manager, who I'd happily have told to take a long walk off a short pier, except in much cruder terms. So while I may decry the 'blame the user' mentality, I'm not entirely immune to it.:)
Slashdot Mirror
Which also prompts the thought... if the console is the Wii, will the new, ground-breaking controller be the Wiimote?
People will think one of two things: "wee", or "why". They will either giggle, and not buy it, or wonder 'why" they should part with their money, and not buy it.
There's a common theme here: not buying it.
This is the all-time stupidest name EVER.
The problem is that your question is a bit vague. You want help 'managing' the IP space, but you don't indicate what 'managing' means to you. If you can be clearer about exactly what you want it to do, you'll probably get more useful suggestions.
Speakers are much more complex than that. WAY more complex than that. A 'flat response' says nothing whatsoever about impulse response and transient control, plus tons of other things that I, frankly, don't understand very well.
Sounds can be described in (at least) two ways: in the frequency domain, and in the time domain. Flat-frequency-response speakers with poor abilities in the time domain will sound like crap. If it takes longer, for instance, for treble to get through the crossover than bass, things will tend to sound a little muffled. If the cabinet has a resonance at a given frequency, it'll take a short time to develop, so tuning for a 'flat frequency response' to long-term sinewaves will screw up the transient response for that frequency. Cabinet resonance can also cause 'boom', frequencies that decay too slowly, which sweeps won't detect.
On top of that, you have all the ways the different drivers can interfere with each other; the typical mid-tweeter-mid design ends up having sound 'lobes' that can cause funny results depending on where you're listening from, and what frequencies are in the music being played.
Sound reproduction is really complex. Claiming that flat frequency response is 'end of story' is among the most clueless things I've seen on Slashdot. If it were really that simple, there would be only one speaker design in the whole world.
Computer people, in general, don't know shit about sound. You're one of them. You can fix that if you want to, but at the moment you are too ignorant to make useful comments.
heh, my INT is low enough that I forgot to tell you what INT is. INT and WIS are Intelligence and Wisdom.
You're not geeky enough to have played D&D, I guess. :)
And the truly braindead -- including yours truly, of course -- know what INT and WIS mean.
If you'll note: in blind testing, there is essentially never a difference. I'm aware of exactly one instance in which cabling made a real difference in a system, and that was because both sending and receiving units were out of spec. Some cables would force the pair into audible failure, where other cables would just barely allow the two to work. Audiophiles raved about the 'revealing quality' of the units in combination, when in fact what they were hearing was the failure of bits to be correctly transmitted.
With competently-designed gear (and that doesn't mean expensive), cables never matter. If it did, you'd see blind testing case studies proving that. You NEVER see those. The reason is because there is essentially no difference between competently-made audio cables, no matter how much you spend on them. It's ALL snake oil. All of it. Buy your cabling at Home Depot or Lowe's.
With visual signals, you're much closer to the limits of copper for sending bandwidth, so you can definitely see some difference between cable designs. Audio signals, however, are very low-bandwidth.
And they also sounded the best. This is not a surprise. Blind testing is important. They may actually sound better to the reviewer, but blind testing is required to be certain.
When I read this earlier, as soon as I saw that he strongly preferred the look of one of the speakers, I immediately predicted that he would like its sound the best. And, of course, he did.
It's important to do blind testing in audio. People just don't hear as well as they think they do.
Also note that everyone appears to hear differently. Vision is highly specialized, and differentiation between people is fairly low. That's why it's easy to pick out 'best' monitors, for instance. But audio isn't like that; each brain appears to figure out hearing a little differently. The brain uses, relatively speaking, very few neurons on auditory signals, which leads to (relatively) wide variations.
All sound reproduction is an illusion, and all speakers make tradeoffs, especially in the low end. It's important to listen to speakers for yourself, in blind testing, to find a set that fits your particular hearing strategy well.
Because of this, speaker reviews are much less useful than other kinds. Being geeks, we're used to being able to categorize and rank things by technical merit. Speakers just don't work like that.
Unfortunately, there's also a vast number of people in the audio business selling snake oil to take advantage of the poor hearing of most humans. So you DO have to listen for yourself.... but with BLIND testing. That's the only way to find out if a given effect is real, or just psychological.
Job Qualification: You must be presentable, affable, and be able to lie brazenly while keeping a straight face.
I should amend... to hold antimatter for long periods takes huge amounts of equipment. They have figured out ways to transport it for short periods (an hour or two) with less stuff... but I don't think we can launch antimatter in 100kg. We could move it to the launch pad from cryo storage in a container that big, but I don't think it would last into orbit. So it'll be more expensive than I first though to get it launched... but it's still not going to pay for the trillions to build the facilities in orbit.
There's just no _reason_ to do that... antimatter is nonpolluting.
A matter/antimatter explosion emits gamma rays, which are non-polluting. Exposure to gamma radiation can certainly kill you, but it leaves no residual radiation behind.
I don't think you understand that it's not going to 'consume everything nearby'. That's just silly. If there are 10mg of antimatter, it would make a pretty darn big explosion, but it's only going to 'consume' 10mg of positive matter. The vast majority of the time, it'll be stored and transported in very small quantities, so that any individual accident won't matter much. They'll put the factories in isolated areas.
It'll be almost exactly like a conventional weapon factory, except that it's a lot more high-tech. We know how to deal with high explosives.
Again, antimatter leaves NO RESIDUAL RADIATION. If there is an accident, there's a flash of radiation and then nothing. If you weren't there at the instant of the accident, it will be perfectly safe to go in five minutes later to rescue people. With good shielding, even if there is a big explosion that blows through that shielding, it will already have done its work... the initial gamma-ray burst will be attenuated well before the conventional shockwave destroys the containment facility. A breach of the containment walls won't matter, because by the time they're breached, they've already done their job.
Even if there's a great big mushroom-cloud style matter/antimatter explosion, it will be perfectly safe downwind... there are no residual byproducts. If you're not within range of the initial burst of radiation, you're safe.
The _only_ real issue with antimatter is that you can pack a really giant explosion into a very small space. We can already make explosions larger than anything we'd ever need, so antimatter weapons won't make _that_ much difference on the battlefield. You might think antimatter would be stealthier, but that's actually not true, because the stuff is so enormously difficult to contain. It requires massive amounts of equipment to hold the antimatter in cryogenic, magnetically-locked storage. It CAN be moved around, but doing it stealthily would be far more difficult than conventional radioactive materials.
ANTIMATTER IS NOT NUCLEAR POWER. It's safer than even fusion power. It won't solve energy problems, because it's very inefficient and expensive to make (and requires more energy than you get out of it, obviously). But it will let us store huge amounts of power in very small spaces, and it will make space travel actually possible.
Your claim that 'antimatter belongs nowhere on Earth' is hysteria based in truthiness, not facts.
You can't have antimatter pollution. All you get is an explosion, of whatever size. Energy is released (and might kill some people), but there's no residual 'pollution' whatsoever.
With reasonable care, it's not really any different than any other kind of explosives plant. Probably less dangerous, since there are no noxious chemicals involved, which CAN pollute the environment.
Antimatter has so little weight per energy unit that it doesn't matter much where it's made. We need only ten milligrams to go to Mars. Even with the containment systems, that's probably not much more than 100kg or so. That's not free to launch, but compared with the cost and energy of making that antimatter in the first place, it's inconsequential. Making orbital antimatter factories would be supremely expensive, trillions of dollars, and all we'd be saving would be a couple of hundred thousand dollars, at most, per trip.
It would require _massive_ space traffic volume to pay for itself, and would have no other benefit whatsoever.
You know, you've got a good point here, overall. But I'm not sure it's ever going to fly in the Unix world.
:) )
It is possible to restrict root with packages like SELinux... maybe someone will use that to make Idiot-Proof Linux. (well.... Idiot-Resistant Linux, anyway.
Look, I haven't run ext2 in probably six years. This post was about eight years ago. (I said 10 in another post: that's an error, I got a little exuberant.) I don't know what ext2 is like now. At the time, if you LOOKED at it funny it would fall over. It was fine as long as the box stayed up, but if it didn't, you had a problem, possibly a serious one. But I'm making NO claim whatsoever about its current status.
I'm just using ext2 as an example of the rabid pro-Linux mindset. When Linux is missing a feature, the feature isn't important and the user is stupid for wanting it. If Linux then develops the feature, suddenly it's a great thing and everyone wonders how they got along without it.
What part of '10 years ago', didn't you understand?
Oh please, that's such a strawman. All I said was (approximately, you gotta realize this was 10 years ago): "Linux isn't ready for the enterprise yet, because the filesystem is fragile. If you take a power hit, or lose a power supply, or the machine crashes, the filesystem is VERY likely to take damage, and the machine will take a long time to come back up. NT doesn't have this problem, and it's a glaring hole in Linux's feature set at the moment. It won't really be enterprise-ready until this is fixed." And I got piled on. (it also went to +5, so I don't think it was major flamebait or being rude. It was just stating facts.)
So MANY times, I've seen a new person ask, "How do I do X?" And if X is hard in Linux, fourteen people will inevitably say, "You don't want to do X." And a lot of them won't even say, "You should do Y instead." They just stop at "don't do X."
It's not as bad as it used to be, because so many things are so much easier now than they were. But go browse hard questions on Linux fora, and watch... you will inevitably see "Doing X is stupid", or some variant, with no alternative offered.
That's what I mean by dismissing user's needs; they want to do X, X is hard in Linux. That doesn't mean X is without value.
Let me give you an example; I remember it clearly because it was me. I was posting on the OpenBSD, um, mailing list or forum, I don't remember now, probably a mailing list. And I asked, "I'd like to do something like a PIX port trigger, where an outbound request opens an inbound port from that machine for a couple of seconds. I don't see a way to do this... am I missing something?" (I wanted this for the ident requests on IRC.) And I was immediately told, "that's stupid, it's no more secure than opening the port to the whole world." "What a dumb idea." (nevermind that Cisco thought it was useful enough to include, and I found it useful enough to want to duplicate.) Now, I'm not a world-class security expert, but it sure seems to me that opening one port briefly to a machine I call is a LOT more secure than opening the port to everyone, all the time, particularly when I'm running Windows. If it wasn't, then why even have stateful inspection firewalls in the first place?
Admittedly, the OpenBSD people know a _lot_ more about security than I do. But just telling me that it was a stupid idea, when I was hoping to duplicate the functionality I already had in my existing firewall, strikes me as more than a bit counter-productive. I asked if there was another way to get ident working, without opening the port to everyone 24x7. I think the only response I got was, "If you were running a decent operating system, you wouldn't have to worry about opening the port."
I've seen that over and over... if X is hard, there will inevitably be a batch of people who always say not to do it, and that it's a dumb idea in the first place, even if it really isn't. They invalidate the need, rather than address it in any meaningful way.
See, that's kind of the whole point of Unix.... total control. You can hose the entire system with one command, if you're root. It's done that way on purpose. If you're just a normal user, it should be impossible for you to do any serious damage... wiping out your own files, perhaps, but not take the system down. (in theory.. there is a constant stream of user level exploits, but those take a great deal of knowledge to use.)
That may never change. I'm reminded of the old adage 'with great power, comes great responsibility'. You have absolute control over the system; it'll let you do ANYTHING you want, even if it will wipe out the OS. Because, after all, perhaps that's exactly what you intend to do. Unix assumes, if you're root, you know what you're doing, and it will do precisely what you ask, no matter how hideously stupid it may be.
In the GGP's case, of course, he got bitten by an ext2 bug, which was unfortunate. So it wasn't robust in that particular case. But, by and large, the kernels of that era were extremely solid; they'd run and run and NEVER fall over. ('course, we weren't loading them as heavily as we do now, so maybe that was an illusion...)
Your expectation of 'make it newbie-proof' is just completely alien to Unix. I think the Mac probably gets closest, but even there, you can sudo your way to instant system death with no difficulty whatsoever.
You gotta realize, information about filesystems was not common knowledge in 1997. You apparently came from Unix, where you'd have been exposed to higher-end ideas. Most of us came up from DOS, and DOS was safe to just power off. So was NT, by and large, although it wasn't exactly recommended practice.
Linux was being pushed by the community as an alternative to NT, but this lack of a solid filesystem was a big issue that NOBODY talked about. And when I did bring it up, in a thread about Linux being 'ready for the enterprise' or something like that, I got jumped on and told that I was doing it all wrong.
And here you are, doing it again, just in a lot of words. "It's your responsibility...". Ok, I'll grant that, but it was YOUR responsibility, and the responsibility of all the other Linux zealots at the time, to TELL me that's what I needed to do. Before it broke, not after. That information was NOT widespread. I don't think there were any pre-97 FAQs that said 'you need a UPS to run a Linux machine safely'. If it's not documented, then you can hardly blame me for not knowing it, now can you?
At any rate, I fixed the server in question, and we didn't have serious downtime, because I had the spare... I was able to extract the zone files and move them over to the secondary in just a few minutes. I was usually able to fix filesystem problems, as they were generally pretty minor, although I really struggled with my Debian workstation one time... I didn't understand Unix that well yet, and it was a slog figuring out what needed fixing. So when 'Linux in the Enterprise' came up, I chimed in to say that the filesystem was terrible. Despite all the blame-gaming, you know what?
THE FILESYSTEM WAS TERRIBLE. And Linux wasn't ready for the enterprise. You can point your finger at me all you like, and it doesn't change that in any way, shape, or form. Ultimately, you're just doing a sophisticated version of what those people did... blame the user, not the software, when the software was obviously at fault. You're holding me responsible to know things that weren't, to my knowledge, documented.
They have probably improved the code, but I'm here to tell ya... in the Redhat 4.X days, ext2 was awful.
Ext3 is very solid... I have zero complaints about it. (well, okay, I have one... I wish it supported bigger files.) And XFS seems good, at least so far, although I've never beat on it to the same degree I have ext3.
Overall, Linux filesystems these days are very good. I trust them as much as I trust NTFS, and that's really saying something. NTFS is one thing Microsoft absolutely nailed. It fragments too much, but it's incredibly robust.
You're blaming me again. You're doing the same thing. It's my fault 'for not doing research'... it's not Linux's fault for having a terrible filesystem.
There WERE NO FSCKING DOCS back then; finding Linux info was *hard*. There was no Google. Maybe you're too young to remember the early internet, but it wasn't like it is now... it took real digging to find stuff, and it was easily possible to miss huge treasure troves of info. I read Slashdot constantly, and hung out at other sites I saw mentioned, and I still found out about ext2 the hard way.
Let me emphasize this to you again: the fact that ext2 breaks is not my fscking fault. Don't blame the user for showing problems in the code.
And, as the AC says, you are doing exactly what I am talking about. You are blaming ME for the problem.
I wasn't going here for support, I was making the observation that ext2 was fragile, and that I had lost data from it. And immediately, it was all my fault.
I was saying, and rightly so, that Linux wasn't ready for business yet, and wouldn't be until it had a better filesystem. This was approximately like pouring blood in the water; the sharks showed up minutes later.
After ext3 and Reiser went mainstream, Linux was finally ready for primetime... and then everyone agreed that ext2 was really awful. It was funny, but also rather sad.
If the user wants your software to do something it doesn't do, that does not mean the user OR the request is stupid. Dismissing needs is probably the second cardinal sin of opensource developers. If something is hard to do, there is always a chorus telling a user that they "don't want to do it that way", even if it's completely obvious that they do, and even if the chorus has no alternate suggestion.
I'm not saying we're obligated to help them; sometimes people are just rude. But I've seen a lot of insults thrown (including at me) just for being ignorant. Ignorance is curable. It doesn't mean stupidity, and an awful lot of people forget that.
:)
Then, of course, you get guys like the Tuttle City Manager, who I'd happily have told to take a long walk off a short pier, except in much cruder terms. So while I may decry the 'blame the user' mentality, I'm not entirely immune to it.