More intelligent database-like filesystems are as inevitable as more intelligent software in general. Traditional Unix filesystems leave a lot to be desired.
Computing needs to move past 1970. Bell Labs kept going with Plan 9 and other OS development, but for some reason a lot of Unix users got stuck and don't want to leave their comfort zone.
Of course this will add complexity, but so does nearly every other advancement in hardware and software.
The author doesn't seem to understand what "urban legend" means. An urban legend is not the same as a myth.
Goetz is in denial and just waves away problems using straw men without providing a truly balanced view of cases where these things cause problems. It depends on the VM, if things are done in a tight loop, and so on.
Suffice it to say I did not like this article. As always, you need to measure application performance for yourself to find true bottlenecks.
How would you enter equations and diagrams? Whip out Mathematica and Visio? I don't think so. Not while keeping up with a lecture.
The sound of people typing would drive me nuts.
Computers sound like a horrible distraction kids would be better off without in the classroom. (Note that I make an exception for blind students for whom a laptop may be a great option as mechanical braille machines are very noisy.)
Paper works just fine and you're not out $1000+ if it gets stolen. Frankly, I'm not even a huge supporter of computers being a significant part of education at all. The idea of requiring laptops for anything but a private school seems unnecessary to me.
Yeah, my 128kbps/32k upload is from Comcast. It sucks, but I don't have any other options. I'm too far from a CO for DSL. I think they say it's supposed to be 256kbps up, but it isn't.
We have Sun hardware die all the time including system boards, i/o boards, boot disks, and memory (frequently). Of course we probably have something like 150 systems of various sizes from 220s to 6800s. The standard procedure seems to be to have stuff crap out and be replaced for a few years on a new system, then the systems are stable. From what I've seen, the IBM servers we have are much more reliable from the start.
Yeah, I know Sun's product line. I never claimed the larger Starfires weren't high-end. I just don't know how much of the market their 10/12/15ks have. Probably more than I was thinking now that I think about it:). Sun doesn't show up in last year's Top 500 Supercomputer list until #145, but I suppose they may still be doing good volume on single systems. Okay, I'll retract what I said.
Sun doesn't play much at the very high end. I would say that's more Cray/NEC/HP/Hitachi/Fujitsu/SGI/IBM. They play in the midrange which means they get pinched from both sides with a charge running right up the middle.
Unless your embedded devices run web servers it probably doesn't make sense. You would just have another computer reading raw data from the embedded devices and then publishing that as SensorML instead.
Since never. What about discovery? The article is full of XML hyperbole. The connection they didn't explain is that _if_ this stuff is tied into the SensorWeb, you could have those capabilities.
This article should have really been about SensorWeb
since SensorML is just an implementation detail.
I agree about the validity of VLIW. We know the parallelism is there or superscalar wouldn't work.
To me, VLIW is the logical extension of superscalar RISC, but (big but) superscalar can deal with the evolution of the functional units and architecture of a chip and VLIW can not.
Executables statically scheduled for Itanium2 may not be optimal for ItaniumN. How do you deal with that? Add OOO to ItaniumN? Oh boy... Itanium2 already has hardware to deal with "split issue" - adjacent instructions that cannot execute in parallel.
Slashdot Mirror
You should know that Adam was involved with one of the most widespread viruses of all time. I had it on a couple dozen computers.
I'm not saying BSD isn't a critical part of the system, just that the OS X architecture is not like "a true, blue" Unix. It's a hybrid.
Subtracting out 29 Gfps for Quartz, that still leaves a decent 1 GFps.
It only runs on one OS family which is a huge limit on hardware choice.
SQL Server triggers do not have as many features as, e.g. DB2.
SQL Server has a lower limit on the number of indexes per table than other RDBMSs.
Other RDBMSs are more tunable (have more exposed parameters).
There you go.
-Kevin
Computing needs to move past 1970. Bell Labs kept going with Plan 9 and other OS development, but for some reason a lot of Unix users got stuck and don't want to leave their comfort zone.
Of course this will add complexity, but so does nearly every other advancement in hardware and software.
-Kevin
Ditto on the other followup - databases use a transaction log that is analogous to a journal.
Goetz is in denial and just waves away problems using straw men without providing a truly balanced view of cases where these things cause problems. It depends on the VM, if things are done in a tight loop, and so on.
Suffice it to say I did not like this article. As always, you need to measure application performance for yourself to find true bottlenecks.
-Kevin
The sound of people typing would drive me nuts.
Computers sound like a horrible distraction kids would be better off without in the classroom. (Note that I make an exception for blind students for whom a laptop may be a great option as mechanical braille machines are very noisy.)
Paper works just fine and you're not out $1000+ if it gets stolen. Frankly, I'm not even a huge supporter of computers being a significant part of education at all. The idea of requiring laptops for anything but a private school seems unnecessary to me.
-Kevin
Believe it or not, some people have data that doesn't fit in RAM and has to access disk.
-Kevin
-Kevin
-Kevin
-Kevin
-Kevin
-Kevin
-Kevin
-Kevin
-Kevin
-Kevin
Look up Hitachi SR8000 / SR2201.
-Kevin
-Kevin
-Kevin
This article should have really been about SensorWeb since SensorML is just an implementation detail.
-Kevin
I agree about the validity of VLIW. We know the parallelism is there or superscalar wouldn't work.
To me, VLIW is the logical extension of superscalar RISC, but (big but) superscalar can deal with the evolution of the functional units and architecture of a chip and VLIW can not.
Executables statically scheduled for Itanium2 may not be optimal for ItaniumN. How do you deal with that? Add OOO to ItaniumN? Oh boy... Itanium2 already has hardware to deal with "split issue" - adjacent instructions that cannot execute in parallel.
-Kevin