My xbox runs xbmc and linux to give me things m$ didn't. My phone runs linux to give me things wm5 didn't. My laptop runs linux to give me things that xp didn't. My linksys wrt54g openwrt gives me many more things linksys didn't. I'm planning on buying a roomba, and if I feel the need a gumstix to exploit its resources.
Other than hardware - I've submitted many OSS patches, and I've modified stuff for myself and companies I work for to get things to work the way I want them to.
I doubt this story is much different for most linux advocates on/. at least.
It's sad, but there are actually people out there that will buy a product specifically because it says it supports Linux. They believe that Linux is the answer to everything. They'll buy iPods and install Linux on them. They'll choose their mobile phone based solely on the fact that it runs Linux, even though it has no bearing on the device's functionality what-so-ever. They just need to see that "runs Linux" sticker on the box. If, for example, Apple swapped out XNU for the Linux kernel, and made no other changes to Mac OS X, I bet you'd see hundreds of Linux zealots buying Macs -- even if it made no difference in the performance or usability of the OS whatsoever. They need that piece of mind that they can always say they're running Linux.
I'll confess to this. I purchase products to run linux, and products known to run linux, and products not known to run linux with the intention of running linux. I do this because it's linux. The reason it matters why it's linux is because I know that I will probably be able to use this hardware and exploit it's resources in ways that are limited by other software - be it windows, osx, wm5.0, xbox kernel, etc. I also know the product will be very flexible, or could be if I chose to spend the time. I purchase it also because it's generally lower cost because there's no software license - though it could be higher cost because they actually have to put quality hardware in because it has to work with linux. I choose linux because though there's normally not commercial support available, I know the guys who will be doing the supporting are almost always technically minded and normally know a thing or two more than an average person who purchase hardware. I choose linux because it's clear that linux will be around for a very long time, with any other os, I wouldn't be so sure. I choose linux because I can modify the code even if every other developer in the world has long given up on it. I choose linux because it's very secure in it's native form and moreso if you spend some time configuring it.
So what exactly are the arguments for NOT choosing linux again? Do they outweight the above? Probably not for me, though I admit I am a rational being and my choices are subject to change.
Does this mean they haven't been detected on Xbox live yet? Is there any news of this?
Of course it won't be warrantied...if M$ is trying to scare them now, it's a bit too late as the warranty seal on the console has already been broken. Just a scare tactic for M$, a risk that's already been calculated for the modders.
It has been false for years now. Ever since Chris Rijk published his earth shattering benchmarks. Give me one example of a well known basic java gui application that is as responsive as any give kde/gnome app, takes a modest amount of memory and is bug free enough to use basic features, and I will change my opinion about java from "Memory hungry, bug ridden, slow, incompatible with itself, bloated piece of shit" to some thing maybe a point or two higher. No piece of java software I've ever run has impressed me. From proprietary java software I use at work to applets on the web, azureus, eclipse, limewire, oracle's applications, and the hundreds of apache tomcat/ant/jboss environments I used to setup and host for customers, I have never seen any java application where I've just said "Wow, that just worked.".
Those benchmarks are next to useless. I'm not saying they're wrong, I just don't see java performing better or even on par with other applications I use.
Back when I admin'd an ISP that billed by usage, we used mrtg and the mrtg 95 percentile scripts. On more than one occasion, we had customers inquire about our billing. Fortunately, most of our customers were technically literate, so I stepped through the code and procedures with them. All of them were happy with the explanitions and were satisfied after they saw the methods. That's not to say mrtg and the 95th percentile scripts are bulletproof, but they held up under our scrutiny.
It always bothers me when people use utilities to restart services that die/have been killed. Shouldn't a daemon be designed to run indefinitely? Doesn't the fact that a process died mean that something is wrong and needs to be fixed? For instance, if my apache daemon dies because the logfile is larger than it can handle, what good is restarting it going to do? It's just going to beat the crap out of a server - process dies - watcher daemon starts it up - process dies...etc. Or, if the OOM killer kills my ftp server because he's hogging the memory, doesn't that mean I have bigger problems than just doing a restart(I need more memory, the ftp server has a mem leak, etc)?
None of my hundreds of critical daemons die for no reason whatsoever - all of require some type of human interaction if they have died. It doesn't happen very often, maybe once every several months.
Not that I care about this software in general, I use hobbit for my trending/graphing/service availability, but I hate to see bad admin'ing, even if I'm not involved.
Umm, no it's not. It's an indication of how much an investors feels the share is worth. Also mixed in there is emotion, outlook and pure, wild speculation. If anything's indicative of "failure", it's certainly not the market's reaction to a numbers release. Sure, if it didn't hit the earnings the share holder wanted it to, or what the whisper numbers said, it may be considered "not worth holding" by some investors - but I'd venture to guess more shareholders held on to their shares than sold them during that particular time.
Yeah there's this thing on ebay it's called "Searching for completed listings". It's actually quite nice. You can look for items that have sold or their time has expired without being sold. See, if you do your research, like I did, with my "ridiculously flawed statement", you will plainly see that there are a good number of systems that have sold for $20 or more above the best buy price. This _DOESN'T_ include shipping, which is often $10-$20. For the ones selling at or below the best buy price, you can rule out the ones with a ridiculous shipping price ($30+), which is just profit for the seller.
So, to sum up, I'm backing my statements up with facts. People WILL and HAVE payed that much. That is demand. Do you have a different definition?
Which explains all the successful sales of X360 on ebay for well over the standard retail price. Consistently selling something for a price higher than what best buy charges sure seems to be indicative of demand. Demand, IIRC, is inextricably linked to the success of a product of this type.
Might be able to make yourself a profit. I'd sure be selling them if they had any in my town.
I think someone's confusing user error/not enough troubleshooting with an almost not reproducable issue. TFA mentions a lot of instructions without enough pause of FPU code to cool down. This isn't your bug if you're playing WC3. WC3 uses TCP/IP. TCP/IP generates interrupts - lots of interrupts. So many interrupts that your FPU has plenty of time to cool down between calculations. There are many handy ways of troubleshooting this issue of yours, and I'd bet you're not going to identify the problem by some slashdot story submission.
Are you sure you're not talking about the P4 vs. XP running while playing quake 3? IIRC, the P4 ran for some number (53?) of seconds afterward, while the XP started smoking the second the HSF was removed.
Personally, I'm very glad they got network-manager in there. Right after feature freeze was when NM was updated to the point where it supported WPA to the point where it was acceptable for Dapper. We had to beg and plead to get NM in after FF, but they finally caved in due to some hard work by some people.
For the past ~2 months, with NM, I've had the most enjoyable (Computer related:)) docking/undocking ever. It's so nice to be able to undock and walk out to the balcony and soak up some sun & computer without running any special scripts. Here's to your XGL.
The amateur radio option supports certain hardware, while we could argue why they should or shouldn't include it until the sun goes down, the simple fact remains that that isn't an apples to apples comparison. Native debugging options, at least in this case, foster a "brute force it until it compiles and works" mentality. (And I'm not going to argue that nothing else fosters that mentality)
Simply writing a complex program and debugging it until it works is not encouraged. You should have a good idea of how to write the code, and you should be 90% working without even attempting the first compile. Most of the rest can be solved with printks in your module, and the remainder are/might be nuances of your hardware/coding style/kernel version. If you understand the architecture intimately and your need for a debugger is minimal, chances are your code will work in multiple versions of the kernel - which is what the Linux community wants. We don't want to contact you, the maintainer every version release when your code breaks just because you don't fully understand how the kernel model works, and only got your code working as a result of a debugger.
By debugging, and not to make a blanket statement here, generally you are saying "I don't fully understand why X is doing Y", or "Why FOO has a lock on BAR.", etc.
Linus is really just sacrificing the immediate good for what would inevitably become the default, which is bad programming. It's no different than not allowing triggers in SQL. Sure, sometimes they're nice, but more often than not they are used because the programmer is lazy and didn't really normalize their database. I, for one, congratulate him on not giving into the pressure. If short term fixes were implemented more often in the kernel, I suspect it'd be much worse off in stability, performance and scalability than it is now. Since linux kernel programmers are forced to do things "The Hard Way" in the kernel, it all but guarantees that they have an intimate knowledge of the systems and workings.
By not having it, you only induced developers lots of pain during the last 10-15 years, for those occasions where a debugger really are the right tool for the job.
If the debugger would have been the right thing for the job, why not just patch it in? There are several different versions of debbuging patches, and they developer should be the only one who worries about debugging. You shouldn't force everyone who uses the Linux kernel to download and maybe even unselect kernel debugging.
Qmail is bad news because you need 50 different patches from 30 different people. Not to mention the all so famous security guarentee isn't even (a) honored by DJB and (b) doesn't apply after you start using Joe's qmail-ldap-mysql-pop3-super-vacation-script patch.
Don't depend on finding anything in the code either. Everything, I mean _everything_ is hard coded. If you can navigate around regular open source code, it's not going to help for qmail. Everything is a nightmare in there. I encourage you to compare any random file out of postfix vs. qmail.
Finally, new features do not exist, unless you got after an aforementioned patch. Wait til the day you have to emergency rebuild qmail and figure out which patches you installed to which binaries on which servers.
I could go on, but those should be enough to have you steer clear.
This way is the only inexpensive, noncommercial software, non-kludge, non-propretary like way to do it. I've built several systems like this, one is close to 100,000 accounts with no problems. This system scales out (i.e. adding another cheap server for more power) as opposed to scaling up with huge servers (price, power demands, price, and price).
It's also very easy to troubleshoot.
Do not split your email users between servers and proxy them. Big problems.
I think he's maybe talking about 7, 8 and 9, in which case, I'd agree with him wholeheartedly.
First, you'd have a newly installed something server, and you'd figure out you need to install Xlibraries and X just so you can use some shitty gui that crashes every 180 seconds.
Next, the shitty gui's fonts would be so fucked and you couldn't click the "next" or "cancel" buttons because java guis are a piece of shit and strech the buttons off your screen.
The install wouldn't warn you you couldn't have underscores in the dbname, it'd just crash after 3 hours of installing on a dual sparc64. Then you'd have to figure it out - not with an error like "Underscores not allowed in db name", oh no, it'd be some huge ugly java+oracle error.
Then, it'd figure out that there's a dash in the hostname of your machine, and crash on that too.
Then, it'd figure out that there were more than 8 characters in your hostname/db name, and crash.
Then, something in your network settings wouldn't be just friggen perfect and dbca would fail after yet another 3 hour install on a dual sparc64.
This assumes you're sitting in front of the machine. If you're smart you have this machine somewhere behind a firewall. If you're even smarter you have a firewall inbetween your desktop and and this server area. Continue down the smart chain to include ssh, Xforwarding, etc. Now, you've got to keep your ssh session alive for longer than your firewall timeout or the firewall will break the connection and cause your installer to fail. But java won't keep it alive - oh no - you can't expect that slow bloated piece of shit software to send update packets across an ssh session in intervals less than 5 minutes. It's running on sparc64, which is supposed to be fast! Ha. Fast.
Browse any patch release notes on Metalink, more often than not they cause more issues than they fix. These are issues _the patch_ caused, not software had before, not issues the patch fixes, _the patch caused_. Either you are just fine with checking the release notes and rigorously ruling out any possible issues as well as just fine with fact that most patches cause more problems than they fix, or you haven't yet convinced yourself that you have quite possibly the most inane and absurdly ridiculous responsibilites in all the world of sysadmin'ing.
Granted, we all run across bugs, but we shouldn't have to be alpha/beta testers.
so we wouldn't need to have a full time guy to test software upgrades with our current Oracle installations, or to troubleshoot errors
LOL. You've never worked with Oracle software have you? They have a very hard time releasing patches, much less testing them. I've spent dozens of hours on the phone with RH, IBM, Oracle, etc, and Oracle are the _last_ people you ever want to due to their gross incompetence and intentional disregard for anything you might know or claim to know.
Slashdot Mirror
Let me see...
/. at least.
My xbox runs xbmc and linux to give me things m$ didn't. My phone runs linux to give me things wm5 didn't. My laptop runs linux to give me things that xp didn't. My linksys wrt54g openwrt gives me many more things linksys didn't. I'm planning on buying a roomba, and if I feel the need a gumstix to exploit its resources.
Other than hardware - I've submitted many OSS patches, and I've modified stuff for myself and companies I work for to get things to work the way I want them to.
I doubt this story is much different for most linux advocates on
It's sad, but there are actually people out there that will buy a product specifically because it says it supports Linux. They believe that Linux is the answer to everything. They'll buy iPods and install Linux on them. They'll choose their mobile phone based solely on the fact that it runs Linux, even though it has no bearing on the device's functionality what-so-ever. They just need to see that "runs Linux" sticker on the box. If, for example, Apple swapped out XNU for the Linux kernel, and made no other changes to Mac OS X, I bet you'd see hundreds of Linux zealots buying Macs -- even if it made no difference in the performance or usability of the OS whatsoever. They need that piece of mind that they can always say they're running Linux.
I'll confess to this. I purchase products to run linux, and products known to run linux, and products not known to run linux with the intention of running linux. I do this because it's linux. The reason it matters why it's linux is because I know that I will probably be able to use this hardware and exploit it's resources in ways that are limited by other software - be it windows, osx, wm5.0, xbox kernel, etc. I also know the product will be very flexible, or could be if I chose to spend the time. I purchase it also because it's generally lower cost because there's no software license - though it could be higher cost because they actually have to put quality hardware in because it has to work with linux. I choose linux because though there's normally not commercial support available, I know the guys who will be doing the supporting are almost always technically minded and normally know a thing or two more than an average person who purchase hardware. I choose linux because it's clear that linux will be around for a very long time, with any other os, I wouldn't be so sure. I choose linux because I can modify the code even if every other developer in the world has long given up on it. I choose linux because it's very secure in it's native form and moreso if you spend some time configuring it.
So what exactly are the arguments for NOT choosing linux again? Do they outweight the above? Probably not for me, though I admit I am a rational being and my choices are subject to change.
Are you after the fanboi of the year award?
Does this mean they haven't been detected on Xbox live yet? Is there any news of this?
Of course it won't be warrantied...if M$ is trying to scare them now, it's a bit too late as the warranty seal on the console has already been broken. Just a scare tactic for M$, a risk that's already been calculated for the modders.
It has been false for years now. Ever since Chris Rijk published his earth shattering benchmarks.
Give me one example of a well known basic java gui application that is as responsive as any give kde/gnome app, takes a modest amount of memory and is bug free enough to use basic features, and I will change my opinion about java from "Memory hungry, bug ridden, slow, incompatible with itself, bloated piece of shit" to some thing maybe a point or two higher. No piece of java software I've ever run has impressed me. From proprietary java software I use at work to applets on the web, azureus, eclipse, limewire, oracle's applications, and the hundreds of apache tomcat/ant/jboss environments I used to setup and host for customers, I have never seen any java application where I've just said "Wow, that just worked.".
Those benchmarks are next to useless. I'm not saying they're wrong, I just don't see java performing better or even on par with other applications I use.
Back when I admin'd an ISP that billed by usage, we used mrtg and the mrtg 95 percentile scripts. On more than one occasion, we had customers inquire about our billing. Fortunately, most of our customers were technically literate, so I stepped through the code and procedures with them. All of them were happy with the explanitions and were satisfied after they saw the methods. That's not to say mrtg and the 95th percentile scripts are bulletproof, but they held up under our scrutiny.
http://www.seanadams.com/95/
It always bothers me when people use utilities to restart services that die/have been killed. Shouldn't a daemon be designed to run indefinitely? Doesn't the fact that a process died mean that something is wrong and needs to be fixed? For instance, if my apache daemon dies because the logfile is larger than it can handle, what good is restarting it going to do? It's just going to beat the crap out of a server - process dies - watcher daemon starts it up - process dies...etc.
Or, if the OOM killer kills my ftp server because he's hogging the memory, doesn't that mean I have bigger problems than just doing a restart(I need more memory, the ftp server has a mem leak, etc)?
None of my hundreds of critical daemons die for no reason whatsoever - all of require some type of human interaction if they have died. It doesn't happen very often, maybe once every several months.
Not that I care about this software in general, I use hobbit for my trending/graphing/service availability, but I hate to see bad admin'ing, even if I'm not involved.
Umm, no it's not. It's an indication of how much an investors feels the share is worth. Also mixed in there is emotion, outlook and pure, wild speculation. If anything's indicative of "failure", it's certainly not the market's reaction to a numbers release. Sure, if it didn't hit the earnings the share holder wanted it to, or what the whisper numbers said, it may be considered "not worth holding" by some investors - but I'd venture to guess more shareholders held on to their shares than sold them during that particular time.
Yeah there's this thing on ebay it's called "Searching for completed listings". It's actually quite nice. You can look for items that have sold or their time has expired without being sold. See, if you do your research, like I did, with my "ridiculously flawed statement", you will plainly see that there are a good number of systems that have sold for $20 or more above the best buy price. This _DOESN'T_ include shipping, which is often $10-$20. For the ones selling at or below the best buy price, you can rule out the ones with a ridiculous shipping price ($30+), which is just profit for the seller.
So, to sum up, I'm backing my statements up with facts. People WILL and HAVE payed that much. That is demand. Do you have a different definition?
Which explains all the successful sales of X360 on ebay for well over the standard retail price. Consistently selling something for a price higher than what best buy charges sure seems to be indicative of demand. Demand, IIRC, is inextricably linked to the success of a product of this type.
Might be able to make yourself a profit. I'd sure be selling them if they had any in my town.
I suspect something far more mundane, like someone reducing die or slug thickness, or a mfg problem with the die/slug gap or thermal goop.
Care to go into a bit more detail for us noobs?
I think someone's confusing user error/not enough troubleshooting with an almost not reproducable issue. TFA mentions a lot of instructions without enough pause of FPU code to cool down. This isn't your bug if you're playing WC3. WC3 uses TCP/IP. TCP/IP generates interrupts - lots of interrupts. So many interrupts that your FPU has plenty of time to cool down between calculations. There are many handy ways of troubleshooting this issue of yours, and I'd bet you're not going to identify the problem by some slashdot story submission.
Use screen to btdownloadcurses:
Start:
screen btdownloadcurses foo.torrent
Detach:
ctrl-a,d
Reattach:
screen -r (pid of screen session)
List of screen sessions:
screen -list
Easy and sleezy.
Are you sure you're not talking about the P4 vs. XP running while playing quake 3? IIRC, the P4 ran for some number (53?) of seconds afterward, while the XP started smoking the second the HSF was removed.
LOL, I'm stealing this if you don't mind:)
Have you learned nothing?
You put it in another PasswordSafe database! Duh!
Personally, I'm very glad they got network-manager in there. Right after feature freeze was when NM was updated to the point where it supported WPA to the point where it was acceptable for Dapper. We had to beg and plead to get NM in after FF, but they finally caved in due to some hard work by some people.
For the past ~2 months, with NM, I've had the most enjoyable (Computer related:)) docking/undocking ever. It's so nice to be able to undock and walk out to the balcony and soak up some sun & computer without running any special scripts. Here's to your XGL.
The amateur radio option supports certain hardware, while we could argue why they should or shouldn't include it until the sun goes down, the simple fact remains that that isn't an apples to apples comparison. Native debugging options, at least in this case, foster a "brute force it until it compiles and works" mentality. (And I'm not going to argue that nothing else fosters that mentality)
Simply writing a complex program and debugging it until it works is not encouraged. You should have a good idea of how to write the code, and you should be 90% working without even attempting the first compile. Most of the rest can be solved with printks in your module, and the remainder are/might be nuances of your hardware/coding style/kernel version. If you understand the architecture intimately and your need for a debugger is minimal, chances are your code will work in multiple versions of the kernel - which is what the Linux community wants. We don't want to contact you, the maintainer every version release when your code breaks just because you don't fully understand how the kernel model works, and only got your code working as a result of a debugger.
By debugging, and not to make a blanket statement here, generally you are saying "I don't fully understand why X is doing Y", or "Why FOO has a lock on BAR.", etc.
Linus is really just sacrificing the immediate good for what would inevitably become the default, which is bad programming. It's no different than not allowing triggers in SQL. Sure, sometimes they're nice, but more often than not they are used because the programmer is lazy and didn't really normalize their database. I, for one, congratulate him on not giving into the pressure. If short term fixes were implemented more often in the kernel, I suspect it'd be much worse off in stability, performance and scalability than it is now. Since linux kernel programmers are forced to do things "The Hard Way" in the kernel, it all but guarantees that they have an intimate knowledge of the systems and workings.
By not having it, you only induced developers lots of pain during the last 10-15 years, for those occasions where a debugger really are the right tool for the job.
If the debugger would have been the right thing for the job, why not just patch it in? There are several different versions of debbuging patches, and they developer should be the only one who worries about debugging. You shouldn't force everyone who uses the Linux kernel to download and maybe even unselect kernel debugging.
Qmail is bad news because you need 50 different patches from 30 different people. Not to mention the all so famous security guarentee isn't even (a) honored by DJB and (b) doesn't apply after you start using Joe's qmail-ldap-mysql-pop3-super-vacation-script patch.
Don't depend on finding anything in the code either. Everything, I mean _everything_ is hard coded. If you can navigate around regular open source code, it's not going to help for qmail. Everything is a nightmare in there. I encourage you to compare any random file out of postfix vs. qmail.
Finally, new features do not exist, unless you got after an aforementioned patch. Wait til the day you have to emergency rebuild qmail and figure out which patches you installed to which binaries on which servers.
I could go on, but those should be enough to have you steer clear.
This way is the only inexpensive, noncommercial software, non-kludge, non-propretary like way to do it.
I've built several systems like this, one is close to 100,000 accounts with no problems. This system scales out (i.e. adding another cheap server for more power) as opposed to scaling up with huge servers (price, power demands, price, and price).
It's also very easy to troubleshoot.
Do not split your email users between servers and proxy them. Big problems.
I think he's maybe talking about 7, 8 and 9, in which case, I'd agree with him wholeheartedly.
First, you'd have a newly installed something server, and you'd figure out you need to install Xlibraries and X just so you can use some shitty gui that crashes every 180 seconds.
Next, the shitty gui's fonts would be so fucked and you couldn't click the "next" or "cancel" buttons because java guis are a piece of shit and strech the buttons off your screen.
The install wouldn't warn you you couldn't have underscores in the dbname, it'd just crash after 3 hours of installing on a dual sparc64. Then you'd have to figure it out - not with an error like "Underscores not allowed in db name", oh no, it'd be some huge ugly java+oracle error.
Then, it'd figure out that there's a dash in the hostname of your machine, and crash on that too.
Then, it'd figure out that there were more than 8 characters in your hostname/db name, and crash.
Then, something in your network settings wouldn't be just friggen perfect and dbca would fail after yet another 3 hour install on a dual sparc64.
This assumes you're sitting in front of the machine. If you're smart you have this machine somewhere behind a firewall. If you're even smarter you have a firewall inbetween your desktop and and this server area. Continue down the smart chain to include ssh, Xforwarding, etc. Now, you've got to keep your ssh session alive for longer than your firewall timeout or the firewall will break the connection and cause your installer to fail. But java won't keep it alive - oh no - you can't expect that slow bloated piece of shit software to send update packets across an ssh session in intervals less than 5 minutes. It's running on sparc64, which is supposed to be fast! Ha. Fast.
Browse any patch release notes on Metalink, more often than not they cause more issues than they fix. These are issues _the patch_ caused, not software had before, not issues the patch fixes, _the patch caused_. Either you are just fine with checking the release notes and rigorously ruling out any possible issues as well as just fine with fact that most patches cause more problems than they fix, or you haven't yet convinced yourself that you have quite possibly the most inane and absurdly ridiculous responsibilites in all the world of sysadmin'ing.
Granted, we all run across bugs, but we shouldn't have to be alpha/beta testers.
so we wouldn't need to have a full time guy to test software upgrades with our current Oracle installations, or to troubleshoot errors
LOL. You've never worked with Oracle software have you? They have a very hard time releasing patches, much less testing them. I've spent dozens of hours on the phone with RH, IBM, Oracle, etc, and Oracle are the _last_ people you ever want to due to their gross incompetence and intentional disregard for anything you might know or claim to know.
For a nominal fee, they'll let you step in the cow pies every second Tuesday.
Didn't they recently change that to the second Tuesday of the month?