It does. It also pays to have them using the right tool for the job. Where you (and the original article) fall down is in proving that C++ is that right tool for this particular job. Carbon efficiency is definitely only one aspect of many there. From the business's perspective, there's no point in being carbon efficient if it leaves you so inflexible that you lose marketshare and cease to be viable. Far better to invest in power sources that reduce the carbon intensity of the business while still permitting flexibility. Oops! Solar power would let them avoid C++!
Latency is a different question than efficiency. If your page generation efficiency is bad, on a small setup the difference may be imperceptible. On a large installation, i.e. one with a large number of servers dedicated to page generation, the efficiency of those servers makes a big difference. Holding latency constant, in a large installation less efficient page generation means more servers. In a small installation, not so much.
But you've got to balance it against other costs. For example, Facebook have plenty of PHP programers now but you're suggesting that they all retrain in C++. That's expensive, especially if they've got to keep on delivering new features for their existing platform at the same time until the rewrite is done. (The development cycle for a site like Facebook is furiously short; for eBay, where I've seen the figures, the cycle is a week. I'd be startled if Facebook was much longer these days.) Add in the fact that the cost of adding servers is low and the cost of carbon is low, then you're left in the position of arguing that something very expensive should be done to mitigate some fairly cheap costs. Not gonna happen! (Now, adding a new datacenter is expensive, comparable to building a new highly-automated factory, but it's not clear to what extent switching from PHP to C++ would really mitigate that.)
Memory management is a non-issue with RAII, smart pointers, Boehm garbage collector, and finally Valgrind.
This smells like an argument you've wheeled out before.
Firstly, Valgrind is not something you use on a production deployment of a webserver; it's performance overhead is really substantial. (Good tool, but makes all memory accesses much slower.) Your suggestion makes me suspect that you don't write high-performance websites for a living. (There are nasty gotchas if you don't go fast enough.)
Secondly, RAII only solves some kinds of memory problem (where other languages would use a finally clause) and it is not syntactically clear when it's being used (not unless you're only using it close to the declaration of the class concerned, but that's got other issues). It's OK when you can bind the object lifetime to a scope, but that's definitely not always true. Smart pointers are better general tools, but rather noisy and inefficient (their refcount management is necessarily conservative and so ends up adding some overhead, which is not necessarily good for cache coherency). They also don't tackle circular structures (if that matters to you).
Lastly, full GC has substantial costs of its own (it increases memory consumption of the application, and churns that memory around more rapidly) and a generational collector will outperform pure Boehm on many workloads, though the fact that the Boehm collector supports thread-local allocation is a big plus; a lot of workloads can be split nicely into parts that are constrained to a single thread. The Boehm GC is good, but is it the right kind of good for a website implementation? I'd need to see some evidence - not just opinion - before commenting in depth.
However, once you've written your site, and its become really popular, you owe it to your balance sheet to recode it in something somewhat more efficient (not Java, k) so you don't have to buy 30,000 servers in the first place. Now you know the code, its well documented, and has good interfaces, then recoding it in C++ should be easy. Bear in mind those extra coders required to write it in C++ are going to be employed one way or another, so they don;t get to be included in your site's carbon footprint. Also, those extra coders will not be needed once the infrastructure is written, and they're still going to be a fraction of the energy cost of running Facebook for a few more years.
It's not at all clear that rewriting your site from PHP to C++ would save that much (websites are I/O bound, not CPU bound) and while you might be able to reduce the number of servers a little bit, the cost of such a rewrite (indeed, of a rewrite from anything to anything) is pretty high in itself. For one thing, the chances of screwing up the rewrite are pretty high; it's a non-trivial quantity of code to convert. Plus if you're rewriting your site, you're not adding value to it in other ways.
The cost of carbon is far too low to justify an expensive rewrite.
Correct, but it does not change the premise. Actually, all major C++ compilers are well aware about the situation and are very good at optimizing inlines (and not optimizing when it does not make sense).
They can only really do a good job if they're taking into account the size of the caches, and that's not portable at all. A lot of people don't have the luxury of only ever coding for one processor variant. (Curiously, I work somewhere where that level of optimization is sometimes used for real. But we tend to not use it for C++, reserving it for key Fortran libraries only.)
In fact, what really counts is not inlining itself, but optimization across multiple functions call - in C++, multiple calls can get collapsed into a couple of assembly instructions. Often, such collapsing leads into less code bytes than required to perform function call.
It critically depends on the details, since the real overall win comes when you get to fit everything in a level of cache that is closer to the CPU than before; L1 beats L2 beats memory beats disk (i.e. paged out). If you're only inlining trivial accessors then you're correct, but that's not the only case that people inline. For something longer, it's a much trickier tradeoff. (And inlines have that ABI-bake-in problem which you ignored, which really bites in production libraries. Mainline developers don't see the issue, but maintenance programmers and deployment engineers do.)
BTW, branch prediction does not have anything to do with unconditional procedure calls. Branch prediction is about conditional jumps. That said, yes, modern CPUs are pretty good at about everything.
Actually, branch prediction is also about unconditional jumps. They just happen to be a very easy case.
Like the Captain of a ship, the people at the top of a company should be responsible in any case, even if they didn't know.
What you do is you find the scum that did it and sack them, making them unemployable in any position of financial responsibility while you're at it. (You also carefully investigate whether they actually committed crimes while you're at it; maybe you'll get lucky...) However you also kick out everyone over them all the way up the management tree to Group CEO (obviously those who were asleep at the wheel when this was going on, not necessarily their replacements). Yes, it blights a few lives quite thoroughly, but it also sends out a message to the irresponsible that if they really fuck up, they'll personally lose out a lot too. There's been too little fear to counterbalance the levels of greed over the past few years; time to correct that (and a grand lynching of bankers and related trades is unfortunately illegal).
Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.
You might think so, but it's not as simple as all that. You also have to take into account the CPU's caching behavior; large numbers of inlines can (i.e., I've seen it happen) make the size of the working set too large to fit in L1 (or even L2) cache. That in turn means that you're taking a substantial performance hit. What's better, the size of those caches is dependent on exactly what sort of processor you're working with, so compilers don't take them into account.
Inlining is a trade-off, as it increases the size of the object code in return for removing the cost of a function call. (It's also total poison for any ABI which needs long-term version management, since it effectively bakes internal details of the called objects into the callers' code, even if not at the source level. But I'm digressing) And yet modern CPUs have pretty decent branch predictors, and so the costs of a function call are often very low to almost non-existent...
Then you are fortunate. The JVM is a good abstraction, but it is a leaky one. The point is that you can't just *assume* it will work on any platform that runs a JVM, which was the original (I would claim largely irrelevant) point behind WORA.
Most things work well across platforms these days, even with GUI applications (the major exception being some of the weird-ass things in the Apple JVM's GUI layer). Server applications have been strongly portable for quite a long time.
Compare with C# where your typical app, whether a GUI app or a server app, can't be ported to work with Mono without reworking loads of things. Or what about the other way? Can you take things built with the Mono toolset on Unix and run it with the Microsoft VM on Windows? All the experience my colleagues have got recently with attempting this sort of thing indicates otherwise. If you're working with C#, one way or another you're bound to a particular implementation. (Alas; it's meant we've had to deploy Windows systems rather than sticking to good old Unix...)
Is it possible to have two broken teeth, broken nose, and a white shirt with no red stain?
It depends on how fast someone got in with something to mop up the blood. I guess that was pretty quick (the video of the events was pretty confused...) We also don't know the extent to which his teeth were damaged; "broken" might be a mistransation of (the Italian word for) "chipped" or "cracked".
The question is, did Sun actually buy it to sell commercial licenses, or as a way to push an integrated hardware stack?
Does it matter? Bought is bought, and they get to choose how to go forward with it.
Sun are quite keen on integrated stacks though; that was where they were making their money for many years, and before the financial sector imploded, it was very lucrative. I've a soft spot for Sun hardware, speaking as someone who pushed my Sun kit really hard; it took a licking and kept on ticking.
But really, PowerShell is better than all of the above.
Depends on whether you think that types are a good thing or a bad thing in shells. If you like types, then PowerShell is indeed MSNirvana(TM). Those of us who think that types are just an annoyance when it comes to sticking programs together to do cool stuff, well, we're just never going to be all that impressed with MS's offering here and will stick to other technologies.
Who's right? I'm definitely biased, but I rather like the POSIX way of doing things.
Also, no, the laches defense requires an affirmative action on the patent owner's part - I send you a notice of infringement, you reply back with a request for a license, and I... disappear. If I never put you on notice, I haven't started the clock ticking.
On the other hand, if you have a patent and don't make any attempt to prevent infringement for many years even if notified of such activity, it does reduce the level of damages that you can claim. Courts don't mollycoddle lazy dumbasses.
Laches? Oh yes, given that there appears to have been no attempt to deal with this matter before now, but it's different if they've been in negotiations over this for a substantial amount of time. It's entirely possible that the court will dictate the terms under which BetaNet offers licenses, but only if what we have here is a matter that's been rumbling on for years between sets of lawyers rather than being sprung upon the defendants like a particularly unpleasant gatecrasher.
Just to be 'that guy', let me point out - If this had actually been modeled, and the news were very, very bad, how long would it remain 'yet to be modeled'?
Not really. Pretending it doesn't exist won't make it go away. About the best we can hope for is that it won't explode until we're all long gone (on a personal level) so that it's someone else's problem.
[Amazon] do, since they have to be able to handle peak loads around Christmas and so forth. It just makes good financial sense to make some money off of all that infrastructure when it's not in use.
There's this great myth that Amazon need all this capacity for handling Christmas. They don't. It may have started that way, but now their infrastructure for handling services is much larger than that. (IIRC, they passed that level sometime last year, or maybe even back in 2007.) They are now a cloud provider that happens to sell stuff (books, etc) on the side.
Now, granted, you're correct in that it would be very difficult indeed to achieve that if every single customer used as much, but the point is that they don't, which is why you *can* really have that - the isp in question just needs to not oversell *too* much.
The more they oversell, the lower they can keep their prices (whether or not they do so is another matter). Simple economics. For almost all usage patterns, overselling is fine as traffic is bursty (stochastic sharing is effective) but when you've got people doing bulk downloads and bulk uploads 24/7, that's a different pattern. What's worse is when people are playing tricks to raise the priority of bulk traffic.
Of course, you can pay more to reduce the level of sharing. This is what a business class connection is. (What did you think they were paying for? Using Denon cables?) Or you can decide to be cheap and have a higher level of sharing, which means that you're going to be impacted if you do a lot of bulk transfers. Some of these choices, you make by switching ISP. Your cash, your choice. (In some parts of the world, you have to move to change ISP. This sucks, but is a different matter.)
Let market forces decide who gets it. Forcing buildouts to the far corners of rural America will just inflate everyone else's prices.
Differentiate between the right to get broadband and the right to get broadband cheaply. The former makes sense, and the latter is just uneconomic; an unjustified subsidy of rural areas by urban citizens.
In this case, yes. But a 100% open service whose functionality required a given (open) server to work wouldn't be affected: just change the server and you're back.
Depends on the nature of the service. If it involves large amounts of data and wasn't already set up to replicate the data to a backup system, bringing things back up (whether or not you've got the source code) might be very difficult simply because people don't just want the service itself, but they also want the state embodied by the service. After all, if you had a NAS box with lots of data on it, you wouldn't be able to bring the service provided by it back up just by plugging a new NAS box in. You'd still need to copy the files across, and if the old NAS is down and you've not been backing up properly, you're in trouble. The OS on the NAS boxes (or on the client systems) doesn't matter at all for that fundamental truth.
Services aren't software. Open source software can still form a closed ecosystem (a lot of Linux desktops feel rather that way) and an open ecosystem need not use any OSS. Of course, best of all is when there is an open ecosystem (so people can use anything they want) and OSS is full part of that ecosystem; the open software acts as an insurance against people trying to close things off, and sets a baseline that the closed providers have to do better than.
I'll tolerate your loud headphone music if you tolerate the smell of other peoples' smoke.
That way, we all win.
Alternatively we can just taser the most egregious assholes before garroting them with their own headphone cables. That way, we all win.
Seriously, the enormous majority of people on the train that I see every day when commuting manage to keep volumes low enough that they're just entertaining themselves. That's great! Only a very few feel the need to impose their sucky tastes in music on the rest of us.
Most likely the regulation will apply only to the headphones sold with the player.
More likely to also apply to any after-market headphones that are specifically advertised as being made for or compatible with a particular player. After all, what's the point of an accessory that cannot be used in the manner for which it is intended, and used safely at that.
People are still willing to pay to go to the movies for the superior screen/sound and crowd experience. Although the impact is far less than they claim, I would imagine pirated movies hurt dvd sales more than box office, at least in the US.
Overall people don't mind going to movies. After all, if the film is good and the projectionist is good, then it is (or should be) a great experience. It's not the same thing as the recorded music business, which was never about providing the total experience like movies have been for ages. I suppose a better parallel to a movie is a music concert. Again, it's about the whole experience and people don't mind paying for that. (Well, most people anyway. Enough to make it potentially very profitable.)
The threat posed by the internet to movies is not really piracy. It's that it is a different, new thing for Joe Sixpack to spend his entertainment money on. Is that a problem yet for the movie industry? Probably not, but that's where the real issue is. Note that this is not a legal threat. It's a threat to the very basis of getting such a large proportion of the national entertainment spend. Hollywood have long tried to counter this with things like film tie-ins, special websites, etc, with varying success. Will that change? No idea.
There are only two things I can think of that the world would miss - MySQLe (the embedded version, which competes with BDB-esque type uses - it's a really cool idea) and the solid Windows support (PostgreSQL added this about a year ago - I'm not sure how solid it is yet).
SQLite is great for embedded databases, even on Windows. And would you really want to run a server DB on Windows? About the only reason I can think of offhand is if you're in an all-Microsoft shop, and if that's so, why would you worry about using an open source server DB? Just go for MS's own product; it won't change the amount that you're tied in...
You're not tied to whatever happens to MySQL. You're certainly not tied to what happens to Sun (unless you work there, of course). And you are most certainly not tied to whatever that stupid hypocrite Monty Widenius says. Ignore his pathetic bleatings, and the world will be a better place. That's the good thing about OSS; you can ignore whatever crap that the author of the software is into - including whether they want to support the code - and just focus on whether the software itself is any good for your purposes. (For those of you following along at home, Monty is a stupid hypocrite because he sold out and left, but is still trying to run things; if you take the money and run, you kiss goodbye to that which you sold. That's what a sale is.)
Slashdot Mirror
It often pays to hire better people.
It does. It also pays to have them using the right tool for the job. Where you (and the original article) fall down is in proving that C++ is that right tool for this particular job. Carbon efficiency is definitely only one aspect of many there. From the business's perspective, there's no point in being carbon efficient if it leaves you so inflexible that you lose marketshare and cease to be viable. Far better to invest in power sources that reduce the carbon intensity of the business while still permitting flexibility. Oops! Solar power would let them avoid C++!
Latency is a different question than efficiency. If your page generation efficiency is bad, on a small setup the difference may be imperceptible. On a large installation, i.e. one with a large number of servers dedicated to page generation, the efficiency of those servers makes a big difference. Holding latency constant, in a large installation less efficient page generation means more servers. In a small installation, not so much.
But you've got to balance it against other costs. For example, Facebook have plenty of PHP programers now but you're suggesting that they all retrain in C++. That's expensive, especially if they've got to keep on delivering new features for their existing platform at the same time until the rewrite is done. (The development cycle for a site like Facebook is furiously short; for eBay, where I've seen the figures, the cycle is a week. I'd be startled if Facebook was much longer these days.) Add in the fact that the cost of adding servers is low and the cost of carbon is low, then you're left in the position of arguing that something very expensive should be done to mitigate some fairly cheap costs. Not gonna happen! (Now, adding a new datacenter is expensive, comparable to building a new highly-automated factory, but it's not clear to what extent switching from PHP to C++ would really mitigate that.)
Memory management is a non-issue with RAII, smart pointers, Boehm garbage collector, and finally Valgrind.
This smells like an argument you've wheeled out before.
Firstly, Valgrind is not something you use on a production deployment of a webserver; it's performance overhead is really substantial. (Good tool, but makes all memory accesses much slower.) Your suggestion makes me suspect that you don't write high-performance websites for a living. (There are nasty gotchas if you don't go fast enough.)
Secondly, RAII only solves some kinds of memory problem (where other languages would use a finally clause) and it is not syntactically clear when it's being used (not unless you're only using it close to the declaration of the class concerned, but that's got other issues). It's OK when you can bind the object lifetime to a scope, but that's definitely not always true. Smart pointers are better general tools, but rather noisy and inefficient (their refcount management is necessarily conservative and so ends up adding some overhead, which is not necessarily good for cache coherency). They also don't tackle circular structures (if that matters to you).
Lastly, full GC has substantial costs of its own (it increases memory consumption of the application, and churns that memory around more rapidly) and a generational collector will outperform pure Boehm on many workloads, though the fact that the Boehm collector supports thread-local allocation is a big plus; a lot of workloads can be split nicely into parts that are constrained to a single thread. The Boehm GC is good, but is it the right kind of good for a website implementation? I'd need to see some evidence - not just opinion - before commenting in depth.
However, once you've written your site, and its become really popular, you owe it to your balance sheet to recode it in something somewhat more efficient (not Java, k) so you don't have to buy 30,000 servers in the first place. Now you know the code, its well documented, and has good interfaces, then recoding it in C++ should be easy. Bear in mind those extra coders required to write it in C++ are going to be employed one way or another, so they don;t get to be included in your site's carbon footprint. Also, those extra coders will not be needed once the infrastructure is written, and they're still going to be a fraction of the energy cost of running Facebook for a few more years.
It's not at all clear that rewriting your site from PHP to C++ would save that much (websites are I/O bound, not CPU bound) and while you might be able to reduce the number of servers a little bit, the cost of such a rewrite (indeed, of a rewrite from anything to anything) is pretty high in itself. For one thing, the chances of screwing up the rewrite are pretty high; it's a non-trivial quantity of code to convert. Plus if you're rewriting your site, you're not adding value to it in other ways.
The cost of carbon is far too low to justify an expensive rewrite.
Correct, but it does not change the premise. Actually, all major C++ compilers are well aware about the situation and are very good at optimizing inlines (and not optimizing when it does not make sense).
They can only really do a good job if they're taking into account the size of the caches, and that's not portable at all. A lot of people don't have the luxury of only ever coding for one processor variant. (Curiously, I work somewhere where that level of optimization is sometimes used for real. But we tend to not use it for C++, reserving it for key Fortran libraries only.)
In fact, what really counts is not inlining itself, but optimization across multiple functions call - in C++, multiple calls can get collapsed into a couple of assembly instructions. Often, such collapsing leads into less code bytes than required to perform function call.
It critically depends on the details, since the real overall win comes when you get to fit everything in a level of cache that is closer to the CPU than before; L1 beats L2 beats memory beats disk (i.e. paged out). If you're only inlining trivial accessors then you're correct, but that's not the only case that people inline. For something longer, it's a much trickier tradeoff. (And inlines have that ABI-bake-in problem which you ignored, which really bites in production libraries. Mainline developers don't see the issue, but maintenance programmers and deployment engineers do.)
BTW, branch prediction does not have anything to do with unconditional procedure calls. Branch prediction is about conditional jumps. That said, yes, modern CPUs are pretty good at about everything.
Actually, branch prediction is also about unconditional jumps. They just happen to be a very easy case.
Like the Captain of a ship, the people at the top of a company should be responsible in any case, even if they didn't know.
What you do is you find the scum that did it and sack them, making them unemployable in any position of financial responsibility while you're at it. (You also carefully investigate whether they actually committed crimes while you're at it; maybe you'll get lucky...) However you also kick out everyone over them all the way up the management tree to Group CEO (obviously those who were asleep at the wheel when this was going on, not necessarily their replacements). Yes, it blights a few lives quite thoroughly, but it also sends out a message to the irresponsible that if they really fuck up, they'll personally lose out a lot too. There's been too little fear to counterbalance the levels of greed over the past few years; time to correct that (and a grand lynching of bankers and related trades is unfortunately illegal).
Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.
You might think so, but it's not as simple as all that. You also have to take into account the CPU's caching behavior; large numbers of inlines can (i.e., I've seen it happen) make the size of the working set too large to fit in L1 (or even L2) cache. That in turn means that you're taking a substantial performance hit. What's better, the size of those caches is dependent on exactly what sort of processor you're working with, so compilers don't take them into account.
Inlining is a trade-off, as it increases the size of the object code in return for removing the cost of a function call. (It's also total poison for any ABI which needs long-term version management, since it effectively bakes internal details of the called objects into the callers' code, even if not at the source level. But I'm digressing) And yet modern CPUs have pretty decent branch predictors, and so the costs of a function call are often very low to almost non-existent...
Then you are fortunate. The JVM is a good abstraction, but it is a leaky one. The point is that you can't just *assume* it will work on any platform that runs a JVM, which was the original (I would claim largely irrelevant) point behind WORA.
Most things work well across platforms these days, even with GUI applications (the major exception being some of the weird-ass things in the Apple JVM's GUI layer). Server applications have been strongly portable for quite a long time.
Compare with C# where your typical app, whether a GUI app or a server app, can't be ported to work with Mono without reworking loads of things. Or what about the other way? Can you take things built with the Mono toolset on Unix and run it with the Microsoft VM on Windows? All the experience my colleagues have got recently with attempting this sort of thing indicates otherwise. If you're working with C#, one way or another you're bound to a particular implementation. (Alas; it's meant we've had to deploy Windows systems rather than sticking to good old Unix...)
Is it possible to have two broken teeth, broken nose, and a white shirt with no red stain?
It depends on how fast someone got in with something to mop up the blood. I guess that was pretty quick (the video of the events was pretty confused...) We also don't know the extent to which his teeth were damaged; "broken" might be a mistransation of (the Italian word for) "chipped" or "cracked".
The question is, did Sun actually buy it to sell commercial licenses, or as a way to push an integrated hardware stack?
Does it matter? Bought is bought, and they get to choose how to go forward with it.
Sun are quite keen on integrated stacks though; that was where they were making their money for many years, and before the financial sector imploded, it was very lucrative. I've a soft spot for Sun hardware, speaking as someone who pushed my Sun kit really hard; it took a licking and kept on ticking.
His Wikipedia page puts his share from the sale to Sun at around EUR 17 million - as it happens, about what Sun spends on MySQL R&D every year.
I don't know about you, but 17M EUR of personal profit sounds pretty neat to me.
But really, PowerShell is better than all of the above.
Depends on whether you think that types are a good thing or a bad thing in shells. If you like types, then PowerShell is indeed MSNirvana(TM). Those of us who think that types are just an annoyance when it comes to sticking programs together to do cool stuff, well, we're just never going to be all that impressed with MS's offering here and will stick to other technologies.
Who's right? I'm definitely biased, but I rather like the POSIX way of doing things.
Also, no, the laches defense requires an affirmative action on the patent owner's part - I send you a notice of infringement, you reply back with a request for a license, and I... disappear. If I never put you on notice, I haven't started the clock ticking.
On the other hand, if you have a patent and don't make any attempt to prevent infringement for many years even if notified of such activity, it does reduce the level of damages that you can claim. Courts don't mollycoddle lazy dumbasses.
Does that apply in patent cases?
Laches? Oh yes, given that there appears to have been no attempt to deal with this matter before now, but it's different if they've been in negotiations over this for a substantial amount of time. It's entirely possible that the court will dictate the terms under which BetaNet offers licenses, but only if what we have here is a matter that's been rumbling on for years between sets of lawyers rather than being sprung upon the defendants like a particularly unpleasant gatecrasher.
Just to be 'that guy', let me point out - If this had actually been modeled, and the news were very, very bad, how long would it remain 'yet to be modeled'?
Not really. Pretending it doesn't exist won't make it go away. About the best we can hope for is that it won't explode until we're all long gone (on a personal level) so that it's someone else's problem.
Cheery thought, yes?
[Amazon] do, since they have to be able to handle peak loads around Christmas and so forth. It just makes good financial sense to make some money off of all that infrastructure when it's not in use.
There's this great myth that Amazon need all this capacity for handling Christmas. They don't. It may have started that way, but now their infrastructure for handling services is much larger than that. (IIRC, they passed that level sometime last year, or maybe even back in 2007.) They are now a cloud provider that happens to sell stuff (books, etc) on the side.
Now, granted, you're correct in that it would be very difficult indeed to achieve that if every single customer used as much, but the point is that they don't, which is why you *can* really have that - the isp in question just needs to not oversell *too* much.
The more they oversell, the lower they can keep their prices (whether or not they do so is another matter). Simple economics. For almost all usage patterns, overselling is fine as traffic is bursty (stochastic sharing is effective) but when you've got people doing bulk downloads and bulk uploads 24/7, that's a different pattern. What's worse is when people are playing tricks to raise the priority of bulk traffic.
Of course, you can pay more to reduce the level of sharing. This is what a business class connection is. (What did you think they were paying for? Using Denon cables?) Or you can decide to be cheap and have a higher level of sharing, which means that you're going to be impacted if you do a lot of bulk transfers. Some of these choices, you make by switching ISP. Your cash, your choice. (In some parts of the world, you have to move to change ISP. This sucks, but is a different matter.)
I expect to have what I've paid for. Do you disagree?
Check what your contract actually says. Don't forget the "fair use" clause(s).
No! We're not gonna take it! We're not gonna take it, anymore.
Stop paying them and you'll indeed not have to put up with it for very much longer.
Let market forces decide who gets it. Forcing buildouts to the far corners of rural America will just inflate everyone else's prices.
Differentiate between the right to get broadband and the right to get broadband cheaply. The former makes sense, and the latter is just uneconomic; an unjustified subsidy of rural areas by urban citizens.
In this case, yes. But a 100% open service whose functionality required a given (open) server to work wouldn't be affected: just change the server and you're back.
Depends on the nature of the service. If it involves large amounts of data and wasn't already set up to replicate the data to a backup system, bringing things back up (whether or not you've got the source code) might be very difficult simply because people don't just want the service itself, but they also want the state embodied by the service. After all, if you had a NAS box with lots of data on it, you wouldn't be able to bring the service provided by it back up just by plugging a new NAS box in. You'd still need to copy the files across, and if the old NAS is down and you've not been backing up properly, you're in trouble. The OS on the NAS boxes (or on the client systems) doesn't matter at all for that fundamental truth.
Services aren't software. Open source software can still form a closed ecosystem (a lot of Linux desktops feel rather that way) and an open ecosystem need not use any OSS. Of course, best of all is when there is an open ecosystem (so people can use anything they want) and OSS is full part of that ecosystem; the open software acts as an insurance against people trying to close things off, and sets a baseline that the closed providers have to do better than.
I'll tolerate your loud headphone music if you tolerate the smell of other peoples' smoke.
That way, we all win.
Alternatively we can just taser the most egregious assholes before garroting them with their own headphone cables. That way, we all win.
Seriously, the enormous majority of people on the train that I see every day when commuting manage to keep volumes low enough that they're just entertaining themselves. That's great! Only a very few feel the need to impose their sucky tastes in music on the rest of us.
Most likely the regulation will apply only to the headphones sold with the player.
More likely to also apply to any after-market headphones that are specifically advertised as being made for or compatible with a particular player. After all, what's the point of an accessory that cannot be used in the manner for which it is intended, and used safely at that.
People are still willing to pay to go to the movies for the superior screen/sound and crowd experience. Although the impact is far less than they claim, I would imagine pirated movies hurt dvd sales more than box office, at least in the US.
Overall people don't mind going to movies. After all, if the film is good and the projectionist is good, then it is (or should be) a great experience. It's not the same thing as the recorded music business, which was never about providing the total experience like movies have been for ages. I suppose a better parallel to a movie is a music concert. Again, it's about the whole experience and people don't mind paying for that. (Well, most people anyway. Enough to make it potentially very profitable.)
The threat posed by the internet to movies is not really piracy. It's that it is a different, new thing for Joe Sixpack to spend his entertainment money on. Is that a problem yet for the movie industry? Probably not, but that's where the real issue is. Note that this is not a legal threat. It's a threat to the very basis of getting such a large proportion of the national entertainment spend. Hollywood have long tried to counter this with things like film tie-ins, special websites, etc, with varying success. Will that change? No idea.
There are only two things I can think of that the world would miss - MySQLe (the embedded version, which competes with BDB-esque type uses - it's a really cool idea) and the solid Windows support (PostgreSQL added this about a year ago - I'm not sure how solid it is yet).
SQLite is great for embedded databases, even on Windows. And would you really want to run a server DB on Windows? About the only reason I can think of offhand is if you're in an all-Microsoft shop, and if that's so, why would you worry about using an open source server DB? Just go for MS's own product; it won't change the amount that you're tied in...
You're not tied to whatever happens to MySQL. You're certainly not tied to what happens to Sun (unless you work there, of course). And you are most certainly not tied to whatever that stupid hypocrite Monty Widenius says. Ignore his pathetic bleatings, and the world will be a better place. That's the good thing about OSS; you can ignore whatever crap that the author of the software is into - including whether they want to support the code - and just focus on whether the software itself is any good for your purposes. (For those of you following along at home, Monty is a stupid hypocrite because he sold out and left, but is still trying to run things; if you take the money and run, you kiss goodbye to that which you sold. That's what a sale is.)