Since organized religion has been heavily involved with some of the worst atrocities that humans have committed against their fellows, I see nothing inconsistent about mafiosos going to Church.
That's where I disagree. Besides Mandrake I just don't think the quality is that much higher, if at all compared to other distros. I also think when you weigh in ease of use and well designed management and setup tools Debian comes up severly lacking.
Debian is NOT a consumer operating system. Whilst Debian isn't suitable for your average home user, it's eminently suitable for the server. It's a lot easier to maintain than, say, RedHat on the server. For people who know what they are doing, the set up tools are not lacking at all.
There is a fallacy about the "pointy clicky" to do everything. On the home desktop that's fine and appropriate. However, if a server administrator can't cope with Debian, they have no business running a server - even a Windows server. Running a real server (that you don't want to be rooted) requires real knowledge, and a person who can command this knowledge is the type of administrator you need whether it's Windows or Solaris or Debian or RedHat.
And this is where so many organizations get into trouble with Windows. They think that because it's point and click, they can hire a cheap (for want of a better term) 'reboot monkey' as an administrator, where in reality Windows is _just as complex_ as a modern Unix-type operating system.
I've got the book written by the co-pilot of the Nagasaki nuclear attack mission - there are logs in the appendices of the book, and one of the crew observations was that crew with fillings (most of them! how dental hygiene has improved since then...) felt the EMP through their fillings as a tingle.
The risk tolerance must be *incredibly* low to believe that eating fish from the Irish Sea is a "risky activity". The biggest risk by orders of magnitude of eating fish from the Irish Sea is choking on a fish bone.
The thing is with TMI - IIRC, no one was even *injured* let alone killed. The design was such that when the shit really did hit the fan, the damage could be contained.
I can't really comment on the first problem - I've not done any serious C++ programming for a couple of years (and you didn't show the specific example).
However, just for fun I decided to time how long it took me to do (2). In Perl, it took 4 minutes. You may say that using Perl rather than C++ was cheating, but I consider it using the right tool for the job.
Your comment is absolutely spot on, and I wish I could mod it up to +6.
It's by far not the only reason why software projects fail, but it's often a big factor. We've just gone through something we call "Business process re-engineering" to avoid precisely the pitfall you describe. The resistance to structural changes to the business (STILL using processes from the prior business it was part of in 1973, which had just been "spreadsheeted over" with no thought to WHY we are still doing this) met enormous resistance. Fortunately, many of the stakeholders were involved in the whole process of trying to make the business infrastructure actually make sense, so it's actually going ahead.
Now, at the "corporate" level (which is actually Government, I'm a contractor for an Authority of the government, which essentially is a business) is deciding to have this big project where they join all the systems up, giving shedloads of money to $BIGCORP who will be essentially the system integrator. As far as I can see, they are doing this whole project and they *haven't even thought* about the restructuring they'll need to mean they aren't just codifying their existing practises in a morass of sphagetti-like mush. Unless they re-engineer their working practises, I confidently predict that the project will overrun on cost, will overrun on time, and might not even work. What's worse is that $BIGCORP, desperate for the contract because they want to sell 'e-gov' solutions is going to rush a proof-of-concept, and management seeing nice clicky squishy buttons on a mock-up will think most of the work is done, and will then pressure the vendor to come up with the goods with an unrealistic schedule.
My last contract was for the United States Postal Service and they just codified their existing practises - it took *two million lines of code* just for the counter system! Sadly, when I started on the contract I was so green I needed mowing so I didn't see it coming (not that I could have probably done anything but tell deaf ears what I thought was wrong anyway). Absolutely no regard was given to "How could we use the software to make our business practises *better*"? The result: an inflexible system that's expensive to change. We essentially turned the entire Domestic Mailing Manual and International Mailing Manual plus a bunch of accounting procedures into a mass of C++ code. No regard as far as I could tell was given to how processes could be changed to make them more ameniable to automation, and serve the customer better!
The users complaining about X are generally the users who have just enough knowledge to be dangerous. Virtually every time people whine and bitch about X, all their complaints are really complaints about the toolkit and not X at all.
No one uses X directly these days. My Dad has no problem with an X based system, he just points and clicks at Kmail, or Openoffice or whatever. He wouldn't know what an X server was if it bit him on the bum. He doesn't complain about X or even Qt. He just moans when someone emails him a Microsoft executable and he can't run it (which I keep explaining to him is entirely the point).
X doesn't need to be thrown out - it does what it's designed to do well. What needs to be done is the toolkits need to be improved - and that's happening. The K Desktop Environment is getting better with each release. So is Gnome. X is merely a low level component that nearly everyone is insulated from now, but which makes my desktop more useful than a Windows desktop.
I'm sure you could have said that when it was discovered you could accelerate electrons off a cathode in a vacuum. However, you now have a very good electron accelerator in your living room - your TV's picture tube.
The discovery of strange subatomic particles may seem irrelevant right now, but they may well be the link we need to cure disease, or prevent hunger.
Your sort of reasoning is incredibly short sighted, and it's a good job that the people who fund physics research don't subscribe to your point of view, or our homes would still be lit by gas lamps.
No, it's extremely SMART to have a buy nothing day on the biggest shopping day of the year - not because of any principle in particular, but because shopping on the day after Thanksgiving is fscking awful - parking lots all full, traffic jams, malls full of screaming children and angry parents, massive checkout lines. It is NOT a pleasant experience.
I try and do all my shopping at off-peak times so I can get somewhere to park and get in and out of a shop as quickly as possible: mainly because I detest shopping.
I find installing Linux and installing Windows XP on current hardware to be about the same level of difficulty - i.e. not particularly difficult. I don't see what's so difficult about booting a RH CD, selecting some packages, and periodically feeding the machine disks. I've not found any mainstream hardware since running RH 7.1 which the graphical installer didn't work. Unlike Windows, I've not needed to feed it additional driver disks AFTER the install on the hardware I've been using recently.
Windows and Linux are as difficult as each other to maintain _properly_. Both are complex systems. Both can easily be fscked up by someone who knows no more than how to click on pretty widgets. It's a myth that Windows is somehow easier to maintain properly - it isn't. It's easier to maintain improperly though. It's a false economy for a company to hire a cheap Windows admin, because they will get a reboot monkey. A Windows admin worth his salt will be expecting the same salary as a Unix admin.
There's no point going to the extra effort to think up and write a good summary, because the vast majority of articles just get rejected. It's not worth the submitter's time.
What XCOR is doing is very interesting, and I wish them every success. I was there for the unveiling of their rocket technology in Mojave, CA. when they flew the rockets (actually for the second time) on a Long-Ez. You can see my writeup of it here (at the risk of a slight Slashdotting).
No, Linus says he's just not interested in the server. Doesn't mean the kernel is no good for the server. Linus also said that Linux would be for the i386 only during his argument with ast. That seems to be not true either.
Just because Linus wants to do his thing with the desktop, it doesn't mean that others will stop working on the server side. Just like Lou Gerstner came from a biscuit making conglomerate, it doesn't mean he was going to turn IBM into a food and beverage company.
It's bloated? We are on X11R6. I used to run X11R6 on a 486 with 16MB of RAM. Hardly bloated. The bloated things are the *toolkits*. Not X.
It's slow? Not in the slightest. It ran fast on a 486, it runs blindingly fast on a P4-2GHz. The slowness is from the *toolkits*.
It's not very good for modern gaming? I run RTCW:ET in 1600x1200 under X with my GeForce 4. Frame rates are perfectly acceptable.
Poor scaling? Dunno about very high res LCDs, but it's fine on my 1600x1200 Trinitron. Again, scaling is a *toolkit* issue.
Royal pain in the ass to get set up? Not since I owned that 486. X has been a simple install from $DISTRIBUTION and has worked first time on every machine I've installed it on in at least the last 4 years.
It doesn't have a high level of standardization? Again a *toolkit* problem. X itself is *highly* standardized. It supports stuff on hundreds of different architectures. I can send the output of a program running on a Sun UltraSPARC system to a Pentium based system using the networking features. Try that with Windows or OSX.
Who really needs network transparency? Well, why is Terminal Services on Windows proving so popular? Unix/X users have been able to do this since 1986. It's a feature I find incredibly useful.
It's a royal pain in the ass to program on. So is basicWin32. I should imagine the low level Mac OSX stuff is too. This is why we use *toolkits*.
It doesn't lock on tight enough etc. Doesn't seem to be a problem for the games I've been playing.
Presentation layer living in the kernel is the WORST idea you've presented. That's not what the kernel is there for.
All the things you've written about saying why X sucks are *nothing* to do with X at all - they are all toolkit issues. Most people who think X should be kicked out genuinely don't understand X. X at its heart is actually a pretty lean, fast machine. It's flexible. The designers had a LOT of foresight. It's extensible.
This is what makes me wonder about job interviews: many interviewers ask some simple C++ (or $LANGUAGE question) when they should be really testing the applicant on their understanding of the building blocks of software engineering. It's a sort of the cart-leading-the-horse thing.
The other aggravating thing about the recruitment process is that it often goes to HR to do, who are clueless. You advertise saying 'We need a software engineer. We are using $FOO language' and HR throws out any CV (tr. US: resume) from a software engineer who has good non-language specific SW engineering education and ten years experience, and calls in the guy who's got 2 years experience in $FOO language, but obviously from their CV is just a code monkey, not a software engineer.
Actually (AFAIK) the vacuum line to the brake booster has a check valve in it for just this reason. Even if the rest of the car were to loose vacuum, there should still be some stored in the brake booster to help the old laty stop. Also, even if she has an auto, the wheels are still going to be coupled to the engine. Try driving down a hill in drive, and then driving down it in neutral
The remaining vacuum in the servo is about good for one brake application.
My experiences of auto transmission cars is that the wheels will keep the RPMs higher if you're going down a hill in drive with the engine _running_, but if the engine has actually quit running, the wheels WON'T continue to turn the engine over - well, certainly when the vehicle hasn't gone into its overdrive gear. (I had a Dodge auto truck that liked to quit when the engine was cold. It was VERY difficult to steer with the engine stopped, and you had to make your first brake application your only brake application, because the brakes required a lot of strength to operate if you'd exhausted the vacuum).
It's not only articulated trailer trucks with "fail on" air brakes. Our 7.5 tonner has "fail on" air brakes and it's a rigid tipper truck with no equipment to hook up an air-braked trailer.
Also don't forget the long-running Alistair Cook's "Letter From America". Or "Dead Ringers" (although not everyone finds it funny, several episodes of Dead Ringers have had me in uncontrollable fits of laughter).
I don't have a TV right now (because I've got a major money crisis on at the moment). With decent radio stations, I don't miss it a bit.
As for the Archers? Well, there was a fight scene on it last week. Hearing the fight on the radio painted a far more vivid picture than watching one on TV!
It's perfectly possible to "shut down" a vehicle without stopping the engine. Simply have the "shut down" system set the engine power to idle and automatically apply the brakes. An idling engine still produces power for the accessories (power steering pump).
Also, a truck braking system is a lot different to your car. I often drive a fairly small truck (only 7.5 tonnes) but the braking system is radically different from that of your car. They are AIR BRAKES. Air brakes will fail safe - loss of pressure in the resevoir will cause the brakes to apply, unlike car brakes which "fail unsafe" where loss of vacuum to the servo will make braking considerably harder (OK, they don't stop working completely, but an elderly woman in a Buick wouldn't be able to apply enough foot pressure for an emergency brake application if her engine quit. If she has manual transmission though, the engine being driven by the wheels will still provide enough vacuum). Unlike your car's servo assisted brakes, which are hydraulic brakes assisted by vacuum off the engine manifold, air brakes will provide many braking applications before needing the resevoirs charging, and if the resevoir pressure gets too low, the brakes automatically apply anyway.
They aren't going to just randomly stop a vehicle. In all probability, a police vehicle will already be in pursuit, and will order the stop at an appropriate time (i.e. not when the tanker truck is halfway across the tracks)
Slashdot Mirror
Since organized religion has been heavily involved with some of the worst atrocities that humans have committed against their fellows, I see nothing inconsistent about mafiosos going to Church.
Debian is NOT a consumer operating system. Whilst Debian isn't suitable for your average home user, it's eminently suitable for the server. It's a lot easier to maintain than, say, RedHat on the server. For people who know what they are doing, the set up tools are not lacking at all.
There is a fallacy about the "pointy clicky" to do everything. On the home desktop that's fine and appropriate. However, if a server administrator can't cope with Debian, they have no business running a server - even a Windows server. Running a real server (that you don't want to be rooted) requires real knowledge, and a person who can command this knowledge is the type of administrator you need whether it's Windows or Solaris or Debian or RedHat.
And this is where so many organizations get into trouble with Windows. They think that because it's point and click, they can hire a cheap (for want of a better term) 'reboot monkey' as an administrator, where in reality Windows is _just as complex_ as a modern Unix-type operating system.
I've got the book written by the co-pilot of the Nagasaki nuclear attack mission - there are logs in the appendices of the book, and one of the crew observations was that crew with fillings (most of them! how dental hygiene has improved since then...) felt the EMP through their fillings as a tingle.
The risk tolerance must be *incredibly* low to believe that eating fish from the Irish Sea is a "risky activity". The biggest risk by orders of magnitude of eating fish from the Irish Sea is choking on a fish bone.
The thing is with TMI - IIRC, no one was even *injured* let alone killed. The design was such that when the shit really did hit the fan, the damage could be contained.
I can't really comment on the first problem - I've not done any serious C++ programming for a couple of years (and you didn't show the specific example).
However, just for fun I decided to time how long it took me to do (2). In Perl, it took 4 minutes.
You may say that using Perl rather than C++ was cheating, but I consider it using the right tool for the job.
Your comment is absolutely spot on, and I wish I could mod it up to +6.
It's by far not the only reason why software projects fail, but it's often a big factor. We've just gone through something we call "Business process re-engineering" to avoid precisely the pitfall you describe. The resistance to structural changes to the business (STILL using processes from the prior business it was part of in 1973, which had just been "spreadsheeted over" with no thought to WHY we are still doing this) met enormous resistance. Fortunately, many of the stakeholders were involved in the whole process of trying to make the business infrastructure actually make sense, so it's actually going ahead.
Now, at the "corporate" level (which is actually Government, I'm a contractor for an Authority of the government, which essentially is a business) is deciding to have this big project where they join all the systems up, giving shedloads of money to $BIGCORP who will be essentially the system integrator. As far as I can see, they are doing this whole project and they *haven't even thought* about the restructuring they'll need to mean they aren't just codifying their existing practises in a morass of sphagetti-like mush. Unless they re-engineer their working practises, I confidently predict that the project will overrun on cost, will overrun on time, and might not even work. What's worse is that $BIGCORP, desperate for the contract because they want to sell 'e-gov' solutions is going to rush a proof-of-concept, and management seeing nice clicky squishy buttons on a mock-up will think most of the work is done, and will then pressure the vendor to come up with the goods with an unrealistic schedule.
My last contract was for the United States Postal Service and they just codified their existing practises - it took *two million lines of code* just for the counter system! Sadly, when I started on the contract I was so green I needed mowing so I didn't see it coming (not that I could have probably done anything but tell deaf ears what I thought was wrong anyway). Absolutely no regard was given to "How could we use the software to make our business practises *better*"? The result: an inflexible system that's expensive to change. We essentially turned the entire Domestic Mailing Manual and International Mailing Manual plus a bunch of accounting procedures into a mass of C++ code. No regard as far as I could tell was given to how processes could be changed to make them more ameniable to automation, and serve the customer better!
The users complaining about X are generally the users who have just enough knowledge to be dangerous. Virtually every time people whine and bitch about X, all their complaints are really complaints about the toolkit and not X at all.
No one uses X directly these days. My Dad has no problem with an X based system, he just points and clicks at Kmail, or Openoffice or whatever. He wouldn't know what an X server was if it bit him on the bum. He doesn't complain about X or even Qt. He just moans when someone emails him a Microsoft executable and he can't run it (which I keep explaining to him is entirely the point).
X doesn't need to be thrown out - it does what it's designed to do well. What needs to be done is the toolkits need to be improved - and that's happening. The K Desktop Environment is getting better with each release. So is Gnome. X is merely a low level component that nearly everyone is insulated from now, but which makes my desktop more useful than a Windows desktop.
Try firing up Konqueror, and typing:
info:
and see how info was really meant to be used. Also try man: in Konqueror. Just another reason why Konqueror rocks!
I'm sure you could have said that when it was discovered you could accelerate electrons off a cathode in a vacuum. However, you now have a very good electron accelerator in your living room - your TV's picture tube.
The discovery of strange subatomic particles may seem irrelevant right now, but they may well be the link we need to cure disease, or prevent hunger.
Your sort of reasoning is incredibly short sighted, and it's a good job that the people who fund physics research don't subscribe to your point of view, or our homes would still be lit by gas lamps.
No, it's extremely SMART to have a buy nothing day on the biggest shopping day of the year - not because of any principle in particular, but because shopping on the day after Thanksgiving is fscking awful - parking lots all full, traffic jams, malls full of screaming children and angry parents, massive checkout lines. It is NOT a pleasant experience.
I try and do all my shopping at off-peak times so I can get somewhere to park and get in and out of a shop as quickly as possible: mainly because I detest shopping.
I find installing Linux and installing Windows XP on current hardware to be about the same level of difficulty - i.e. not particularly difficult. I don't see what's so difficult about booting a RH CD, selecting some packages, and periodically feeding the machine disks. I've not found any mainstream hardware since running RH 7.1 which the graphical installer didn't work. Unlike Windows, I've not needed to feed it additional driver disks AFTER the install on the hardware I've been using recently.
Windows and Linux are as difficult as each other to maintain _properly_. Both are complex systems. Both can easily be fscked up by someone who knows no more than how to click on pretty widgets. It's a myth that Windows is somehow easier to maintain properly - it isn't. It's easier to maintain improperly though. It's a false economy for a company to hire a cheap Windows admin, because they will get a reboot monkey. A Windows admin worth his salt will be expecting the same salary as a Unix admin.
There's no point going to the extra effort to think up and write a good summary, because the vast majority of articles just get rejected. It's not worth the submitter's time.
Lead acid batteries can already do that. Short a lead acid battery, and watch the wire get cherry red hot.
What XCOR is doing is very interesting, and I wish them every success. I was there for the unveiling of their rocket technology in Mojave, CA. when they flew the rockets (actually for the second time) on a Long-Ez. You can see my writeup of it here (at the risk of a slight Slashdotting).
No, Linus says he's just not interested in the server. Doesn't mean the kernel is no good for the server. Linus also said that Linux would be for the i386 only during his argument with ast. That seems to be not true either.
Just because Linus wants to do his thing with the desktop, it doesn't mean that others will stop working on the server side. Just like Lou Gerstner came from a biscuit making conglomerate, it doesn't mean he was going to turn IBM into a food and beverage company.
It's bloated? We are on X11R6. I used to run X11R6 on a 486 with 16MB of RAM. Hardly bloated. The bloated things are the *toolkits*. Not X.
It's slow? Not in the slightest. It ran fast on a 486, it runs blindingly fast on a P4-2GHz. The slowness is from the *toolkits*.
It's not very good for modern gaming? I run RTCW:ET in 1600x1200 under X with my GeForce 4. Frame rates are perfectly acceptable.
Poor scaling? Dunno about very high res LCDs, but it's fine on my 1600x1200 Trinitron. Again, scaling is a *toolkit* issue.
Royal pain in the ass to get set up? Not since I owned that 486. X has been a simple install from $DISTRIBUTION and has worked first time on every machine I've installed it on in at least the last 4 years.
It doesn't have a high level of standardization? Again a *toolkit* problem. X itself is *highly* standardized. It supports stuff on hundreds of different architectures. I can send the output of a program running on a Sun UltraSPARC system to a Pentium based system using the networking features. Try that with Windows or OSX.
Who really needs network transparency? Well, why is Terminal Services on Windows proving so popular? Unix/X users have been able to do this since 1986. It's a feature I find incredibly useful.
It's a royal pain in the ass to program on. So is basicWin32. I should imagine the low level Mac OSX stuff is too. This is why we use *toolkits*.
It doesn't lock on tight enough etc. Doesn't seem to be a problem for the games I've been playing.
Presentation layer living in the kernel is the WORST idea you've presented. That's not what the kernel is there for.
All the things you've written about saying why X sucks are *nothing* to do with X at all - they are all toolkit issues. Most people who think X should be kicked out genuinely don't understand X. X at its heart is actually a pretty lean, fast machine. It's flexible. The designers had a LOT of foresight. It's extensible.
Ease of development? Have you ever had the misfortune to work with the Win32 API for 6 years?
This is what makes me wonder about job interviews: many interviewers ask some simple C++ (or $LANGUAGE question) when they should be really testing the applicant on their understanding of the building blocks of software engineering. It's a sort of the cart-leading-the-horse thing.
The other aggravating thing about the recruitment process is that it often goes to HR to do, who are clueless. You advertise saying 'We need a software engineer. We are using $FOO language' and HR throws out any CV (tr. US: resume) from a software engineer who has good non-language specific SW engineering education and ten years experience, and calls in the guy who's got 2 years experience in $FOO language, but obviously from their CV is just a code monkey, not a software engineer.
My bets are that the Longhorn CLI *still* won't have job control. And that the Longhorn FS *still* won't have real symbolic links.
Things *NIX operating systems have had for well over a decade.
Isn't that like having multiple nested User Mode Linux instances?
The remaining vacuum in the servo is about good for one brake application.
My experiences of auto transmission cars is that the wheels will keep the RPMs higher if you're going down a hill in drive with the engine _running_, but if the engine has actually quit running, the wheels WON'T continue to turn the engine over - well, certainly when the vehicle hasn't gone into its overdrive gear. (I had a Dodge auto truck that liked to quit when the engine was cold. It was VERY difficult to steer with the engine stopped, and you had to make your first brake application your only brake application, because the brakes required a lot of strength to operate if you'd exhausted the vacuum).
It's not only articulated trailer trucks with "fail on" air brakes. Our 7.5 tonner has "fail on" air brakes and it's a rigid tipper truck with no equipment to hook up an air-braked trailer.
Also don't forget the long-running Alistair Cook's "Letter From America". Or "Dead Ringers" (although not everyone finds it funny, several episodes of Dead Ringers have had me in uncontrollable fits of laughter).
I don't have a TV right now (because I've got a major money crisis on at the moment). With decent radio stations, I don't miss it a bit.
As for the Archers? Well, there was a fight scene on it last week. Hearing the fight on the radio painted a far more vivid picture than watching one on TV!
It's perfectly possible to "shut down" a vehicle without stopping the engine. Simply have the "shut down" system set the engine power to idle and automatically apply the brakes. An idling engine still produces power for the accessories (power steering pump).
Also, a truck braking system is a lot different to your car. I often drive a fairly small truck (only 7.5 tonnes) but the braking system is radically different from that of your car. They are AIR BRAKES. Air brakes will fail safe - loss of pressure in the resevoir will cause the brakes to apply, unlike car brakes which "fail unsafe" where loss of vacuum to the servo will make braking considerably harder (OK, they don't stop working completely, but an elderly woman in a Buick wouldn't be able to apply enough foot pressure for an emergency brake application if her engine quit. If she has manual transmission though, the engine being driven by the wheels will still provide enough vacuum). Unlike your car's servo assisted brakes, which are hydraulic brakes assisted by vacuum off the engine manifold, air brakes will provide many braking applications before needing the resevoirs charging, and if the resevoir pressure gets too low, the brakes automatically apply anyway.
They aren't going to just randomly stop a vehicle. In all probability, a police vehicle will already be in pursuit, and will order the stop at an appropriate time (i.e. not when the tanker truck is halfway across the tracks)