Either I read the article correctly or it is misleading. It says that different command line parameters are necessary for different printing modes, and that the parameters are set by the user. In order to set up his different printers, he had to change the printing command line options in each of the different printer instances. It's true that this only needs to be done once per mode and the user can then select different "virtual" printers for the right option set without re-typing the stored command line, but it does need to be done once per mode -- or else the article is false in saying that "when I want to print in colour, I can just change the print command used by the program from 'lpr' to something like 'lpt -Ptp0'". That states that the user changes the command line; it does not state at any point that using GUI options changes the command line for the user.
Printer set-up and configuration is as simple as on Windows or MacOS
TurboPrint for Linux comes as a tarball containing 'install' and 'uninstall' shell scripts, installation instructions, and all the binary software.
Yes, it's a command-line installer!
The default printing would be in black and white, and when I want to print in colour, I can just change the print command used by the program from 'lpr' to something like 'lpt -Ptp0'.
Yes, you have to give command line options to set printing modes every time you print with a different mode!
And yet this gets an 18 out of 20 in the review. It's amazing to me that this late in the game, there are still so many Linux-heads who just don't get it. This is not just inferior to Mac and Windows -- it's a giant quantum leap backward from where Mac has been for seventeen years and Windows for six. Real end users don't memorize command languages.
I agree completely. Performance considerations trump elegance considerations, provided they are driven by empirical measurement rather than speculation.
However, this does not necessarily mean throwing all abstraction out the window. Much can be inlined or macro'd effectively.
But yes, needs must when the devil drives. However, this is a very different case from the usual lazy copy-and-paste scenario, which seems to be driven by the strange idea that adding the one line of code to make something a method or subroutine takes longer than copying the entire segment and tailoring it to a local need. I've really never understood how this was supposed to save coding time even in the short term, and it's clearly a huge loss over the middle and long term.
The old 'clunky Mozilla' widgets still appear in Preferences, but there are native widgets when veiwing and dealing with forms in pages.
Hmm. That's the exact opposite of what I'm seeing on the Mac. I see Mozilla widgets in form pages, but (some) native widgets in Preferences and other dialogs. If the bug report said something about what the intent and effects of the change were, that might help make sense of this.
The strangest thing I noticed about the new Mozilla for the Mac is that it seems to be using some native widgets in the UI. Bring up Preferences and what ho, those are Macintosh buttons, check boxes, and radio buttons, not the clunky Mozilla ones. But look on a form page and you'll still see the boxy Mozilla controls.
Is there a partial adoption of native widgets in progress? Bug 112980 seems to imply so but details are scanty. The bug does not even have a description, only a title and comments.
If the Mozilla team has finally caught on to the importance of respecting platform UI standards, though, hats off to them.
I second all that has been said about making sure that you really need to do this and that it is worth the time and risk. One sign that you may need to do so is an excessive reopened bug rate, where fixing one bug often creates another bug due to side effects and component interactions. If you decide that it is, then the three keys to success will be modularity, incremental rollout, and unit tests.
Modularity is probably what you're already thinking about. Go over the old code base, in a code review, and find where the same thing is done over and over either with copy-and-paste code -- the bane of crap engineers -- or with different code that serves the same ends. Look for repeated sequences in particular. Create a new library that encapsulates those pieces of code.
Incremental rollout is vital. Only replace small parts of your system at a time, doing complete retests frequently. Don't write a new encapsulated routine and then roll it out to each of the three dozen places in which it appears in the whole code base. Write the whole function library, with unit tests, and then start applying it to separable modules one by one, retesting as you go. Otherwise I guarantee the whole thing will fall apart and you won't be able to tell why. Ideally, you might set a threshold on the rate of replacement of old modules and work primarily on creating new modules with the abstracted logic.
Unit tests are crucial because, as noted, the messiness of your old code probably conceals a lot of necessary logic. We had this great phenomenon on Apple's Copland where people who had never used the old OS managers were rewriting them in C or C++ from the assembly source. When they saw something in the assembly they didn't understand, they just ignored it. Guess what -- the new managers didn't have any backwards compatibility. The only answer to this is to have a thorough unit test for any module that you replace, against which you can test the new version. This also confers other quality benefits, but during a rewrite it's critical.
Finally, once you have replaced a significant number of your modules, you will find that new levels of abstraction appear. The average size of each function or method will have shrunk considerably, and now it becomes possible to see new repeated code sequences that were not visible due to the old cruft. Move these into your new library modules and start using them in continuing replacement work. In addition, start going back -- slowly and incrementally -- through the already converted modules and replacing the repeated sequences with calls to the new abstractions.
Finally, figure out how you got into this mess in the first place. The worst programmer habit I know of is copy-and-paste coding instead of using subroutines. You can tell people not to do it, but some always will. Those people should be bid farewell -- you can't afford their overhead. Other common problems include lack of planning and review, a code first and think later mentality. Start moving your organization up the levels of the CMM and you may find that you wind up with fewer modules that need replacement.
Excerllent points. One of the things overlooked by the "Linux is friendly -- there's even a GUI now" crowd is that usability concerns are pervasive throughout system design. It would never occur to most engineers that driver recompilation is a user experience issue, but as you've shown, requiring compilation per kernel version is a major usability flaw.
Yet even on a project with dedicated usability staff -- unlike, say, the Linux kernel -- the engineers would probably push back if usability tried to get involved with such an issue. They would be told that it "works great for me" or that users should "RTFM" or that "we're not going to build it for stupid people" or "it doesn't have a user interface."
Until the user-centered design revolution comes to permeate the open source engineering culture, open source software will never be able to match the products of companies like Apple, Microsoft and Adobe. But since open source largely exists as a revolt against user-friendly software, and as a reactionary return to the command line, that cultural change will probably never happen.
Nanotech is decades off. This whole thing was completley blown out of proportion. Let's keep it in reality, please. What's the point of even having a business alliance for a non-existant business?
I've been a critic of nanotechnology ever since reading Drexler's rather silly book in the 1980's, but I feel you are mistaken in the absolutism of your position. It has become clear from the mid-1990's to the present that nanotechnology is real, and that nanotechnology has very little to do with the crackpot speculations of the 1980's. The movement has differentiated into the real wing, represented by among others the inventors of buckminsterfullerene, and the remaining crackpot wing, still led by K. Eric Drexler and other quacks such as Ralph Merkle.
Which half of the movement is being represented here? Well, let's take a look at the overview of nanotechnology at the NanoBusiness Aliance web site. What ho, it's quite pragmatic. "Reporting, both from the popular press and respected business sources, all too often mixes up nanotechnologies that are just around the corner with those that are highly speculative or very long-term." Very true, and as polite a critique of the quack wing as one could hope for.
Let's see what technology they're most interested in. Is it artificial intelligence? Resurrection of the dead? Medical nanobots? General-purpose assemblers? Smart mists? No, it's materials, electronics, and biochemistry, all of which have started to be affected by nanotechnology now. Interesting. Even more interesting, looking at their coming reports page, we see very plausible applications for the short term, and no bizarre science fantasy of any kind.
So it looks like these are the people we would want talking to Congress. Let's give them a shot.
The post in question is neither a troll nor a flame. It is something which apparently the net, nineteen years later, still has no category for dealing with. It is called "humor."
I went looking for a couple of long-lost messages, but they are clearly not in the archive. Search for "Bean-Hill-Influence Lad", a parody of a bad comic book called the Legion of Super Heroes, and you will find quite a few messages quoting and discussing the original post, but no copy of the original.
Similarly, I looked for the original discussion of the resemblance of Star Trek's Ferengi to traditional anti-Semitic stereotypes in sf-lovers, and found that it is also not extant in the archives.
It worries me that the two messages I went looking for are both not present, in that it seems to imply quite a few holes in the archive. Still, perhaps I can be content with the 8,280 posts containing my name.
Exactly. And there's very little need for documentation in most well-designed software systems. A program that is designed to present how it works in a clear and accessible fashion makes a manual largely unnecessary. Where there is a remaining need for software documentation is in geek-oriented systems like programming languages. For end-user-targeted software, documentation is just a CYA that companies still produce for legacy reasons.
"Hey, my web site works perfectly! It's probably your own fault. You did read the help page, right?"
And it's even easier to set up fle sharing on the Mac. It's an interesting obstacle we're seeing here, where people insist on one hand that the platform is perfectly easy to use, but then on the other say "oh, that's just for experts" when dealing with basic features like file sharing that are perfectly easy on the other platforms. Web sharing would be another example. On the Mac, you can literally just drag HTML files into your web sharing folder. On Linux, you'd have to spend two days learning Apache, and only a system administrator would even succeed in that. Peripheral setup is another area where there are vast differences in friendliness between the platforms, and which an ordinary user would want (or more likely need) to do.
The command line mentality may be crumbling in some areas, but these "expert areas" will have to give way if Linux is ever to reach the user-friendliness of the Mac.
Nerves are hard to regenerate once cut - the actual nerve cells only proliferate at birth, so if you lost a nerve cell that's them gone forever.
Actually, the formation of new nerve cells in the adult human brain has been observed for several years now. Your statement would have been taken as correct some years ago but is now known to be incorrect. As you noted yourself:
The story does not say anything about sight having been regained through use of the technique, only about the degree of regrowth. If any tests on sight were done, they are not mentioned. That makes this result highly questionable in terms of possible clinical value.
There are many things that could thwart the restoration of sight -- for instance, if severed axons joined to the wrong partners, then sight could be kaleidoscoped; or if the axons grew back incorrectly, they might not transmit action potentials reliably.
Given that the lens is damaged in this procedure, it might not have been possible for them to test sight, but assuming there are other possible sources of crystallins, a followup experiment that tests for sight restoration should be this team's first priority. I'll go out on a limb and predict that 30% regrowth plus probable kaleidoscoping will prove to be only barely useful.
For all the questions asked and objections raised, you have yet to either defend or apologize for your overtly anti-Semitic statement, "it's probably just a greedy jew thing." Is it your feeling that this nauseating comment was somehow justified, or that it is such a minor issue that it is beneath your notice?
You said, "I'm proud to be a Black man." Well, congratulations, you've just reinforced the stereotype that all African-Americans are anti-Semites. Now that's something to be proud of!
I'm glad I know it's not true, and that bigots like yourself do not represent the entire black community. But I see more than enough of this crap, and it makes me wonder just how bad the problem is.
It's not a buffer overrun error, though. It's an unallocated pointer deallocation. There's a message below that says a bit more, but I'm still not clear on how you could use an earlier successful request to forge a malicious malloc header at an arbitrary location pointed to by an uninitialized variable. Seems like some heavy voodoo, if it's even possible -- and unless circumstances conspire to make the uninitialized variable value deterministic, probably not possible at all. All in all it seems to rest on a bizarre set of coincidences that probably wouldn't happen. The uninitialized value would have to always be the same, and you'd need to be able to predict that your successful request would always store its data into the indicated place, which would have to be within the memory space of the program. How likely is that?
The exploit seems to require a great deal of preparation, in-depth knowledge of software, and some other form of access to the target host.
Yeah, it seemed to me that the requirement that you be able to write into process memory made this a no-op. It's kind of like a way to pick a lock that requires you to already be on the inside of the door. If you can write into process memory, don't you already pretty much have the keys to the kingdom? But it's not the easiest thing to get.
Again, if I'm missing something here, please set me straight gently. Maybe there are standard clever hacker tricks for exploiting deallocation of unallocated pointers. But I've been programming (legitimately) for twenty years and I don't know how I would make use of this to do anything but risk a crash, unless I already had so much access that I wouldn't need this trick.
The attacker must ensure that a maliciously constructed malloc header containing the target address and it's replacement value are in the right location in the uninitialized part of the heap. The attacker must also place shellcode in server process memory.
Color me stupid, but that doesn't sound too feasible for a remote hack. How would you muck with the malloc heap this way? DoS, maybe, but unless there's something I'm missing, not too great for root access. Let me know if there's something I'm missing.
Tens of thousands per year. More important still is the installed base of these machines, which run into the hundreds of thousands. To be honest, most of the installed base of these machines don't currently run Linux, being split among OS/390, OS/400, AIX, and (of course)
I'm not sure of the source of your numbers, but let's take them as golden, and say 50,000. Now, I wonder how many of those new systems run Linux, and how many run IBM's OS. Would half be a nice optimistic guesstimate? As for conversion of machines already in the field, I'd have to say I'd be surprised if it were as much as five percent overall, and much less than that per year. For now let's ignore it. So that's maybe 25,000 each year.
Now, how much are the support contracts? The Red Hat site doesn't really give numbers for all its options, but the Enterprise Edition comes with a pretty sweet support contract, and it's $2,500. A later message in the thread says IBM support can be about $10,000 per annum, so let's split the difference and say $6,250 per box. Let's further be optimistic and say that anyone who can afford one of these servers will get a support contract -- even though people running Linux may be inherently cost-averse.
Yeah, I know this is really fuzzy. I'm just trying to get somewhere close to an order of magnitude here.
So that would be something close to 25,000 * $6,250 = $156 million per year, increasing by that amount per year, and more than doubling Red Hat's current revenue in the first year. Not too shabby! But I'm not sure how real those numbers are, or what the cost of generating the revenue would be -- services businesses traditionally have pretty slim margins, and it looks like there's some R&D to be done before this even starts. Still, if this is even in the ballpark it could be pretty sweet.
Plus, [IBM has] laid off the risk of Linux failing and the cost of hiring new people to an independent entity.
That's the thing that concerns me. There's something about this that smells more like passing the buck than sharing the wealth. If the adoption percentages are significantly lower than my guesstimates -- like 25% of new systems instead of 50%, or a 50% purchase of support contracts instead of 100%, much less both -- it's not going to do that much for Red Hat. I guess time will tell. For now I'm happy to be confused on a higher plane.
I'm not sure what to make of this exactly. How many of these servers does IBM sell? If the services market here is lucrative, then why doesn't IBM keep it for itself? Still, it seems like it might be a nice little revenue stream for Red Hat.
Do you think a computer (no matter how much people idolise the things) could tell the difference between two basic thoughts? For a start you'd have to interface to some massive fraction of the number of nerve cells, then you'd have to get all this data to a huge computer somewhere and have it analysed. And for what? The best way to find out what someone is thinking is to just ask them. There'll never be a computer that can read peoples' minds anywhere near as well as a good trial lawyer who's trained to study faces.
I appreciate your attempt to reign in wild speculators who think mind-reading is as easy as sticking a wire in the brain, but "never" is a long time. If Moore's Law continues and noninvasive scanning technologies continue to improve at the rate they have for the last century, then the technology for this might be available next century, or even this century. Or genetic engineering might have the capability to plant a large number of noninjurious artificial probes.
What's much harder than the collection is the data analysis. We still don't really have much of a grasp on a scientific level of what consciousness is or what thoughts are. What's more, the data so far concerning machines that try to allow the handicapped to write via brain waves indicate that the brain's state is extremely variable from hour to hour, so that the same signal patterns don't recur even when the person is having what they think is the same thought. I have a feeling we will only begin to make substantial progress in consciousness research once we create the necessary data collection technologies, and even then it may be decades or more before the problem is solved to the extent that, say, the human genome is now.
On the other hand, simple affectors and effectors are certainly a much easier problem than global mind-reading or the direct absorption of information. When the first generally useful neural interfaces become available, they'll probably function a lot like a modern head-mounted computer with speech recognition. There will be a virtual screen with translucent overlay of the visual field, a way to speak into the system while not speaking aloud, and some way to point on the screen. This is probably not more than two or three decades away. The question is what it will be good for, since the same technology in an external form through wired glasses, a miniature microphone, gesture recognition wristwatch or ring, and tiny personal computer will all be available without surgery or bioengineering. Privacy in public spaces is the only major advantage that comes to mind.
Slashdot Mirror
Either I read the article correctly or it is misleading. It says that different command line parameters are necessary for different printing modes, and that the parameters are set by the user. In order to set up his different printers, he had to change the printing command line options in each of the different printer instances. It's true that this only needs to be done once per mode and the user can then select different "virtual" printers for the right option set without re-typing the stored command line, but it does need to be done once per mode -- or else the article is false in saying that "when I want to print in colour, I can just change the print command used by the program from 'lpr' to something like 'lpt -Ptp0'". That states that the user changes the command line; it does not state at any point that using GUI options changes the command line for the user.
Tim
What's wrong with this picture?
Printer set-up and configuration is as simple as on Windows or MacOS
TurboPrint for Linux comes as a tarball containing 'install' and 'uninstall' shell scripts, installation instructions, and all the binary software.
Yes, it's a command-line installer!
The default printing would be in black and white, and when I want to print in colour, I can just change the print command used by the program from 'lpr' to something like 'lpt -Ptp0'.
Yes, you have to give command line options to set printing modes every time you print with a different mode!
And yet this gets an 18 out of 20 in the review. It's amazing to me that this late in the game, there are still so many Linux-heads who just don't get it. This is not just inferior to Mac and Windows -- it's a giant quantum leap backward from where Mac has been for seventeen years and Windows for six. Real end users don't memorize command languages.
Tim
I agree completely. Performance considerations trump elegance considerations, provided they are driven by empirical measurement rather than speculation.
However, this does not necessarily mean throwing all abstraction out the window. Much can be inlined or macro'd effectively.
But yes, needs must when the devil drives. However, this is a very different case from the usual lazy copy-and-paste scenario, which seems to be driven by the strange idea that adding the one line of code to make something a method or subroutine takes longer than copying the entire segment and tailoring it to a local need. I've really never understood how this was supposed to save coding time even in the short term, and it's clearly a huge loss over the middle and long term.
Tim
I believe the current Mac numbers are more like 4-5% than 10%, sadly.
Tim
The old 'clunky Mozilla' widgets still appear in Preferences, but there are native widgets when veiwing and dealing with forms in pages.
Hmm. That's the exact opposite of what I'm seeing on the Mac. I see Mozilla widgets in form pages, but (some) native widgets in Preferences and other dialogs. If the bug report said something about what the intent and effects of the change were, that might help make sense of this.
Tim
The strangest thing I noticed about the new Mozilla for the Mac is that it seems to be using some native widgets in the UI. Bring up Preferences and what ho, those are Macintosh buttons, check boxes, and radio buttons, not the clunky Mozilla ones. But look on a form page and you'll still see the boxy Mozilla controls.
Is there a partial adoption of native widgets in progress? Bug 112980 seems to imply so but details are scanty. The bug does not even have a description, only a title and comments.
If the Mozilla team has finally caught on to the importance of respecting platform UI standards, though, hats off to them.
Tim
I second all that has been said about making sure that you really need to do this and that it is worth the time and risk. One sign that you may need to do so is an excessive reopened bug rate, where fixing one bug often creates another bug due to side effects and component interactions. If you decide that it is, then the three keys to success will be modularity, incremental rollout, and unit tests.
Modularity is probably what you're already thinking about. Go over the old code base, in a code review, and find where the same thing is done over and over either with copy-and-paste code -- the bane of crap engineers -- or with different code that serves the same ends. Look for repeated sequences in particular. Create a new library that encapsulates those pieces of code.
Incremental rollout is vital. Only replace small parts of your system at a time, doing complete retests frequently. Don't write a new encapsulated routine and then roll it out to each of the three dozen places in which it appears in the whole code base. Write the whole function library, with unit tests, and then start applying it to separable modules one by one, retesting as you go. Otherwise I guarantee the whole thing will fall apart and you won't be able to tell why. Ideally, you might set a threshold on the rate of replacement of old modules and work primarily on creating new modules with the abstracted logic.
Unit tests are crucial because, as noted, the messiness of your old code probably conceals a lot of necessary logic. We had this great phenomenon on Apple's Copland where people who had never used the old OS managers were rewriting them in C or C++ from the assembly source. When they saw something in the assembly they didn't understand, they just ignored it. Guess what -- the new managers didn't have any backwards compatibility. The only answer to this is to have a thorough unit test for any module that you replace, against which you can test the new version. This also confers other quality benefits, but during a rewrite it's critical.
Finally, once you have replaced a significant number of your modules, you will find that new levels of abstraction appear. The average size of each function or method will have shrunk considerably, and now it becomes possible to see new repeated code sequences that were not visible due to the old cruft. Move these into your new library modules and start using them in continuing replacement work. In addition, start going back -- slowly and incrementally -- through the already converted modules and replacing the repeated sequences with calls to the new abstractions.
Finally, figure out how you got into this mess in the first place. The worst programmer habit I know of is copy-and-paste coding instead of using subroutines. You can tell people not to do it, but some always will. Those people should be bid farewell -- you can't afford their overhead. Other common problems include lack of planning and review, a code first and think later mentality. Start moving your organization up the levels of the CMM and you may find that you wind up with fewer modules that need replacement.
Hope this helps.
Tim
Excerllent points. One of the things overlooked by the "Linux is friendly -- there's even a GUI now" crowd is that usability concerns are pervasive throughout system design. It would never occur to most engineers that driver recompilation is a user experience issue, but as you've shown, requiring compilation per kernel version is a major usability flaw.
Yet even on a project with dedicated usability staff -- unlike, say, the Linux kernel -- the engineers would probably push back if usability tried to get involved with such an issue. They would be told that it "works great for me" or that users should "RTFM" or that "we're not going to build it for stupid people" or "it doesn't have a user interface."
Until the user-centered design revolution comes to permeate the open source engineering culture, open source software will never be able to match the products of companies like Apple, Microsoft and Adobe. But since open source largely exists as a revolt against user-friendly software, and as a reactionary return to the command line, that cultural change will probably never happen.
Tim
Nanotech is decades off. This whole thing was completley blown out of proportion. Let's keep it in reality, please. What's the point of even having a business alliance for a non-existant business?
I've been a critic of nanotechnology ever since reading Drexler's rather silly book in the 1980's, but I feel you are mistaken in the absolutism of your position. It has become clear from the mid-1990's to the present that nanotechnology is real, and that nanotechnology has very little to do with the crackpot speculations of the 1980's. The movement has differentiated into the real wing, represented by among others the inventors of buckminsterfullerene, and the remaining crackpot wing, still led by K. Eric Drexler and other quacks such as Ralph Merkle.
Which half of the movement is being represented here? Well, let's take a look at the overview of nanotechnology at the NanoBusiness Aliance web site. What ho, it's quite pragmatic. "Reporting, both from the popular press and respected business sources, all too often mixes up nanotechnologies that are just around the corner with those that are highly speculative or very long-term." Very true, and as polite a critique of the quack wing as one could hope for.
Let's see what technology they're most interested in. Is it artificial intelligence? Resurrection of the dead? Medical nanobots? General-purpose assemblers? Smart mists? No, it's materials, electronics, and biochemistry, all of which have started to be affected by nanotechnology now. Interesting. Even more interesting, looking at their coming reports page, we see very plausible applications for the short term, and no bizarre science fantasy of any kind.
So it looks like these are the people we would want talking to Congress. Let's give them a shot.
Tim
The post in question is neither a troll nor a flame. It is something which apparently the net, nineteen years later, still has no category for dealing with. It is called "humor."
Tim
I went looking for a couple of long-lost messages, but they are clearly not in the archive. Search for "Bean-Hill-Influence Lad", a parody of a bad comic book called the Legion of Super Heroes, and you will find quite a few messages quoting and discussing the original post, but no copy of the original.
Similarly, I looked for the original discussion of the resemblance of Star Trek's Ferengi to traditional anti-Semitic stereotypes in sf-lovers, and found that it is also not extant in the archives.
It worries me that the two messages I went looking for are both not present, in that it seems to imply quite a few holes in the archive. Still, perhaps I can be content with the 8,280 posts containing my name.
Tim Maroney
the first USENET censorship case
Users. Don't. Read. Documentation.
Exactly. And there's very little need for documentation in most well-designed software systems. A program that is designed to present how it works in a clear and accessible fashion makes a manual largely unnecessary. Where there is a remaining need for software documentation is in geek-oriented systems like programming languages. For end-user-targeted software, documentation is just a CYA that companies still produce for legacy reasons.
"Hey, my web site works perfectly! It's probably your own fault. You did read the help page, right?"
Tim
And it's even easier to set up fle sharing on the Mac. It's an interesting obstacle we're seeing here, where people insist on one hand that the platform is perfectly easy to use, but then on the other say "oh, that's just for experts" when dealing with basic features like file sharing that are perfectly easy on the other platforms. Web sharing would be another example. On the Mac, you can literally just drag HTML files into your web sharing folder. On Linux, you'd have to spend two days learning Apache, and only a system administrator would even succeed in that. Peripheral setup is another area where there are vast differences in friendliness between the platforms, and which an ordinary user would want (or more likely need) to do.
The command line mentality may be crumbling in some areas, but these "expert areas" will have to give way if Linux is ever to reach the user-friendliness of the Mac.
Tim
Interesting, thanks. However, if you check the rest of the story, they did confirm adult neuron growth in the hippocampus and the olfactory bulb.
Tim
Nerves are hard to regenerate once cut - the actual nerve cells only proliferate at birth, so if you lost a nerve cell that's them gone forever.
Actually, the formation of new nerve cells in the adult human brain has been observed for several years now. Your statement would have been taken as correct some years ago but is now known to be incorrect. As you noted yourself:
science moves very fast
Cheers,
Tim
The story does not say anything about sight having been regained through use of the technique, only about the degree of regrowth. If any tests on sight were done, they are not mentioned. That makes this result highly questionable in terms of possible clinical value.
There are many things that could thwart the restoration of sight -- for instance, if severed axons joined to the wrong partners, then sight could be kaleidoscoped; or if the axons grew back incorrectly, they might not transmit action potentials reliably.
Given that the lens is damaged in this procedure, it might not have been possible for them to test sight, but assuming there are other possible sources of crystallins, a followup experiment that tests for sight restoration should be this team's first priority. I'll go out on a limb and predict that 30% regrowth plus probable kaleidoscoping will prove to be only barely useful.
Tim
Why do we bother sending people to space when there are so many problems on earth?
/. when you could be off working in a soup kitchen?
Why do you bother posting to
Tim
For all the questions asked and objections raised, you have yet to either defend or apologize for your overtly anti-Semitic statement, "it's probably just a greedy jew thing." Is it your feeling that this nauseating comment was somehow justified, or that it is such a minor issue that it is beneath your notice?
You said, "I'm proud to be a Black man." Well, congratulations, you've just reinforced the stereotype that all African-Americans are anti-Semites. Now that's something to be proud of!
I'm glad I know it's not true, and that bigots like yourself do not represent the entire black community. But I see more than enough of this crap, and it makes me wonder just how bad the problem is.
Tim
You deserve a mod up for that -- it's the most informative post in the thread.
Holy cow, though, some people do have way too much time on their hands.
Tim
It's not a buffer overrun error, though. It's an unallocated pointer deallocation. There's a message below that says a bit more, but I'm still not clear on how you could use an earlier successful request to forge a malicious malloc header at an arbitrary location pointed to by an uninitialized variable. Seems like some heavy voodoo, if it's even possible -- and unless circumstances conspire to make the uninitialized variable value deterministic, probably not possible at all. All in all it seems to rest on a bizarre set of coincidences that probably wouldn't happen. The uninitialized value would have to always be the same, and you'd need to be able to predict that your successful request would always store its data into the indicated place, which would have to be within the memory space of the program. How likely is that?
Tim
The exploit seems to require a great deal of preparation, in-depth knowledge of software, and some other form of access to the target host.
Yeah, it seemed to me that the requirement that you be able to write into process memory made this a no-op. It's kind of like a way to pick a lock that requires you to already be on the inside of the door. If you can write into process memory, don't you already pretty much have the keys to the kingdom? But it's not the easiest thing to get.
Again, if I'm missing something here, please set me straight gently. Maybe there are standard clever hacker tricks for exploiting deallocation of unallocated pointers. But I've been programming (legitimately) for twenty years and I don't know how I would make use of this to do anything but risk a crash, unless I already had so much access that I wouldn't need this trick.
Tim
The attacker must ensure that a maliciously constructed malloc header containing the target address and it's replacement value are in the right location in the uninitialized part of the heap. The attacker must also place shellcode in server process memory.
Color me stupid, but that doesn't sound too feasible for a remote hack. How would you muck with the malloc heap this way? DoS, maybe, but unless there's something I'm missing, not too great for root access. Let me know if there's something I'm missing.
Tim
Tens of thousands per year. More important still is the installed base of these machines, which run into the hundreds of thousands. To be honest, most of the installed base of these machines don't currently run Linux, being split among OS/390, OS/400, AIX, and (of course)
I'm not sure of the source of your numbers, but let's take them as golden, and say 50,000. Now, I wonder how many of those new systems run Linux, and how many run IBM's OS. Would half be a nice optimistic guesstimate? As for conversion of machines already in the field, I'd have to say I'd be surprised if it were as much as five percent overall, and much less than that per year. For now let's ignore it. So that's maybe 25,000 each year.
Now, how much are the support contracts? The Red Hat site doesn't really give numbers for all its options, but the Enterprise Edition comes with a pretty sweet support contract, and it's $2,500. A later message in the thread says IBM support can be about $10,000 per annum, so let's split the difference and say $6,250 per box. Let's further be optimistic and say that anyone who can afford one of these servers will get a support contract -- even though people running Linux may be inherently cost-averse.
Yeah, I know this is really fuzzy. I'm just trying to get somewhere close to an order of magnitude here.
So that would be something close to 25,000 * $6,250 = $156 million per year, increasing by that amount per year, and more than doubling Red Hat's current revenue in the first year. Not too shabby! But I'm not sure how real those numbers are, or what the cost of generating the revenue would be -- services businesses traditionally have pretty slim margins, and it looks like there's some R&D to be done before this even starts. Still, if this is even in the ballpark it could be pretty sweet.
Plus, [IBM has] laid off the risk of Linux failing and the cost of hiring new people to an independent entity.
That's the thing that concerns me. There's something about this that smells more like passing the buck than sharing the wealth. If the adoption percentages are significantly lower than my guesstimates -- like 25% of new systems instead of 50%, or a 50% purchase of support contracts instead of 100%, much less both -- it's not going to do that much for Red Hat. I guess time will tell. For now I'm happy to be confused on a higher plane.
Tim
The press release at Red Hat also mentions software solutions.
I'm not sure what to make of this exactly. How many of these servers does IBM sell? If the services market here is lucrative, then why doesn't IBM keep it for itself? Still, it seems like it might be a nice little revenue stream for Red Hat.
Tim
Do you think a computer (no matter how much people idolise the things) could tell the difference between two basic thoughts? For a start you'd have to interface to some massive fraction of the number of nerve cells, then you'd have to get all this data to a huge computer somewhere and have it analysed. And for what? The best way to find out what someone is thinking is to just ask them. There'll never be a computer that can read peoples' minds anywhere near as well as a good trial lawyer who's trained to study faces.
I appreciate your attempt to reign in wild speculators who think mind-reading is as easy as sticking a wire in the brain, but "never" is a long time. If Moore's Law continues and noninvasive scanning technologies continue to improve at the rate they have for the last century, then the technology for this might be available next century, or even this century. Or genetic engineering might have the capability to plant a large number of noninjurious artificial probes.
What's much harder than the collection is the data analysis. We still don't really have much of a grasp on a scientific level of what consciousness is or what thoughts are. What's more, the data so far concerning machines that try to allow the handicapped to write via brain waves indicate that the brain's state is extremely variable from hour to hour, so that the same signal patterns don't recur even when the person is having what they think is the same thought. I have a feeling we will only begin to make substantial progress in consciousness research once we create the necessary data collection technologies, and even then it may be decades or more before the problem is solved to the extent that, say, the human genome is now.
On the other hand, simple affectors and effectors are certainly a much easier problem than global mind-reading or the direct absorption of information. When the first generally useful neural interfaces become available, they'll probably function a lot like a modern head-mounted computer with speech recognition. There will be a virtual screen with translucent overlay of the visual field, a way to speak into the system while not speaking aloud, and some way to point on the screen. This is probably not more than two or three decades away. The question is what it will be good for, since the same technology in an external form through wired glasses, a miniature microphone, gesture recognition wristwatch or ring, and tiny personal computer will all be available without surgery or bioengineering. Privacy in public spaces is the only major advantage that comes to mind.
Tim