Since when is an FTP server considered part of the kernel? Damn userland wannabes don't even know what the kernel *is* let alone how to develop one.
Re:But how do they choose the container to use?
on
Ageism in IT?
·
· Score: 2, Insightful
How can you just say they can "choose a container" when they don't even know why they would choose one container over another?
To choose the right container they need to understand algorithmic complexity and the performance guarantees made by each container type (I never said they didn't have to know anything) but they don't need to know how each container is actually implemented. It's the same as needing to know what delivery/ordering guarantees are made when they call a network API, or what durability/consistency guarantees are associated with filesystem calls, without actually knowing how those things are implemented. Interfaces can and should be defined in terms of function, not implementation.
A lot of people seem to be suggesting that you just threaten to quit en masse. In its simplest form I don't think that would work, but a related approach might. I'd consider having everyone work regular hours, no matter what management wants. Make it clear that if they fire you for doing your jobs under the same conditions as existed before, you'll sue both them and the customer for wrongful termination, breach of contract, unfair retaliation, and anything else that has any chance whatsoever of sticking in your jurisdiction. Mention the adverse publicity too. Instead of allowing your employer to stick you with a choice between taking it up the rear or losing your job, stick them with a choice between getting the project done on a reasonable schedule or having it done even later and under a cloud of lawsuits that will forever poison their relationship with the customer. Sure, they can fire you after the project's done, but most of the grounds for lawsuits would still exist and the economy might be better then.
Not only did other flavors of UNIX, and even NT, have virtual filesystem layers long before Linux, they are all to this day better than the one in Linux. The only thing "original" about the Linux VFS layer is the severe NIH syndrome and the near impossibility of getting a satisfactory result from its brain-damaged locking.
You don't have to love Java/C++/C#, but refusing to look into it because 'you can do the same in C' is not an acceptable answer when we start a multi-site, multi-engineering project.
I've had to put up with the opposite too - people who insist on using Java in part of a complex system even though other components had to be written in C/C++ and they all had to work together closely. To mingle and paraphrase a couple of your points, I don't care how good their Java skills are, or what Java toys they get to play with in preparation for a jump to the next dot-com. If I'd been there at the time to see them start using Java for a primarily C/C++ project, I would have kicked their asses. Nothing could have justified the multiple instances of cross-language API integration that such a selfish decision has caused.
That doesn't refute your point, of course; it's not intended to. Just another "war story" from another old fart.;-)
Re:Not true of programming
on
Ageism in IT?
·
· Score: 1
after ten+ years of programming experience (and that's just industry, not counting the stuff I did in college and before) I'm still telling some people what hashtables are.
Then again, most programmers don't need to know what hash tables are, any more than they need calculate individual pixels to draw a circle on the screen. The level of abstraction has moved up. Someone, somewhere, has to know that stuff, just like compiler writers need to know how to generate decent machine code, but most programmers just need to choose the right STL container and run their code through a compiler. They don't need to know how those things work, and in fact they might work quite differently from one version to the next while still honoring the same contract.
Personally I'm a low-level kind of guy; I know damn well what a hash table is and how a reliable communication protocol works and so on. I look down on user-level programmers because what they do is so easy, and because so many of them (patterns weenies, J2EE dorks, FP zealots) obsess over style while forgetting substance, but not because they don't know things that there's no longer any good reason for them to know.
MTV has been lame for six years? Try fifteen, and it was only slightly un-lame before that. If you think MTV was *ever* more than a slightly less tedious than average way to pass time between classes, you're nuts.
Changing the executable name should be standard procedure when running a benchmark for public consumption. Ideally, benchmark developers would go even further and actively try to cloak their identity from the drivers, databases, or whatever software the benchmark tests. You might think this could lead to an "arms race" between vendors and benchmarkers, but I don't think so. To get away with cheating, the vendors' detection of the benchmark would have to be totally foolproof. It would have to guess right every single time to avoid being caught, and that's almost as much work as making the optimization properly general in the first place. Vendors wouldn't bother, if the risk/reward ration were that poor. The benchmark "cloaking" doesn't have to be perfect any more than crypto needs to be perfect. It just needs to be good enough that folks decide another road is better.
A lot of people are answering the question of why there are bugs at all, and it's an important question, but I'd like to take a different angle and consider why there are so many visible bugs. Why does a bug in a driver, or even an application, bring down a whole system? In addition to reducing the incidence of actual bugs, IMO, we should also do a better job of containing the bugs that will inevitably exist even if we all use the latest whiz-bang code analysis tools (which rarely work for kernel code anyway). Some of the semi-informed members of the audience are probably thinking that's the job of the operating system; I'd argue that our entire current notion of operating systems is flawed. There are way too many components in a typical computer system that "trust each other with their lives" in the sense that if one dies all die. Memory protection between user processes is great, but there should be memory protection between kernel entities, and other kinds of protection, as well. One of the basic services that operating systems need to provide going forward is greater fault isolation and graceful instead of catastrophic degradation.
The Recovery Oriented Computing project at Berkeley has gotten some press recently for trying to address this issue. Many here on Slashdot don't seem to "get it" because they've never worked on systems in which a component failure was survivable; they don't realize that rebooting a single component - perhaps even preemptively - is better than having the whole system crash. "Software rot" is a real problem, no matter how hard we try to wish it away. ROC isn't about saying bugs are OK; it's about saying that bugs happen even though they're not OK, and let's do the best we can about that. Another project in the same space, with more of a hardware/security orientation, is Self Securing Devices at CMU. There, the idea is to find ways that parts of a system can work together without having to share each others' fate. While the focus of the work is on security, it shouldn't be hard to see how much of the same technology could be applied to protect a system from outright failure as well as compromise. There are plenty of other projects out there trying to address this problem, but those are two with which I happen to have personal experience.
The key idea in all cases is that current OS design forces us to put all of our eggs in one basket, and that's really not necessary. Designing fault-resilient systems is tough - few know that better than I do - but that's only a reason why we should do it once instead of devising ad-hoc clustering solutions for each specific application. Lots of people use various forms of clustering as a way to achieve fault containment and survive failures, but the solutions tend to be very ad-hoc and application-specific. Do you think Google's solution works for anything but Google, or that a database transaction monitor is useful for anything that's not a database? Fault containment needs to be a fundamental part of the OS, not something we layer on top of it.
One more thing I wish they would fix, however, and that is links that open in a new window.
I got tired of this too, a long time ago. As a result, I have both Proxomitron (Windows) and Privoxy (Linux) filters to fix it. Conversely, one site that I use insists on opening new pages in the current window even if you try shift-click/control-click/whatever to open them in a new one. My Proxomitron/Privoxy filters fix that too.:-) Don't leave $HOME without one or the other.
I used to use AVG, but then I noticed several benchmark sites saying that its detection rates sucked. After that it was between Avast! and AntiVir, with the former having a slight edge in detection rates (plus auto-update), so that's what I went with. It's great that AVG's free, and performs well, but it doesn't really perform the basic task of protecting from viruses so none of that matters.
The key is not to build the system hierarchically, with one "big brain" that watches everyone else but nobody watching it back. A more robust approach is to have several peers all watching each other and using a more "democratic" method to determine who's faulty. It's more difficult to design and implement the necessary protocols, but it's not impossible. The folks at Berkeley have quite a bit of experience with this stretching from OceanStore back (at least) to NOW and, having met them, I have full confidence that they know what they're doing.
any time it's imaginable that a system might need another gig of storage, it's probably worth going to the store and spending the hundred dollars.
A gig is nothing in the enterprise space. What happens when a terabyte is the unit you allocate between applications or departments, and a petabyte is still big but no longer guaranteed to be the biggest on the block? Gonna walk down to the store and buy a terabyte of RAM, plus a CPU and chipset and OS capable of addressing it? This whole discussion is based on a faulty concept of what "big" is nowadays. For a truly big database, RAM isn't going to cut it. RAM and disk sizes have grown rapidly, but database sizes have (at least) kept pace. That will probably always be the case. If something came along that was even bigger than disks, but even more cumbersome to access, databases would interface to it anyway. General-purpose OS access won't be far behind, either. VM is far from dead; if anything, the change that's needed is to get rid of bogus 2x/4x physical-to-virtual ratios in broken operating systems like Linux and Windows so they can address even more virtual memory.
we can either a) use other machines as our "VM" failover, or more interestingly, b) Directly treat remote RAM as a local resource
I worked at a company several years ago (Dolphin) that allowed just this sort of remote memory access at the hardware level. Even then, there were so many issues around consistency, varying latency (this is NUMA where access is *really* non-uniform), and system isolation (it sucks taking a bus fault because something outside your box hiccuped) that the market resisted. InfiniBand HCAs don't even do that; access to remote memory is explicit via a library, not just simple memory accesses. RDMA over Ethernet is even less transparent, and has a host of other problems to solve before it's even where IB is today; it's a step backwards functionally from software DSM, which has been around for at least a decade without overcoming the same sort of acceptance issues mentioned above.
What I'm convinced we're going to start seeing is some capacity for distributed computation in the RAM logic itself
You could start with IRAM at Berkeley. There are links to other projects as well, and some of the papers mention still more that don't seem to be in the links. A lot of what you talk about is possible, and being thought about, but a lot further off than you seem to think.
I have the ME-6000, which draws less than most of the other boards, plus a 3.5" 7200RPM hard disk, plus a slim combo optical drive. The optical drive isn't really a factor because it wasn't in use when I saw the lockups so it wouldn't have been drawing more than a tiny trickle of current. I also don't know for sure that the lockups were heat-related; the symptoms could also be explained by a chipset bug (always happens right during or after a heavy burst of disk I/O) but that's even worse.
The thing is, power-wise, this isn't exactly a demanding sort of system. This is exactly the sort of load the PSU should have been designed to handle, and it shouldn't be anywhere near "topping out" as you say. If it's the power supply that's causing these problems then the power supply is defective. People shouldn't have to babysit the power supply by selecting their hard drive purely by its power consumption and not plugging anything into external ports etc. Responsible vendors don't design, manufacture, or sell components that are one tiny step from failure at normal load. This system doesn't draw 55W and it's supposed to be a 55W power supply; it should have headroom.
I just built a system very similar to these, and it's a blast, but there are some problems. One is that the Morex 55W power supply seems to have some issues, particularly at boot-up, that can result in a hung system. Another is heat. The EPIA boards don't generate a lot, but they do generate some, and other components (e.g. hard disk) do too. VIA does not recommend running the M-9000 fanless; that's precisely why I bought an ME-6000, and the case does have two (very quiet) case fans, and I've still had a couple of lockups that might be attributable to heat. Other users at VIA Arena using the same mobo/case combination have reported very similar problems. Overall, there seems to be a growing feeling among the community of people who've actually bought them that systems built around these components might not be silent and stable at the same time. Pick one.:-( Maybe the next generation will be capable of running silently without these stability problems, and it's fine for a hobby project, but I couldn't really recommend this type of system for regular use.
If the RAM drive is using the same connection as a rotating-media drive, you're really dealing with an SSD and you're subject to the bottlenecks that Conquest supposedly avoids. Some filesystems already allow you to store the journal on a separate disk from the target filesystem, and it's a pretty common trick already to put that journal on an SSD.
While this is great for some environments, it will remain a research toy until several real-world problems and limitations are addressed. Several people have already brought up the issue of having more small files than will fit into the BB-RAM. Another issue is portability. With a traditional filesystem, if a whole machine dies you can slap the disk into another one (of the same type). With Conquest, you have to transplant the BB-RAM as well. How many slots do you think a machine has for BB-RAM, vs. how many disks can you attach? At the very least you'd need to coordinate use of the BB-RAM across filesystems, plus a way to flush/restore one filesystem's portion to actual disk.
There are many more issues like these, which would need to be addressed before a Conquest-like approach is really viable in the real world. One of more of those issues might turn out to be a show-stopper. It's interesting research, but don't expect it to replace traditional filesystems any time soon.
I don't know where you're shopping, but at one online retailer I use 10-packs of Memorex DVD media are priced right now as follows:
DVD+R $25.44
DVD-R $25.99
DVD+RW $30.61
DVD-RW $44.99
That's right: DVD+R is actually cheaper than DVD-R. DVD-RW is almost 50% more expensive than DVD+RW while also lacking some DVD+RW features like defect management and lossless linking, and being very slightly less compatible with consumer A/V gear (dvdrhelp.com).
You can get DVD-R media for $0.70 apiece if you buy a hundred or so of some off-brand that won't work in most drives. You can do the same with DVD+R. The claim that DVD+R is "several times" more expensive was never true, and is not even close nowadays.
I can only wonder what sort of favors Daniel Lyons is receiving from Star Bridge. The only news here is that Forbes is being so blatant about whoring themselves out as a PR machine for a troubled company. No wait, that's not news either.
VIA has been selling the CIII as part of the EPIA Mini-ITX platform
The CPU component of the Eden Platform is referred to as ESP. C3 is the name of a processor family that's sold quite separately from the Eden Platform; I have one in an SV24 at home. There's no doubt that the C3 and ESP are very similar technologically, but they really are different products packaged and marketed differently and I'm sure VIA would like to continue selling both.
the installation detected and supported all of my devices ( printer, scanner, sound card , etc )
Lucky you. For most people, getting XFree86 to do anything like the right thing is a major chore, and getting sound to work is worse. That's not just the technically clueless, either. I've been writing kernel code longer than Linus has, and with the common distros I still find it a major pain in the ass to get those things working properly on anything but the most vanilla systems in the universe. Knoppix shows great promise, though. It couldn't handle my SV24, but on another system it came up all the way to a working browser etc. without a single click to configure anything. That's even better than Windows. Maybe there's hope after all, but not while RH/Mandrake/SuSE are the most common distros.
Been there.Done that. These types of algorithms are not exactly new, and what this paper describes is no more "self-assembling" than any other distributed routing/discovery protocol - examples of which have existed for over twenty years. Of course, lots of things are new to the Slashdot editors that are old to the rest of us.
good programming job, but nothing that any hacker couldn't come up with.
Maybe it's not "real AI" but I still disagree that any hacker could do it. It's even less likely that any hacker could do it fast enough to generate scenes of such complexity in time for the film's release. That ratio of complexity/realism to compute cycles is far beyond what "any hacker" could do, and that's what makes MASSIVE a breakthrough.
When microwaves first came out, people thought of them as a new way of cooking the same old foods, quicker. Nice, but not earth-shattering. Since then, though, microwaves have spawned a whole new kind of cooking. Whole supermarket aisles are full of products that have been specially formulated to be microwave-friendly, or that wouldn't exist at all without the microwave. People's lifestyles have changed because of the microwave. If you looked around at all the gadgets in the average person's house, you'd be hard pressed to find more than a couple whose absence would be more keenly felt than the microwave...the computer, the TV, the phone. All of those were expected to be revolutionary though, so they haven't exceeded expectations as the title asks. The microwave has had a much more profound effect than expected.
Slashdot Mirror
Since when is an FTP server considered part of the kernel? Damn userland wannabes don't even know what the kernel *is* let alone how to develop one.
To choose the right container they need to understand algorithmic complexity and the performance guarantees made by each container type (I never said they didn't have to know anything) but they don't need to know how each container is actually implemented. It's the same as needing to know what delivery/ordering guarantees are made when they call a network API, or what durability/consistency guarantees are associated with filesystem calls, without actually knowing how those things are implemented. Interfaces can and should be defined in terms of function, not implementation.
A lot of people seem to be suggesting that you just threaten to quit en masse. In its simplest form I don't think that would work, but a related approach might. I'd consider having everyone work regular hours, no matter what management wants. Make it clear that if they fire you for doing your jobs under the same conditions as existed before, you'll sue both them and the customer for wrongful termination, breach of contract, unfair retaliation, and anything else that has any chance whatsoever of sticking in your jurisdiction. Mention the adverse publicity too. Instead of allowing your employer to stick you with a choice between taking it up the rear or losing your job, stick them with a choice between getting the project done on a reasonable schedule or having it done even later and under a cloud of lawsuits that will forever poison their relationship with the customer. Sure, they can fire you after the project's done, but most of the grounds for lawsuits would still exist and the economy might be better then.
Not only did other flavors of UNIX, and even NT, have virtual filesystem layers long before Linux, they are all to this day better than the one in Linux. The only thing "original" about the Linux VFS layer is the severe NIH syndrome and the near impossibility of getting a satisfactory result from its brain-damaged locking.
I've had to put up with the opposite too - people who insist on using Java in part of a complex system even though other components had to be written in C/C++ and they all had to work together closely. To mingle and paraphrase a couple of your points, I don't care how good their Java skills are, or what Java toys they get to play with in preparation for a jump to the next dot-com. If I'd been there at the time to see them start using Java for a primarily C/C++ project, I would have kicked their asses. Nothing could have justified the multiple instances of cross-language API integration that such a selfish decision has caused.
That doesn't refute your point, of course; it's not intended to. Just another "war story" from another old fart. ;-)
Then again, most programmers don't need to know what hash tables are, any more than they need calculate individual pixels to draw a circle on the screen. The level of abstraction has moved up. Someone, somewhere, has to know that stuff, just like compiler writers need to know how to generate decent machine code, but most programmers just need to choose the right STL container and run their code through a compiler. They don't need to know how those things work, and in fact they might work quite differently from one version to the next while still honoring the same contract.
Personally I'm a low-level kind of guy; I know damn well what a hash table is and how a reliable communication protocol works and so on. I look down on user-level programmers because what they do is so easy, and because so many of them (patterns weenies, J2EE dorks, FP zealots) obsess over style while forgetting substance, but not because they don't know things that there's no longer any good reason for them to know.
MTV has been lame for six years? Try fifteen, and it was only slightly un-lame before that. If you think MTV was *ever* more than a slightly less tedious than average way to pass time between classes, you're nuts.
Changing the executable name should be standard procedure when running a benchmark for public consumption. Ideally, benchmark developers would go even further and actively try to cloak their identity from the drivers, databases, or whatever software the benchmark tests. You might think this could lead to an "arms race" between vendors and benchmarkers, but I don't think so. To get away with cheating, the vendors' detection of the benchmark would have to be totally foolproof. It would have to guess right every single time to avoid being caught, and that's almost as much work as making the optimization properly general in the first place. Vendors wouldn't bother, if the risk/reward ration were that poor. The benchmark "cloaking" doesn't have to be perfect any more than crypto needs to be perfect. It just needs to be good enough that folks decide another road is better.
A lot of people are answering the question of why there are bugs at all, and it's an important question, but I'd like to take a different angle and consider why there are so many visible bugs. Why does a bug in a driver, or even an application, bring down a whole system? In addition to reducing the incidence of actual bugs, IMO, we should also do a better job of containing the bugs that will inevitably exist even if we all use the latest whiz-bang code analysis tools (which rarely work for kernel code anyway). Some of the semi-informed members of the audience are probably thinking that's the job of the operating system; I'd argue that our entire current notion of operating systems is flawed. There are way too many components in a typical computer system that "trust each other with their lives" in the sense that if one dies all die. Memory protection between user processes is great, but there should be memory protection between kernel entities, and other kinds of protection, as well. One of the basic services that operating systems need to provide going forward is greater fault isolation and graceful instead of catastrophic degradation.
The Recovery Oriented Computing project at Berkeley has gotten some press recently for trying to address this issue. Many here on Slashdot don't seem to "get it" because they've never worked on systems in which a component failure was survivable; they don't realize that rebooting a single component - perhaps even preemptively - is better than having the whole system crash. "Software rot" is a real problem, no matter how hard we try to wish it away. ROC isn't about saying bugs are OK; it's about saying that bugs happen even though they're not OK, and let's do the best we can about that. Another project in the same space, with more of a hardware/security orientation, is Self Securing Devices at CMU. There, the idea is to find ways that parts of a system can work together without having to share each others' fate. While the focus of the work is on security, it shouldn't be hard to see how much of the same technology could be applied to protect a system from outright failure as well as compromise. There are plenty of other projects out there trying to address this problem, but those are two with which I happen to have personal experience.
The key idea in all cases is that current OS design forces us to put all of our eggs in one basket, and that's really not necessary. Designing fault-resilient systems is tough - few know that better than I do - but that's only a reason why we should do it once instead of devising ad-hoc clustering solutions for each specific application. Lots of people use various forms of clustering as a way to achieve fault containment and survive failures, but the solutions tend to be very ad-hoc and application-specific. Do you think Google's solution works for anything but Google, or that a database transaction monitor is useful for anything that's not a database? Fault containment needs to be a fundamental part of the OS, not something we layer on top of it.
I got tired of this too, a long time ago. As a result, I have both Proxomitron (Windows) and Privoxy (Linux) filters to fix it. Conversely, one site that I use insists on opening new pages in the current window even if you try shift-click/control-click/whatever to open them in a new one. My Proxomitron/Privoxy filters fix that too. :-) Don't leave $HOME without one or the other.
I used to use AVG, but then I noticed several benchmark sites saying that its detection rates sucked. After that it was between Avast! and AntiVir, with the former having a slight edge in detection rates (plus auto-update), so that's what I went with. It's great that AVG's free, and performs well, but it doesn't really perform the basic task of protecting from viruses so none of that matters.
The key is not to build the system hierarchically, with one "big brain" that watches everyone else but nobody watching it back. A more robust approach is to have several peers all watching each other and using a more "democratic" method to determine who's faulty. It's more difficult to design and implement the necessary protocols, but it's not impossible. The folks at Berkeley have quite a bit of experience with this stretching from OceanStore back (at least) to NOW and, having met them, I have full confidence that they know what they're doing.
A gig is nothing in the enterprise space. What happens when a terabyte is the unit you allocate between applications or departments, and a petabyte is still big but no longer guaranteed to be the biggest on the block? Gonna walk down to the store and buy a terabyte of RAM, plus a CPU and chipset and OS capable of addressing it? This whole discussion is based on a faulty concept of what "big" is nowadays. For a truly big database, RAM isn't going to cut it. RAM and disk sizes have grown rapidly, but database sizes have (at least) kept pace. That will probably always be the case. If something came along that was even bigger than disks, but even more cumbersome to access, databases would interface to it anyway. General-purpose OS access won't be far behind, either. VM is far from dead; if anything, the change that's needed is to get rid of bogus 2x/4x physical-to-virtual ratios in broken operating systems like Linux and Windows so they can address even more virtual memory.
I worked at a company several years ago (Dolphin) that allowed just this sort of remote memory access at the hardware level. Even then, there were so many issues around consistency, varying latency (this is NUMA where access is *really* non-uniform), and system isolation (it sucks taking a bus fault because something outside your box hiccuped) that the market resisted. InfiniBand HCAs don't even do that; access to remote memory is explicit via a library, not just simple memory accesses. RDMA over Ethernet is even less transparent, and has a host of other problems to solve before it's even where IB is today; it's a step backwards functionally from software DSM, which has been around for at least a decade without overcoming the same sort of acceptance issues mentioned above.
You could start with IRAM at Berkeley. There are links to other projects as well, and some of the papers mention still more that don't seem to be in the links. A lot of what you talk about is possible, and being thought about, but a lot further off than you seem to think.
I have the ME-6000, which draws less than most of the other boards, plus a 3.5" 7200RPM hard disk, plus a slim combo optical drive. The optical drive isn't really a factor because it wasn't in use when I saw the lockups so it wouldn't have been drawing more than a tiny trickle of current. I also don't know for sure that the lockups were heat-related; the symptoms could also be explained by a chipset bug (always happens right during or after a heavy burst of disk I/O) but that's even worse.
The thing is, power-wise, this isn't exactly a demanding sort of system. This is exactly the sort of load the PSU should have been designed to handle, and it shouldn't be anywhere near "topping out" as you say. If it's the power supply that's causing these problems then the power supply is defective. People shouldn't have to babysit the power supply by selecting their hard drive purely by its power consumption and not plugging anything into external ports etc. Responsible vendors don't design, manufacture, or sell components that are one tiny step from failure at normal load. This system doesn't draw 55W and it's supposed to be a 55W power supply; it should have headroom.
I just built a system very similar to these, and it's a blast, but there are some problems. One is that the Morex 55W power supply seems to have some issues, particularly at boot-up, that can result in a hung system. Another is heat. The EPIA boards don't generate a lot, but they do generate some, and other components (e.g. hard disk) do too. VIA does not recommend running the M-9000 fanless; that's precisely why I bought an ME-6000, and the case does have two (very quiet) case fans, and I've still had a couple of lockups that might be attributable to heat. Other users at VIA Arena using the same mobo/case combination have reported very similar problems. Overall, there seems to be a growing feeling among the community of people who've actually bought them that systems built around these components might not be silent and stable at the same time. Pick one. :-( Maybe the next generation will be capable of running silently without these stability problems, and it's fine for a hobby project, but I couldn't really recommend this type of system for regular use.
If the RAM drive is using the same connection as a rotating-media drive, you're really dealing with an SSD and you're subject to the bottlenecks that Conquest supposedly avoids. Some filesystems already allow you to store the journal on a separate disk from the target filesystem, and it's a pretty common trick already to put that journal on an SSD.
While this is great for some environments, it will remain a research toy until several real-world problems and limitations are addressed. Several people have already brought up the issue of having more small files than will fit into the BB-RAM. Another issue is portability. With a traditional filesystem, if a whole machine dies you can slap the disk into another one (of the same type). With Conquest, you have to transplant the BB-RAM as well. How many slots do you think a machine has for BB-RAM, vs. how many disks can you attach? At the very least you'd need to coordinate use of the BB-RAM across filesystems, plus a way to flush/restore one filesystem's portion to actual disk.
There are many more issues like these, which would need to be addressed before a Conquest-like approach is really viable in the real world. One of more of those issues might turn out to be a show-stopper. It's interesting research, but don't expect it to replace traditional filesystems any time soon.
I don't know where you're shopping, but at one online retailer I use 10-packs of Memorex DVD media are priced right now as follows:
That's right: DVD+R is actually cheaper than DVD-R. DVD-RW is almost 50% more expensive than DVD+RW while also lacking some DVD+RW features like defect management and lossless linking, and being very slightly less compatible with consumer A/V gear (dvdrhelp.com).
You can get DVD-R media for $0.70 apiece if you buy a hundred or so of some off-brand that won't work in most drives. You can do the same with DVD+R. The claim that DVD+R is "several times" more expensive was never true, and is not even close nowadays.
I can only wonder what sort of favors Daniel Lyons is receiving from Star Bridge. The only news here is that Forbes is being so blatant about whoring themselves out as a PR machine for a troubled company. No wait, that's not news either.
The CPU component of the Eden Platform is referred to as ESP. C3 is the name of a processor family that's sold quite separately from the Eden Platform; I have one in an SV24 at home. There's no doubt that the C3 and ESP are very similar technologically, but they really are different products packaged and marketed differently and I'm sure VIA would like to continue selling both.
Lucky you. For most people, getting XFree86 to do anything like the right thing is a major chore, and getting sound to work is worse. That's not just the technically clueless, either. I've been writing kernel code longer than Linus has, and with the common distros I still find it a major pain in the ass to get those things working properly on anything but the most vanilla systems in the universe. Knoppix shows great promise, though. It couldn't handle my SV24, but on another system it came up all the way to a working browser etc. without a single click to configure anything. That's even better than Windows. Maybe there's hope after all, but not while RH/Mandrake/SuSE are the most common distros.
Been there. Done that. These types of algorithms are not exactly new, and what this paper describes is no more "self-assembling" than any other distributed routing/discovery protocol - examples of which have existed for over twenty years. Of course, lots of things are new to the Slashdot editors that are old to the rest of us.
I doubt it. There have been power mats - basically just big LiPoly batteries - for ages, but not inductive power units. They're very different things.
Maybe it's not "real AI" but I still disagree that any hacker could do it. It's even less likely that any hacker could do it fast enough to generate scenes of such complexity in time for the film's release. That ratio of complexity/realism to compute cycles is far beyond what "any hacker" could do, and that's what makes MASSIVE a breakthrough.
When microwaves first came out, people thought of them as a new way of cooking the same old foods, quicker. Nice, but not earth-shattering. Since then, though, microwaves have spawned a whole new kind of cooking. Whole supermarket aisles are full of products that have been specially formulated to be microwave-friendly, or that wouldn't exist at all without the microwave. People's lifestyles have changed because of the microwave. If you looked around at all the gadgets in the average person's house, you'd be hard pressed to find more than a couple whose absence would be more keenly felt than the microwave...the computer, the TV, the phone. All of those were expected to be revolutionary though, so they haven't exceeded expectations as the title asks. The microwave has had a much more profound effect than expected.