OK, so how do you explain the fact that, on the referenced benchmark, the 7200RPM SCSI Quantum Atlas V beats the very best ATA drive (the 7200RPM Maxtor DiamondMax D740X) by 174 to 133. That's a 30% difference. Sure, the Atlas is smaller and costs more, but it does perform better and that's what we're supposedly talking about.
In fact, this is a hard comparison to do, because it's hard to find SCSI drives below 10000RPM or ATA drives above 7200RPM? Why do you suppose that is? One possibility is that it's a vast conspiracy. Another possibility, which seems more rational to people who know something about storage, is that the drive vendors know the extra speed would be wasted on an ATA drive. It'd be like putting a GigE interface on a DSL modem. OK, not quite that bad, but you get the point: it doesn't make sense to upgrade one part of a system that remains bottlenecked elsewhere. If putting an ATA interface on a 10K RPM mechanism really gave better performance than a 7200 RPM mechanism, the drive vendors would be all over that, but it doesn't so they don't. No conspiracy theory is necessary to explain that.
Wrong. Building a PC from scratch requires quite a bit of knowledge - not deep knowledge, but broad. Jumpers and DIP switches and voltage settings and connectors that are easy to insert backwards. Non-obvious concepts like master vs. slave vs. cable select. How to install a heatsink/fan without cracking the CPU core, and so that it actually provides the necessary cooling. How not to zap your system into oblivion with static. Get one thing wrong and your system won't even get into the BIOS...now, or perhaps forever if you really managed to screw up.
Linux installs on vanilla hardware have gotten pretty damn easy, even for novices. Building a custom machine, and then installing Linux and XFree86 with the right drivers (because the basic install might not recognize what you have or know how to set it up properly) is still very hard for most people. It's a hill - not a mountain - they're just not interested in climbing, nor should we expect them to. They have better things to do with their time; they're willing to pay someone else to put together even a mediocre computer system rather than have to deal with it themselves, and that's a valid choice. I also have better things to do with my time than learn how to fiddle with my car's engine, so I pay someone else to do that. Civilization itself is based on that same willingness to pay someone else for their specialized skills, and it's hardly a bad thing. Just think, if everyone did learn how to do this stuff themselves, you'd no longer have even that one lame reason to feel so special.
a Samsung 40 gig.. Samsung is far from a reputable HD company
On what notion of "reputable" do you base that? Among professional storage folks, Samsung drives have a perfectly decent if not stellar reputation. Sure, their drives are no performance kings, but they're as reliable as anything else and are generally above average wrt environmental factors such as heat and noise. IBM is supposedly a "reputable" vendor, but look at their GXP series. Other vendors have put out clunkers from time to time as well. Who do you think is better, and what evidence do you have to back that up?
they didn't mention RPM's.. which ill assume is 5400rpm.
RPMs don't matter; performance matters, and this isn't supposed to be a rule-the-road kind of machine anyway. For mom and pop surfing the web and so on, there's no way the fact that it's a 5400RPM drive is going to matter even one little bit.
Only 128mb of RAM? and its shared with onboard video ?
If there's one place that they might have been a little bit too skimpy, it's here. It's a budget machine, sure, but RAM's dirt-cheap right now. An upgrade to 256MB would give a lot of bang for the buck, more than doubling the memory available to the OS and applications.
a MicroATX motherboard? wow, forget upgrading.
It's not as bad as you think. MicroATX is an increasingly popular form factor, with quite a few good boards available from well-regarded vendors. Motherboard swaps are pretty rare compared to other types of upgrades anyway, and spec-compliant cards fit just fine. Lastly, it's not uncommon for budget-oriented machines to have limited expandability; some of the most common vendors of full-ATX systems are less upgradable than this.
In short, you're wrong that the board being MicroATX has a significant effect on upgradability, and even if you were right it's a common and acceptable tradeoff for this class of machine.
Microstar, another not too reputable manufacturer
Nonsense. Microstar products are mediocre, but no worse. There are a lot of worse vendors, even among the big names. While it would be insane for an enthusiast to buy a Microstar board, it's a reasonable choice for a budget PC.
In short, you're a snob. Your criticisms of the components seem to be influenced more by advertising and name recognition than on a realistic consideration of the components' and vendors' actual track records, and you resolutely refuse to accept that the requirements of building a budget mass-market PC are very different than those affecting an enthusiast such as yourself. This is a perfectly reasonable machine for its target market, even if the lack of an endorsement from Britney Spears seems to bother you.
It would be interesting to hear some ideas instead of sarcasm
Fair enough.
The multiple-host problem isn't too bad if the multiple hosts are accessing separate pieces of storage in a statically patritioned system. But that's increasingly unrealistic. For one thing, shared storage is becoming more common. That requires cluster-aware LVMs, filesystems, and databases, which are quite a bit less common, complicated, and expensive than the "vanilla" versions. For another, storage is becoming more fluid. People want to be able to create, delete, resize, and reconfigure volumes on the fly to accomodate changing needs. They might not do it every day, but they do it enough times per year that they will not accept having to take the system offline to do it. Similarly, instant snapshots have almost reached the status of a must-have feature, and people balk at needing to allocate a complete mirror set up front for each snapshot they might ever take; more and more they want to allocate snapshot space on a strictly as-needed basis.
The multiple-failure-recovery problem is very similar, but adds a few more dimensions. User tolerance for staying in a degraded state is decreasing. If a drive fails, for example, you don't want to be regenerating data from parity forever; you want to grab some free storage (anywhere, not a designated "hot spare"), recreate the failed drive's contents on it, and totally forget about the old drive...all automatically. If you've sliced and diced the now-failed drive into 20GB chunks, it might get more interesting; now you might have to recreate chunk 1 that's part of volume X, chunk 2 that's part of volume Y, etc. all in parallel to minimize exposure to a second failure. If you lose a node, with all of its cache including writes that might not have been destaged yet, you have to do a similar kind of rebuild. Then you realize that exactly the same infrastructure can be used to deal with hotspots instead of failures, so you're actually going through this all the time instead of just in response to failures.
What you end up with is a storage system that's constantly reconfiguring itself to adapt to conditions, with many overlapping activities in progress almost all the time, all needing to be carefully coordinated between independent storage nodes. Even something as simple as a write has to be properly coordinated with everything else that might be going on around it, and everything still has to run as fast as possible, so it can get pretty hairy in there. That's the challenge they're trying to tackle, and it most certainly is not addressed by off-the-shelf host-side software.
what does that do to performance is yet to be seen
Probably won't be a factor, because of caches and parallelism. If both your reads and writes are served via cache most of the time (the latter to be destaged to disk on the array's own time) then the actual disk speed is less of a factor. Also, if your requests are being served by a relatively large number of disks then a single disk doesn't become a bottleneck. Large transfers can occur in parallel, queuing effects are reduced, etc. Combine caches with lots of disks, so that the array has lots of flexibility in how it schedules I/O, and the result is even more powerful.
But what, you say, about the potential data loss when a node holding a cached block fails? Well, the bricks have very fast connections. It doesn't seem too much of a stretch to suppose that caches might be replicated (this is one of the interesting software challenges to which IBM alludes). Thus, the time to complete a write is only the time to replicate its data to another block, not the time to actually write it to disk. As long as you retain enough reserve power so that cache can be flushed to a special area on each brick's local disks in case of an external power failure, you could even claim to be ACID-compliant (some vendors do exactly this).
Oh yes, you've thought about it for five minutes and solved all the problems. You're so brilliant. Errr...except that you don't address multiple hosts, recovery from multiple (even non-concurrent) failures, reconfiguration to avoid hotspots, etc. etc. etc. Just about anything is solvable with current technology if you ignore enough parts of the problem. The whole point of this, the whole reason they say that the software is such a challenge, is that they actually want to address the parts of the problem you ignore.
I find a society where there is no such thing as 'privacy' to be upsetting. The fact that David likes it so much
You're misrepresenting his position. Have you actually read the book? Brin doesn't think a society without privacy is a good thing, just that with current (or near-future) technology it's unavoidable. The government simply will be able to watch you, no matter what precautions you take. Maybe you don't believe that, but so far Brin has been much more convincing on that point than you have, and if one accepts his arguments on that point then the rest of what he has to say about symmetry between watchers and watched makes a lot of sense.
That's why message passing is typically used...You eliminate the synchronization problems
Wrong. Just plain wrong. Explicit message passing can often reduce communication overhead compared to coherent shared memory, but the synchronization problems are still very much present. You still can't operate on data before it becomes available, regardless of the programming model. Explicit message-passing systems handle synchronization very differently than shared-memory systems, but those problems don't just go away.
I found a copy of the course-specific honor code here. Here's the relevant excerpt:
All assignments must reflect an individual effort, and must be completed "from scratch." It is a violation of the Honor Code to copy or derive solutions from text books, internet resources, or previous instances of this course unless specifically instructed to do so in assignment directions. When instructed to do so, all material not created by you and its source must be clearly identified. Copying solutions from other students, including those who previous took the course, is prohibited. A good guideline is that you must be able to explain and/or reproduce anything that you submit for any assignment.
It actually looks pretty reasonable. I'd like to direct people's attention particularly to the last "good guideline" sentence. Now, what did the student do? From the original story:
When he found himself with a homework assignment he did not understand, and no teaching assistants or professors available on a campus off-week, he convinced himself that just chatting with another student would not violate the rules.
Now, "chatting" is obviously vague; there's a big difference between "what are they asking us to do" and "how do we do it". However, it doesn't matter. According to the "good guideline" in the honor code, the student would be in the right even if he discussed answers with the other student, so long as neither was looking at or copying from the other's actual code and both could explain independently how their solution worked. If anything, the honor-code standard as stated in the referenced link seems a little too lenient to me.
It's entirely possible that the student did something more egregious than what's mentioned in the article. It's also entirely possible that someone's being a little overzealous about enforcing their own interpretation of what is really a pretty lenient standard. Assuming either to be the case would be premature, based on the information available. All of the political rhetoric, on either side, seems just a little bit misguided in the absence of anything but the most fragmentary and incomplete information.
Why does the repository need to be public? In an era of very powerful client machines, why must we have a centralized database
Why do you assume that public implies centralized? The article author certainly didn't; that was actually one of the questions s/he was asking? If you look at systems like OceanStore or SFS, or even Microsoft's own Farsite, you'll quickly realize that your assumption is false.
its just that I hear this constantly. And its never with any proof.
If you keep hearing it from every user, that's the proof right there. What kind of proof do you want, other than actual user experiences? Surely anything else would be more FUDdy than that.
People seem to be assuming that subterfugue is kernel code. I just looked at the source, and it's not. It depends on some kernel patches for 2.3.x, but subterfugue itself is a user-level syscall interceptor. When they refer to sf as the subterfugue driver, they mean "driver" in the mushy sense of "anything that's not an application is a driver", not in the precise sense of something that gets loaded into the kernel. Also, only programs (and their descendants) run explicitly via subterfugue are affected at all; it doesn't hook in at a level that allows it to operate on arbitrary processes.
Subterfugue is basically a Python wrapper for strace, so you can inspect and modify syscalls and their arguments in Python instead of in C. Yes, it's neat, but not nearly as neat as being able to implement real drivers or network protocols or filesystems in Python (like this).
Re:Just because you _can_ doesn't mean you _wanna_
on
Managing Einsteins
·
· Score: 2
I'd say that generally, the programmers were not the 'techies' you're referring to. In fact, those 'techies' were simply one part pseudotechie
Nope, that's just denial. As unwilling as we true techies are to admit our own group's complicity, many of the people helping to inflate the dot-com bubble were from our ranks. They knew about some cool technology, and they were too naive too realize that cool technology is only one ingredient in making a successful business. The managers and marketers weren't alone in screwing things up, not by a long shot.
My point was its still not as good (both for society, and for the quality of production) as when the builders value what they're building
And that's a good point, but not one that anybody except a mind-reader might have taken from your previous post.
Re:Just because you _can_ doesn't mean you _wanna_
on
Managing Einsteins
·
· Score: 4, Insightful
dont think you'll find many construction workers that like to build useless buildings
Actually, builders seem to have absolutely no problem with that. They get a contract, they do the work, they get paid, they move on, without obsessing over whether the project is interesting or challenging or sexy like programmers do.
as the.com flop showed, those grumblins and skeptical snide remarks by your programmers are often going to be the first sign
Let's not rewrite history, OK? The techies were in the vanguard for that debacle. They were the ones leading the way, yammering about new economies grumbling about how those old-school types just didn't get it, yadda yadda yadda. They were rampant optimists. The skepticism was coming from above, and turned out to be well justified.
Now, much of the IT industry is about spurring people against their will...to entice them to building things that businesses want.
Sounds like a pretty fucking good business model to me. Much better than building things that nobody wants, that's for sure.
Programmers and techies can spot and sniff the 'empty promises' in technology
No, it's the people running the businesses who've learned to spot empty promises, like the "if you let us build it, they will come" promise of the dot-bomb era. The techies are more often the ones making the empty promises.
Web-browsing used to being up a plethora of intelligent, well-written, interesting pages back in the day
I'm sorry, but can we give the "Golden Era" meme a rest after several thousand years of constant use? I was here when the web was invented, I remember what it was like. I don't think the quality of the ideas, or the writing, or the visual presentation, has changed a whole heck of a lot either way since then. There's a lot of crap now, but there was a lot of crap then too. Maybe it used to be geekier crap, more to fellow geeks' liking, but it was still crap.
only us "old timers" bother with things like netiquette
Here you do touch on the one thing that seems to be different: the prevalence of trolls. Trolls are, by and large, a lazy lot. Even the smallest barrier to entry - even free registration - is often enough that they'll seek easier targets, so in the early days of the web trolls weren't a problem. Now, of course...well, you know.
I don't see it as a "newbie" vs. "oldbie" thing, though. Oldbies might know netiquette, but that doesn't mean they follow it. In fact, the net tends to train trolls. Think about the stage each young troll goes through when they first learn about these things called logical fallacies. Do they use this knowledge to clean up their act? No, they use it to club other people over the head. Over time, trolls get better at what they do, and the most annoying trolls are usually the ones who've had the most years of practice.
For more on "us old timers" and newbie-bashing, you might find this article from last February interesting.
The main problem with USEnet is that it still has to route every single article to every single node whether it is going to be read or not.
First, don't say "Usenet" (not an acronym BTW) when you mean "NNTP" and vice versa. While there are strong and obvious relationships between the two, they are different things.
Second, censorship-resistance was not and is not the main reason for NNTP working the way it does. I know somebody else already pointed that out, but it bears repeating.
Third, NNTP doesn't do flooding ("flood fill routing" is not a phrase with any kind of common meaning and is thus equivalent to a typo). NNTP is a point-to-point protocol, and is this incapable of flooding. Usenet doesn't use flooding either. For one thing, flooding is generally understood to mean "pushing" data everywhere it can go when it becomes available, whereas Usenet and NNTP have always been based on sending information where and when it is requested. For another, Usenet connectivity patterns are mostly tree-like and flooding - which refers to sending the same data along all possible paths to a single destination - is generally considered an inoperative term when only one path existed to begin with.
are you talking about plain bad coding, or a design for simplicity for the programmer that may be slow, but takes far less time/code to solve the problem (eg. priority issue)?
Neither, in the context of this particular thread. If we're talking about programs like GNOME or KDE, I think we're talking about code that has grown over time with both modularity and performance taking a back seat to bells and whistles.
In a more general context, probably somewhere between your first and third options. A lot of code seems to hover at a level somewhere between "didn't know any better" and "didn't even care".;-)
if I'm a free software developer I owe nothing to the users of my software.
You don't have to owe them anything for it to be bad code. I don't know about you, but even when I'm writing code for myself I hate to write bad code. It's just a bad habit, that tends to carry over to areas where it really does matter.
I've said this before and I'll say it again -- FEATURE REQUESTS!
I've said this before and I'll say it again -- MODULARITY! Designing software that can be configured up or down to suit users' preferences and hardware capabilities is not rocket science. Maybe that wimpy-machine user will have to turn off some of the latest features to get adequate performance, but that should be their choice. The software should be constructed - both at a deep level and at a user interface level - to make that choice possible.
I think you're off base. I just used the Wayback Machine to look at PC Magazine from March 1997. Typical is the Dell Dimension XPS P200s which, at $3179, sported a 200MHz PPro and 32MB of SDRAM. Cut those numbers in half to find what a true five-year-old POS would be like, and then consider that a lot of people are still stuck with even older machines than that. Obviously we don't expect such a machine to keep up even with your machine that has 4x the MHz and 12x the MB (not to mention better I/O and who knows what other improvements) let alone a modern machine, but there's no reason a god-damned window manager or file browser shouldn't run just fine on it...and apparently they don't.
Optimizing software for slower machines has a cost.
You'll find no disagreement from me, if you're talking about optimizing for those slower machines. However, what we're generally dealing with is programmers just pissing away dozens of megabytes and millions of CPU cycles to no purpose whatsoever. I've seen a lot of code in my time that could be simplified or streamlined such that there will be some platforms on which it will run faster and no platforms on which it will run slower, and such that it would be more readable and maintainable besides. Some of it was my code, written before I knew everything.;-) This is being presented as a tradeoff, and sometimes it is, but other times it's just an out and out waste.
You get a big juicy -1/Illiterate for not reading the article before you responded. The author explains quite clearly why what you suggest is not an option in many environments. You can afford a decent computer, I can afford an even better one, but there are people whose new-equipment budget is zero and who have to make do with whatever five-year-old POS is lying around. Programmers who make software that's unusable for some people just because they (the programmers) aren't affected by the waste and are too lazy to do anything about it are just crappy programmers.
Slashdot Mirror
OK, so how do you explain the fact that, on the referenced benchmark, the 7200RPM SCSI Quantum Atlas V beats the very best ATA drive (the 7200RPM Maxtor DiamondMax D740X) by 174 to 133. That's a 30% difference. Sure, the Atlas is smaller and costs more, but it does perform better and that's what we're supposedly talking about.
In fact, this is a hard comparison to do, because it's hard to find SCSI drives below 10000RPM or ATA drives above 7200RPM? Why do you suppose that is? One possibility is that it's a vast conspiracy. Another possibility, which seems more rational to people who know something about storage, is that the drive vendors know the extra speed would be wasted on an ATA drive. It'd be like putting a GigE interface on a DSL modem. OK, not quite that bad, but you get the point: it doesn't make sense to upgrade one part of a system that remains bottlenecked elsewhere. If putting an ATA interface on a 10K RPM mechanism really gave better performance than a 7200 RPM mechanism, the drive vendors would be all over that, but it doesn't so they don't. No conspiracy theory is necessary to explain that.
Wrong. Building a PC from scratch requires quite a bit of knowledge - not deep knowledge, but broad. Jumpers and DIP switches and voltage settings and connectors that are easy to insert backwards. Non-obvious concepts like master vs. slave vs. cable select. How to install a heatsink/fan without cracking the CPU core, and so that it actually provides the necessary cooling. How not to zap your system into oblivion with static. Get one thing wrong and your system won't even get into the BIOS...now, or perhaps forever if you really managed to screw up.
Linux installs on vanilla hardware have gotten pretty damn easy, even for novices. Building a custom machine, and then installing Linux and XFree86 with the right drivers (because the basic install might not recognize what you have or know how to set it up properly) is still very hard for most people. It's a hill - not a mountain - they're just not interested in climbing, nor should we expect them to. They have better things to do with their time; they're willing to pay someone else to put together even a mediocre computer system rather than have to deal with it themselves, and that's a valid choice. I also have better things to do with my time than learn how to fiddle with my car's engine, so I pay someone else to do that. Civilization itself is based on that same willingness to pay someone else for their specialized skills, and it's hardly a bad thing. Just think, if everyone did learn how to do this stuff themselves, you'd no longer have even that one lame reason to feel so special.
On what notion of "reputable" do you base that? Among professional storage folks, Samsung drives have a perfectly decent if not stellar reputation. Sure, their drives are no performance kings, but they're as reliable as anything else and are generally above average wrt environmental factors such as heat and noise. IBM is supposedly a "reputable" vendor, but look at their GXP series. Other vendors have put out clunkers from time to time as well. Who do you think is better, and what evidence do you have to back that up?
RPMs don't matter; performance matters, and this isn't supposed to be a rule-the-road kind of machine anyway. For mom and pop surfing the web and so on, there's no way the fact that it's a 5400RPM drive is going to matter even one little bit.
If there's one place that they might have been a little bit too skimpy, it's here. It's a budget machine, sure, but RAM's dirt-cheap right now. An upgrade to 256MB would give a lot of bang for the buck, more than doubling the memory available to the OS and applications.
It's not as bad as you think. MicroATX is an increasingly popular form factor, with quite a few good boards available from well-regarded vendors. Motherboard swaps are pretty rare compared to other types of upgrades anyway, and spec-compliant cards fit just fine. Lastly, it's not uncommon for budget-oriented machines to have limited expandability; some of the most common vendors of full-ATX systems are less upgradable than this.
In short, you're wrong that the board being MicroATX has a significant effect on upgradability, and even if you were right it's a common and acceptable tradeoff for this class of machine.
Nonsense. Microstar products are mediocre, but no worse. There are a lot of worse vendors, even among the big names. While it would be insane for an enthusiast to buy a Microstar board, it's a reasonable choice for a budget PC.
In short, you're a snob. Your criticisms of the components seem to be influenced more by advertising and name recognition than on a realistic consideration of the components' and vendors' actual track records, and you resolutely refuse to accept that the requirements of building a budget mass-market PC are very different than those affecting an enthusiast such as yourself. This is a perfectly reasonable machine for its target market, even if the lack of an endorsement from Britney Spears seems to bother you.
Fair enough.
The multiple-host problem isn't too bad if the multiple hosts are accessing separate pieces of storage in a statically patritioned system. But that's increasingly unrealistic. For one thing, shared storage is becoming more common. That requires cluster-aware LVMs, filesystems, and databases, which are quite a bit less common, complicated, and expensive than the "vanilla" versions. For another, storage is becoming more fluid. People want to be able to create, delete, resize, and reconfigure volumes on the fly to accomodate changing needs. They might not do it every day, but they do it enough times per year that they will not accept having to take the system offline to do it. Similarly, instant snapshots have almost reached the status of a must-have feature, and people balk at needing to allocate a complete mirror set up front for each snapshot they might ever take; more and more they want to allocate snapshot space on a strictly as-needed basis.
The multiple-failure-recovery problem is very similar, but adds a few more dimensions. User tolerance for staying in a degraded state is decreasing. If a drive fails, for example, you don't want to be regenerating data from parity forever; you want to grab some free storage (anywhere, not a designated "hot spare"), recreate the failed drive's contents on it, and totally forget about the old drive...all automatically. If you've sliced and diced the now-failed drive into 20GB chunks, it might get more interesting; now you might have to recreate chunk 1 that's part of volume X, chunk 2 that's part of volume Y, etc. all in parallel to minimize exposure to a second failure. If you lose a node, with all of its cache including writes that might not have been destaged yet, you have to do a similar kind of rebuild. Then you realize that exactly the same infrastructure can be used to deal with hotspots instead of failures, so you're actually going through this all the time instead of just in response to failures.
What you end up with is a storage system that's constantly reconfiguring itself to adapt to conditions, with many overlapping activities in progress almost all the time, all needing to be carefully coordinated between independent storage nodes. Even something as simple as a write has to be properly coordinated with everything else that might be going on around it, and everything still has to run as fast as possible, so it can get pretty hairy in there. That's the challenge they're trying to tackle, and it most certainly is not addressed by off-the-shelf host-side software.
Probably won't be a factor, because of caches and parallelism. If both your reads and writes are served via cache most of the time (the latter to be destaged to disk on the array's own time) then the actual disk speed is less of a factor. Also, if your requests are being served by a relatively large number of disks then a single disk doesn't become a bottleneck. Large transfers can occur in parallel, queuing effects are reduced, etc. Combine caches with lots of disks, so that the array has lots of flexibility in how it schedules I/O, and the result is even more powerful.
But what, you say, about the potential data loss when a node holding a cached block fails? Well, the bricks have very fast connections. It doesn't seem too much of a stretch to suppose that caches might be replicated (this is one of the interesting software challenges to which IBM alludes). Thus, the time to complete a write is only the time to replicate its data to another block, not the time to actually write it to disk. As long as you retain enough reserve power so that cache can be flushed to a special area on each brick's local disks in case of an external power failure, you could even claim to be ACID-compliant (some vendors do exactly this).
Oh yes, you've thought about it for five minutes and solved all the problems. You're so brilliant. Errr...except that you don't address multiple hosts, recovery from multiple (even non-concurrent) failures, reconfiguration to avoid hotspots, etc. etc. etc. Just about anything is solvable with current technology if you ignore enough parts of the problem. The whole point of this, the whole reason they say that the software is such a challenge, is that they actually want to address the parts of the problem you ignore.
You're misrepresenting his position. Have you actually read the book? Brin doesn't think a society without privacy is a good thing, just that with current (or near-future) technology it's unavoidable. The government simply will be able to watch you, no matter what precautions you take. Maybe you don't believe that, but so far Brin has been much more convincing on that point than you have, and if one accepts his arguments on that point then the rest of what he has to say about symmetry between watchers and watched makes a lot of sense.
Wrong. Just plain wrong. Explicit message passing can often reduce communication overhead compared to coherent shared memory, but the synchronization problems are still very much present. You still can't operate on data before it becomes available, regardless of the programming model. Explicit message-passing systems handle synchronization very differently than shared-memory systems, but those problems don't just go away.
I found a copy of the course-specific honor code here. Here's the relevant excerpt:
It actually looks pretty reasonable. I'd like to direct people's attention particularly to the last "good guideline" sentence. Now, what did the student do? From the original story:
Now, "chatting" is obviously vague; there's a big difference between "what are they asking us to do" and "how do we do it". However, it doesn't matter. According to the "good guideline" in the honor code, the student would be in the right even if he discussed answers with the other student, so long as neither was looking at or copying from the other's actual code and both could explain independently how their solution worked. If anything, the honor-code standard as stated in the referenced link seems a little too lenient to me.
It's entirely possible that the student did something more egregious than what's mentioned in the article. It's also entirely possible that someone's being a little overzealous about enforcing their own interpretation of what is really a pretty lenient standard. Assuming either to be the case would be premature, based on the information available. All of the political rhetoric, on either side, seems just a little bit misguided in the absence of anything but the most fragmentary and incomplete information.
OK, everyone. Add UIUC to the list of schools that you should avoid.
Why do you assume that public implies centralized? The article author certainly didn't; that was actually one of the questions s/he was asking? If you look at systems like OceanStore or SFS, or even Microsoft's own Farsite, you'll quickly realize that your assumption is false.
If you keep hearing it from every user, that's the proof right there. What kind of proof do you want, other than actual user experiences? Surely anything else would be more FUDdy than that.
People seem to be assuming that subterfugue is kernel code. I just looked at the source, and it's not. It depends on some kernel patches for 2.3.x, but subterfugue itself is a user-level syscall interceptor. When they refer to sf as the subterfugue driver, they mean "driver" in the mushy sense of "anything that's not an application is a driver", not in the precise sense of something that gets loaded into the kernel. Also, only programs (and their descendants) run explicitly via subterfugue are affected at all; it doesn't hook in at a level that allows it to operate on arbitrary processes.
Subterfugue is basically a Python wrapper for strace, so you can inspect and modify syscalls and their arguments in Python instead of in C. Yes, it's neat, but not nearly as neat as being able to implement real drivers or network protocols or filesystems in Python (like this).
Nope, that's just denial. As unwilling as we true techies are to admit our own group's complicity, many of the people helping to inflate the dot-com bubble were from our ranks. They knew about some cool technology, and they were too naive too realize that cool technology is only one ingredient in making a successful business. The managers and marketers weren't alone in screwing things up, not by a long shot.
And that's a good point, but not one that anybody except a mind-reader might have taken from your previous post.
Actually, builders seem to have absolutely no problem with that. They get a contract, they do the work, they get paid, they move on, without obsessing over whether the project is interesting or challenging or sexy like programmers do.
Let's not rewrite history, OK? The techies were in the vanguard for that debacle. They were the ones leading the way, yammering about new economies grumbling about how those old-school types just didn't get it, yadda yadda yadda. They were rampant optimists. The skepticism was coming from above, and turned out to be well justified.
Sounds like a pretty fucking good business model to me. Much better than building things that nobody wants, that's for sure.
No, it's the people running the businesses who've learned to spot empty promises, like the "if you let us build it, they will come" promise of the dot-bomb era. The techies are more often the ones making the empty promises.
That can't be it. A computer with good taste would eject the disk immediately, without even thinking about playing it.
I'm sorry, but can we give the "Golden Era" meme a rest after several thousand years of constant use? I was here when the web was invented, I remember what it was like. I don't think the quality of the ideas, or the writing, or the visual presentation, has changed a whole heck of a lot either way since then. There's a lot of crap now, but there was a lot of crap then too. Maybe it used to be geekier crap, more to fellow geeks' liking, but it was still crap.
Here you do touch on the one thing that seems to be different: the prevalence of trolls. Trolls are, by and large, a lazy lot. Even the smallest barrier to entry - even free registration - is often enough that they'll seek easier targets, so in the early days of the web trolls weren't a problem. Now, of course...well, you know.
I don't see it as a "newbie" vs. "oldbie" thing, though. Oldbies might know netiquette, but that doesn't mean they follow it. In fact, the net tends to train trolls. Think about the stage each young troll goes through when they first learn about these things called logical fallacies. Do they use this knowledge to clean up their act? No, they use it to club other people over the head. Over time, trolls get better at what they do, and the most annoying trolls are usually the ones who've had the most years of practice.
For more on "us old timers" and newbie-bashing, you might find this article from last February interesting.
First, don't say "Usenet" (not an acronym BTW) when you mean "NNTP" and vice versa. While there are strong and obvious relationships between the two, they are different things.
Second, censorship-resistance was not and is not the main reason for NNTP working the way it does. I know somebody else already pointed that out, but it bears repeating.
Third, NNTP doesn't do flooding ("flood fill routing" is not a phrase with any kind of common meaning and is thus equivalent to a typo). NNTP is a point-to-point protocol, and is this incapable of flooding. Usenet doesn't use flooding either. For one thing, flooding is generally understood to mean "pushing" data everywhere it can go when it becomes available, whereas Usenet and NNTP have always been based on sending information where and when it is requested. For another, Usenet connectivity patterns are mostly tree-like and flooding - which refers to sending the same data along all possible paths to a single destination - is generally considered an inoperative term when only one path existed to begin with.
Neither, in the context of this particular thread. If we're talking about programs like GNOME or KDE, I think we're talking about code that has grown over time with both modularity and performance taking a back seat to bells and whistles.
In a more general context, probably somewhere between your first and third options. A lot of code seems to hover at a level somewhere between "didn't know any better" and "didn't even care". ;-)
You don't have to owe them anything for it to be bad code. I don't know about you, but even when I'm writing code for myself I hate to write bad code. It's just a bad habit, that tends to carry over to areas where it really does matter.
I've said this before and I'll say it again -- MODULARITY! Designing software that can be configured up or down to suit users' preferences and hardware capabilities is not rocket science. Maybe that wimpy-machine user will have to turn off some of the latest features to get adequate performance, but that should be their choice. The software should be constructed - both at a deep level and at a user interface level - to make that choice possible.
I think you're off base. I just used the Wayback Machine to look at PC Magazine from March 1997. Typical is the Dell Dimension XPS P200s which, at $3179, sported a 200MHz PPro and 32MB of SDRAM. Cut those numbers in half to find what a true five-year-old POS would be like, and then consider that a lot of people are still stuck with even older machines than that. Obviously we don't expect such a machine to keep up even with your machine that has 4x the MHz and 12x the MB (not to mention better I/O and who knows what other improvements) let alone a modern machine, but there's no reason a god-damned window manager or file browser shouldn't run just fine on it...and apparently they don't.
You'll find no disagreement from me, if you're talking about optimizing for those slower machines. However, what we're generally dealing with is programmers just pissing away dozens of megabytes and millions of CPU cycles to no purpose whatsoever. I've seen a lot of code in my time that could be simplified or streamlined such that there will be some platforms on which it will run faster and no platforms on which it will run slower, and such that it would be more readable and maintainable besides. Some of it was my code, written before I knew everything. ;-) This is being presented as a tradeoff, and sometimes it is, but other times it's just an out and out waste.
You get a big juicy -1/Illiterate for not reading the article before you responded. The author explains quite clearly why what you suggest is not an option in many environments. You can afford a decent computer, I can afford an even better one, but there are people whose new-equipment budget is zero and who have to make do with whatever five-year-old POS is lying around. Programmers who make software that's unusable for some people just because they (the programmers) aren't affected by the waste and are too lazy to do anything about it are just crappy programmers.
Don't pay attention to what they say the reasons are. It's the taxes.