The reason that Linux 2.4.x systems get into swap when running XMMS is because they read from the disk a lot, and they only need the page they read once.
That shouldn't be a problem. Effective methods of recognizing and/or dealing with this sort of process-doing-sequential-I/O problem have been well known for the better part of a decade. After the first few accesses, XMMS's activity shouldn't be polluting the rest of the page cache with no-longer-wanted pages.
Rik's VM is going to push *all* other processes out of memory in order to cache all of those disk pages that nobody ever wants to see again.
That would be totally inane, if it were true. I don't think it is, but I have to admit I haven't actually looked into that particular aspect. God, I hope you're wrong.
Rik the megalomaniac is never going to fix it because he's convinced that his system is the best thing that can be acheived by human beings
OK, Rik has pissed me off with his defensiveness and general attitude lately, but I still think that's unfair. Despite its warts, there are also some good reasons not to go making major architecture-level changes to the VM system at this stage in 2.4 development. If a strong enough case can be made that something is actually broken - not just subject to improvement - and that the proposed fix will do no harm or invalidate the testing that has already occurred, I'm sure Rik and the others would listen.
He should get together and have a beer with Hans Reiser.
I've been in the room with both of them and a bottle of liquor. They've had their opportunity to just that, though I can't quite recall whether they took advantage of it. Must've been because I was drinking too.;-)
Oops, that last paragraph was in response to an accidentally-omitted blockquote. "Possibly not" was in response to "Really I don't think we're disagreeing".
Yes, you are, you're just not overcommitted - which is sorta "out of memory, and then some". The whole point is to stop selling tickets when all the seats are full, instead of selling more tickets than you have seats and then shooting someone in the head to make room when everyone with a ticket actually does show up.
OK, maybe that metaphor's a little bit too colorful, but you get the idea.
Possibly not, except that if these mechanisms had been in place sooner there would never have been a (perceived) need for an OOM killer at all...and I think that would have been a good thing. In any case, it has been nice talking to you.
For the existing processes to continue they would need to be able to keep working without allocating any memory. That's feasible on a real-time OS, but on a general purpose OS at least some of the processes are going to become useless
No, it's entirely feasible and has been done in general-purpose OSes. If every process has adequate paging space as it should, and there's also an emergency reserve as there should be, then you can be smart about how you apply that emergency reserve and avoid having the system lock up. It's actually a generalization of the policy decision that the OOM killer makes, in that you have choices between "allowed to survive" and "killed". In a degenerate case you could get behavior very similar to what the OOM killer gives you, with certain "victim" processes starving instead of being killed, but you can also do much better because of the additional flexibility.
Preventing new processes from starting is very bad. It means you can't, for example, start a new console session in order to administer (and hopefully save) the system
Again, this is where emergency reserves and policy-based mechanisms come into play. Some filesystems on Linux have space reserved only for root; the same can be done for paging space. Nobody has to die in order that root may live.
So you would rather your box locked up if it happened to run out of memory? I know I sure wouldn't.
Neither would I. I'd prefer that the condition be prevented than that it be allowed and then handled so stupidly.
Or do you throw out every code idea you have the moment you discover a bug in it?
That's totally uncalled-for. I've been a developer for over a decade, and a significant portion of that time has been spent fixing bugs in my own and other people's code - including VM-system bugs (no, not in Linux). I know the value of leveraging existing code - which is what makes me wonder why the Linux crew reinvented yet another wheel in this case instead of taking the opportunity to adapt and improve on existing tried-and-true approaches. The Linux VM system as it exists today bears all the hallmarks of code written by people who didn't find out what they were getting into before they started.
Sun disagrees with you too - Solaris has an OOM killer...
Someone at Sun might have thought it was a good idea, but I know other people at Sun who realize it stinks. BTW, do you really think Solaris is that exemplary an OS?
If your system is out of memory (totally out - no RAM, so Swap) then stuff will fail. That's true on any system
That is untrue. There is no need for any existing process to die in an OOM condition, although it may be necessary to prevent new processes from being spawned. The problem that the OOM killer tries to address is exhaustion of paging space by a rogue process, but that can be handled adequately by higher-level policy means (e.g. per-process limits, applying quota to paging space). Rejecting the policy-based approach in favor of warping the entire VM system's page-replacement strategy is IMO a mistake of the first magnitude. Contrary to what you imply, most other systems get by just fine without an OOM killer; many of them - but notably not including any flavor of NT - behave much more gracefully under memory pressure than Linux does.
Before you attempt to lecture me on how VM systems work, I should point out that I was at one time the go-to guy for a VM system more sophisticated than Linux's on one of the earlier SMP UNIXes (Encore's UMAX V). I do know how these things work, and that is why I make the claims that I do. The OOM killer does deserve to be killed.
Don't be an ass. Things like "VM/shmem" cleanups" (pre13) and "sysctl/VM documentation" (pre8) don't give any indication of serious changes to how the VM subsystem actually works. Similarly "VM race fix" (pre12) could as easily refer to something that has been in there for a year as to something that was introduced recently. Aside from those, there is still exactly one hint that anything major occurred - "major VM merge" in pre11. That phrase is still pretty darn vague; "major" could still refer to a bunch of fixes that merely required lots of lines without really changing anything deep. I already 'fessed up to the error, which was a simple honest mistake, so I'm not going to take any more gratuitous crap from karma whores about it.
I did read it, but I confess that I missed that one entry. I expected that if there were significant VM changes we'd see a whole list of entries like "fixed XXX bogosity from previous VM changes" instead of a single line.
Separation of presentation and logic is good; what if the presentation is non-trivial? Do you want a server getting bogged down sending low-level instructions or generated images to clients? Do you want all presentation methods hard-coded into clients? Or might it be better to provide a way to specify complex presentation to clients, which is what Java does?
Of course you can't guarantee performance on other people's hardware, but that's their problem. Making it your problem by assuming all of the load is just stupid. Equipment and bandwidth budgets are finite - a lesson learned to late by many other dot-bombs. If you only have X hardware and Y bandwidth, you can use client resources - via mobile code or otherwise - to serve more users than you can with the totally server-centric approach you suggest.
Mobile code doesn't solve all problems, and it does create a few, but it's still a valuable part of the toolbox. If your control issues still prevent you from accepting that, see a therapist.
In addition, if one of those other/.ers on you block decided to read up on the latest nerd news his local machine wouldn't have to go very far to get it.. thus reducing the latency. You'd end up with your block being your very own slashdot server with the people who access it the most storing most of the content.
This is very similar to what content distribution networks (e.g. Akamai) do already, and more general/sophisticated mechanisms are on the way. Stay tuned.
There are some good ideas here, but they seem to disregard the problem of latency.
While it's nice to see people recognizing the importance of latency, you're way off base. First, I can assure you that the authors are not unaware of the problems of latency. They might not have spent a lot of time delving into technical details in that blue-sky paper, but I've met two of them and they are very cognizant of these issues.
On a more technical note, I ask you to consider how the problems of latency might be avoided or reduced. Someone else already beat me to the mention of trading storage for latency, caching data in multiple locations. I know a little bit about that, but I don't think the point needs to be belabored. Also, there's the flexibility gained by moving computation nearer to data (or other resources) via mobile code. Sometimes that can be a really big win, as various Java applets have demonstrated.
There will always be some cases where latency continues to plague us, no matter what tricks we throw at it, but those will be relatively few. It's just like managing caches, or memory access in NUMA architectures; some people will get down and dirty to wrestle with the details and wring out the last drop of performance, but the vast majority won't need to care because functionally the memory all acts the same. Right now, everyone has to care very much about location on a network, not just for performance but for functional reasons as well. If we abstract some of that away and do a reasonable job of implementing the abstraction, we won't see so many people implementing crappy messaging layers with broken security just because the structure of the system forces them into it even though it's not their forte. Some people will still "step behind the curtain" but they'll be few and far between.
it seems the only way you could have this level of hands-off "use-ability" would be to have complete control of all aspects of the hardware and enviroments your software is running under
Nope. It's entirely possible to implement such a system using only the resources that are explicitly granted to it. It has been done many times, and several of those projects are referenced in the paper's bibliography.
if we move to a level of...how can we possibly innovate and improve?
By implementing above the abstraction, instead of reimplementing the abstraction endlessly. This has always been the case. At one time every programmer had to program down to the bare metal, jiggling interrupts and managing the movement of data between memory and backing store, writing their own schedulers, etc. Then we came up with abstractions like drivers and filesystems and operating systems with demand-paged virtual memory, so they don't have to do that any more (unless they want to). All that the Millennium authors are suggesting is that we consider treating things like location the same way we've gotten used to considering something like virtual memory or scheduling - as something that we don't have to worry about because it's taken care of for us by the system. This frees people to innovate, instead of requiring that they perform the same tedious chores for every non-trivial application they write. If I don't have to write yet another scheduler and yet another memory manager and yet another messaging layer, that leaves me more time to focus on the real higher-level problem I'm trying to solve. It's a good thing.
I'm glad I wasnt the only one thinking Freenet all the way through reading that article....strange it didnt get a credit - it already does pretty much all the data side of what they were talking about
Oh, bullshit. The paper specifically talks about data remaining in the system until it's no longer needed or referenced; Freenet drops data whenever it feels like it. The paper talks about making storage hierarchies invisible; Freenet as currently implemented is totally non-transparent, requiring a user to explicitly download a file in the Freenet app and then operate on it in another app. Freenet's primary goal is to obscure the identities of requesters and responders - information that will most definitely be necessary to keep a general-purpose distributed OS secure.
There's nothing wrong with the fact that Freenet is this way. Those are its design goals, and they're valid ones. It's just not at all related to what the Millennium folks lay out. Continuing to push Freenet as the solution to every problem when it's really only a solution for an extremely narrow range of problems just makes Freenet advocates look like fools.
over and over and over again, Open Source projects have allowed me as a developer to roll out stable and working applications for the company I work for
Please forgive me, but I just have to ask: are these open-source-based applications of which you speak themselves open-source? If so, where are they available?
Basically what it comes down to, for me and me alone, is one of two things:
What the hell, I already wrote it, I don't want to be a salesman, why the hell not just plop it out there just in case it's useful to someone else?
Getting this idea (expressed as code) out there is much more important than profiting from it.
Obviously, the first motivation applies more to small projects while the second applies to larger projects. There's a little bit of "scratch an itch" about it, maybe a little bit of altruism, maybe even a little bit of ego (in assuming that the world needs my brain-droppings). What is absent, for me, is any thought of reward - either monetary or otherwise. Sure, it's wonderful when I find out that my code helped someone, or that they learned something by looking at it. It's also wonderful when someone else builds on your ideas and creates something else that's cool. I won't deny the "rush" that comes from these things, but it's just not why I do it. When it comes right down to it, I do it because I can.
Re:If a camel is a horse designed by committee
on
USB 2.0 For Linux
·
· Score: 2
USB 2.0 is a duckbilled platypus.
I resent that metaphor. The platypus is unique and special, whereas USB 2.0 is a rehash of an existing standard in a failed effort to make it competitive with another existing standard. If we must pick a mascot for USB 2.0, I suggest the frilled lizard - a small lizard that uses fakery to make itself look like a much larger lizard.
Re:nice, but welcome back to the real world
on
Software Aesthetics
·
· Score: 2
The point you're missing is that even getting things to "just work ASAP" doesn't happen by itself. Only the most trivial programs are created in a single flash of insight. Most follow some sort of process, which often looks something like this:
Write component A.
Start writing component B, realize that A doesn't really do what it needed to.
Fix A, go back to working on B.
Finish B, C, D, and E. On a roll!
Start work on F. Realize there's something else wrong with A.
Try to fix A, realize you forgot how it works, the code is a mess, and there's neither design nor comments to remind you of what you were thinking at the time.
Rewrite A, forget what enhancements you meant to add for F.
Figure out what you needed for F, add the enhancements to A.
Fix B, which you broke when you rewrote A.
Try to fix C, which also broke when you rewrote A, but now you've forgotten how C worked. Again, no design or comments,...
etc.
Hey, now your productivity is approaching zero, but hey, at least you're having fun, right? WRONG! The whole idea of good software engineering is to stay out of this trap, not for aesthetics or on principle, but because it sucks, and it sucks even more when you realize it was oh-so-predictable and oh-so-avoidable. It's pure self-interest.
If you can program in tiny little pieces and dump them on someone else while you job-hop, you might be able to get away with this kind of slop, but as soon as you start writing anything that has any meat to it you'll recognize the need for better methods. Unfortunately, very few people realize this until they've spent a job or two fighting through the kind of swamp outlines above.
It is futile to think that private funding can make up what is being lost
Yeah, well, that's sure of hell true when the private donors desert researchers in their very hour of need, breaking promises in the process. It seems likely to me that this has less to do with principle than with Mr. Clark feeling a little less rich than he used to.
Ambitious, greedy and ruthless go a long way toward filling my definition of evil.
Then I would say you have a rather weak definition of evil. Ambition, greed, or ruthlessness do not necessarily involve a total lack of interest in the suffering or anguish one's actions cause. They do not necessarily make one more likely to cheat, steal, break promises, or worse. There are people in the business world who will tell you a lie that will wipe out your life's savings, and they won't even blink. Some will even take pride in having been so clever, and brag about it to their friends. Those are the people I would call evil.
Aside from the percentage of bad apples that exists in every field, I don't think VCs are evil in that sense. They don't want you to fail. They are, if not friends or even necessarily allies, not adversaries in a zero-sum game. Their ambition and greed are what - along with your own ambition and greed - what brought you together, and their ruthlessness can work for you as well as against you. They might not be the best of company, but calling them "evil" robs the word of meaning. If that's evil, how little must someone do for you to consider them good?
He might have the skills. It's highly unlikely, but it's possible. More importantly, 28 is not old enough to feel all entitled about the whole thing, or to whine about "oh, I've had to wait so long". Even if he is All That, there are plenty of other people who are also All That plus they have some ethics plus they've already had to wait longer due to reasons beyond their control. I'm sorry, but I'll save my sympathy for them, not some 28-year-old punk who thinks that six years past college is too long to wait to become a multi-millionaire.
It's my company, and I'm not going to report to a boss after taking this long to become my own boss.
You're 28! That's not even old enough, in most cases, to have reached full technical competency, let alone to have also reached the level of maturity and business skill where you could be entrusted with employees' livelihoods. There are only so many hours in each day to learn all these very different skills.
"Taking this long" my ass. Along with all the other things you need to learn, try learning some patience.
is it truly ethical to use a non-profit organization as a front for your for-profit business venture
In a word, no. In two words, HELL NO. Anybody who would even stop to think about it has a lot to learn about ethics.
Reducing the engineers' share of the pie is counterproductive, however: they become demoralized; productivity suffers; eventually, they leave.
To be fair, some VCs do recognize this and do something about it. I have a friend who's been involved in a few startups. Not too long ago he described what had happened in one funding round. BTW, you're practically always involved in some sort of funding-related activity or another, all day every day. If you're a true techie you'll go insane wishing you could sit down and write code again. Anyway, this is basically what the lead VC said:
You don't have any business, so that's not your value to us. Your IP isn't that valuable either. [Ow, harsh.] What's valuable to us is the talent you represent, and if your people's share gets too low we know you'll start to defect. That share is already below our standard, so we will not participate in the next round unless in the process we can bring the founders' share back up to that standard.
What ended up happening is that some of the previous-round investors saw their share reduced so the founders' share could be increased. I'm sure they didn't like that much, but I'm also sure that if it was presented as a choice between that and losing the lead investor (with nobody else ready to step in) they would have gone along. Losing the lead investor like that at that point in time would basically have meant that the company had zero prospects of survival (in fact it did not survive).
The upshot is that a "vulture capitalist" really - for once - did try to do the right thing by the founders, and even leaned on other investors to make the right things happen. They're not evil people. They're ambitious, they're greedy, they're often ruthless, they almost always have goals that are at odds with techies' goals, but they do have honor.
I wish I could name the east-coast VC company involved, because I like to see good behavior rewarded. Unfortunately, I don't feel safe doing so. One character trait they hold very dear is "discretion"; it's not very discreet to tell stories like this one in a place like slashdot, and I might want to do business with them myself someday.;-)
What an interesting phrase. Is it 90% probable that it's 100% accurate, or just 51% probable, and in any case what the hell does that mean? Are you certain of its accuracy, or uncertain? Or are you not sure which you mean?;-)
They don't, and that's the point. The standard excuse when it's pointed out Berlin gives app developers fewer options seems to be that those options are being given to the users instead, in the form of themes. But themes don't cut it. They don't offer the same sorts of flexibility that the developer needs to create the right interface for a particular application. Sure, many (most?) developers abuse that responsibility instead of using it responsibly, but - as I said - you can't deny them that flexibility without a downside.
When did "people can't handle flexibility, we should abandon flexibility in favor of conformity" become the mantra around here? That's Windows thinking. It's totally opposite to the philosophy that underlies UNIX in general or Linux in particular. Do you think all of your favorite X-window-manager toys - transparent and oddly-shaped title bars, dockable apps, virtual desktops just the way you like them - are going to survive a transition to Berlin? Think again. Because developers no longer have such flexibility, the environment you'd get with Berlin will be oh so spartan and sterile. But at least it'll be consistent, so I guess it's OK, right? Have you all tired of freedom so soon?
Slashdot Mirror
That shouldn't be a problem. Effective methods of recognizing and/or dealing with this sort of process-doing-sequential-I/O problem have been well known for the better part of a decade. After the first few accesses, XMMS's activity shouldn't be polluting the rest of the page cache with no-longer-wanted pages.
That would be totally inane, if it were true. I don't think it is, but I have to admit I haven't actually looked into that particular aspect. God, I hope you're wrong.
OK, Rik has pissed me off with his defensiveness and general attitude lately, but I still think that's unfair. Despite its warts, there are also some good reasons not to go making major architecture-level changes to the VM system at this stage in 2.4 development. If a strong enough case can be made that something is actually broken - not just subject to improvement - and that the proposed fix will do no harm or invalidate the testing that has already occurred, I'm sure Rik and the others would listen.
I've been in the room with both of them and a bottle of liquor. They've had their opportunity to just that, though I can't quite recall whether they took advantage of it. Must've been because I was drinking too. ;-)
Oops, that last paragraph was in response to an accidentally-omitted blockquote. "Possibly not" was in response to "Really I don't think we're disagreeing".
Yes, you are, you're just not overcommitted - which is sorta "out of memory, and then some". The whole point is to stop selling tickets when all the seats are full, instead of selling more tickets than you have seats and then shooting someone in the head to make room when everyone with a ticket actually does show up.
OK, maybe that metaphor's a little bit too colorful, but you get the idea.
Possibly not, except that if these mechanisms had been in place sooner there would never have been a (perceived) need for an OOM killer at all...and I think that would have been a good thing. In any case, it has been nice talking to you.
No, it's entirely feasible and has been done in general-purpose OSes. If every process has adequate paging space as it should, and there's also an emergency reserve as there should be, then you can be smart about how you apply that emergency reserve and avoid having the system lock up. It's actually a generalization of the policy decision that the OOM killer makes, in that you have choices between "allowed to survive" and "killed". In a degenerate case you could get behavior very similar to what the OOM killer gives you, with certain "victim" processes starving instead of being killed, but you can also do much better because of the additional flexibility.
Again, this is where emergency reserves and policy-based mechanisms come into play. Some filesystems on Linux have space reserved only for root; the same can be done for paging space. Nobody has to die in order that root may live.
Neither would I. I'd prefer that the condition be prevented than that it be allowed and then handled so stupidly.
That's totally uncalled-for. I've been a developer for over a decade, and a significant portion of that time has been spent fixing bugs in my own and other people's code - including VM-system bugs (no, not in Linux). I know the value of leveraging existing code - which is what makes me wonder why the Linux crew reinvented yet another wheel in this case instead of taking the opportunity to adapt and improve on existing tried-and-true approaches. The Linux VM system as it exists today bears all the hallmarks of code written by people who didn't find out what they were getting into before they started.
Someone at Sun might have thought it was a good idea, but I know other people at Sun who realize it stinks. BTW, do you really think Solaris is that exemplary an OS?
That is untrue. There is no need for any existing process to die in an OOM condition, although it may be necessary to prevent new processes from being spawned. The problem that the OOM killer tries to address is exhaustion of paging space by a rogue process, but that can be handled adequately by higher-level policy means (e.g. per-process limits, applying quota to paging space). Rejecting the policy-based approach in favor of warping the entire VM system's page-replacement strategy is IMO a mistake of the first magnitude. Contrary to what you imply, most other systems get by just fine without an OOM killer; many of them - but notably not including any flavor of NT - behave much more gracefully under memory pressure than Linux does.
Before you attempt to lecture me on how VM systems work, I should point out that I was at one time the go-to guy for a VM system more sophisticated than Linux's on one of the earlier SMP UNIXes (Encore's UMAX V). I do know how these things work, and that is why I make the claims that I do. The OOM killer does deserve to be killed.
Don't be an ass. Things like "VM/shmem" cleanups" (pre13) and "sysctl/VM documentation" (pre8) don't give any indication of serious changes to how the VM subsystem actually works. Similarly "VM race fix" (pre12) could as easily refer to something that has been in there for a year as to something that was introduced recently. Aside from those, there is still exactly one hint that anything major occurred - "major VM merge" in pre11. That phrase is still pretty darn vague; "major" could still refer to a bunch of fixes that merely required lots of lines without really changing anything deep. I already 'fessed up to the error, which was a simple honest mistake, so I'm not going to take any more gratuitous crap from karma whores about it.
I did read it, but I confess that I missed that one entry. I expected that if there were significant VM changes we'd see a whole list of entries like "fixed XXX bogosity from previous VM changes" instead of a single line.
The ChangeLog doesn't mention any VM changes, so I'd have to assume it still blows.
Separation of presentation and logic is good; what if the presentation is non-trivial? Do you want a server getting bogged down sending low-level instructions or generated images to clients? Do you want all presentation methods hard-coded into clients? Or might it be better to provide a way to specify complex presentation to clients, which is what Java does?
Of course you can't guarantee performance on other people's hardware, but that's their problem. Making it your problem by assuming all of the load is just stupid. Equipment and bandwidth budgets are finite - a lesson learned to late by many other dot-bombs. If you only have X hardware and Y bandwidth, you can use client resources - via mobile code or otherwise - to serve more users than you can with the totally server-centric approach you suggest.
Mobile code doesn't solve all problems, and it does create a few, but it's still a valuable part of the toolbox. If your control issues still prevent you from accepting that, see a therapist.
This is very similar to what content distribution networks (e.g. Akamai) do already, and more general/sophisticated mechanisms are on the way. Stay tuned.
While it's nice to see people recognizing the importance of latency, you're way off base. First, I can assure you that the authors are not unaware of the problems of latency. They might not have spent a lot of time delving into technical details in that blue-sky paper, but I've met two of them and they are very cognizant of these issues.
On a more technical note, I ask you to consider how the problems of latency might be avoided or reduced. Someone else already beat me to the mention of trading storage for latency, caching data in multiple locations. I know a little bit about that, but I don't think the point needs to be belabored. Also, there's the flexibility gained by moving computation nearer to data (or other resources) via mobile code. Sometimes that can be a really big win, as various Java applets have demonstrated.
There will always be some cases where latency continues to plague us, no matter what tricks we throw at it, but those will be relatively few. It's just like managing caches, or memory access in NUMA architectures; some people will get down and dirty to wrestle with the details and wring out the last drop of performance, but the vast majority won't need to care because functionally the memory all acts the same. Right now, everyone has to care very much about location on a network, not just for performance but for functional reasons as well. If we abstract some of that away and do a reasonable job of implementing the abstraction, we won't see so many people implementing crappy messaging layers with broken security just because the structure of the system forces them into it even though it's not their forte. Some people will still "step behind the curtain" but they'll be few and far between.
Nope. It's entirely possible to implement such a system using only the resources that are explicitly granted to it. It has been done many times, and several of those projects are referenced in the paper's bibliography.
By implementing above the abstraction, instead of reimplementing the abstraction endlessly. This has always been the case. At one time every programmer had to program down to the bare metal, jiggling interrupts and managing the movement of data between memory and backing store, writing their own schedulers, etc. Then we came up with abstractions like drivers and filesystems and operating systems with demand-paged virtual memory, so they don't have to do that any more (unless they want to). All that the Millennium authors are suggesting is that we consider treating things like location the same way we've gotten used to considering something like virtual memory or scheduling - as something that we don't have to worry about because it's taken care of for us by the system. This frees people to innovate, instead of requiring that they perform the same tedious chores for every non-trivial application they write. If I don't have to write yet another scheduler and yet another memory manager and yet another messaging layer, that leaves me more time to focus on the real higher-level problem I'm trying to solve. It's a good thing.
Oh, bullshit. The paper specifically talks about data remaining in the system until it's no longer needed or referenced; Freenet drops data whenever it feels like it. The paper talks about making storage hierarchies invisible; Freenet as currently implemented is totally non-transparent, requiring a user to explicitly download a file in the Freenet app and then operate on it in another app. Freenet's primary goal is to obscure the identities of requesters and responders - information that will most definitely be necessary to keep a general-purpose distributed OS secure.
There's nothing wrong with the fact that Freenet is this way. Those are its design goals, and they're valid ones. It's just not at all related to what the Millennium folks lay out. Continuing to push Freenet as the solution to every problem when it's really only a solution for an extremely narrow range of problems just makes Freenet advocates look like fools.
Please forgive me, but I just have to ask: are these open-source-based applications of which you speak themselves open-source? If so, where are they available?
Basically what it comes down to, for me and me alone, is one of two things:
Obviously, the first motivation applies more to small projects while the second applies to larger projects. There's a little bit of "scratch an itch" about it, maybe a little bit of altruism, maybe even a little bit of ego (in assuming that the world needs my brain-droppings). What is absent, for me, is any thought of reward - either monetary or otherwise. Sure, it's wonderful when I find out that my code helped someone, or that they learned something by looking at it. It's also wonderful when someone else builds on your ideas and creates something else that's cool. I won't deny the "rush" that comes from these things, but it's just not why I do it. When it comes right down to it, I do it because I can.
I resent that metaphor. The platypus is unique and special, whereas USB 2.0 is a rehash of an existing standard in a failed effort to make it competitive with another existing standard. If we must pick a mascot for USB 2.0, I suggest the frilled lizard - a small lizard that uses fakery to make itself look like a much larger lizard.
The point you're missing is that even getting things to "just work ASAP" doesn't happen by itself. Only the most trivial programs are created in a single flash of insight. Most follow some sort of process, which often looks something like this:
Hey, now your productivity is approaching zero, but hey, at least you're having fun, right? WRONG! The whole idea of good software engineering is to stay out of this trap, not for aesthetics or on principle, but because it sucks, and it sucks even more when you realize it was oh-so-predictable and oh-so-avoidable. It's pure self-interest.
If you can program in tiny little pieces and dump them on someone else while you job-hop, you might be able to get away with this kind of slop, but as soon as you start writing anything that has any meat to it you'll recognize the need for better methods. Unfortunately, very few people realize this until they've spent a job or two fighting through the kind of swamp outlines above.
Yeah, well, that's sure of hell true when the private donors desert researchers in their very hour of need, breaking promises in the process. It seems likely to me that this has less to do with principle than with Mr. Clark feeling a little less rich than he used to.
Then I would say you have a rather weak definition of evil. Ambition, greed, or ruthlessness do not necessarily involve a total lack of interest in the suffering or anguish one's actions cause. They do not necessarily make one more likely to cheat, steal, break promises, or worse. There are people in the business world who will tell you a lie that will wipe out your life's savings, and they won't even blink. Some will even take pride in having been so clever, and brag about it to their friends. Those are the people I would call evil.
Aside from the percentage of bad apples that exists in every field, I don't think VCs are evil in that sense. They don't want you to fail. They are, if not friends or even necessarily allies, not adversaries in a zero-sum game. Their ambition and greed are what - along with your own ambition and greed - what brought you together, and their ruthlessness can work for you as well as against you. They might not be the best of company, but calling them "evil" robs the word of meaning. If that's evil, how little must someone do for you to consider them good?
He might have the skills. It's highly unlikely, but it's possible. More importantly, 28 is not old enough to feel all entitled about the whole thing, or to whine about "oh, I've had to wait so long". Even if he is All That, there are plenty of other people who are also All That plus they have some ethics plus they've already had to wait longer due to reasons beyond their control. I'm sorry, but I'll save my sympathy for them, not some 28-year-old punk who thinks that six years past college is too long to wait to become a multi-millionaire.
You're 28! That's not even old enough, in most cases, to have reached full technical competency, let alone to have also reached the level of maturity and business skill where you could be entrusted with employees' livelihoods. There are only so many hours in each day to learn all these very different skills.
"Taking this long" my ass. Along with all the other things you need to learn, try learning some patience.
In a word, no. In two words, HELL NO. Anybody who would even stop to think about it has a lot to learn about ethics.
To be fair, some VCs do recognize this and do something about it. I have a friend who's been involved in a few startups. Not too long ago he described what had happened in one funding round. BTW, you're practically always involved in some sort of funding-related activity or another, all day every day. If you're a true techie you'll go insane wishing you could sit down and write code again. Anyway, this is basically what the lead VC said:
What ended up happening is that some of the previous-round investors saw their share reduced so the founders' share could be increased. I'm sure they didn't like that much, but I'm also sure that if it was presented as a choice between that and losing the lead investor (with nobody else ready to step in) they would have gone along. Losing the lead investor like that at that point in time would basically have meant that the company had zero prospects of survival (in fact it did not survive).
The upshot is that a "vulture capitalist" really - for once - did try to do the right thing by the founders, and even leaned on other investors to make the right things happen. They're not evil people. They're ambitious, they're greedy, they're often ruthless, they almost always have goals that are at odds with techies' goals, but they do have honor.
I wish I could name the east-coast VC company involved, because I like to see good behavior rewarded. Unfortunately, I don't feel safe doing so. One character trait they hold very dear is "discretion"; it's not very discreet to tell stories like this one in a place like slashdot, and I might want to do business with them myself someday. ;-)
What an interesting phrase. Is it 90% probable that it's 100% accurate, or just 51% probable, and in any case what the hell does that mean? Are you certain of its accuracy, or uncertain? Or are you not sure which you mean? ;-)
They don't, and that's the point. The standard excuse when it's pointed out Berlin gives app developers fewer options seems to be that those options are being given to the users instead, in the form of themes. But themes don't cut it. They don't offer the same sorts of flexibility that the developer needs to create the right interface for a particular application. Sure, many (most?) developers abuse that responsibility instead of using it responsibly, but - as I said - you can't deny them that flexibility without a downside.
When did "people can't handle flexibility, we should abandon flexibility in favor of conformity" become the mantra around here? That's Windows thinking. It's totally opposite to the philosophy that underlies UNIX in general or Linux in particular. Do you think all of your favorite X-window-manager toys - transparent and oddly-shaped title bars, dockable apps, virtual desktops just the way you like them - are going to survive a transition to Berlin? Think again. Because developers no longer have such flexibility, the environment you'd get with Berlin will be oh so spartan and sterile. But at least it'll be consistent, so I guess it's OK, right? Have you all tired of freedom so soon?