This actually came up in a weird way where I used to work (EMC). One day they made a deal with a vending-machine company, probably owned by one of the Egans, and our free soda disappeared. Several people, including me, immediately went out and bought little mini-fridges to keep in our offices so we'd only be paying grocery-store prices for our beverages. Obviously this cut into the vending-machine profits, so a notice was sent out explaining that such fridges were banned - ostensibly for power-usage and safety reasons. I pointed out that the power-usage argument was totally bogus since these little fridges used less power than several dozen machines running SETI@home 24/7, and the safety issue was almost as ridiculous. I've seen more PCs catch fire than fridges.
Of course, that got me nowhere. They weren't interested in facts or reasoned arguments. They were willing to fire someone who was a mentor and knowledge resource for everyone in that facility and many beyond, to preserve profits for their vending-machine subsidiary. I (uncharacteristically) backed down, but it ended up being one of many bonehead things they did to convince me that I'd be better off elsewhere. Behavior like that has cost them many talented people, some of whom are likely to take a bite out of their business by working for competitors some day. Brilliant management, huh?
Roblimo's "review" is just FUD, and we all hate FUD, right? Oh, so IE doesn't have tabs? There are about a hundred free add-ons that do; I'm using CrazyBrowser right now. It doesn't stop pop-ups? Again, there are plenty of free solutions available. OE doesn't filter spam? Ditto. The list just goes on and on. I use both Windows and Linux every day, and I find them about equally customizable without spending a dime on either one. If roblimo had invested 1% as much time investigating the availability of free add-ons for Windows as he has spent investigating free add-ons for Linux, just about every one of the "problems" he identifies would go away.
Sure, Windows could throw in everything but the kitchen sink, just like commercial Linux distros do, but you know what? They tried bundling stuff with the OS and a whole bunch of people bitched. They backed off because people like roblimo kept saying choice is good and bundling deprives users of choice. How quickly those very same people forget that when it comes to (for example) bundling GNOME/KDE or Mozilla or StarOffice with a commercial Linux distro. What's good for the goose is good for the gander.
That's like saying it's OK to lie, because it's someone else's responsibility to find the truth. Yes, people should understand the technology before they waste money on it, but vendors and Linux advocates also shouldn't be spreading misinformation.
I think you're completely right. Unfortunately, there are a lot of companies out there making claims to the contrary, and a lot of people spending real cash money based on those claims.
The only thing that really hasn't been mature on Linux until fairly recently is the desktop.
Yeah, well, that plus there hasn't been a scheduler that was capable of meeting common real-time requirements. Lots of claims, lots of "Linux on top of something else" hacks that cause more hybrid-environment pain than they're worth, but no native Linux scheduler you could really use for any but the very softest of soft real-time. That lack has been more keenly felt on many projects than the absence of a few "make Windows users feel at home" features on a desktop that people who do real work have considered just fine for several years.
Programs that simply don't work right, that don't meet quality standards we'd apply to every other product category, is a perfect illustration of why the public at large views geek culture - that includes you, we're on Slashdot - as a bunch of overpaid lazy clods.
Mindless flames that make unwarranted assumptions (such as "propping up a can of mountain dew") are a perfect illustration of why the public at large and even the geek community views Slashdot - and particularly the anti-community of aptly named anonymous cowards like you - as filled with twats.
In the latter case, at least, they are right. You're in no position to criticize others' behavior.
I've had to suffer through these guys' port of Joust on shockwave.com (in fact I have the high score for the month currently) and it has several inexcusable flaws. The most annoying is that it doesn't always respond to keypress events properly - rather critical functionality for a game. It doesn't actually seem to drop the events, which would be bad enough, but it ignores them for as much as half a second at a time and then spits a whole bunch out together. If your game wasn't screwed up when it seemed to ignore the event, it's damn sure going to be screwed up when they all get played back in a burst along with the other keys you hit to recover from the original failure. I know Windows is not a real-time system, and I've worked on real real-time systems (microsecond response times) so I do know the difference, but there's no excuse for a delay this long on an unloaded modern system. Other games don't seem to be afflicted by the same problems. The problem is not in Windows; it's in Digital Eclipse's emulation of the hardware on which the game originally ran (even if the code is translated the non-CPU hardware still has to be emulated).
There was also a time when the game's speed calibration was totally broken. I'd play on my 600MHz laptop and it would be just about right, but when I went to my 1.5GHz desktop guess what happened. Yeah, everything in the game was moving about 2.5x as fast and the game was unplayable. This only persisted for a week or two, but it's still not something that should happen in a version that's released to the public. These technical failures, combined with their apparent acquiescence to Shockwave's desire to add deliberate player-killing features to their translation (the very laws of physics in the game change after you get a good score, and I've looked at the original ROM code so I know exactly how they're doing it) have left me with the impression that Digital Eclipse is both incompetent and unethical.
Been there, read that. Proper grounding and adequate voltage are minimum expectations for any case out of the box - not something the buyer should have to fix. Any case with problems like that is simply defective, and when somebody sells a product that is defective by design I think it deserves public mention. If somebody sold you a car that didn't run, even if you were capable of fixing it, would you not be annoyed?
Yeah, so you can put it in a Cubid case...if you don't mind the undervoltage and lack of grounding. I have a Cubid 2699R which used to house a VIA ME-6000 mobo, but that system wasn't stable so I got a case that actually works and the Cubid lies empty in a drawer. The same components have been completely stable in their new home during the months since I ditched the Cubid POS.
back in the real world, we have real programs, and real programs branch. If the branch prediction fails, or if there is an unconditional jump or function call, the rest of the pipeline has to be thrown out.
In that real world, how often do those branches occur? "Every eight instructions" was never really true except for the most CISCy architectures, and the number has only increased since then. Would you rather have a bigger bubble at 3GHz, or a smaller one at 1GHz while also reducing parallelism for code that doesn't branch as often? Do the math. That's the real lesson of H&P: do the math instead of making wild-ass guesses about what works better.
As for the branch and load delay slots, yeah, they needed them when the MIPS ISA was set, but since the R10K, branch delays have been unnecessary. HP's PA-RISC doesn't use a branch delay, either (it just starts executing the next op, and throws it out if the branch is taken).
Speculative execution is a waste of functional units that could be used for real work instead of solving what should be the compiler's problem.
there is an increase in the density of jumps in code
Got any sources for that, Sparky? When you factor out the effects of things like abusing dispatch tables because it's "too hard" to deal with C++ semantics or JVM interpretation the right way, the frequency of jumps in real code written for real performance is going down.
1) Get rid of 20-stage pipeline, it's too long for anything serious.
2) As a follow up to 1, try to actually get some work done in a clock cycle.
3) Throw out the x86 ISA.
4) Look at the MIPS ISA.
5) Realize that it's actually possible to understand the MIPS arch, and that it still works great for multimedia, math, and general use.
6) Buy the rights to the MIPS ISA, make small improvements (get rid of branch delay slot, load delay slot), speed it up, and design new Intel processors from the improved ISA.
Looks like someone needs to read Hennessy and Patterson. The deep pipelines are there for a reason. The branch and load delay slots are there for a reason. Those are things compilers can deal with, and it wouldn't be possible to reach these clock rates without them. Let's review the old formula, shall we?
WPS = WPI * IPC * CPS, where
WPS = work per second
WPI = work per instruction
IPC = instructions per cycle
CPS = cycles per second
Deep pipelines are critical for improving both IPC and CPS, and delay slots help too. It might seem like you're sacrificing WPS, but studies have shown that such an effect is minimal; processors spend practically all of their time implementing the simple instructions anyway for most code. If you increase two factors significantly, and reduce the third only slightly, the result is - obviously - a net win. History has proven that H&P knew what they were talking about, and that their analysis played a pivotal role in achieving the sorts of performance we see today.
Yeah, the x86 instruction set sucks. Oh well. Unless you write compilers there's no reason to care (no, not even for embedded or high-performance work, which I've done). If you do write compilers, think of it as job security. Compatibility with existing applications really does matter more than aesthetics.
They missed the most basic rule of them all though, convert to C++.
Better yet, convert to a language that doesn't have every wart from C plus some tumors of its own. Why settle for moving to a different piece of the swamp when you can climb onto dry land?
First off, it's very important to note that bittorrent isn't a P2P network; it is a completely new protocol, fundamentally different then anything that has come before it.
Without taking anything away from the excellent work Bram Cohen has done (Hi Bram!) I take issue with "fundamentally different" in the above. There were at least a half-dozen projects that did various kinds of "swarming" or cooperative downloading of files before BitTorrent. You could argue that BitTorrent does it better, or is easier to use, or whatever - there must be some reason it has gained greater exposure than those others - but compared to them it's evolutionary, not revolutionary.
Transactions are not the only possible model for reliable systems. They're just what some people are used to, and if all you have is a hammer everything looks like a nail. Those people need to enlarge their toolboxes, not make the world conform to the tools they've learned.
The article is not about filesystems in anything like a general sense; it's just a PR piece for ReiserFS and its creator, enunciating criteria specific to that implementation and then attempting to show how it actually (gasp!) meets its own idiosyncratic goals. What a waste of time.
The author seems to enjoy dispelling myths but, in this and one of his other articles (RISCy Business) that he links to, he seems to cling rather stubbornly to a couple of his own. For example, I just read twice about how "some RISC chips" don't have multiplication instructions, even though most do nowadays. But hey, it's a convenient club to bash with, just like the one about code density. The guy's a troll. He hates RISC for some reason, and perhaps he has some good points to justify that dislike in the embedded space, but in his zeal he just goes too far into exaggeration and misrepresentation. He also needs to read H&P to understand the real rationale behind RISC, instead of the strawman rationale he gives in the article.
The legal phrase is "substantial non-infringing use". If something is primarily used to infringe on copyrights, and adapting it to legitimate use is difficult or unlikely, it can be considered contributory to the infringement and thus held liable. The "Betamax" case hinged on this very issue, and the VCR manufacturers barely won. P2P networks generally have an even greater preponderance of illegal use, so it's not at all clear the Betamax precedent would apply.
The same principle has been applied to other areas as well - certain types of weapons, drug paraphernalia, etc. If an object's primary function is to assist in breaking the law, I think a legitimate case can be made for prosecuting those who make it. That's true even when the law in question is a stupid one (as is definitely the case with copyrights in their current state); until the stupid law is changed, it's a matter for the courts to decide and one cannot disallow suits based on that rationale.
XML compresses well because it's so mind-numbingly redundant in the first place, and gzipping a bloated format costs more memory and CPU than having a non-bloated format in the first place. Usually it's not enough to worry about because there are other, bigger performance problems to worry about first, but when you've reduced inefficiency elsewhere in the code you're stuck looking at an inherently inefficient format that you can no longer change because to do so would make you inoperable with existing implementations. Bad idea.
Reading your post, the phrase "too clever by half" comes to mind. If the client doesn't want some avant-garde artsy design, you should know that up front; if you're overshooting their design comfort level and then having to "water it down" you're wasting their time and money. The problem is, everyone who studies design wants to be on the cutting edge, but there's really only room for 10% (at most) to be there; the rest should get used to working on less exciting projects unless/until they can prove that they deserve to be one of the few who get to do the good stuff. It's the same as in programming - a few get to strike out in bold new directions, the rest earn their stripes by making derivatives or lesser enhancements.
It's not about people thinking change is bad. You only say that because you want to be the one making the changes, and I suspect you'd seem just as conservative about unasked-for "screwing around with stuff" in areas outside your own specialty. Do you use any software? How would you like it if the entire UI changed, just because someone thought they had a better idea? How about if your ZIP code or telephone area code kept changing, just because someone came up with a more "logical" way to assign them? If some traffic designer had the "bright idea" to make some of the streets in your neighborhood one-way, would you just say "cool, change is good"? Hmmm. What this is about is balancing change with consistency. Too bad if that leaves you frustrated because there aren't enough opportunities to do what you want to do.
Heh. Same here. Why, just this morning I was making the turn onto Maguire, and I was thinking "what is the natural nickname for people who work at IDEO, anyway?" I don't think they'd appreciate the answer I came up with.
BTW, cool name. If you ever decide to abandon that identity, let me know.;-)
Is it right to assume that softupdates are faster, but journaling might save a little bit more data in case of a crash?
I'd have to say it depends. The beauty of soft updates is that they require exactly zero additional writes beyond what you'd be doing anyway; you're just being careful about the order in which you do them. Performance is fine, but this pretty much does nothing to ensure that data is consistent without some sort of sync/flush. With journals the picture is more complicated. Yes, there are additional writes, but they can be overlapped with the writes you're already doing so they often don't impact performance that much. Also, there are usually more opportunities to combine/strategize the metadata writes. Ultimately, the performance ends up being affected very little. As far as data protection, it's a big tradeoff. Most journaling filesystems only journal metadata, so they provide the exact same non-guarantee regarding data that soft updates would. If you want to journal data as well you get a better guarantee but worse performance, and it's rarely done; if you're heading in that direction you might as well go all the way to a log-structured filesystem.
There are certainly ways that either journaling or soft-update filesystems can be tweaked to provide guarantees for data or metadata. In either case, you write to a "clean" set of blocks (never write in place) and take care of the metadata updates in such a way that if the metadata makes it the new data automatically comes along for the ride and if it doesn't then the blocks containing new data get reclaimed. This can be useful in certain cases, but it can also suck massively for performance if you have a lot of sub-block updates.
As you can see, it's an interesting set of tradeoffs. It gets even better when your filesystem is distributed. No matter what, though, I tend to prefer soft updates due to greater storage efficiency and less need for provisioning/tuning.
Oh, and forget softupdates, they are _not_ comparable to journaling filesystems, for instance you still need to fsck, it's just faster.
That's true, but misleading. If soft updates are done right, the only reason to fsck is to reclaim resources (orphaned blocks etc.). It is not necessary to get your filesystem into a usable state, and can therefore be done in the background after you've come up. Journaling filesystems also still need to fsck, it's just faster and it's called a log redo, and that is necessary to make the filesystem usable. I'd say the two are very comparable, and soft updates come out slightly ahead. BTW, I'm one of those guys who writes filesystems, the ones you say are not so dumb.:-P
I would rather have a reliable if slower 2.6 or 3.0 kernel now with the features I need than see the 2.4 kernel limp along from bug regression to bug regression.
A motto I've heard is "if you have scalability you can buy performance". In other words, maybe QNX is slower on a single node, but it's designed to scale well across many while preserving the functionality that makes it special. In most cases that's a far better route to getting both the features and performance you need for an application than hoping to tweak something like Linux which was never designed to have those features.
I question the validity of blindly praising microkernels.
How do you feel about praising microkernels with eyes wide open?
being a fanboy for one design approach or another is just bad engineering sense. It's something I see all the time and I'd wish they'd teach a lot more critical thinking skills at the high school level because of it.
Accusing someone you don't know of being a "fanboy" because they disagree with you without providing a complete CV and dissertation is a well known fallacy (hint: its initials in Latin are AH). Those critical-thinking classes you favor should teach that.
Slashdot Mirror
This actually came up in a weird way where I used to work (EMC). One day they made a deal with a vending-machine company, probably owned by one of the Egans, and our free soda disappeared. Several people, including me, immediately went out and bought little mini-fridges to keep in our offices so we'd only be paying grocery-store prices for our beverages. Obviously this cut into the vending-machine profits, so a notice was sent out explaining that such fridges were banned - ostensibly for power-usage and safety reasons. I pointed out that the power-usage argument was totally bogus since these little fridges used less power than several dozen machines running SETI@home 24/7, and the safety issue was almost as ridiculous. I've seen more PCs catch fire than fridges.
Of course, that got me nowhere. They weren't interested in facts or reasoned arguments. They were willing to fire someone who was a mentor and knowledge resource for everyone in that facility and many beyond, to preserve profits for their vending-machine subsidiary. I (uncharacteristically) backed down, but it ended up being one of many bonehead things they did to convince me that I'd be better off elsewhere. Behavior like that has cost them many talented people, some of whom are likely to take a bite out of their business by working for competitors some day. Brilliant management, huh?
Roblimo's "review" is just FUD, and we all hate FUD, right? Oh, so IE doesn't have tabs? There are about a hundred free add-ons that do; I'm using CrazyBrowser right now. It doesn't stop pop-ups? Again, there are plenty of free solutions available. OE doesn't filter spam? Ditto. The list just goes on and on. I use both Windows and Linux every day, and I find them about equally customizable without spending a dime on either one. If roblimo had invested 1% as much time investigating the availability of free add-ons for Windows as he has spent investigating free add-ons for Linux, just about every one of the "problems" he identifies would go away.
Sure, Windows could throw in everything but the kitchen sink, just like commercial Linux distros do, but you know what? They tried bundling stuff with the OS and a whole bunch of people bitched. They backed off because people like roblimo kept saying choice is good and bundling deprives users of choice. How quickly those very same people forget that when it comes to (for example) bundling GNOME/KDE or Mozilla or StarOffice with a commercial Linux distro. What's good for the goose is good for the gander.
That's like saying it's OK to lie, because it's someone else's responsibility to find the truth. Yes, people should understand the technology before they waste money on it, but vendors and Linux advocates also shouldn't be spreading misinformation.
I think you're completely right. Unfortunately, there are a lot of companies out there making claims to the contrary, and a lot of people spending real cash money based on those claims.
Yeah, well, that plus there hasn't been a scheduler that was capable of meeting common real-time requirements. Lots of claims, lots of "Linux on top of something else" hacks that cause more hybrid-environment pain than they're worth, but no native Linux scheduler you could really use for any but the very softest of soft real-time. That lack has been more keenly felt on many projects than the absence of a few "make Windows users feel at home" features on a desktop that people who do real work have considered just fine for several years.
Programs that simply don't work right, that don't meet quality standards we'd apply to every other product category, is a perfect illustration of why the public at large views geek culture - that includes you, we're on Slashdot - as a bunch of overpaid lazy clods.
Mindless flames that make unwarranted assumptions (such as "propping up a can of mountain dew") are a perfect illustration of why the public at large and even the geek community views Slashdot - and particularly the anti-community of aptly named anonymous cowards like you - as filled with twats.
In the latter case, at least, they are right. You're in no position to criticize others' behavior.
I've had to suffer through these guys' port of Joust on shockwave.com (in fact I have the high score for the month currently) and it has several inexcusable flaws. The most annoying is that it doesn't always respond to keypress events properly - rather critical functionality for a game. It doesn't actually seem to drop the events, which would be bad enough, but it ignores them for as much as half a second at a time and then spits a whole bunch out together. If your game wasn't screwed up when it seemed to ignore the event, it's damn sure going to be screwed up when they all get played back in a burst along with the other keys you hit to recover from the original failure. I know Windows is not a real-time system, and I've worked on real real-time systems (microsecond response times) so I do know the difference, but there's no excuse for a delay this long on an unloaded modern system. Other games don't seem to be afflicted by the same problems. The problem is not in Windows; it's in Digital Eclipse's emulation of the hardware on which the game originally ran (even if the code is translated the non-CPU hardware still has to be emulated).
There was also a time when the game's speed calibration was totally broken. I'd play on my 600MHz laptop and it would be just about right, but when I went to my 1.5GHz desktop guess what happened. Yeah, everything in the game was moving about 2.5x as fast and the game was unplayable. This only persisted for a week or two, but it's still not something that should happen in a version that's released to the public. These technical failures, combined with their apparent acquiescence to Shockwave's desire to add deliberate player-killing features to their translation (the very laws of physics in the game change after you get a good score, and I've looked at the original ROM code so I know exactly how they're doing it) have left me with the impression that Digital Eclipse is both incompetent and unethical.
Been there, read that. Proper grounding and adequate voltage are minimum expectations for any case out of the box - not something the buyer should have to fix. Any case with problems like that is simply defective, and when somebody sells a product that is defective by design I think it deserves public mention. If somebody sold you a car that didn't run, even if you were capable of fixing it, would you not be annoyed?
Yeah, so you can put it in a Cubid case...if you don't mind the undervoltage and lack of grounding. I have a Cubid 2699R which used to house a VIA ME-6000 mobo, but that system wasn't stable so I got a case that actually works and the Cubid lies empty in a drawer. The same components have been completely stable in their new home during the months since I ditched the Cubid POS.
In that real world, how often do those branches occur? "Every eight instructions" was never really true except for the most CISCy architectures, and the number has only increased since then. Would you rather have a bigger bubble at 3GHz, or a smaller one at 1GHz while also reducing parallelism for code that doesn't branch as often? Do the math. That's the real lesson of H&P: do the math instead of making wild-ass guesses about what works better.
Speculative execution is a waste of functional units that could be used for real work instead of solving what should be the compiler's problem.
Got any sources for that, Sparky? When you factor out the effects of things like abusing dispatch tables because it's "too hard" to deal with C++ semantics or JVM interpretation the right way, the frequency of jumps in real code written for real performance is going down.
Looks like someone needs to read Hennessy and Patterson. The deep pipelines are there for a reason. The branch and load delay slots are there for a reason. Those are things compilers can deal with, and it wouldn't be possible to reach these clock rates without them. Let's review the old formula, shall we?
Deep pipelines are critical for improving both IPC and CPS, and delay slots help too. It might seem like you're sacrificing WPS, but studies have shown that such an effect is minimal; processors spend practically all of their time implementing the simple instructions anyway for most code. If you increase two factors significantly, and reduce the third only slightly, the result is - obviously - a net win. History has proven that H&P knew what they were talking about, and that their analysis played a pivotal role in achieving the sorts of performance we see today.
Yeah, the x86 instruction set sucks. Oh well. Unless you write compilers there's no reason to care (no, not even for embedded or high-performance work, which I've done). If you do write compilers, think of it as job security. Compatibility with existing applications really does matter more than aesthetics.
Nice satire. Unfortunately, I think a lot of Slashdotters will take it (especially the second bullet) seriously.
Better yet, convert to a language that doesn't have every wart from C plus some tumors of its own. Why settle for moving to a different piece of the swamp when you can climb onto dry land?
Without taking anything away from the excellent work Bram Cohen has done (Hi Bram!) I take issue with "fundamentally different" in the above. There were at least a half-dozen projects that did various kinds of "swarming" or cooperative downloading of files before BitTorrent. You could argue that BitTorrent does it better, or is easier to use, or whatever - there must be some reason it has gained greater exposure than those others - but compared to them it's evolutionary, not revolutionary.
Transactions are not the only possible model for reliable systems. They're just what some people are used to, and if all you have is a hammer everything looks like a nail. Those people need to enlarge their toolboxes, not make the world conform to the tools they've learned.
The article is not about filesystems in anything like a general sense; it's just a PR piece for ReiserFS and its creator, enunciating criteria specific to that implementation and then attempting to show how it actually (gasp!) meets its own idiosyncratic goals. What a waste of time.
The author seems to enjoy dispelling myths but, in this and one of his other articles (RISCy Business) that he links to, he seems to cling rather stubbornly to a couple of his own. For example, I just read twice about how "some RISC chips" don't have multiplication instructions, even though most do nowadays. But hey, it's a convenient club to bash with, just like the one about code density. The guy's a troll. He hates RISC for some reason, and perhaps he has some good points to justify that dislike in the embedded space, but in his zeal he just goes too far into exaggeration and misrepresentation. He also needs to read H&P to understand the real rationale behind RISC, instead of the strawman rationale he gives in the article.
The legal phrase is "substantial non-infringing use". If something is primarily used to infringe on copyrights, and adapting it to legitimate use is difficult or unlikely, it can be considered contributory to the infringement and thus held liable. The "Betamax" case hinged on this very issue, and the VCR manufacturers barely won. P2P networks generally have an even greater preponderance of illegal use, so it's not at all clear the Betamax precedent would apply.
The same principle has been applied to other areas as well - certain types of weapons, drug paraphernalia, etc. If an object's primary function is to assist in breaking the law, I think a legitimate case can be made for prosecuting those who make it. That's true even when the law in question is a stupid one (as is definitely the case with copyrights in their current state); until the stupid law is changed, it's a matter for the courts to decide and one cannot disallow suits based on that rationale.
XML compresses well because it's so mind-numbingly redundant in the first place, and gzipping a bloated format costs more memory and CPU than having a non-bloated format in the first place. Usually it's not enough to worry about because there are other, bigger performance problems to worry about first, but when you've reduced inefficiency elsewhere in the code you're stuck looking at an inherently inefficient format that you can no longer change because to do so would make you inoperable with existing implementations. Bad idea.
Reading your post, the phrase "too clever by half" comes to mind. If the client doesn't want some avant-garde artsy design, you should know that up front; if you're overshooting their design comfort level and then having to "water it down" you're wasting their time and money. The problem is, everyone who studies design wants to be on the cutting edge, but there's really only room for 10% (at most) to be there; the rest should get used to working on less exciting projects unless/until they can prove that they deserve to be one of the few who get to do the good stuff. It's the same as in programming - a few get to strike out in bold new directions, the rest earn their stripes by making derivatives or lesser enhancements.
It's not about people thinking change is bad. You only say that because you want to be the one making the changes, and I suspect you'd seem just as conservative about unasked-for "screwing around with stuff" in areas outside your own specialty. Do you use any software? How would you like it if the entire UI changed, just because someone thought they had a better idea? How about if your ZIP code or telephone area code kept changing, just because someone came up with a more "logical" way to assign them? If some traffic designer had the "bright idea" to make some of the streets in your neighborhood one-way, would you just say "cool, change is good"? Hmmm. What this is about is balancing change with consistency. Too bad if that leaves you frustrated because there aren't enough opportunities to do what you want to do.
Heh. Same here. Why, just this morning I was making the turn onto Maguire, and I was thinking "what is the natural nickname for people who work at IDEO, anyway?" I don't think they'd appreciate the answer I came up with.
BTW, cool name. If you ever decide to abandon that identity, let me know. ;-)
I'd have to say it depends. The beauty of soft updates is that they require exactly zero additional writes beyond what you'd be doing anyway; you're just being careful about the order in which you do them. Performance is fine, but this pretty much does nothing to ensure that data is consistent without some sort of sync/flush. With journals the picture is more complicated. Yes, there are additional writes, but they can be overlapped with the writes you're already doing so they often don't impact performance that much. Also, there are usually more opportunities to combine/strategize the metadata writes. Ultimately, the performance ends up being affected very little. As far as data protection, it's a big tradeoff. Most journaling filesystems only journal metadata, so they provide the exact same non-guarantee regarding data that soft updates would. If you want to journal data as well you get a better guarantee but worse performance, and it's rarely done; if you're heading in that direction you might as well go all the way to a log-structured filesystem.
There are certainly ways that either journaling or soft-update filesystems can be tweaked to provide guarantees for data or metadata. In either case, you write to a "clean" set of blocks (never write in place) and take care of the metadata updates in such a way that if the metadata makes it the new data automatically comes along for the ride and if it doesn't then the blocks containing new data get reclaimed. This can be useful in certain cases, but it can also suck massively for performance if you have a lot of sub-block updates.
As you can see, it's an interesting set of tradeoffs. It gets even better when your filesystem is distributed. No matter what, though, I tend to prefer soft updates due to greater storage efficiency and less need for provisioning/tuning.
That's true, but misleading. If soft updates are done right, the only reason to fsck is to reclaim resources (orphaned blocks etc.). It is not necessary to get your filesystem into a usable state, and can therefore be done in the background after you've come up. Journaling filesystems also still need to fsck, it's just faster and it's called a log redo, and that is necessary to make the filesystem usable. I'd say the two are very comparable, and soft updates come out slightly ahead. BTW, I'm one of those guys who writes filesystems, the ones you say are not so dumb. :-P
A motto I've heard is "if you have scalability you can buy performance". In other words, maybe QNX is slower on a single node, but it's designed to scale well across many while preserving the functionality that makes it special. In most cases that's a far better route to getting both the features and performance you need for an application than hoping to tweak something like Linux which was never designed to have those features.
How do you feel about praising microkernels with eyes wide open?
Accusing someone you don't know of being a "fanboy" because they disagree with you without providing a complete CV and dissertation is a well known fallacy (hint: its initials in Latin are AH). Those critical-thinking classes you favor should teach that.