Archive for August, 2008
Reportedly, the USA is falling behind the rest of the world in bandwidth:
The 2008 median real-time download speed in the U.S. is a mere 2.3 megabits per second. This represents a gain of only 0.4 mbps over last year’s median download speed. It compares to an average download speed in Japan of 63 mbps, the survey reveals.
US also trails South Korea at 49 mbps, Finland at 21 mbps, France at 17 mbps, and Canada at 7.6 mbps, and the median upload speed was just 435 kilobits per second (kbps), far too slow for patient monitoring or to transmit large files such as medical records.
But don’t tell Chris Blizzard’s commenters. He writes about Comcast’s annoucement of a 250GB/month bandwidth cap, and gets an earful from commenters from Canada and Europe:
A boo hoo hoo. Major Canadian ISPs have had a limit of 60 GB for months, if not years.
Oh wait… probably the same way as most of the world manages on 10-20GB, for far more money than you’re paying for $250. Not a lot of sympathy from this corner…
Yep, no sympathy from here either — in Australia, with the only _independant_ ISP left, $280 AUD gets you 100GB. $50 with a major telco (the rest of the ISPs here) gets you 5GB.
eg with my current ISP, a 8 MB line with a 300 GB monthly cap costs 20 GBP/month. A 8 MB line with unlimited bandwidth costs 160 GBP/month. Quite a difference!
I pay the equivalent of $40 a month for 30GB, and extra GB on top are $3 each. That’s with Plus Net (http://www.plus.net).
I’m in South Africa paying about $130 for a 10GB cap.
So who’s really better off? By my calculations, if a Canadian ISP provides 7.8 mb/s with a 60 GB cap, that’s about 17.5 hours per month of sustained maximum bandwidth before you’ve blown your limit. By contrast, an American ISP with 2.3 mb/s and a 250 GB cap gives you about 247 hours per month of sustained maximum bandwidth.
Perhaps part of the answer is that only one country–Canada–shows up in the list of “faster countries” and in the comments section of Chris’s post. That could explain the apparent disconnect; maybe Great Britain and Australia are worse off than the USA, while Finland and Japan are better off.
Still, this does bring the question to mind: which is better, raw speed, or the ability to actually use it without fear?
Picking up where we left off last time…
The LSB spec invents things without consulting distros. Like the whole init scripts thing. But that’s not as bad as depending on RPM or requiring a specific layout.
What can be very frustrating is that we do reach out to all the major distros, and a number of the less major ones. But we don’t talk to every single person on every single distro; we can’t. We also try to follow best practices for an open project: open version control, open IRC, open mailing lists.
Part of the problem may be that we also talk to independent software developers, and sometimes, distro people aren’t prepared to hear what developers are saying. So, it looks like we’re pushing things on them, like predictable directory layouts, hooks for working with the user environment, different options for software installation, and the like.
We used to just listen to distros and do what they wanted. Part of the reason there’s still a lingering perception that “the LSB failed” is that software developers saw us as irrelevant. And they were right: we were irrelevant, because we only listened to the distros. So now we listen to both sides, and try to get them to talk to each other, and act as a go-between when they don’t seem able to.
I had an eye-opening experience in Berlin in 2006. We talked to packaging people, and talked about the need for cooperation between package managers and third-party installer tools. A lot of people thought that was a bad idea. So we got them together with some major ISVs in Berlin, and told them to figure it out. And they did figure something out, and surprise! Communication between package managers and third-party installers became a good thing, at least if done right.
And we don’t have a problem with the “done right” part, either. We made a few attempts at proposals for the communication system above, and someone has created an independent implementation. Some of those proposals came under sharp criticism. And we’re cool with that; happy, in fact, that it got attention.
So if you want to find out what’s going on with us, and what terrible things we’re going to make you do in the future, check out our project plan, sign up for our mailing list, or just come by our IRC channel (irc.linuxfoundation.org, #lsb) and ask some questions. We try to be friendly and helpful.
So it looks like the project I’ve been laboring on has been getting some attention:
Ever thought it was difficult to write software for Linux? For multiple distros? InternetNews reports that the LSB is making a push for their next release (due out later this year) that should help make all that much easier.
They even link to our project status page. Cool!
Of course, good publicity invites criticism. This time, there seem to be two themes. William Pitcock seems to have the most succinct summary:
To put things simply, the LSB sucks. Here’s why:
- The LSB spec depends on RPM. I mean, come on. Seriously. Why do they need to require a specific package manager? If package handling is really required, then why not create a simple package format that can be converted on demand into the system package format? Or why care about packages at all?
- The LSB spec invents things without consulting distros. Like the whole init scripts thing. But that’s not as bad as depending on RPM or requiring a specific layout.
(See also Scott James Remnant.)
Let’s take this one part at a time. Today’s topic: packaging.
Part of William’s problem may be that he doesn’t understand the spec. The LSB doesn’t require a specific package manager, or a specific package format. It doesn’t even require that the distribution be set up using package management at all!
The spec only requires that LSB-compliant software be distributed so that any LSB-compliant distribution can install it. That could be tarballs with POSIX-compliant install scripts, an LSB-compliant install binary, a shar archive, a Python script with embedded base64 binaries, whatever. One of the options allowed is an RPM package, with a number of restrictions.
The restrictions are key, because they effectively define a subset of RPM that acts as, to quote William again:
…a simple package format that can be converted on demand into the system package format…
The difference being, of course, that we didn’t reinvent the wheel and create our own; we used a popular format as the basis for ours.
Scott raises another concern:
While much of the LSB can be hacked into a different distribution through compatibility layers and tools, such as alien, what ISV or other vendor wants to provide a support contract against a distribution that has such kludges?
I’m not sure if he’s referring specifically to packaging or to the standard in general. As regards packaging: the reason we specify a strict subset is because we can test that subset, and we’ve tailored it to the needs of tools such as alien. The theory goes that alien isn’t a kludge when it comes to LSB packages.
But, as already mentioned, if vendors aren’t comfortable with supporting RPM, they have a number of other options. As it turns out, most of them are doing just that; the feedback we’re getting from most ISVs is that packaging (whether LSB-subset RPM, full RPM, or Debian) is just not worth the effort.
Coming up: part 2…