I think all of this will be moot when the nVidia Tegra devices come out. That will be when I break down and buy either a mini-laptop or a hand-held device.
I understand why the kernel panic code is there. I'm not saying it shouldn't be there, or that one of the developers screwed up if that code ever executes for any reason. All software has bugs in it, and even mostly bug-free code can be broken by invalid input. But like a GPF, the technical information it provides is to help developers figure out why it crashed so they can find a way to fix it and make it stop crashing. For instance, in the case of bad input, it may tell the developers they need to be more careful about validating the input.
What I'm saying is that I believe it is possible for kernel developers to add safeguards around the code that is generating this specific kernel panic, and that they should make an effort to do so if they can reproduce the problem. It may not be possible to fix it in some extreme cases, but there is almost always something that can be done to make it behave in a better fashion.
If Foxconn deliberately sabotaged one specific OS, then someone should sue them for violating anti-trust laws (or something along those lines. But law suits are expensive, uncertain, and take forever. Either way, it may be more helpful for the kernel developers to make an effort to tighten down that part of the boot process. I'm not talking about Foxconn-specific checks either, but generic safety checks that may help.
I already said I was certain there was a problem in the motherboard. If you want to argue with me, at least try to make a relevant point AGAINST one of the two points I made. Since you seem to have missed something, my main points were:
1) There's a bug in the motherboard (feel free to argue against this point, NOT FOR IT). 2) The Linux kernel should be more careful with these inputs to avoid a kernel panic when it runs on a bad motherboard. At the least, it should give end users a more useful error message than "kernel panic". At the most, it should disable the module if it's not critical, and continue booting up.
I have a motherboard (ECS) that gives a kernel panic when any Linux distro tries to boot. Since the installer boots Linux, I can't install or test any Linux distro on it. On one hand I feel certain that there is a bug in the motherboard, but on the other hand a kernel panic is like a GPF, and it should not occur even with bad input. At the very least, add a check and give me a warning or error message better than "kernel panic". So IMO, there is also a bug in the Linux kernel.
Given the fact that this problem with the motherboard is not fatal to any other OS I've tried, I consider the bug in the Linux kernel to be worse than the bug in the motherboard. Should developers have to deal with bad input? Not in a perfect world, but this has never been a perfect world.
In this case, I believe confronting and then ignoring would work better. After making a fair effort to help, simply point out (for everyone to read) that everything he has posted has been inaccurate, that he's either stupid or a troll, and that you don't really care which because either way he's just wasting your time. Then ignore any further replies he makes on that thread (no matter what they are, he's almost guaranteed to look like a dumb-ass to anyone reading them). If he tries to start another thread to complain, THEN ban him. This way you take away the attention he craves, and you get a chance to leave him with a bad taste in his mouth before you do it.
I don't mind getting a negative mod for that, but off-topic is not accurate. I was suggesting they waterboard him to get him to give up the password, and it was a joke. It was off-color, but definitely not off-topic.
...who thinks "Well, duh" to this? Apple has always been more expensive. It probably always will be. If you like Apple enough to pay the premium for one, then get over it. It's rare that you hear people complain about being ripped off at the BMW dealership. When you buy a premium car, you expect to pay a premium for the car AND the service. I've never owned an Apple, but everything I've read has indicated that (usually) Apple users also expect significantly better service than you can get from Dell. You guys have to pay for it somehow. TANSTAAFL.
If they also charge extra to "downgrade" to Ubuntu as well, and they'll make a fortune from the people trying to flee Vista like rats fleeing a sinking ship.
There's a problem with your logic. I never said I agreed that this fusion research was a waste of money. If it works, it is fabulous. If it doesn't, it helps point out something that is wrong with existing theories, which may help lead us to something else that does work. Either way, it is worthwhile. The gay bomb is a waste of money, along with a great many things the US military invests in.
I went to Tech, and that's not entirely true. That major was not just for the folks who couldn't cut it. It was also for most of Tech's athletes and women. I'm not bashing athletes or women, just citing a statistic that was true during the years I attended. At the time I fervently wished that there had been more women in my classes.;-)
Tech has changed a lot, though. I hear they have a new major that's like CS, but without any actual programming. WTF is that about? I believe I read something about trying to attract more women to the CS field, but that seems to be the wrong way to do it. I imagine it will become like a second (or should I say extra?) "Management" major there.
Actually, that's different: "The modified file was 'kernel/exit.c', modified directly on the CVS mirror of the 2.6-test development kernel tree [forum]. The CVS logs erroneously "credited" kernel hacker David Miller for the changes."
That was someone breaking into the CVS server to sneak in a change. I'm talking about developers making real code contributions the normal way, with the changes concerted in such a way that each change seems innocent until they are all put together. It doesn't have to be in the Linux kernel, either. It could be in Apache, one of its modules, or any number of other pieces of software.
How hard would it be to create a vulnerability in open source software? If subtle enough, I imagine a vulnerability could be added to a project via several coordinated updates made by multiple contributors (something where no single change caused it, but a combination of changes caused it), and spread out over time so it would appear to be an innocent mistake.
Well, I did say it was the "assembly language" of scripting languages. When you try to extend it in C, you even have to manually push args onto the "stack" and pop the results off. *shudder* IMO Ruby is the best scripting language, but its runtime engine has some serious issues (slow, violently unfriendly to threads even in C/C++ extensions, etc.) Once you get used to Ruby, other scripting languages seem like a pain (and compiled languages even more of a pain). FYI, Rails sucks, but the core Ruby language is a thing of beauty and elegance.
Oh please. The last time I rolled my own AVL tree, it ran an order of magnitude faster than std::map (benchmarked using a 32-bit int for a key). Adds, seeks, and deletes were all much faster whether I was inserting data in order or not. I will use std::map where I don't need speed, but I'll use my own in some cases where speed is critical.
Standards and guidelines are all very good, but no programming rule I've ever read makes sense 100% of the time (although a few rules come damn close), and knowing when you should bend the rules is part of being a good programmer. Too many of the newer rules seem to exist solely to keep poor programmers out of trouble. To those of us who can keep ourselves out of trouble, it is definitely a mixed blessing.
I agree that Java is great in many ways, and IMO provides the best cross-platform web/app server available. However, if you need to distribute a commercial application with a web app attached to it (for a company's Intranet), distributing the entire JDK for JSP compilation is a bit of a burden.;-) You can precompile the JSP, but even the distributing the JRE is a bit of a burden (and sometimes you may need to test customizations and/or hotfixes on a customer's system).
That's the big Achilles heel of most scripting languages, and just about anything else developed for cross-platform Unix support (look at how long it took Apache to get threads, and even then it doesn't help to use them with mod-php, mod-python, or mod-ruby). If you want fast (for a scripting language), multi-threaded, and not dependent on Java or.Net, I suppose there's Lua (and LuaJIT). Unfortunately, Lua is like the "assembly language" of scripting languages.
BS. They don't have to take down the building. The fire caused would presumably do more damage than the explosion. Perhaps they would load it up with something like napalm instead of explosives. And with millions of flying cars buzzing around a city, they could use dozens in one attack far more easily than they could use planes today. Read the response I made to the other guy's reply. It adds a lot more to the argument.
1) A high curb or a few steps would be enough to stop a car from crashing into a building at high speed. There are any number of simple and cheap barriers like that one could use. Even the way downtown city streets are designed would keep cars from being able to come flying through the front door of a building at 100 MPH. Most tall buildings I've seen have thick concrete walls at the base (something a car wouldn't be able to break through), and most have at least a few steps leading up to the front door. An explosion happening on the outside of a building would do very little damage compared to one happening on the inside. A flying car could very easily pick a window it wanted to enter through, and come tearing in at top speed (which may be up to 200 or 300 MPH). A good bit of the damage would be caused by the weight and velocity, and any potential fires it might start.
2) Airplanes are more expensive, there are far fewer of them, and they are more tightly controlled than cars. Aircraft deviating from their flight plan are more easily spotted, and more easily intercepted if necessary because there are so few of them. It would be very different if there were millions of vehicles flying around every city, going pretty much anywhere they wanted (with soccer moms accidentally flying over a military base while putting on their makeup). They would also be cheaper and easier to obtain, and it would be possible for terrorist groups to use dozens of them in a single attack. It would make things 100 times easier for them than it would be for them to do the same with airplanes today, especially if they chose to go after military targets.
3) Kamikaze pilots were extremely effective in WWII. They were so effective that if they hadn't run out of planes and pilots, they might have sunk our naval fleet, causing us to lose on the Pacific front. If you don't think a dozen flying cars hitting a military base would be a problem, what about a hundred or a thousand? With planes today it would be unthinkable for anyone to try something that big. With everyone in a city using a flying car, it would seem a lot easier.
Slashdot Mirror
I think all of this will be moot when the nVidia Tegra devices come out. That will be when I break down and buy either a mini-laptop or a hand-held device.
I understand why the kernel panic code is there. I'm not saying it shouldn't be there, or that one of the developers screwed up if that code ever executes for any reason. All software has bugs in it, and even mostly bug-free code can be broken by invalid input. But like a GPF, the technical information it provides is to help developers figure out why it crashed so they can find a way to fix it and make it stop crashing. For instance, in the case of bad input, it may tell the developers they need to be more careful about validating the input.
What I'm saying is that I believe it is possible for kernel developers to add safeguards around the code that is generating this specific kernel panic, and that they should make an effort to do so if they can reproduce the problem. It may not be possible to fix it in some extreme cases, but there is almost always something that can be done to make it behave in a better fashion.
If Foxconn deliberately sabotaged one specific OS, then someone should sue them for violating anti-trust laws (or something along those lines. But law suits are expensive, uncertain, and take forever. Either way, it may be more helpful for the kernel developers to make an effort to tighten down that part of the boot process. I'm not talking about Foxconn-specific checks either, but generic safety checks that may help.
I already said I was certain there was a problem in the motherboard. If you want to argue with me, at least try to make a relevant point AGAINST one of the two points I made. Since you seem to have missed something, my main points were:
1) There's a bug in the motherboard (feel free to argue against this point, NOT FOR IT).
2) The Linux kernel should be more careful with these inputs to avoid a kernel panic when it runs on a bad motherboard. At the least, it should give end users a more useful error message than "kernel panic". At the most, it should disable the module if it's not critical, and continue booting up.
I have a motherboard (ECS) that gives a kernel panic when any Linux distro tries to boot. Since the installer boots Linux, I can't install or test any Linux distro on it. On one hand I feel certain that there is a bug in the motherboard, but on the other hand a kernel panic is like a GPF, and it should not occur even with bad input. At the very least, add a check and give me a warning or error message better than "kernel panic". So IMO, there is also a bug in the Linux kernel.
Given the fact that this problem with the motherboard is not fatal to any other OS I've tried, I consider the bug in the Linux kernel to be worse than the bug in the motherboard. Should developers have to deal with bad input? Not in a perfect world, but this has never been a perfect world.
In this case, I believe confronting and then ignoring would work better. After making a fair effort to help, simply point out (for everyone to read) that everything he has posted has been inaccurate, that he's either stupid or a troll, and that you don't really care which because either way he's just wasting your time. Then ignore any further replies he makes on that thread (no matter what they are, he's almost guaranteed to look like a dumb-ass to anyone reading them). If he tries to start another thread to complain, THEN ban him. This way you take away the attention he craves, and you get a chance to leave him with a bad taste in his mouth before you do it.
I don't mind getting a negative mod for that, but off-topic is not accurate. I was suggesting they waterboard him to get him to give up the password, and it was a joke. It was off-color, but definitely not off-topic.
Come on, you all know you were thinking it. ;-)
I agree, and I'm waiting for the Tegra devices to be released.
In a perfect world perhaps. Right now the bad guys are telling the F-22 pilots who to do stuff TO. Trust me when I say they're not doing it FOR me.
...who thinks "Well, duh" to this? Apple has always been more expensive. It probably always will be. If you like Apple enough to pay the premium for one, then get over it. It's rare that you hear people complain about being ripped off at the BMW dealership. When you buy a premium car, you expect to pay a premium for the car AND the service. I've never owned an Apple, but everything I've read has indicated that (usually) Apple users also expect significantly better service than you can get from Dell. You guys have to pay for it somehow. TANSTAAFL.
Always use BSD.
If they also charge extra to "downgrade" to Ubuntu as well, and they'll make a fortune from the people trying to flee Vista like rats fleeing a sinking ship.
There's a problem with your logic. I never said I agreed that this fusion research was a waste of money. If it works, it is fabulous. If it doesn't, it helps point out something that is wrong with existing theories, which may help lead us to something else that does work. Either way, it is worthwhile. The gay bomb is a waste of money, along with a great many things the US military invests in.
I agree, and it's got to be better than some of the things the US Army has invested millions of dollars in, like the "gay bomb".
I went to Tech, and that's not entirely true. That major was not just for the folks who couldn't cut it. It was also for most of Tech's athletes and women. I'm not bashing athletes or women, just citing a statistic that was true during the years I attended. At the time I fervently wished that there had been more women in my classes. ;-)
Tech has changed a lot, though. I hear they have a new major that's like CS, but without any actual programming. WTF is that about? I believe I read something about trying to attract more women to the CS field, but that seems to be the wrong way to do it. I imagine it will become like a second (or should I say extra?) "Management" major there.
Actually, that's different: "The modified file was 'kernel/exit.c', modified directly on the CVS mirror of the 2.6-test development kernel tree [forum]. The CVS logs erroneously "credited" kernel hacker David Miller for the changes."
That was someone breaking into the CVS server to sneak in a change. I'm talking about developers making real code contributions the normal way, with the changes concerted in such a way that each change seems innocent until they are all put together. It doesn't have to be in the Linux kernel, either. It could be in Apache, one of its modules, or any number of other pieces of software.
Of course, I was also partially joking.
How hard would it be to create a vulnerability in open source software? If subtle enough, I imagine a vulnerability could be added to a project via several coordinated updates made by multiple contributors (something where no single change caused it, but a combination of changes caused it), and spread out over time so it would appear to be an innocent mistake.
Well, I did say it was the "assembly language" of scripting languages. When you try to extend it in C, you even have to manually push args onto the "stack" and pop the results off. *shudder* IMO Ruby is the best scripting language, but its runtime engine has some serious issues (slow, violently unfriendly to threads even in C/C++ extensions, etc.) Once you get used to Ruby, other scripting languages seem like a pain (and compiled languages even more of a pain). FYI, Rails sucks, but the core Ruby language is a thing of beauty and elegance.
Oh please. The last time I rolled my own AVL tree, it ran an order of magnitude faster than std::map (benchmarked using a 32-bit int for a key). Adds, seeks, and deletes were all much faster whether I was inserting data in order or not. I will use std::map where I don't need speed, but I'll use my own in some cases where speed is critical.
Standards and guidelines are all very good, but no programming rule I've ever read makes sense 100% of the time (although a few rules come damn close), and knowing when you should bend the rules is part of being a good programmer. Too many of the newer rules seem to exist solely to keep poor programmers out of trouble. To those of us who can keep ourselves out of trouble, it is definitely a mixed blessing.
As with other solar collectors, they may also be able to go vertical like this:
http://www.verticalfarm.com/
I agree that Java is great in many ways, and IMO provides the best cross-platform web/app server available. However, if you need to distribute a commercial application with a web app attached to it (for a company's Intranet), distributing the entire JDK for JSP compilation is a bit of a burden. ;-) You can precompile the JSP, but even the distributing the JRE is a bit of a burden (and sometimes you may need to test customizations and/or hotfixes on a customer's system).
That's the big Achilles heel of most scripting languages, and just about anything else developed for cross-platform Unix support (look at how long it took Apache to get threads, and even then it doesn't help to use them with mod-php, mod-python, or mod-ruby). If you want fast (for a scripting language), multi-threaded, and not dependent on Java or .Net, I suppose there's Lua (and LuaJIT). Unfortunately, Lua is like the "assembly language" of scripting languages.
See title.
BS. They don't have to take down the building. The fire caused would presumably do more damage than the explosion. Perhaps they would load it up with something like napalm instead of explosives. And with millions of flying cars buzzing around a city, they could use dozens in one attack far more easily than they could use planes today. Read the response I made to the other guy's reply. It adds a lot more to the argument.
BS.
1) A high curb or a few steps would be enough to stop a car from crashing into a building at high speed. There are any number of simple and cheap barriers like that one could use. Even the way downtown city streets are designed would keep cars from being able to come flying through the front door of a building at 100 MPH. Most tall buildings I've seen have thick concrete walls at the base (something a car wouldn't be able to break through), and most have at least a few steps leading up to the front door. An explosion happening on the outside of a building would do very little damage compared to one happening on the inside. A flying car could very easily pick a window it wanted to enter through, and come tearing in at top speed (which may be up to 200 or 300 MPH). A good bit of the damage would be caused by the weight and velocity, and any potential fires it might start.
2) Airplanes are more expensive, there are far fewer of them, and they are more tightly controlled than cars. Aircraft deviating from their flight plan are more easily spotted, and more easily intercepted if necessary because there are so few of them. It would be very different if there were millions of vehicles flying around every city, going pretty much anywhere they wanted (with soccer moms accidentally flying over a military base while putting on their makeup). They would also be cheaper and easier to obtain, and it would be possible for terrorist groups to use dozens of them in a single attack. It would make things 100 times easier for them than it would be for them to do the same with airplanes today, especially if they chose to go after military targets.
3) Kamikaze pilots were extremely effective in WWII. They were so effective that if they hadn't run out of planes and pilots, they might have sunk our naval fleet, causing us to lose on the Pacific front. If you don't think a dozen flying cars hitting a military base would be a problem, what about a hundred or a thousand? With planes today it would be unthinkable for anyone to try something that big. With everyone in a city using a flying car, it would seem a lot easier.