Never ascribe to malice what can be equally ascribed to incompetence.
The corollary of this is, of course, that you should still be wary of single points of failure, even if you do not believe they will fail you on purpose.
The work Sun did on their JVM may or may not be very impressive (I don't know), but their compiler still lacks some basic optimization techniques, which can sometimes lead to very suboptimal results. Also, the JVM is a heavyweight VM, geared towards the features of (older versions of) Java, not a general purpose VM. Getting JavaScript to run on it at anywhere near decent speed would not be trivial. Compiling JavaScript to x86 machine code is probably easier and likely to yield much better results, not to mention that it allows you to do without the bulk of a Java runtime.
``I would go a little further than that, realizing this is difficult to swallow for many following the javascript/ajax bashing meme here on Slashdot for so long, but in their desire to snub it as something "real" software engineers wouldn't touch (or is it fear of change from an aging community?) the clear reality IMHO is that javascript is taking over the role on the client side that java was supposed to be,''
Speaking as someone who isn't entirely happy with the direction JavaScripts have taken since the invention of the term "AJAX", perhaps I can shed some light on that. I can't speak for the entire "aging community", but there are bound to be some people who agree with my opinions.
First of all, calling AJAX bashing a meme is somewhat misleading. I did not speak out against it because it was a meme, I spoke out against it because I had actual technical and philosophical objections. Some of that is emotional: I resent the hype around AJAX. It wasn't actually new; I have been doing stuff like that since 1997 or thereabouts. Where's my recognition? But, the grumpiness of an old man aside, let's look at the technical aspects.
Many modern, cool websites try to use JavaScript, HTML, CSS, and HTTP to create user interfaces that resemble those of desktop applications. These web technologies were meant to support a request-response model, where each response is essentially a static page. Using JavaScript and CSS, developers create the illusion that it isn't a static page, but a dynamic environment with windows, buttons, menus, popups, anymation, smooth transitions, interaction, etc. In other words, an environment that is nothing like how the web used to be. To support this illusion, heaps of JavaScript are piled on disfigured HTML, and HTTP requests are abused to send what should be small pieces of data to and from the server.
In the process, compatibility is thrown out of the window - don't try to view any of those pages with an unsupported browser, and don't try to analyze the page with a web spider; you will only end up with garbage. Even if you have a supported browser, you will need a pretty powerful computer to get anywhere near decent responsiveness from what are really very primitive user interfaces. This is why I have opposed the wave of AJAX websites. It's not that I don't think the things that are being built with it aren't cool. But they are being built on the wrong technology, which yields suboptimal results and, at the same time, inhibits the adoption of what would be the right technologies. I am happy to see fancy interactive applications being built on open standards, rather than on proprietary technology, but I would rather have it be built on standards that were designed for it, rather than breaking existing standards to get something that sort of works, if you have a fast computer and the right browser. And yes, I do regard any HTML that can't be usefully processed by a search engine or screen reader as broken.
All this is is nothing against JavaScript. I think JavaScript is a nice language, and I am happy to see we're finally working on creating implementations that aren't dog slow. Perhaps we can also add some useful features...for example, raw sockets, so that we don't have to occur the overhead of a full HTTP request any time we wish to communicate with another system. And perhaps we could actually standardize APIs to functionality like native widgets (how is XUL these days?) and drawing functions (something like Cairo, perhaps?). Then we would have a platform that is actually good for interactive applications. Throw in some support for libraries (with caching and versioning) so that not everything needs to be reloaded all the time, and it's starting to look like a very workable solution.
You see, I am not opposed to change... I am opposed to changing in a direction we know isn't very good, when we know how to make it better.
``Jesus H. Fucking Christ. 99.9999999% of all companies just want to buy a tool that works.''
You are right about that (well, maybe not about the percentage, but the general point), but that doesn't contradict anything I said. They _would_ rather buy something that Just Works. They _would_ rather spend money on software licenses than spend more money on developing their own software. And all this makes perfect sense.
``They don't want to build the fucking thing. They don't even want to fix it. That's why they buy the support license. This whole 'we can customize the code if we want' is a huge stinking load of specious crap.''
Now, I don't know where that comes from. Who said anything about having to "build the fucking thing"? Did you miss the part where Zarafa is called a "drop-in replacement for Exchange" and "binaries... are available"? You don't have to build anything, and you don't have to fix anything. You seem to have confused what you _can_ do with what you _must_ do. Having to fix something is a Bad Thing. Being able to fix something is a Good Thing.
The comparison is like this:
On the one hand, you have Microsoft Exchange. There are various versions, each with their own bugs and limitations. If you need those bugs and limitations removed, you might be able to buy a different version, you might have to wait for a newer version to become available, or you might be simply out of luck. You pay for the software itself, and for client licenses - the more people use the software, the more you pay.
On the other hand, there is Zarafa. There will be various versions, each with their own bugs and limitations. If you need those bugs and limitations removed, you might be able to obtain a different version, you could wait for a newer version to become available (possibly with a patch from some company in the same position as you), or you could remove the bugs and limitations yourself. You can get everything for free.
Now, you tell me which seems to be the more attractive option.
Finally, I would like to point out that open source software tends to get easy installation procedures and low maintenance cost once Linux distributions start packaging it. Also, if running a particular piece of software is too tedious for you, you can always get it hosted by someone else. There is Exchange server hosting, and I imagine there will be Zarafa server hosting, as well.
That reminds me of something I thought of a couple of months ago (or is it years by now?). It seems to me that a lot of people who had a great impact on the world have had beards. Does anyone have any theories as to why that might be?
The bottom line here is that the paradigm isn't a property of the language, but of the program. You can do functional programming in Java, and you can do imperative programming in Haskell. At the end of the day, different paradigms are best for different tasks, and the best languages are those that don't get in your way, but give you the tools to build what you need.
Well, I imagine that an open source alternative to Exchange would not have Exchange's arbitrary limitations (e.g. maximum size of mailboxes) and would allow you to fix bugs and add features as you see fit. Those things _should_ make the switch worthwhile to many companies. I've heard complaints about arbitrary limitations and things just not working right in more than one company.
Holding criminals accountable is important, but let's not forget the reason why: it is so that innocents can live in peace. Punishing innocents is the very worst a system can do.
``If people want to eat McDonald's for dinner every day, let them.''
Aye, as long as they don't harm me, people can do whatever they want. But what about eating McDonald's for dinner every day, while I contribute to their health insurance? What about people running insecure systems, leaving me to cope with the spam once they get infected?
``If openness coincides sufficiently well with developer self-interest, then openness may win out as well.''
If, at least, developers act in a way that maximizes their self-interest. In practise, that is probably only partially the case. At best, they will act in a way that they _think_ maximizes their self interest... but their thinking can be affected, say, by a clever marketing campaign.
``Paul Kafasis (co-founder of Rogue Amoeba Software) makes the point that this action by Apple will scare talented developers away from the iPhone platform.''
I hope it will, but I doubt it. I hope the talented developers will favor open platforms over closed ones, help create and improve open platforms, and help making the world more open.
While many other posters give you heat for not being knowledgeable, I commend you for making the effort to learn. Keep that attitude, and you will eventually get good at it!
As for optimization, my advice to you is:
1. Know what you need to optimize 2. Measure, don't guess
It's good to read some generic "how to optimize foo" advice, but be careful you don't end up spending your time and effort optimizing something that doesn't need it. Know what things need to be fast, and focus on those. Very often, you will find that, actually, everything is fast enough, which means you don't need to optimize anything at all.
Once you have determined what, if anything, needs optimizing (by measuring, of course), the main thing is to identify the bottlenecks. If your pages take a long time to render, is it the web server that's slow, the network connection, the web browser, the code on the page, the code that generates the page, the database, the filesystem, or something else? Once you know where the slowdown is, find out what's causing it. Again, measure, don't guess.
Then, once you know the cause, you need to think about how you can solve it. In many cases, this will be clear to someone who is skilled at working with whatever technology it is. For example, a good programmer will know how to improve a program, a good DBA will know how to optimize database access, etc. In some cases, however, you will find that the performance at your bottleneck can't be improved significantly. You can have a skilled programmer spend a couple of days to squeeze the last few percents of performance out of some function, but that isn't going to help if you need things to go twice as fast. In that case, you may be able to solve the problem by using more hardware or faster hardware, or you may simply not be able to solve the problem.
Many fundamental questions about Mersenne primes remain unresolved. It is not even known whether there is a largest Mersenne prime, which would mean that the set of Mersenne primes is finite. The Lenstra-Pomerance-Wagstaff conjecture asserts that, on the contrary, there are infinitely many Mersenne primes and predicts their order of growth. It is also not known whether infinitely many Mersenne numbers with prime exponents are composite, although this would follow from widely believed conjectures about prime numbers, for example, the infinitude of Sophie Germain primes.
Mersenne primes are used in pseudorandom number generators such as Mersenne Twister and ParkMiller RNG.
Mersenne primes were considered already by Euclid, who found a connection with the perfect numbers.
Mersenne numbers are very good test cases for the special number field sieve algorithm
Out of those, I only knew about the connection with pseudorandom number generators, which I became interested in after writing my deadbeef random number generator.
``should Google be able to pick winners and losers among industries and business models?''
While it is interesting to consider what Google should be able to do, it is also important to recognize what they can do. AdWords is theirs. They control it. They can set the rules, and your only choices are to accept the rules, or to not play.
``Also a real pity, i wonder if the so called improved javascript VM will actually ever make it in the real world... cause we REALLY REALLY need optimized javascript;''
Well, it seems several people are already working on that. From Mozilla, there is Tamarin. From Apple, there is SquirrelFish.
You are right as far as widgets go, but you don't have to use widgets for HTTP, HTML parsing, JavaScript, and even web page rendering. You can pretty much build your whole browser on top of standard APIs, build the rendering on top of some abstraction of a canvas you can put text and graphics on, and then the only thing you have to implement for each OS is that abstration layer, and the surrounding widgets - menu bar, etc.
``I suppose it's good business sense to write software for the most popular platform. With around 75% of the OS hits being from Windows, it would be prudent to sink resources into a windows browser, rather than Mac or Linux.''
Of course, the right thing to do is to develop at least the core of it so that it doesn't depend too much on any one platform.
``Please be kind enough and show us something that has an open protocol, works as p2p, not proprietary, has 12 million people online and is not being blocked/traffic shaped by your ISP ?''
Why all those requirements? I thought we were talking about video chat and not leaving people out. The best way I know to accomplish that is to use an open protocol that does video chat. The requirement for doing video chat should be obvious. The requirement for openness is so that nobody is left out. Because that's what closed protocols do: they lock people out.
I don't see any reason for your requirements of "p2p" and "12 million people online", and, well, not being blocked by your ISP is certainly a must-have feature, but not something the protocol can enforce. The same goes for the number of users, of course: what users end up using is their decision, and, by and large, that seems to be Skype.
``Just maybe, i mean really, just maybe, there is a reason why skype doesn't want everyone on their cake party ?''
I am sure there is. If I were to guess, I would say that, by keeping their protocol closed, they retain control. By retaining control, they can make money. But I am not interested in whether or not some company I don't own makes money. I am interested in freedom of choice and interoperability. I promote open standards because they enable people to choose the software they want, or write their own if they don't like any of the existing software. I don't want people to be locked into using software that has been blessed by some company.
``I just see why skype does things the way it does, i'm not saying that it's 100% right, but it is one of the best options out there today.''
Perhaps, for some definition of "best". I am sad to see how popular Skype has gotten, though. Video chat using open standards was there long before Skype started doing video chat. In fact, it was there before Skype even existed. I wish people had stuck with the open standards, rather than making the founders of Skype millionaires for getting the world locked into yet another proprietary protocol.
I can't speak for the submitter, but Skype is not an open protocol, which disqualifies it for me. I would go with H.323 or SIP, both of which are supported by Ekiga.
``Actually, threads are heavier in Windows than in every other OS including Linux, MacOSX and Singularity. Still they are way cheaper than a process and that is the whole point of their existence.''
Exactly. Threads are kind of a hack to work around heavy processes and inter-process communication. But they introduce their own problems, especially when programming imperatively: suddenly, you have to take into account that your program's state might (will) be modified, without your program code doing that.
Threads and processes have been converging, so that you can now have processes sharing memory, threads having thread-local storage, and processes that aren't expensive to create. Nowadays, I think the difference is along the lines "everything is private by default" (processes) and "everything is shared by default" (threads). The former is easier to program for, and I therefore regard it as a good idea to use processes, rather than threads.
Your argument in favor of caps is a false dichotomy. The choice isn't between caps on the one hand and tampering and overcommitting on the other hand. Theoretically, there can be neither, and, plausibly, there can be both.
Personally, I prefer honesty. If you're selling the connection as so-many-bps, it should actually be that fast. I'll allow for occassional hiccups, but nothing like "slow during peak hours" or "fast only until you hit the cap" or "unless it's bittorrent" or "we'll send you nasty letters" or anything of that crap.
I have no issue with ISPs wanting to limit my usage of the network per se. But let them be upfront about it, so that I can choose one whose limits I can live with. In that sense "250 GB a month" is better than "Unlimited (Fair Use Policy)", because, at least, I know what I get.
Because, if you have to pay rent, utility bill, phone bill, internet bill, health insurance, and car insurance, you're already up to an hour of time you could have saved. Since I live in a country where automated bill payment is the norm and rarely goes wrong, I'd rather have my extra hour. If I lived in the States, I would think twice about that, though. But then again, that's one of the reasons I don't want to live in the States.
Slashdot Mirror
Never ascribe to malice what can be equally ascribed to incompetence.
The corollary of this is, of course, that you should still be wary of single points of failure, even if you do not believe they will fail you on purpose.
The work Sun did on their JVM may or may not be very impressive (I don't know), but their compiler still lacks some basic optimization techniques, which can sometimes lead to very suboptimal results. Also, the JVM is a heavyweight VM, geared towards the features of (older versions of) Java, not a general purpose VM. Getting JavaScript to run on it at anywhere near decent speed would not be trivial. Compiling JavaScript to x86 machine code is probably easier and likely to yield much better results, not to mention that it allows you to do without the bulk of a Java runtime.
``I would go a little further than that, realizing this is difficult to swallow for many following the javascript/ajax bashing meme here on Slashdot for so long, but in their desire to snub it as something "real" software engineers wouldn't touch (or is it fear of change from an aging community?) the clear reality IMHO is that javascript is taking over the role on the client side that java was supposed to be,''
Speaking as someone who isn't entirely happy with the direction JavaScripts have taken since the invention of the term "AJAX", perhaps I can shed some light on that. I can't speak for the entire "aging community", but there are bound to be some people who agree with my opinions.
First of all, calling AJAX bashing a meme is somewhat misleading. I did not speak out against it because it was a meme, I spoke out against it because I had actual technical and philosophical objections. Some of that is emotional: I resent the hype around AJAX. It wasn't actually new; I have been doing stuff like that since 1997 or thereabouts. Where's my recognition? But, the grumpiness of an old man aside, let's look at the technical aspects.
Many modern, cool websites try to use JavaScript, HTML, CSS, and HTTP to create user interfaces that resemble those of desktop applications. These web technologies were meant to support a request-response model, where each response is essentially a static page. Using JavaScript and CSS, developers create the illusion that it isn't a static page, but a dynamic environment with windows, buttons, menus, popups, anymation, smooth transitions, interaction, etc. In other words, an environment that is nothing like how the web used to be. To support this illusion, heaps of JavaScript are piled on disfigured HTML, and HTTP requests are abused to send what should be small pieces of data to and from the server.
In the process, compatibility is thrown out of the window - don't try to view any of those pages with an unsupported browser, and don't try to analyze the page with a web spider; you will only end up with garbage. Even if you have a supported browser, you will need a pretty powerful computer to get anywhere near decent responsiveness from what are really very primitive user interfaces. This is why I have opposed the wave of AJAX websites. It's not that I don't think the things that are being built with it aren't cool. But they are being built on the wrong technology, which yields suboptimal results and, at the same time, inhibits the adoption of what would be the right technologies. I am happy to see fancy interactive applications being built on open standards, rather than on proprietary technology, but I would rather have it be built on standards that were designed for it, rather than breaking existing standards to get something that sort of works, if you have a fast computer and the right browser. And yes, I do regard any HTML that can't be usefully processed by a search engine or screen reader as broken.
All this is is nothing against JavaScript. I think JavaScript is a nice language, and I am happy to see we're finally working on creating implementations that aren't dog slow. Perhaps we can also add some useful features...for example, raw sockets, so that we don't have to occur the overhead of a full HTTP request any time we wish to communicate with another system. And perhaps we could actually standardize APIs to functionality like native widgets (how is XUL these days?) and drawing functions (something like Cairo, perhaps?). Then we would have a platform that is actually good for interactive applications. Throw in some support for libraries (with caching and versioning) so that not everything needs to be reloaded all the time, and it's starting to look like a very workable solution.
You see, I am not opposed to change ... I am opposed to changing in a direction we know isn't very good, when we know how to make it better.
``Jesus H. Fucking Christ. 99.9999999% of all companies just want to buy a tool that works.''
You are right about that (well, maybe not about the percentage, but the general point), but that doesn't contradict anything I said. They _would_ rather buy something that Just Works. They _would_ rather spend money on software licenses than spend more money on developing their own software. And all this makes perfect sense.
``They don't want to build the fucking thing. They don't even want to fix it. That's why they buy the support license. This whole 'we can customize the code if we want' is a huge stinking load of specious crap.''
Now, I don't know where that comes from. Who said anything about having to "build the fucking thing"? Did you miss the part where Zarafa is called a "drop-in replacement for Exchange" and "binaries ... are available"? You don't have to build anything, and you don't have to fix anything. You seem to have confused what you _can_ do with what you _must_ do. Having to fix something is a Bad Thing. Being able to fix something is a Good Thing.
The comparison is like this:
On the one hand, you have Microsoft Exchange. There are various versions, each with their own bugs and limitations. If you need those bugs and limitations removed, you might be able to buy a different version, you might have to wait for a newer version to become available, or you might be simply out of luck. You pay for the software itself, and for client licenses - the more people use the software, the more you pay.
On the other hand, there is Zarafa. There will be various versions, each with their own bugs and limitations. If you need those bugs and limitations removed, you might be able to obtain a different version, you could wait for a newer version to become available (possibly with a patch from some company in the same position as you), or you could remove the bugs and limitations yourself. You can get everything for free.
Now, you tell me which seems to be the more attractive option.
Finally, I would like to point out that open source software tends to get easy installation procedures and low maintenance cost once Linux distributions start packaging it. Also, if running a particular piece of software is too tedious for you, you can always get it hosted by someone else. There is Exchange server hosting, and I imagine there will be Zarafa server hosting, as well.
That reminds me of something I thought of a couple of months ago (or is it years by now?). It seems to me that a lot of people who had a great impact on the world have had beards. Does anyone have any theories as to why that might be?
By the way, I have a beard, too. And I'm working on a programming language.
The bottom line here is that the paradigm isn't a property of the language, but of the program. You can do functional programming in Java, and you can do imperative programming in Haskell. At the end of the day, different paradigms are best for different tasks, and the best languages are those that don't get in your way, but give you the tools to build what you need.
Well, I imagine that an open source alternative to Exchange would not have Exchange's arbitrary limitations (e.g. maximum size of mailboxes) and would allow you to fix bugs and add features as you see fit. Those things _should_ make the switch worthwhile to many companies. I've heard complaints about arbitrary limitations and things just not working right in more than one company.
Actually, the fact that Osama bin-Laden denied being responsible for the 9/11 attacks was aired on TV worldwide - even in the USA, I believe.
Holding criminals accountable is important, but let's not forget the reason why: it is so that innocents can live in peace. Punishing innocents is the very worst a system can do.
``If people want to eat McDonald's for dinner every day, let them.''
Aye, as long as they don't harm me, people can do whatever they want. But what about eating McDonald's for dinner every day, while I contribute to their health insurance? What about people running insecure systems, leaving me to cope with the spam once they get infected?
``If openness coincides sufficiently well with developer self-interest, then openness may win out as well.''
If, at least, developers act in a way that maximizes their self-interest. In practise, that is probably only partially the case. At best, they will act in a way that they _think_ maximizes their self interest ... but their thinking can be affected, say, by a clever marketing campaign.
``Paul Kafasis (co-founder of Rogue Amoeba Software) makes the point that this action by Apple will scare talented developers away from the iPhone platform.''
I hope it will, but I doubt it. I hope the talented developers will favor open platforms over closed ones, help create and improve open platforms, and help making the world more open.
While many other posters give you heat for not being knowledgeable, I commend you for making the effort to learn. Keep that attitude, and you will eventually get good at it!
As for optimization, my advice to you is:
1. Know what you need to optimize
2. Measure, don't guess
It's good to read some generic "how to optimize foo" advice, but be careful you don't end up spending your time and effort optimizing something that doesn't need it. Know what things need to be fast, and focus on those. Very often, you will find that, actually, everything is fast enough, which means you don't need to optimize anything at all.
Once you have determined what, if anything, needs optimizing (by measuring, of course), the main thing is to identify the bottlenecks. If your pages take a long time to render, is it the web server that's slow, the network connection, the web browser, the code on the page, the code that generates the page, the database, the filesystem, or something else? Once you know where the slowdown is, find out what's causing it. Again, measure, don't guess.
Then, once you know the cause, you need to think about how you can solve it. In many cases, this will be clear to someone who is skilled at working with whatever technology it is. For example, a good programmer will know how to improve a program, a good DBA will know how to optimize database access, etc. In some cases, however, you will find that the performance at your bottleneck can't be improved significantly. You can have a skilled programmer spend a couple of days to squeeze the last few percents of performance out of some function, but that isn't going to help if you need things to go twice as fast. In that case, you may be able to solve the problem by using more hardware or faster hardware, or you may simply not be able to solve the problem.
Not knowing why Mersenne primes matter, I looked it up on The Ultimate Source Of Truth. From The Fine Article:
Out of those, I only knew about the connection with pseudorandom number generators, which I became interested in after writing my deadbeef random number generator.
If the witness in my case is a human, do I have a constitutional right to know how the human works?
``should Google be able to pick winners and losers among industries and business models?''
While it is interesting to consider what Google should be able to do, it is also important to recognize what they can do. AdWords is theirs. They control it. They can set the rules, and your only choices are to accept the rules, or to not play.
``Also a real pity, i wonder if the so called improved javascript VM will actually ever make it in the real world... cause we REALLY REALLY need optimized javascript;''
Well, it seems several people are already working on that. From Mozilla, there is Tamarin. From Apple, there is SquirrelFish.
And here's a comparison of the performance of various JavaScript engines, including Tamarin, SquirrelFish, and Chrome's V8.
You are right as far as widgets go, but you don't have to use widgets for HTTP, HTML parsing, JavaScript, and even web page rendering. You can pretty much build your whole browser on top of standard APIs, build the rendering on top of some abstraction of a canvas you can put text and graphics on, and then the only thing you have to implement for each OS is that abstration layer, and the surrounding widgets - menu bar, etc.
``I suppose it's good business sense to write software for the most popular platform. With around 75% of the OS hits being from Windows, it would be prudent to sink resources into a windows browser, rather than Mac or Linux.''
Of course, the right thing to do is to develop at least the core of it so that it doesn't depend too much on any one platform.
``Please be kind enough and show us something that has an open protocol, works as p2p, not proprietary, has 12 million people online and is not being blocked/traffic shaped by your ISP ?''
Why all those requirements? I thought we were talking about video chat and not leaving people out. The best way I know to accomplish that is to use an open protocol that does video chat. The requirement for doing video chat should be obvious. The requirement for openness is so that nobody is left out. Because that's what closed protocols do: they lock people out.
I don't see any reason for your requirements of "p2p" and "12 million people online", and, well, not being blocked by your ISP is certainly a must-have feature, but not something the protocol can enforce. The same goes for the number of users, of course: what users end up using is their decision, and, by and large, that seems to be Skype.
``Just maybe, i mean really, just maybe, there is a reason why skype doesn't want everyone on their cake party ?''
I am sure there is. If I were to guess, I would say that, by keeping their protocol closed, they retain control. By retaining control, they can make money. But I am not interested in whether or not some company I don't own makes money. I am interested in freedom of choice and interoperability. I promote open standards because they enable people to choose the software they want, or write their own if they don't like any of the existing software. I don't want people to be locked into using software that has been blessed by some company.
``I just see why skype does things the way it does, i'm not saying that it's 100% right, but it is one of the best options out there today.''
Perhaps, for some definition of "best". I am sad to see how popular Skype has gotten, though. Video chat using open standards was there long before Skype started doing video chat. In fact, it was there before Skype even existed. I wish people had stuck with the open standards, rather than making the founders of Skype millionaires for getting the world locked into yet another proprietary protocol.
I can't speak for the submitter, but Skype is not an open protocol, which disqualifies it for me. I would go with H.323 or SIP, both of which are supported by Ekiga.
``Actually, threads are heavier in Windows than in every other OS including Linux, MacOSX and Singularity. Still they are way cheaper than a process and that is the whole point of their existence.''
Exactly. Threads are kind of a hack to work around heavy processes and inter-process communication. But they introduce their own problems, especially when programming imperatively: suddenly, you have to take into account that your program's state might (will) be modified, without your program code doing that.
Threads and processes have been converging, so that you can now have processes sharing memory, threads having thread-local storage, and processes that aren't expensive to create. Nowadays, I think the difference is along the lines "everything is private by default" (processes) and "everything is shared by default" (threads). The former is easier to program for, and I therefore regard it as a good idea to use processes, rather than threads.
Your argument in favor of caps is a false dichotomy. The choice isn't between caps on the one hand and tampering and overcommitting on the other hand. Theoretically, there can be neither, and, plausibly, there can be both.
Personally, I prefer honesty. If you're selling the connection as so-many-bps, it should actually be that fast. I'll allow for occassional hiccups, but nothing like "slow during peak hours" or "fast only until you hit the cap" or "unless it's bittorrent" or "we'll send you nasty letters" or anything of that crap.
I have no issue with ISPs wanting to limit my usage of the network per se. But let them be upfront about it, so that I can choose one whose limits I can live with. In that sense "250 GB a month" is better than "Unlimited (Fair Use Policy)", because, at least, I know what I get.
Because, if you have to pay rent, utility bill, phone bill, internet bill, health insurance, and car insurance, you're already up to an hour of time you could have saved. Since I live in a country where automated bill payment is the norm and rarely goes wrong, I'd rather have my extra hour. If I lived in the States, I would think twice about that, though. But then again, that's one of the reasons I don't want to live in the States.
Well, the more people who don't vote, the more you can make a difference by casting your vote. So go for it, already!