And you tell me the conspiracy theory wasn't believable?
Heck, you didn't make it past the INTRODUCTION. You couldn't have even met all the major player characters that far in. You have NO IDEA how utterly flabbergasting it got.
For many years, I made a point of reading Illuminatus! at least once a year, just to keep my head on straight. Any time I started taking life too seriously, that trilogy was the fix.
Those weren't ENVIRONMENTALISTS. Those were the spokespeople for the uber-wealthy who would suffer with those horrible windmills cluttering their view of the bay! The "environmental" arguments made came from professional PR organizations they hired to manipulate people like, well, you.
Interestingly, there's a Republican politician in Kansas named Moran (who just decided to not run for governor). Considering that the Kansas GOP has been taken over by far-right fundamentalist wackos who are trying to replace evolution with Creationism in (what should no longer be called) "science" textbooks, the name Moran is altogether too appropriate.
You know what's weird? Rocks falling from the sky. Obviously, rocks can't fall from the sky, because there are no rocks in the sky. Therefore, any claims that rocks fall from the sky are unscientific nonsense.
As Charles Fort points out, that was the unanimous opinion of the scientific community through most of the 19th century, and their explanation for meteorites.
Of course, ice doesn't fall from the sky. That's impossible, because there is no ice in the sky. Keep telling yourself that.
The idea of a musical sci-fi/fantasy tv show isn't that new... check out "The Bitter Suite" episode of Xena (which was also really good).
Personally, i thought there were better individual episodes of Buffy this year than "Once More, with Feeling". The writing was okay, but it was hampered by the fact that only about half the cast could really sing, and that half doesn't include SMG. How come Tara and Giles got so much airtime in an episode not about them, and Willow was virtually offscreen? Balance of talent.
My last day on my first real programming job... hoping to spend it saying goodbye to my friends. But noooo...
Quick bug summary... there was a BLOB column in a Sybase table, a legacy from some code changes i had done that summer. But nothing was being written to that BLOB, so it shouldn't take any memory, right? Right? Well. The system was a batch workflow that moved a LOT of data. First day of a production run was my last day of work. The system started, and the database started filling - fast.
Turned out that some ancient library that predated me initialized the BLOB field with 0, not NULL. This caused Sybase to allocate a page (4096 bytes) for the BLOB field. Ouch!
At least i found the bug before the entire system came to a grinding halt... but it pretty much ruined my last day there.
I don't know if he counted them, but yes, there were many one-sided wars through the 19th and 20th centuries. All it requires is a vast technological difference between one side and the other. Good old-fashioned imperialist subjugation of Africa, Asia, and the Americas largely consisted of one-sided slaughters, usually those with guns and horses versus those without.
Have you purchased any content, say some popular music, that was readily available for bootleg online? If you're still purchasing and online bootlegging gets even easier, would you stop purchasing and start bootlegging?
Now, do you think the vast, vast majority of consumers would steal their content rather than pay for it, assuming the content they wanted was readily available at a reasonable price? Or do you share Hilary Rosen's view that most consumers are thieves who will steal anything that isn't nailed down? (takes one to know one, i say)
If, like me, you believe that most people would prefer legitimately purchased content *if it is readily available, reasonably priced, and allows fair use*, then your whole argument falls apart. Consumers WILL pay for online content. The problem is that the industry currently refuses to allow them to buy online content in a real way.
A friend of mine once said that if we had the Congress 100 years ago that we do today, we'd have subsidies for buggy whips.
The way to fix the problem isn't surveillance or legislation; the real solution is to adapt the marketing model to price the music/movies whatever low enough that that the financial benefit of bootlegging doesn't exceed the moral benefit of legitimate copies. This is perfectly doable, given the exceedingly low cost of online distribution.
Two points - first, the music industry works by their oligopoly on the distribution of physical media and store shelf space. THAT is what they don't want to give up, because then their role as middleman becomes irrelevant.
Second, i'd feel a lot more moral inclination to avoid bootlegging if music artists saw even a dime for every dollar their label makes off their art.
The plain and simple truth is that the vast majority of working, professional musicians are NOT part of the major label system. In fact, it's very difficult to make a living at music once you're signed your soul over in blood to the labels. This legislation is NOT FOR THE ARTISTS. It is for the record distributors.
The movie industry is different, but only slightly. VCRs were supposed to destroy their industry, but instead it became a huge boon. Most people watch most movies only once or twice, so they need to keep the per-view cost down, period. They've already solved their distribution problem, unlike the RIAA.
Think about it... do you really believe this legislation is to protect ARTISTS? Or, gawd forbid, consumers? No, it's their to keep a couple of fat industry's reality checks from bouncing for a few more years.
I say we let the Invisible Hand of the market slap some sense into them.
Have you read the XP books yet? Meeting client expectations is first and foremost of the XP processes. Does RUP or any other methodology recommend having an on-site customer that the programmers can talk to at any time? XP does. The "release early, release often" approach gives the customer critical feedback into the development process, and short iterations plus the story mechanism keep the pace of development under control.
I have no doubt that projects that just start coding with no design AND no XP techniques have high failure rates. They have no way to fix anything! The beauty of XP is that, by constantly refactoring the code, there is very little to fix, and you're not afraid to fix it when something needs fixed. That's where unit tests and continuous integration come in. Since i started using XP techniques (not full XP, unfortunately), i've never been "slapped around" by refactoring or something i missed. I've never spent more than a half hour refactoring anything to get it working again, because i had my unit tests to guide me.
I also don't think XP is anti-design. It's just anti-BDUF (Big Design Up Front). Keep a general architecture in your head, but do the smallest bits you possibly can, and make them work. I do design sessions all the time. A half hour in the cafeteria with some paper, or a whiteboard, and i have a healthy day's programming ahead of me. Yes, i make mistakes. I'd have made those same mistakes if i spent months designing up front. Except now i can *fix* mistakes in rational time.
I don't think XP is competing with RUP and other iterative methodologies so much as waterfall design and the Ball of Mud antipattern. Unfortunately, the latter two are the primary design methodologies of 95% of the industry.
I got news for you... in most cases, some failure and loss IS acceptable. Not all of us are writing software for the space shuttle. I'll bet you aren't, either. In most cases, what we're worrying about is getting something done, on time and under budget, that has at least moderate congruence to end user requirements. And in most cases, those requirements are a moving target.
The techniques of XP are incredibly useful in the world many of us have to work in. They work and produce tangible results.
As for the whole "software built like a bridge" crap... there's a bridge over the Mississippi near where i live. It causes traffic backups in both directions every day because it doesn't scale. They're planning on fixing it... it will take six years, cost millions of dollars, and make traffic even worse during that time. Does this sound like a software project to you?
If you have a working unit testing mechanism, then JUnit doesn't have much of an advantage. The best thing it has going for it is standardization... it's what most people who are bothering to actually test their code (i pity the poor fools who think they are too busy coding to prove that their code actually works) use. That means it gets integrated into just about any open source Java tools - Ant, NetBeans, etc. You can integrate yours too, but it's work and maintenance.
Sorry, but that's a TERRIBLE idea. Things will always happen out of order. The best baseline is a fresh cvs checkout. Programmers are responsible for not checking things in until they know it doesn't break anything. How do they know it doesn't break anything? All the tests pass. Where do the tests come from? (Wahwahwah, we're too busy coding to write tests!) You write tests BEFORE you write code. When you write the test, it's broken. Then you fix it. It works.
Another useful Extreme Programming idea is "stories". Programmers work on problems small enough that they can fit on a notecard. If it won't fit on a notecard, break it into smaller problems that will. Pretty soon, you have a huge stack of "stories". Sit down with your customer and triage them. Release early, release often, and the code is ALWAYS correct. Or at least all the tests run, which is more than can be said for 99% of all the code out there.
Check out the development techniques of Extreme Programming (just search Google, silly, and buy a book or three). They have a real solid handle on concurrent rapid development.
The real heart of Extreme Programming is "test-first" programming. The entire development process revolves around unit and integration tests, for extremely fine-grained control over code quality. Any changes that might impact other code should break a test. You fix the stuff that breaks, check in your changes, and move on.
Multiple programmers touching the same C files many times a day sounds like you have either design issues, structural issues, or both. That just should not happen, crunch time or not. Heck, crunch shouldn't happen if you're managing your development correctly.
If you're using cvs, conflicts with source checkins should be very easy to resolve. Even if two programmers touch the same file, they shouldn't be in the same function. If they are, you're back to management and architecture problems, and you need to fix those NOW before work grinds to a complete halt.
Oh, i like pointers. I like high-powered handguns too, but i wouldn't use them to settle ALL my social problems! Pointers are fantastic where precise memory control is required. Precise memory control is NEVER required, except for systems programming. Something like the Linux kernel should absolutely be written in C. Something like the typical business app has no business whatsoever using C. And yes, C is the mother tongue. Any professional programmer that doesn't at least understand it is severely ignorant, even if they never use it.
I wouldn't even say VB is for dabblers. I'd say it's for morons, and the poor victims who are forced to use that wretched excuse for a language. The only decent part at all is the IDE, and there are better ones.
I don't even think much about the language anymore... my programming these days is abstracted away at the problem and architecture level, and the language is just a side point, as it should be. That's why i want my language to get in the way as little as possible. C often gets in the way, due to its crude libraries. I find Java, Python, Perl, SQL, and Unix shell to be my languages of choice.
Why flamebait, when you can throw fresh chum with no nasty hooks in it?:}
"From what I've seen, Java sucks". Does this mean you've never actually programmed in it?
ALL high-level computer languages, even C, are "hand holding". That's the point! I want my language to make my life easier by hiding the gory details, and i will use the highest-level language that can possibly work well for whatever i'm doing. In many cases, that will be Java.
If you want language-bashing, C++ is a horror. Someone please tell them that you can't solve every problem by adding a new keyword. And if you want to bring up yacc (and by extension, LALR parsing), Java is as clean as C. C itself isn't pure here... try this statement: 'if(a) if (b) something(); else something_else();' Legal C, with a shift-reduce conflict. Does the else apply to if(a), or if(b)? You DID read about LALR parsing in detail, didn't you? But that pales in comparison to C++, which simply cannot be parsed without dynamic type information in the parser. See Knuth's one-line crushing criticism of in in DDJ a few years back. But i digress.
Counting books on the shelf for a language is NO measure of its success, because most computer books are crap. The bad ones are dying off. I keep exactly two C books on my shelf - K&R and Plauger. Does this mean C is dying? No, it means those two books are so effective i don't need anything else.
As for VB... it's not a language for programmers who need hand-holding, because it's saddled with that horrible BASIC grammar that will do nothing but get in their way. If you want a language for beginners, check out Python. The worst thing about using it for a student language is that the students will be grossed out the moment they have to learn a bloated monster like C++ or Perl (not knocking Perl, it's my favorite language, but Python is better).
Java reminds me a lot of Unix... it's not perfect by any stretch, but it's so dang good that there is little point in trying to do better. Its utility as a lingua franca outweighs its minor shortcomings. The nicest thing i can say about Java is that i hardly ever come up against limitations of the language itself - if i have a language-level problem in Java, it is usually due to my own ignorance, especially ignorance of its excellent libraries.
Heh. I even own a copy of Dan Hillis' PhD thesis, and wrote papers on fault-tolerant algorithms for hypercube architectures. Fascinating design. It was able to efficiently address graphing problems (not graphics, GRAPHING, you Slashdot ninnies!) that couldn't really be done well on a Von Neumann load-store architecture - it was one of the few real alternatives to the dominant mode of thought.
Unfortunately, elegance often dies in the face of brute force, and Moore's Law, along with the lousy economics of the supercomputer industry, did them in. But before they died, they were working on running the Connection Machine model on a network of Sun workstations, rather than the custom dedicated hardware. Considering how easy it is to model a Connection Machine, and how easily the model scales, it made sense.
Same problem i've been trying to explain in the end... not useful for enough problems to be a general-purpose solution.
Frankly, "high latencies and frequent failures" are why such an idea is impractical, regardless of whether or not the theoretical problems can be solved (and i argue that they already have been solved).
Massive distribution should not and will not be done just because it's techno-cool... it has to produce real value. What sort of real value can it produce? That depends on what sort of problems it can solve.
First, let's look at constraints. The three obvious ones are CPU power, disk space, and network bandwidth. All three of these have been growing relatively in proportion to Moore's Law for the last couple of decades. Their relative proportions have not shifted much... the CPU is by far the fastest, followed by local disk, and then network bandwidth.
Now, let's look at the problems we want to solve. How about data storage ("Jane's computer has an encrypted fragment of someone else's movie")? Local disk space is far, far cheaper and more robust than network storage! Bandwidth is the most expensive part of the equation. I can buy another few dozen gig of disk space for $100. How long will it take to transmit a few dozen gig via DSL? Sure, network speed will scale up, but so will disk space. Unless something changes, the balance of the equation remains the same... local storage is cheaper then network, as well as more reliable.
Of course, not all files you want will be on your computer, hence peer-to-peer file sharing, which is what Microsoft is trying to solve. But in this case, local disk storage is far slower than CPU, and far faster than network... in other words, there is no reason to not use a user-level process to manage the data exchange. No OS support is necessary beyond TCP/IP and disk I/O, right? This problem has already been solved in numerous real-world ways.
Now let's look at CPU-bound problems. There are computations we may want to make that can't be done in a fraction of a second locally. These are generally math problems, sometimes with large datasets. Some of these problems can be parallelized, and some cannot. Of those that can be parallelized, some have coarse granularity, and some have fine granularity. Coarse problems, like keyspace searches for brute-force encryption cracking or SETI pattern searches, don't need OS-level support - data is most efficiently shared at the process level, which is what distributed.net and SETI do already. Others optimize at finer granularity. In those cases, data sharing and communication requirements between threads are so intense that using a slow, unreliable network is impractical! That's what big parallel supercomputers are for. So there's no need for OS-level support for parallelized number crunching that is practical in the current CPU/bandwidth ratio.
So what problem are we trying to solve that is distributed (or distributable) efficiently across multiple computers, and requires OS-level support for optimum efficiency? I don't see it.
Now, i should revise my previous statement that no one uses OS-level distributed computing. Fault tolerant databases, clusters, and massively parallel supercomputers all use it - at the local level. And even those are butting up against the network bandwidth problem. If it can't be done with gigabit connections on the backplane, how will it be done over a modem?
"If so, EH? about VMS clusters - they're hardly ignored, they're in use wherever VAXen are still in use."
Wherever VAXen are still in use? You make my case for me.:} I can count on one hand all the VAX/VMS professionals i know these days. They're outnumbered a hundred to one by mainframe admins, much less Unix or Windows people.
Massively distributed operating systems have been around for years... check out Tannenbaum's work on Amoeba. Does anyone use Amoeba? No.
This is two days in a row now that Slashdot has posted articles on the great new idea of distributed operating systems that CS theorists solved and have largely ignored for the last ten years. Besides Amoeba, there was the Connection Machine, VMS clusters, and others.
The fact is, massive distribution is of VERY limited use, and doesn't require OS-level hooks - Napster and distributed.net are both prime examples of useful massive distribution without involving the OS at all.
Rather than looking for a buzzword-compliant language, might i STRONGLY suggest that you read "The Pragmatic Programmer", by Andrew Hunt and David Thomas? The clear, solid, *useful* ideas in that book will maybe, just maybe, cure you of your faith in buzzwords - or at least your willingness to blindly march over the cliff your PHB just sent you to investigate.
Language features will not in and of themselves make for a successful programming project. I'd argue that they're merely a convenience for good programmers, and often and impediment for poor ones.
That being said, look at a multi-language approach to development - an interpreted scripting language (Python, Perl, VB(ewww)) mixed with a stricter compiled language (Java, C++(ewww)). And don't forget SQL, which is a respectable language unto itself, and very important if your project involves a database.
Good luck, and may the God Murphy Goddess Eris have mercy on your soul.
There's an old joke about how Apple products are developed by a committee consisting of a genius and and idiot. Personally, i've decided that Apple is managed by a committee consisting of a genius and an idiot, and the committee's name is Steve Jobs.:}
On most modern PCs, the BIOS is flashable. The control chips on the IDE drives are flashable. The CPU has flashable instructions. These are all there to deliver upgrades in case of a bug.
Now, imagine a virus that destroys the IDE control chips on each drive (no accessing the data again, short of mechanically removing the platters), destroys the BIOS (no booting again short of physical replacement of the BIOS chip), and destroys the CPU (instructions are broken, starting with the ability to update the instructions).
Cross this with Warhol propogation techniques. While you're at it, delay the payload long enough to maximize propogation rates, but not long enough to allow antiviral reaction.
This could lead to *hardware kill rates* on the order of 10%-50% (or more) of the computers on the Internet. None of those computers would ever work again, and data stored on them could not be easily recovered.
All of this is doable from publicly documented information, crossed with the Microsoft wormhole-of-the-week.
Slashdot Mirror
Did you know that Cuba has a lower infant mortality rate than the United States?
I didn't think so.
And you tell me the conspiracy theory wasn't believable?
Heck, you didn't make it past the INTRODUCTION. You couldn't have even met all the major player characters that far in. You have NO IDEA how utterly flabbergasting it got.
For many years, I made a point of reading Illuminatus! at least once a year, just to keep my head on straight. Any time I started taking life too seriously, that trilogy was the fix.
Those weren't ENVIRONMENTALISTS. Those were the spokespeople for the uber-wealthy who would suffer with those horrible windmills cluttering their view of the bay! The "environmental" arguments made came from professional PR organizations they hired to manipulate people like, well, you.
Interestingly, there's a Republican politician in Kansas named Moran (who just decided to not run for governor). Considering that the Kansas GOP has been taken over by far-right fundamentalist wackos who are trying to replace evolution with Creationism in (what should no longer be called) "science" textbooks, the name Moran is altogether too appropriate.
I just wanted to say that was a really great, well-written and informative article. Thanks!
You know what's weird? Rocks falling from the sky. Obviously, rocks can't fall from the sky, because there are no rocks in the sky. Therefore, any claims that rocks fall from the sky are unscientific nonsense.
As Charles Fort points out, that was the unanimous opinion of the scientific community through most of the 19th century, and their explanation for meteorites.
Of course, ice doesn't fall from the sky. That's impossible, because there is no ice in the sky. Keep telling yourself that.
The idea of a musical sci-fi/fantasy tv show isn't that new... check out "The Bitter Suite" episode of Xena (which was also really good).
Personally, i thought there were better individual episodes of Buffy this year than "Once More, with Feeling". The writing was okay, but it was hampered by the fact that only about half the cast could really sing, and that half doesn't include SMG. How come Tara and Giles got so much airtime in an episode not about them, and Willow was virtually offscreen? Balance of talent.
My last day on my first real programming job... hoping to spend it saying goodbye to my friends. But noooo...
Quick bug summary... there was a BLOB column in a Sybase table, a legacy from some code changes i had done that summer. But nothing was being written to that BLOB, so it shouldn't take any memory, right? Right? Well. The system was a batch workflow that moved a LOT of data. First day of a production run was my last day of work. The system started, and the database started filling - fast.
Turned out that some ancient library that predated me initialized the BLOB field with 0, not NULL. This caused Sybase to allocate a page (4096 bytes) for the BLOB field. Ouch!
At least i found the bug before the entire system came to a grinding halt... but it pretty much ruined my last day there.
I don't know if he counted them, but yes, there were many one-sided wars through the 19th and 20th centuries. All it requires is a vast technological difference between one side and the other. Good old-fashioned imperialist subjugation of Africa, Asia, and the Americas largely consisted of one-sided slaughters, usually those with guns and horses versus those without.
Have you purchased any content, say some popular music, that was readily available for bootleg online? If you're still purchasing and online bootlegging gets even easier, would you stop purchasing and start bootlegging?
Now, do you think the vast, vast majority of consumers would steal their content rather than pay for it, assuming the content they wanted was readily available at a reasonable price? Or do you share Hilary Rosen's view that most consumers are thieves who will steal anything that isn't nailed down? (takes one to know one, i say)
If, like me, you believe that most people would prefer legitimately purchased content *if it is readily available, reasonably priced, and allows fair use*, then your whole argument falls apart. Consumers WILL pay for online content. The problem is that the industry currently refuses to allow them to buy online content in a real way.
A friend of mine once said that if we had the Congress 100 years ago that we do today, we'd have subsidies for buggy whips.
The way to fix the problem isn't surveillance or legislation; the real solution is to adapt the marketing model to price the music/movies whatever low enough that that the financial benefit of bootlegging doesn't exceed the moral benefit of legitimate copies. This is perfectly doable, given the exceedingly low cost of online distribution.
Two points - first, the music industry works by their oligopoly on the distribution of physical media and store shelf space. THAT is what they don't want to give up, because then their role as middleman becomes irrelevant.
Second, i'd feel a lot more moral inclination to avoid bootlegging if music artists saw even a dime for every dollar their label makes off their art.
The plain and simple truth is that the vast majority of working, professional musicians are NOT part of the major label system. In fact, it's very difficult to make a living at music once you're signed your soul over in blood to the labels. This legislation is NOT FOR THE ARTISTS. It is for the record distributors.
The movie industry is different, but only slightly. VCRs were supposed to destroy their industry, but instead it became a huge boon. Most people watch most movies only once or twice, so they need to keep the per-view cost down, period. They've already solved their distribution problem, unlike the RIAA.
Think about it... do you really believe this legislation is to protect ARTISTS? Or, gawd forbid, consumers? No, it's their to keep a couple of fat industry's reality checks from bouncing for a few more years.
I say we let the Invisible Hand of the market slap some sense into them.
Have you read the XP books yet? Meeting client expectations is first and foremost of the XP processes. Does RUP or any other methodology recommend having an on-site customer that the programmers can talk to at any time? XP does. The "release early, release often" approach gives the customer critical feedback into the development process, and short iterations plus the story mechanism keep the pace of development under control.
I have no doubt that projects that just start coding with no design AND no XP techniques have high failure rates. They have no way to fix anything! The beauty of XP is that, by constantly refactoring the code, there is very little to fix, and you're not afraid to fix it when something needs fixed. That's where unit tests and continuous integration come in. Since i started using XP techniques (not full XP, unfortunately), i've never been "slapped around" by refactoring or something i missed. I've never spent more than a half hour refactoring anything to get it working again, because i had my unit tests to guide me.
I also don't think XP is anti-design. It's just anti-BDUF (Big Design Up Front). Keep a general architecture in your head, but do the smallest bits you possibly can, and make them work. I do design sessions all the time. A half hour in the cafeteria with some paper, or a whiteboard, and i have a healthy day's programming ahead of me. Yes, i make mistakes. I'd have made those same mistakes if i spent months designing up front. Except now i can *fix* mistakes in rational time.
I don't think XP is competing with RUP and other iterative methodologies so much as waterfall design and the Ball of Mud antipattern. Unfortunately, the latter two are the primary design methodologies of 95% of the industry.
I got news for you... in most cases, some failure and loss IS acceptable. Not all of us are writing software for the space shuttle. I'll bet you aren't, either. In most cases, what we're worrying about is getting something done, on time and under budget, that has at least moderate congruence to end user requirements. And in most cases, those requirements are a moving target.
The techniques of XP are incredibly useful in the world many of us have to work in. They work and produce tangible results.
As for the whole "software built like a bridge" crap... there's a bridge over the Mississippi near where i live. It causes traffic backups in both directions every day because it doesn't scale. They're planning on fixing it... it will take six years, cost millions of dollars, and make traffic even worse during that time. Does this sound like a software project to you?
If you have a working unit testing mechanism, then JUnit doesn't have much of an advantage. The best thing it has going for it is standardization... it's what most people who are bothering to actually test their code (i pity the poor fools who think they are too busy coding to prove that their code actually works) use. That means it gets integrated into just about any open source Java tools - Ant, NetBeans, etc. You can integrate yours too, but it's work and maintenance.
Sorry, but that's a TERRIBLE idea. Things will always happen out of order. The best baseline is a fresh cvs checkout. Programmers are responsible for not checking things in until they know it doesn't break anything. How do they know it doesn't break anything? All the tests pass. Where do the tests come from? (Wahwahwah, we're too busy coding to write tests!) You write tests BEFORE you write code. When you write the test, it's broken. Then you fix it. It works.
Another useful Extreme Programming idea is "stories". Programmers work on problems small enough that they can fit on a notecard. If it won't fit on a notecard, break it into smaller problems that will. Pretty soon, you have a huge stack of "stories". Sit down with your customer and triage them. Release early, release often, and the code is ALWAYS correct. Or at least all the tests run, which is more than can be said for 99% of all the code out there.
Check out the development techniques of Extreme Programming (just search Google, silly, and buy a book or three). They have a real solid handle on concurrent rapid development.
The real heart of Extreme Programming is "test-first" programming. The entire development process revolves around unit and integration tests, for extremely fine-grained control over code quality. Any changes that might impact other code should break a test. You fix the stuff that breaks, check in your changes, and move on.
Multiple programmers touching the same C files many times a day sounds like you have either design issues, structural issues, or both. That just should not happen, crunch time or not. Heck, crunch shouldn't happen if you're managing your development correctly.
If you're using cvs, conflicts with source checkins should be very easy to resolve. Even if two programmers touch the same file, they shouldn't be in the same function. If they are, you're back to management and architecture problems, and you need to fix those NOW before work grinds to a complete halt.
Oh, i like pointers. I like high-powered handguns too, but i wouldn't use them to settle ALL my social problems! Pointers are fantastic where precise memory control is required. Precise memory control is NEVER required, except for systems programming. Something like the Linux kernel should absolutely be written in C. Something like the typical business app has no business whatsoever using C. And yes, C is the mother tongue. Any professional programmer that doesn't at least understand it is severely ignorant, even if they never use it.
I wouldn't even say VB is for dabblers. I'd say it's for morons, and the poor victims who are forced to use that wretched excuse for a language. The only decent part at all is the IDE, and there are better ones.
I don't even think much about the language anymore... my programming these days is abstracted away at the problem and architecture level, and the language is just a side point, as it should be. That's why i want my language to get in the way as little as possible. C often gets in the way, due to its crude libraries. I find Java, Python, Perl, SQL, and Unix shell to be my languages of choice.
Why flamebait, when you can throw fresh chum with no nasty hooks in it? :}
"From what I've seen, Java sucks". Does this mean you've never actually programmed in it?
ALL high-level computer languages, even C, are "hand holding". That's the point! I want my language to make my life easier by hiding the gory details, and i will use the highest-level language that can possibly work well for whatever i'm doing. In many cases, that will be Java.
If you want language-bashing, C++ is a horror. Someone please tell them that you can't solve every problem by adding a new keyword. And if you want to bring up yacc (and by extension, LALR parsing), Java is as clean as C. C itself isn't pure here... try this statement: 'if(a) if (b) something(); else something_else();' Legal C, with a shift-reduce conflict. Does the else apply to if(a), or if(b)? You DID read about LALR parsing in detail, didn't you? But that pales in comparison to C++, which simply cannot be parsed without dynamic type information in the parser. See Knuth's one-line crushing criticism of in in DDJ a few years back. But i digress.
Counting books on the shelf for a language is NO measure of its success, because most computer books are crap. The bad ones are dying off. I keep exactly two C books on my shelf - K&R and Plauger. Does this mean C is dying? No, it means those two books are so effective i don't need anything else.
As for VB... it's not a language for programmers who need hand-holding, because it's saddled with that horrible BASIC grammar that will do nothing but get in their way. If you want a language for beginners, check out Python. The worst thing about using it for a student language is that the students will be grossed out the moment they have to learn a bloated monster like C++ or Perl (not knocking Perl, it's my favorite language, but Python is better).
Java reminds me a lot of Unix... it's not perfect by any stretch, but it's so dang good that there is little point in trying to do better. Its utility as a lingua franca outweighs its minor shortcomings. The nicest thing i can say about Java is that i hardly ever come up against limitations of the language itself - if i have a language-level problem in Java, it is usually due to my own ignorance, especially ignorance of its excellent libraries.
Okay, i'll stop now.
Heh. I even own a copy of Dan Hillis' PhD thesis, and wrote papers on fault-tolerant algorithms for hypercube architectures. Fascinating design. It was able to efficiently address graphing problems (not graphics, GRAPHING, you Slashdot ninnies!) that couldn't really be done well on a Von Neumann load-store architecture - it was one of the few real alternatives to the dominant mode of thought.
Unfortunately, elegance often dies in the face of brute force, and Moore's Law, along with the lousy economics of the supercomputer industry, did them in. But before they died, they were working on running the Connection Machine model on a network of Sun workstations, rather than the custom dedicated hardware. Considering how easy it is to model a Connection Machine, and how easily the model scales, it made sense.
Same problem i've been trying to explain in the end... not useful for enough problems to be a general-purpose solution.
Frankly, "high latencies and frequent failures" are why such an idea is impractical, regardless of whether or not the theoretical problems can be solved (and i argue that they already have been solved).
Massive distribution should not and will not be done just because it's techno-cool... it has to produce real value. What sort of real value can it produce? That depends on what sort of problems it can solve.
First, let's look at constraints. The three obvious ones are CPU power, disk space, and network bandwidth. All three of these have been growing relatively in proportion to Moore's Law for the last couple of decades. Their relative proportions have not shifted much... the CPU is by far the fastest, followed by local disk, and then network bandwidth.
Now, let's look at the problems we want to solve. How about data storage ("Jane's computer has an encrypted fragment of someone else's movie")? Local disk space is far, far cheaper and more robust than network storage! Bandwidth is the most expensive part of the equation. I can buy another few dozen gig of disk space for $100. How long will it take to transmit a few dozen gig via DSL? Sure, network speed will scale up, but so will disk space. Unless something changes, the balance of the equation remains the same... local storage is cheaper then network, as well as more reliable.
Of course, not all files you want will be on your computer, hence peer-to-peer file sharing, which is what Microsoft is trying to solve. But in this case, local disk storage is far slower than CPU, and far faster than network... in other words, there is no reason to not use a user-level process to manage the data exchange. No OS support is necessary beyond TCP/IP and disk I/O, right? This problem has already been solved in numerous real-world ways.
Now let's look at CPU-bound problems. There are computations we may want to make that can't be done in a fraction of a second locally. These are generally math problems, sometimes with large datasets. Some of these problems can be parallelized, and some cannot. Of those that can be parallelized, some have coarse granularity, and some have fine granularity. Coarse problems, like keyspace searches for brute-force encryption cracking or SETI pattern searches, don't need OS-level support - data is most efficiently shared at the process level, which is what distributed.net and SETI do already. Others optimize at finer granularity. In those cases, data sharing and communication requirements between threads are so intense that using a slow, unreliable network is impractical! That's what big parallel supercomputers are for. So there's no need for OS-level support for parallelized number crunching that is practical in the current CPU/bandwidth ratio.
So what problem are we trying to solve that is distributed (or distributable) efficiently across multiple computers, and requires OS-level support for optimum efficiency? I don't see it.
Now, i should revise my previous statement that no one uses OS-level distributed computing. Fault tolerant databases, clusters, and massively parallel supercomputers all use it - at the local level. And even those are butting up against the network bandwidth problem. If it can't be done with gigabit connections on the backplane, how will it be done over a modem?
"If so, EH? about VMS clusters - they're hardly ignored, they're in use wherever VAXen are still in use."
:} I can count on one hand all the VAX/VMS professionals i know these days. They're outnumbered a hundred to one by mainframe admins, much less Unix or Windows people.
Wherever VAXen are still in use? You make my case for me.
Massively distributed operating systems have been around for years... check out Tannenbaum's work on Amoeba. Does anyone use Amoeba? No.
This is two days in a row now that Slashdot has posted articles on the great new idea of distributed operating systems that CS theorists solved and have largely ignored for the last ten years. Besides Amoeba, there was the Connection Machine, VMS clusters, and others.
The fact is, massive distribution is of VERY limited use, and doesn't require OS-level hooks - Napster and distributed.net are both prime examples of useful massive distribution without involving the OS at all.
Rather than looking for a buzzword-compliant language, might i STRONGLY suggest that you read "The Pragmatic Programmer", by Andrew Hunt and David Thomas? The clear, solid, *useful* ideas in that book will maybe, just maybe, cure you of your faith in buzzwords - or at least your willingness to blindly march over the cliff your PHB just sent you to investigate.
Language features will not in and of themselves make for a successful programming project. I'd argue that they're merely a convenience for good programmers, and often and impediment for poor ones.
That being said, look at a multi-language approach to development - an interpreted scripting language (Python, Perl, VB(ewww)) mixed with a stricter compiled language (Java, C++(ewww)). And don't forget SQL, which is a respectable language unto itself, and very important if your project involves a database.
Good luck, and may the God Murphy Goddess Eris have mercy on your soul.
There's an old joke about how Apple products are developed by a committee consisting of a genius and and idiot. Personally, i've decided that Apple is managed by a committee consisting of a genius and an idiot, and the committee's name is Steve Jobs. :}
On most modern PCs, the BIOS is flashable. The control chips on the IDE drives are flashable. The CPU has flashable instructions. These are all there to deliver upgrades in case of a bug.
Now, imagine a virus that destroys the IDE control chips on each drive (no accessing the data again, short of mechanically removing the platters), destroys the BIOS (no booting again short of physical replacement of the BIOS chip), and destroys the CPU (instructions are broken, starting with the ability to update the instructions).
Cross this with Warhol propogation techniques. While you're at it, delay the payload long enough to maximize propogation rates, but not long enough to allow antiviral reaction.
This could lead to *hardware kill rates* on the order of 10%-50% (or more) of the computers on the Internet. None of those computers would ever work again, and data stored on them could not be easily recovered.
All of this is doable from publicly documented information, crossed with the Microsoft wormhole-of-the-week.
Are you frightened? I am.