Limiting the total data volume per month doesn't help either, because that doesn't keep people from using their quota at the same time as everybody else, so it doesn't prevent congestion. Flat-price metering has the same problem.
However, both provide reasonable constraints, alongside the "unlimited bandwidth" possibility.
Put another way: If everyone used 100% of the electrical capacity in their house, the plant would likely fall over. So what you do is, you charge for the amount used -- then people will at least make some effort to cut back. If they don't, and they still pay the bill, you invest that money in building infrastructure.
For all other utilities, this works. You very rarely have the power go out because everyone turned their AC on at once, or the water run out (or the sewers overflow) because everyone flushed at once (the mythic "superbowl flush", as busted on MythBusters).
Only with Internet do we find so much focus on limiting or penalizing "abuse", rather than simply charging for the amount used, and investing it back into service.
A simple comparison: Two "utility computing" services I know charge about the same -- 10 cents/gig upload (to the server), 20 cents/gig download. In other words, were someone to download 20 gigs from my computer on such a service, it would cost a grand total of... $4.
Contrast this to my current fiber service, capped at 20 gigs/month, for $65/mo. Overage is 50 cents/gig.
Look, I know it costs money to lay fiber. I know it's cheaper to buy bandwidth in bulk for a datacenter, than to run cables all over the last mile.
That still doesn't justify a tenfold increase.
The streams, which are essentially the same for a lot of users, give or take a couple of minutes, are sent in duplicate as unicast streams. That is a terribly inefficient way to send video.
CDNs help with this, and are likely a way for ISPs to both save money (on their connection), and make a little on the side (for hosting the CDN's boxes). I'm not entirely sure how that works -- maybe they usually pay CDNs for the privilege -- but I'd imagine it would be the other way around, or at least free.
If you can't do that, you lose the biggest advantages of a video streaming service: On-demand, and diversity. I can go to YouTube and watch a video no one else wants to watch at the moment, and I can have it start playing instantly, if my connection is fast enough, rather than having to wait for it to start broadcasting from the beginning again.
Multicast is cool, and I hope they find a way to leverage that, especially for live streams (like Internet radio). But it buys you very little for the kind of service we're talking about here.
I am guessing this was debunking the point about "most people don't use that much in a year".
44 * (1024^3) / 365 = 129,437,370 bytes/day
Or, divide that by (1024^2) and you get 123.4 megabytes/day.
In other words: Most people absolutely use that much in a year, and likely quite a bit more.
Now yes, in one month, it comes to 1.5 gigs/day, or one and a half HD Hulu shows. Replace your TV service with something like Hulu or YouTube and you're easily over that, even for a single person -- never mind a roommate.
In fact, take a closer look -- Time Warner? What other business are they in? I wouldn't be surprised to find Cable TV. And what happens to the value of cable TV when it has to compete with Internet TV?
You can't even provide a possible zip code or city?
If you read the journal entry I linked to, you'd know that I haven't decided where to. Being unemployed, it doesn't really matter to me -- the two biggest criterion are:
- Hopefully somewhere I can get a job
and
- Decent Internet.
So there you go -- find me somewhere in the US that offers a better deal than Lisco Fiber.
there are parts of the Backbone that are oversold, and it would be physically impossible for every customer to use 100% of the bandwidth at one time and get the speed they were advertised.
Then that is the problem than needs fixing, not these "abusers".
Rather than going after "abusers", you want to start upgrading your network now to accommodate them, before the majority discover sites like Hulu and Youtube.
But the majority would not want their fees to go up because of that kind of usage.
Nor, I suspect, would the majority want to get hit with that lecture the second they discover how to actually use the connection they've been sold.
Best of both worlds -- you don't have to make any scary choices, as most of the software you need is preinstalled, and they've made those choices for you (you'll be using GNOME, end of story).
But, the moment you know enough about the above choices to want to change something, you can.
"Hello, help desk"..."ok, I need for you to tell me the following 35 different things..."
Oh, that's what Ubuntu is for. My point is that any claim that Linux "kills competition" is simply uneducated.
It all setteled down because people didn't want to deal with that many combos.
You sure it didn't also have something to do with compatibility? See, the huge difference here is, nothing stops me from running GNOME apps on KDE, or vice versa. All those changes I might make, and chances are, all the other stuff still works.
Now, if I could buy a plain DVD with such a file that I could drag-and-drop to my hard drive, and then dispose of the DVD or toss the plain DVD on to a spool somewhere that would be fine too.
On OS X: Open up Disk Utility. Click the DVD drive. Then select File -> New -> Disk Image (this may have changed, been awhile since I used a Mac).
On Linux: cp/dev/dvd movie.img
If the above fails, or if you're on Windows: Drag and drop all files off the DVD onto a folder in your hard drive.
VLC and mplayer can both be used to play either a raw image, or a VIDEO_TS folder. The biggest problem you might have are discs that add other "copy protection" in the form of unreadable sectors, designed to prevent exactly this kind of thing.
Technically it is possible to copy DVDs to a hard drive but as everyone here knows that is forbidden by a truckload of laws!!!
Actually, just the DMCA's anti-circumvention law. And technically, with the above technique, you won't be breaking it until you attempt to play the movie.
Oh, and should I mention how painful dealing with most regular DVDs are? Put in the DVD and be forced to watch a dozen commercials for crap?
Most DVDs don't do this. But VLC to the rescue again...
So why do I even want a physical MPAA-pressed DVD again?
Because, depending on your Internet connection, it may still be cheaper and more convenient to rent a DVD and rip it than to download something of similar quality from the Internet. However, you've identified many ways the MPAA tries to make this not so...
If you have an unlimited Blockbuster or Netflicks account you could "back up" dozens of movies a month for less than a $1 a piece. The potential is a massive loss to the filmmakers,
What, that I might now have even more of an incentive to keep that Blockbuster or Netflix account?
And, pray tell, how did video stores ever survive before the invention of DVDs? It certainly wasn't difficult to copy a VHS tape. Then again, maybe you bought Jack Valenti's "Jack the Ripper" line.
It's already very hard to lock down distribution as an indy.
Dude. You have BitTorrent. You have YouTube. Distribution is easier now than it ever was. A single person with a little tech savvy can distribute to as many users as he can find.
Copyright laws should be stronger for the artists and weaker for the corporations.
They should also be stronger for the consumers. Without them, neither the artists nor the corporations would have a job.
Most of them still attempt to sell DRM-locked formats, like the Kindle or various PDF / MSreader abominations. PDF by itself is a fine format, but PDF + DRM is just annoying.
If I'm unhappy about something provided by competitive private sector, I can always switch.
Again, this assumes that there is something to switch to. Not all monopolies are government-created. Microsoft, for instance, grabbed its current monopoly status through simple business tactics.
The alternatives cannot compete, reasonably, because to do so, they would not only have to duplicate all of Microsoft's work -- and I do mean all; it would have to run existing Windows apps perfectly -- they would also have to build a product significantly better to be worth the risk for most people to try it out. These two goals are, to a certain extent, mutually exclusive.
private ones don't survive very long in that stage
Citation needed... I see quite a few that seem to last entirely too long. Microsoft, for example.
If you assume Apple would fill that void, I wholeheartedly agree. In their own way, they are worse than Microsoft.
However, if Linux filled that void, that is actually much better. Have you not noticed?
There is competition on every level on Linux, from the kernel down.
On the kernel level, you can have Linux, Solaris, BSD, Darwin, even HURD.
If you choose Linux, you can use ext3, xfs, jfs, or reiserfs -- and those are just the ones off the top of my head that are reasonably stable and fit for desktop use.
There are alternate init systems -- everything from old-school sysvinit to Apple's launchd to Gentoo's weird dependency system to Ubuntu's upstart.
There are alternate shells -- bash, dash, csh, ksh, rush, emacs...
There have even been a few attempts at alternate X servers, though X.org remains pretty key for now.
There are alternate desktop environments -- GNOME, KDE, XFCE, etc -- and alternate window managers which can be used within those, or by themselves -- metacity, compiz, kwin, fluxbox, ratpoison, windowmaker, fvwm, twm... Or none at all.
There are alternate file browsers -- Gentoo, Nautilus, Konqueror, Dolphin, Midnight Commander, bash...
There are alternate web browsers -- Firefox, Konqueror, Epiphany, Galeon, Opera...
There are alternate package managers -- apt, rpm, portage, ports...
And there are alternate distros to wrap it all up.
Trust me, if Ubuntu ever gains a dominant position, that would be more consumer choice, and more competition, not less. The most obvious reason? I'd probably be using Kubuntu.
And that's ignoring the reasons competition doesn't matter as much, for open source things...
This all comes as Microsoft posts quarterly sales that have fallen for the first time in the company's 23-year history.
This is a perfect opportunity for trash talk! Suck on failure, Microsoft! Sales looking a little limp this quarter? I guess that's why they call it both micro and soft!
Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. It could do everything wrong for a decade before it started to be in remote danger, and you never know... they could reinvent themselves as a shaved-ice company at the last minute.
It's good to see a hint that this fall might finally be starting, but even in this economy, it will be a long time before Microsoft dies.
I live in a small town in Iowa, and until recently, I had 100 mbit fiber, for $65/mo.
Granted, it's capped at 20 gigs/mo, with 50 cents/gig overage. But still, I find it amazing that there are places in this country where your choice is satellite, dialup, or cell.
Doesn't the garbage collector rely on malloc/free internally?
It does. However, it's how these are used...
The first advantage is: Bulk allocation is more efficient than individual allocation. I assume when you say "used properly", you mean allocating some memory for a task (or an object, say), performing the task, and then freeing that memory. Basically, like writing destructors properly in C++.
The garbage collector can maintain a heap of memory internally, and allocate more (or free chunks of it) in much larger units than a single object. For an extreme example, small Ruby scripts (simple commands and such), which never use much RAM before they exit a few milliseconds later, will perform exactly one malloc at the beginning for some small chunk of RAM, and not free it until the program terminates.
The second advantage is: All those malloc/free calls, and any logic around them (like reference counting on shared resources, say) -- all of that is code. That takes up RAM (who cares), and Cache (important!). It's basically equivalent to having garbage collection code running all the time, adding significant overhead to your application code.
Contrast to a GC'd application, the garbage collector tends to run only periodically -- triggered by things like a timer, or a certain number of allocations, or a certain amount of memory used... It's not going to be running all the time. That means when it's running, it isn't sharing cache with your application code -- and similarly, when you application is running, it isn't sharing cache with the garbage collector.
That added cache coherency alone can sometimes make up for what time it takes to run the garbage collector.
(I assume you are talking about efficiency of code execution, not cost of maintainance or how easy it is to understand the code).
Well, within reason. Technically speaking, you could write code which allocates and frees at exactly the optimum points, for a given CPU and set of circumstances... But at that point, you've just written a highly specialized garbage collector. It might be more efficient than the standard one, it might not -- it's really analogous to writing assembly instead of C. Sometimes it's justified, but most of the time, the compiler (or garbage collector) will do a better job than you will, in much less time.
Another advantage shared by both compiled languages and garbage collectors (versus assembly or manual memory management) is that the compiler (or garbage collector) can be improved, independently of your application. In fact, this can be said for any code you don't write yourself -- it's likely that this code will be shared with others, and well understood, and refined to where you're really not going to do a better job yourself.
All of this said... I don't have benchmarks to back this up. It is theoretical, though I'm sure I could find the whitepaper I read on it. The whitepaper was actually comparing apples to apples -- Boehm GC vs manual malloc/free strategies, both in C.
As for other runtime optimizations, there's a crazy anecdote where someone wrote a VM that executed the same exact RISC instruction set as the hardware it ran on. But some programs written for that hardware actually ran faster inside the VM. In fact, I believe this is the premise behind LLVM -- GCC already gives you compile-time optimizations; LLVM adds link time, runtime, and idle time optimizations.
Yeah, but that's all behind the scenes stuff - it isn't something that most users will be able to point to and say "that does X Y and Z and is worth the bloat".
However, if it wasn't there, they could point to it and say "Why do I have to do all this shit to get my digital camera working? It Just Works on Windows!"
the only thing it does for me is channel mixing in software... which is a shame since I get channel mixing in hardware if I'm not running this "improvement"...
My understanding is, it should be able to use that hardware mixing, too, when available. No idea if that's working yet.
no compile-time typechecking and no requirement to declare variables before use.
Compile-time typechecking is overrated. Duck typing and unit tests are much better.
maybe because you typoed the attribute name,
If this happened, and you had decent test coverage, your tests wouldn't pass. However, type checking and variable names are only a subset of what a test can cover. People use them in static languages, too.
I also dispute the idea that you can't have memory leaks in Python
Didn't say "can't". However, there is a certain class of "I forgot to free this" memory leak that is impossible.
garbage collection often leads to lazyness where the programmer never even thinks about freeing memory (and thus destroying references to objects as soon as they have finished with them
Given most garbage collectors don't make it terribly easy to free memory explicitly, I'd expect that.
And the other point is, it'd be a premature optimization. Once you find your program is using too much RAM, that's when to start thinking about this. Even then, you want to measure where the leaks actually are.
I think that's a much better use of your time than developing a habit of running free() as much as possible, especially when that may actually be slower.
I wouldn't say "always" though - there's a point where the price of absolutely tiny reliability gains is just too high
Thus the qualifier "almost" always.
And certainly, there is bloat which does nothing for reliability.
In a lot of cases it provides easier development, but in far too many cases it just seems to be down to stubborn programmers using an unsuitable technology because they don't want to learn the suitable one.
I know C. I would not use it where it isn't needed.
You can write downright ugly code in any language. On the other hand, I've seen some downright elegant C code
Yes, you can also write elegant code in any language. Drupal is proof that you can write elegant PHP.
By virtue of being Turing-complete, anything I can write in Ruby, you can write in C. After all, Ruby itself is written in C.
The more important question is, how much of your time will you spend fighting the language? Or re-inventing things that a higher-level language might provide for you? After all, Ruby 1.9.1 includes over a million lines of C (including various libraries).
Your Ruby code may get faster over the years, but so will the C program.
That is true. However, at a certain point it is "fast enough". A command that runs in 10 milliseconds isn't that much better of a user experience than one that runs in 100 milliseconds. If that 10-millisecond command segfaults ever, it loses.
Also worth mentioning, in a business setting, if my Ruby code gets to market before the C program, I'll have enough business and cash to rewrite it in C, if I have to, and I'll have learned exactly what kind of load I'll be dealing with. I suppose that's what you meant by "prototyping".
HAL, UDEV, PulseAudio, etc. To the end user they don't offer a really noticeable advantage and they do add to the bloat.
HAL and UDEV make devices work better and easier. Things like being able to plug a USB hard drive in, and have it autodetected and ready to mount, is directly the result of udev.
Also, udev isn't slow. I've used it on incredibly weak hardware. Trust me, it's not the bottleneck.
PulseAudio, you might have a point -- at least in that the user-visible improvement isn't there yet, unless your soundcard is too weak to handle multiple audio streams -- I know I configure everything to just use ALSA.
But it will come. Like Vista -- having a volume knob per-app would be very useful.
There are a whole load of processes running and socking up memory that just don't need to be there too - the PC Card daemon (this is a desktop machine with no PC Card slots), the Bluetooth daemons (this machine has no bluetooth interface), gpm, gnome-power-monitor (why do I need this on a desktop machine?), etc.
That is true -- it would be very nice if these things could be handled by some sort of hotplug script (which you still need HAL and udev for), so that the moment a PC card slot appears, you're ready for it.
Interestingly, I see absolutely no bluetooth icon on my Kubuntu 8.10 machine (can't risk upgrading yet), until I turn it on (via the hardware switch).
And yes, I know I could spend hours tuning my system, but my point is that I shouldn't have to - there's no need for modern systems to have all this bloat running all the time, it's just there because it is easier to be lazy and tell people to get better hardware than write efficient systems.
Well, yes and no. I used to spend hours tuning my system, when I had a 200 mhz machine with 256 megs of RAM. I even carried these same habits to my 1.7 ghz machine with 512 megs of RAM.
Now I have a 2.5 ghz dual-core with 4 gigs of RAM. The slowest it will run is 800 mhz. And it's a laptop.
It is simply not worth my time to run around tuning this stuff. It's not a personal itch I feel like scratching. Just let it eat 200 mhz (more than my old machine even had) and a gig or two of RAM -- better than me having to spend hours tweaking it.
If someone else wants to, that's great! Certainly, I'll tend to use more efficient alternatives when they work -- for example, as I'm in KDE, I'm writing this post in Konqueror, rather than Firefox. But for the most part, it's just not worth it.
a lot of stuff is now written in Python and Java. As far as I'm concerned, there is absolutely no sane reason to use a system like Java with the overhead of a VM when you already know what architecture the binaries will be running on when you build them.
Firstly, Java can actually do some runtime optimizations that (for example) C can't. There are even circumstances where a garbage collector is faster than manual malloc/free. So purely from a performance aspect, it's not quite as clean as you think.
Second, there's still Python. And I don't know about you, but I'd much rather most of my system be written in Python than in C. Just by virtue of the respective languages, less code to do the same things means less bugs, garbage collection means fewer memory leaks and fewer segfaults, and really no sane possibility of buffer overruns...
I don't know about you, but I'll almost always trade a few more cycles for a bit more reliability and security.
The reason? With apologies to Churchill: My Ruby script may be slow today, but it will get faster as the hardware and interpreters improve. Your C program, however, will still be ugly. (Uglier code, more of it, and buggier...)
Slashdot Mirror
Limiting the total data volume per month doesn't help either, because that doesn't keep people from using their quota at the same time as everybody else, so it doesn't prevent congestion. Flat-price metering has the same problem.
However, both provide reasonable constraints, alongside the "unlimited bandwidth" possibility.
Put another way: If everyone used 100% of the electrical capacity in their house, the plant would likely fall over. So what you do is, you charge for the amount used -- then people will at least make some effort to cut back. If they don't, and they still pay the bill, you invest that money in building infrastructure.
For all other utilities, this works. You very rarely have the power go out because everyone turned their AC on at once, or the water run out (or the sewers overflow) because everyone flushed at once (the mythic "superbowl flush", as busted on MythBusters).
Only with Internet do we find so much focus on limiting or penalizing "abuse", rather than simply charging for the amount used, and investing it back into service.
A simple comparison: Two "utility computing" services I know charge about the same -- 10 cents/gig upload (to the server), 20 cents/gig download. In other words, were someone to download 20 gigs from my computer on such a service, it would cost a grand total of... $4.
Contrast this to my current fiber service, capped at 20 gigs/month, for $65/mo. Overage is 50 cents/gig.
Look, I know it costs money to lay fiber. I know it's cheaper to buy bandwidth in bulk for a datacenter, than to run cables all over the last mile.
That still doesn't justify a tenfold increase.
The streams, which are essentially the same for a lot of users, give or take a couple of minutes, are sent in duplicate as unicast streams. That is a terribly inefficient way to send video.
CDNs help with this, and are likely a way for ISPs to both save money (on their connection), and make a little on the side (for hosting the CDN's boxes). I'm not entirely sure how that works -- maybe they usually pay CDNs for the privilege -- but I'd imagine it would be the other way around, or at least free.
If you can't do that, you lose the biggest advantages of a video streaming service: On-demand, and diversity. I can go to YouTube and watch a video no one else wants to watch at the moment, and I can have it start playing instantly, if my connection is fast enough, rather than having to wait for it to start broadcasting from the beginning again.
Multicast is cool, and I hope they find a way to leverage that, especially for live streams (like Internet radio). But it buys you very little for the kind of service we're talking about here.
I am guessing this was debunking the point about "most people don't use that much in a year".
44 * (1024^3) / 365 = 129,437,370 bytes/day
Or, divide that by (1024^2) and you get 123.4 megabytes/day.
In other words: Most people absolutely use that much in a year, and likely quite a bit more.
Now yes, in one month, it comes to 1.5 gigs/day, or one and a half HD Hulu shows. Replace your TV service with something like Hulu or YouTube and you're easily over that, even for a single person -- never mind a roommate.
In fact, take a closer look -- Time Warner? What other business are they in? I wouldn't be surprised to find Cable TV. And what happens to the value of cable TV when it has to compete with Internet TV?
You can't even provide a possible zip code or city?
If you read the journal entry I linked to, you'd know that I haven't decided where to. Being unemployed, it doesn't really matter to me -- the two biggest criterion are:
- Hopefully somewhere I can get a job
and
- Decent Internet.
So there you go -- find me somewhere in the US that offers a better deal than Lisco Fiber.
If you're streaming 10hrs a day of music 7 days a week at home, you need to go get a job.
And what if I work from home, and like listening to the music while I work?
That was just over a 1/4 of the 44GB....got something better?
That was 1/4th for a single machine. Now imagine a family of 4, or a slight increase in quality...
there are parts of the Backbone that are oversold, and it would be physically impossible for every customer to use 100% of the bandwidth at one time and get the speed they were advertised.
Then that is the problem than needs fixing, not these "abusers".
44 GB is more than most people use in a year.
...yet.
Rather than going after "abusers", you want to start upgrading your network now to accommodate them, before the majority discover sites like Hulu and Youtube.
But the majority would not want their fees to go up because of that kind of usage.
Nor, I suspect, would the majority want to get hit with that lecture the second they discover how to actually use the connection they've been sold.
Ubuntu Just Works.
Best of both worlds -- you don't have to make any scary choices, as most of the software you need is preinstalled, and they've made those choices for you (you'll be using GNOME, end of story).
But, the moment you know enough about the above choices to want to change something, you can.
No, actually, we just tell people to use Ubuntu, if they don't want to deal with choice.
"Hello, help desk"..."ok, I need for you to tell me the following 35 different things..."
Oh, that's what Ubuntu is for. My point is that any claim that Linux "kills competition" is simply uneducated.
It all setteled down because people didn't want to deal with that many combos.
You sure it didn't also have something to do with compatibility? See, the huge difference here is, nothing stops me from running GNOME apps on KDE, or vice versa. All those changes I might make, and chances are, all the other stuff still works.
...of ISPs I will avoid.
Hey, I might be moving soon, so I might actually have a choice. Is there anyone decent out there?
Now, if I could buy a plain DVD with such a file that I could drag-and-drop to my hard drive, and then dispose of the DVD or toss the plain DVD on to a spool somewhere that would be fine too.
On OS X: Open up Disk Utility. Click the DVD drive. Then select File -> New -> Disk Image (this may have changed, been awhile since I used a Mac).
On Linux: cp /dev/dvd movie.img
If the above fails, or if you're on Windows: Drag and drop all files off the DVD onto a folder in your hard drive.
VLC and mplayer can both be used to play either a raw image, or a VIDEO_TS folder. The biggest problem you might have are discs that add other "copy protection" in the form of unreadable sectors, designed to prevent exactly this kind of thing.
Technically it is possible to copy DVDs to a hard drive but as everyone here knows that is forbidden by a truckload of laws!!!
Actually, just the DMCA's anti-circumvention law. And technically, with the above technique, you won't be breaking it until you attempt to play the movie.
Oh, and should I mention how painful dealing with most regular DVDs are? Put in the DVD and be forced to watch a dozen commercials for crap?
Most DVDs don't do this. But VLC to the rescue again...
So why do I even want a physical MPAA-pressed DVD again?
Because, depending on your Internet connection, it may still be cheaper and more convenient to rent a DVD and rip it than to download something of similar quality from the Internet. However, you've identified many ways the MPAA tries to make this not so...
If you have an unlimited Blockbuster or Netflicks account you could "back up" dozens of movies a month for less than a $1 a piece. The potential is a massive loss to the filmmakers,
What, that I might now have even more of an incentive to keep that Blockbuster or Netflix account?
And, pray tell, how did video stores ever survive before the invention of DVDs? It certainly wasn't difficult to copy a VHS tape. Then again, maybe you bought Jack Valenti's "Jack the Ripper" line.
It's already very hard to lock down distribution as an indy.
Dude. You have BitTorrent. You have YouTube. Distribution is easier now than it ever was. A single person with a little tech savvy can distribute to as many users as he can find.
Copyright laws should be stronger for the artists and weaker for the corporations.
They should also be stronger for the consumers. Without them, neither the artists nor the corporations would have a job.
In other words, it's about controlling what you watch, and how you watch it.
In which case, they should be applauding Real's effort. Unlike, say, AnyDVD, Real is actually re-DRM-ing the rip, thus taking back that control.
They should be looking to partner with Real, not sue them.
Of course, in a saner world, they should just give up...
I'd rather see AnyDVD remain legal, even if it means Real takes longer to die.
Baen did. The Pragmatic Programmers did.
Most of them still attempt to sell DRM-locked formats, like the Kindle or various PDF / MSreader abominations. PDF by itself is a fine format, but PDF + DRM is just annoying.
The essential problem is, it's entirely legal to make such a backup copy.
It is, however, illegal to reverse engineer and crack the DRM measures that would prevent you from making such a copy.
Grpuavpnyyl fcrnxvat, vg'f vyyrtny sbe lbh gb ernq guvf grkg, vs V vagraqrq guvf EBG13 "rapelcgvba" gb cerirag lbh sebz cvengvat vg.
If I'm unhappy about something provided by competitive private sector, I can always switch.
Again, this assumes that there is something to switch to. Not all monopolies are government-created. Microsoft, for instance, grabbed its current monopoly status through simple business tactics.
The alternatives cannot compete, reasonably, because to do so, they would not only have to duplicate all of Microsoft's work -- and I do mean all; it would have to run existing Windows apps perfectly -- they would also have to build a product significantly better to be worth the risk for most people to try it out. These two goals are, to a certain extent, mutually exclusive.
private ones don't survive very long in that stage
Citation needed... I see quite a few that seem to last entirely too long. Microsoft, for example.
We need more competition not less.
If you assume Apple would fill that void, I wholeheartedly agree. In their own way, they are worse than Microsoft.
However, if Linux filled that void, that is actually much better. Have you not noticed?
There is competition on every level on Linux, from the kernel down.
On the kernel level, you can have Linux, Solaris, BSD, Darwin, even HURD.
If you choose Linux, you can use ext3, xfs, jfs, or reiserfs -- and those are just the ones off the top of my head that are reasonably stable and fit for desktop use.
There are alternate init systems -- everything from old-school sysvinit to Apple's launchd to Gentoo's weird dependency system to Ubuntu's upstart.
There are alternate shells -- bash, dash, csh, ksh, rush, emacs...
There have even been a few attempts at alternate X servers, though X.org remains pretty key for now.
There are alternate desktop environments -- GNOME, KDE, XFCE, etc -- and alternate window managers which can be used within those, or by themselves -- metacity, compiz, kwin, fluxbox, ratpoison, windowmaker, fvwm, twm... Or none at all.
There are alternate file browsers -- Gentoo, Nautilus, Konqueror, Dolphin, Midnight Commander, bash...
There are alternate web browsers -- Firefox, Konqueror, Epiphany, Galeon, Opera...
There are alternate package managers -- apt, rpm, portage, ports...
And there are alternate distros to wrap it all up.
Trust me, if Ubuntu ever gains a dominant position, that would be more consumer choice, and more competition, not less. The most obvious reason? I'd probably be using Kubuntu.
And that's ignoring the reasons competition doesn't matter as much, for open source things...
This all comes as Microsoft posts quarterly sales that have fallen for the first time in the company's 23-year history.
This is a perfect opportunity for trash talk! Suck on failure, Microsoft! Sales looking a little limp this quarter? I guess that's why they call it both micro and soft!
Heh. More seriously, as Joel points out:
Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. It could do everything wrong for a decade before it started to be in remote danger, and you never know... they could reinvent themselves as a shaved-ice company at the last minute.
It's good to see a hint that this fall might finally be starting, but even in this economy, it will be a long time before Microsoft dies.
What, like ZFS?
Where's all my cool Linux stuff on Solaris, though?
I live in a small town in Iowa, and until recently, I had 100 mbit fiber, for $65/mo.
Granted, it's capped at 20 gigs/mo, with 50 cents/gig overage. But still, I find it amazing that there are places in this country where your choice is satellite, dialup, or cell.
Speaking of which: Does anyone know where I can get better Internet?
Can you provide more details?
Seems I have to, every time this comes up...
Doesn't the garbage collector rely on malloc/free internally?
It does. However, it's how these are used...
The first advantage is: Bulk allocation is more efficient than individual allocation. I assume when you say "used properly", you mean allocating some memory for a task (or an object, say), performing the task, and then freeing that memory. Basically, like writing destructors properly in C++.
The garbage collector can maintain a heap of memory internally, and allocate more (or free chunks of it) in much larger units than a single object. For an extreme example, small Ruby scripts (simple commands and such), which never use much RAM before they exit a few milliseconds later, will perform exactly one malloc at the beginning for some small chunk of RAM, and not free it until the program terminates.
The second advantage is: All those malloc/free calls, and any logic around them (like reference counting on shared resources, say) -- all of that is code. That takes up RAM (who cares), and Cache (important!). It's basically equivalent to having garbage collection code running all the time, adding significant overhead to your application code.
Contrast to a GC'd application, the garbage collector tends to run only periodically -- triggered by things like a timer, or a certain number of allocations, or a certain amount of memory used... It's not going to be running all the time. That means when it's running, it isn't sharing cache with your application code -- and similarly, when you application is running, it isn't sharing cache with the garbage collector.
That added cache coherency alone can sometimes make up for what time it takes to run the garbage collector.
(I assume you are talking about efficiency of code execution, not cost of maintainance or how easy it is to understand the code).
Well, within reason. Technically speaking, you could write code which allocates and frees at exactly the optimum points, for a given CPU and set of circumstances... But at that point, you've just written a highly specialized garbage collector. It might be more efficient than the standard one, it might not -- it's really analogous to writing assembly instead of C. Sometimes it's justified, but most of the time, the compiler (or garbage collector) will do a better job than you will, in much less time.
Another advantage shared by both compiled languages and garbage collectors (versus assembly or manual memory management) is that the compiler (or garbage collector) can be improved, independently of your application. In fact, this can be said for any code you don't write yourself -- it's likely that this code will be shared with others, and well understood, and refined to where you're really not going to do a better job yourself.
All of this said... I don't have benchmarks to back this up. It is theoretical, though I'm sure I could find the whitepaper I read on it. The whitepaper was actually comparing apples to apples -- Boehm GC vs manual malloc/free strategies, both in C.
As for other runtime optimizations, there's a crazy anecdote where someone wrote a VM that executed the same exact RISC instruction set as the hardware it ran on. But some programs written for that hardware actually ran faster inside the VM. In fact, I believe this is the premise behind LLVM -- GCC already gives you compile-time optimizations; LLVM adds link time, runtime, and idle time optimizations.
Yeah, but that's all behind the scenes stuff - it isn't something that most users will be able to point to and say "that does X Y and Z and is worth the bloat".
However, if it wasn't there, they could point to it and say "Why do I have to do all this shit to get my digital camera working? It Just Works on Windows!"
the only thing it does for me is channel mixing in software... which is a shame since I get channel mixing in hardware if I'm not running this "improvement"...
My understanding is, it should be able to use that hardware mixing, too, when available. No idea if that's working yet.
no compile-time typechecking and no requirement to declare variables before use.
Compile-time typechecking is overrated. Duck typing and unit tests are much better.
maybe because you typoed the attribute name,
If this happened, and you had decent test coverage, your tests wouldn't pass. However, type checking and variable names are only a subset of what a test can cover. People use them in static languages, too.
I also dispute the idea that you can't have memory leaks in Python
Didn't say "can't". However, there is a certain class of "I forgot to free this" memory leak that is impossible.
garbage collection often leads to lazyness where the programmer never even thinks about freeing memory (and thus destroying references to objects as soon as they have finished with them
Given most garbage collectors don't make it terribly easy to free memory explicitly, I'd expect that.
And the other point is, it'd be a premature optimization. Once you find your program is using too much RAM, that's when to start thinking about this. Even then, you want to measure where the leaks actually are.
I think that's a much better use of your time than developing a habit of running free() as much as possible, especially when that may actually be slower.
I wouldn't say "always" though - there's a point where the price of absolutely tiny reliability gains is just too high
Thus the qualifier "almost" always.
And certainly, there is bloat which does nothing for reliability.
In a lot of cases it provides easier development, but in far too many cases it just seems to be down to stubborn programmers using an unsuitable technology because they don't want to learn the suitable one.
I know C. I would not use it where it isn't needed.
You can write downright ugly code in any language. On the other hand, I've seen some downright elegant C code
Yes, you can also write elegant code in any language. Drupal is proof that you can write elegant PHP.
By virtue of being Turing-complete, anything I can write in Ruby, you can write in C. After all, Ruby itself is written in C.
The more important question is, how much of your time will you spend fighting the language? Or re-inventing things that a higher-level language might provide for you? After all, Ruby 1.9.1 includes over a million lines of C (including various libraries).
Your Ruby code may get faster over the years, but so will the C program.
That is true. However, at a certain point it is "fast enough". A command that runs in 10 milliseconds isn't that much better of a user experience than one that runs in 100 milliseconds. If that 10-millisecond command segfaults ever, it loses.
Also worth mentioning, in a business setting, if my Ruby code gets to market before the C program, I'll have enough business and cash to rewrite it in C, if I have to, and I'll have learned exactly what kind of load I'll be dealing with. I suppose that's what you meant by "prototyping".
HAL, UDEV, PulseAudio, etc. To the end user they don't offer a really noticeable advantage and they do add to the bloat.
HAL and UDEV make devices work better and easier. Things like being able to plug a USB hard drive in, and have it autodetected and ready to mount, is directly the result of udev.
Also, udev isn't slow. I've used it on incredibly weak hardware. Trust me, it's not the bottleneck.
PulseAudio, you might have a point -- at least in that the user-visible improvement isn't there yet, unless your soundcard is too weak to handle multiple audio streams -- I know I configure everything to just use ALSA.
But it will come. Like Vista -- having a volume knob per-app would be very useful.
There are a whole load of processes running and socking up memory that just don't need to be there too - the PC Card daemon (this is a desktop machine with no PC Card slots), the Bluetooth daemons (this machine has no bluetooth interface), gpm, gnome-power-monitor (why do I need this on a desktop machine?), etc.
That is true -- it would be very nice if these things could be handled by some sort of hotplug script (which you still need HAL and udev for), so that the moment a PC card slot appears, you're ready for it.
Interestingly, I see absolutely no bluetooth icon on my Kubuntu 8.10 machine (can't risk upgrading yet), until I turn it on (via the hardware switch).
And yes, I know I could spend hours tuning my system, but my point is that I shouldn't have to - there's no need for modern systems to have all this bloat running all the time, it's just there because it is easier to be lazy and tell people to get better hardware than write efficient systems.
Well, yes and no. I used to spend hours tuning my system, when I had a 200 mhz machine with 256 megs of RAM. I even carried these same habits to my 1.7 ghz machine with 512 megs of RAM.
Now I have a 2.5 ghz dual-core with 4 gigs of RAM. The slowest it will run is 800 mhz. And it's a laptop.
It is simply not worth my time to run around tuning this stuff. It's not a personal itch I feel like scratching. Just let it eat 200 mhz (more than my old machine even had) and a gig or two of RAM -- better than me having to spend hours tweaking it.
If someone else wants to, that's great! Certainly, I'll tend to use more efficient alternatives when they work -- for example, as I'm in KDE, I'm writing this post in Konqueror, rather than Firefox. But for the most part, it's just not worth it.
a lot of stuff is now written in Python and Java. As far as I'm concerned, there is absolutely no sane reason to use a system like Java with the overhead of a VM when you already know what architecture the binaries will be running on when you build them.
Firstly, Java can actually do some runtime optimizations that (for example) C can't. There are even circumstances where a garbage collector is faster than manual malloc/free. So purely from a performance aspect, it's not quite as clean as you think.
Second, there's still Python. And I don't know about you, but I'd much rather most of my system be written in Python than in C. Just by virtue of the respective languages, less code to do the same things means less bugs, garbage collection means fewer memory leaks and fewer segfaults, and really no sane possibility of buffer overruns...
I don't know about you, but I'll almost always trade a few more cycles for a bit more reliability and security.
The reason? With apologies to Churchill: My Ruby script may be slow today, but it will get faster as the hardware and interpreters improve. Your C program, however, will still be ugly. (Uglier code, more of it, and buggier...)