Slashdot Mirror

Lately, what I have been primarily running has been Ubuntu's Maverick Meerkat's alpha and then beta. Not to suggest the alpha was always rock-solid - sometimes huge bugs crept up in it that had me switching back to my stable Ubuntu Lucid Lynx distribution. But if they were bad they were usually dealt with swiftly.

Here is why I think Ubuntu, Canonical and Maverick Meerkat have done a great job.

In February of this year, I was installing Debian squeeze on another system. Once installed, I looked in /etc/fstab to see information on my disk partitions. The disk information was in UUID format, and a comment line in fstab said "Use 'vol_id --uuid' to print the universally unique identifier for a device". So, I did what the file told me and did a "vol_id --uuid". But it didn't work. There was no vol_id program. I did a little digging and saw that the vol_id program had been a part of the udev package on lenny, but now it no longer was. The program to decode those mysterious UUID's had disappeared. I did a little more digging and discovered the blkid program in the util-linux package could decode those UUIDs. I tried it out, it translated the UUIDs to device names for me, and I was happy. However, I realized /etc/fstab was still giving everyone faulty information. So in February I filed a bug report with Debian.

So now it is October, and my bug report sits in Debian's bug tracker, undisturbed by anyone. There have been four updates to the partman-target package (which creates the initial /etc/fstab) since my bug, but none implementing my suggestion to remove the outdated suggestion of using the no longer existent vol_id program, and replacing it with a suggestion to use blkid. In August, Debian squeeze froze in anticipation of release, so it becomes more unlikely my bug will be fixed.

So where does Ubuntu stand with all of this? Well back in May, Ubuntu resynchronized their partman-target with Debian. While doing so, someone checked out Debian's bug tracker, saw my report, and fixed the problem in Ubuntu. While their change log in May notes this, I can see it myself when looking at /etc/fstab on my meerkat - "Use 'blkid -o value -s UUID' to print the universally unique identifier for a device".

So this - I find impressive. I am having a problem with Debian and report a bug there, although it remains unfixed. But Ubuntu comes in and fixes the bug which was put on the bug tracker of another system.

Yes, this is just talking about the quality of the distribution and not all of the other things involved, which of course, are important. I know how some Debian developers were (and some still are) unhappy with Canonical and Ubuntu, and how some other upstream contributors are unhappy with Canonical (like Linux developer Greg Kroah-Hartman) and so forth. And whatever acrimony exists, I think the Debian folks and Linux folks and the like are right that Canonical and Ubuntu have to find a way to push more patches upstream. Here is a case though where the bug fix was already upstream, but only Ubuntu decided to implement it.

Considering that I got Ubuntu for free (as in beer), I have been very happy with the responsiveness of the (Canonical etc.) Ubuntu team to my problems and patches via their bug-tracking system, Launchpad. As far as I'm concerned, it is one of the best, and probably largest, testbeds of the Gnome desktop environment out there. I think it's really going to allow for a good, integrated Gnome desktop environment experience, and hopefully the Canonical/Gnome relationship goes w

Why did the parent get modded a score of 0 ?:

See http://wiki.debian.org/DebTorrent

Exactly applies to the subject at hand.

It's a Linux distribution which can use bittorrent to download new software & updates.

Not a lot of people use it and the number of mirrors for Debian is very large.

I think it could be possible to use it with Ubuntu as well.

See DebTorrent

That's it, forget Linux, I'm moving to GNU HURD.

2012: The Year of the HURD Desktop.

It is already patched in Debian: http://www.debian.org/security/2010/dsa-2110http://www.debian.org/security/2010/dsa-2110

Mac OS X: http://www.apple.com/downloads/macosx/games/role_strategy/foxminesweeper.html
Debian GNU/Linux: http://packages.debian.org/lenny/xbomb
FreeBSD: ftp://ftp.internat.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/games/xdemineur-2.1.1_1.tbz
Windows Vista: http://windows.microsoft.com/en-US/windows-vista/Learn-about-Windows-games

HA!

ISPs realize that enforcing their TOS is a bad business decision when a large enough group of people are using diaspora

Which is why the ISPs would feel need to nip Diaspora in the bud before the TOS violation that would undermine ISPs' market segmentation becomes widespread.

and freedom boxes

ISPs' response: "If you want to use your FreedomBox, feel free to upgrade to business-class service." Even if you're talking about a different FreedomBox, ISPs won't know nor care about the difference.

This is doubly so in areas where there is competition between residential ISPs.

ISPs' response: "Of course there's competition. Our service is just two orders of magnitude faster than the 0.05 Mbps that our dial-up competitors provide."

It's not even that. We do a decent job getting patches upstream to both Debian and upstream. Bugs and patches submitted to Debian are "sort of" measured in the Ultimate Debian Database. I say sort of because not all maintainers use debtags (some fix it in Debian itself instead, because it's less work). Look at the list of all the new DMs and DDs from the past few years, you'll see a nice percentage of those coming from Ubuntu and then working on Debian. This is a good thing.

For general "patches from people on Launchpad" we are swamped with about 1400 some bugs. Some might be good, some might be crap, we need volunteers to help us go through these. If anyone wants to help get the patch queue down, you can help with Operation Cleansweep.

I think in general the critique isn't with "Ubuntu is hogging all these fixes", since it's all open code and we make a concerted effort to push the stuff. I don't think we do any better or worse than any other distro (and yes, contrary to popular belief, Fedora carries patches as well for things). The main critique is that Canonical isn't doing any pure upstream development, ie. working on GNOME, the kernel, Xorg, etc. directly.

About a year ago I upgraded my synaptic (the only user-friendly package manager I know so far). Turns out that the Debian guys missed a critical flaw which made Synaptic crash when loading the repos. Downgrading synaptic using command-line tools was a royal pain in the ass. That's the kind of errors that I hate, and the guys criticizing Ubuntu are much more prone to commit them.

Was this on Debian or Ubuntu? If Debian, was it in the stable repo, the testing repo, or the unstable repo?

I ask about Ubuntu because a lot of the packages in Ubuntu are repackaged from Debian Sid... the unstable repo. Debian's own comment about Sid?

"sid" is subject to massive changes and in-place library updates. This can result in a very "unstable" system which contains packages that cannot be installed due to missing libraries, dependencies that cannot be fulfilled etc. Use it at your own risk!

(Source)

Take out Linux or take out GNU -- what you're left with is not an operating system any more. Take out anything else, then what's left still defines an operating system. That's why it's most efficient to call it GNU/Linux, but, of course, you are free to call it whatever you want, as long as you're not being misleading. I don't think anyone has an objection to calling a system KDE/Xorg/GNU/Linux, if you have the stamina to type it then go ahead!

The difference between using two-part names and multi-part names is that every operating system needs to have a basic userland and a kernel, but all the other programs are purely optional. If a system doesn't have GNU, it will have something else in its place. Your home router will probably not be running GNU/Linux, but Busybox/Linux instead. Your phone will be running Android/Linux. The key point is that these are incompatible, different operating systems, and you will likely have problems if you want to run a program with particular system dependencies on all of these. Because this is free software, there are many possibilities of such pairs, such as FreeBSD/kFreeBSD, GNU/kFreeBSD, GNU/kSolaris, etc.

When you say "I run Linux", strictly speaking, you refer to all possible operating systems that run on the Linux kernel. Since you need a userland to make a full operating system, such a description is incomplete. And when someone asks you what system you're running, they're not asking about just the kernel, they want to know the whole thing. So *at minimum* you should say what kernel and userland it has. If you say "I run Linux" to mean "I run GNU with Linux", then, strictly speaking, you are being misleading, because Linux does not necessarily imply GNU, same as GNU does not imply Linux.

So, you see, it's not just about giving credit, it's also because Linux is not an operating system, and it's because us geeks want to communicate precisely.

And actually, I'll need to do:

pacman -Qs

Not every distro uses aptitude ;)

You may not always have aptitude, but the odds of finding the right tool on one distro that doesn't use it are much lower, so you may want to search the debian packages...

...has me doing a "me too!" to everyone telling you to use IMAP + maildir; I use dovecot myself, complete with self-signed SSL cert (curse you firefox!).

El_Muerte_TDS has just pointed me towards mairix, a dedicated maildir + friends indexing system which I've just tried out, and seems to be ideal for my use - fast email search has always been a good thing for me, but I've rarely found a nice lightweight indexing solution that was catered only to mail; "desktop" search engines tend to take the opinion that if I want one thing indexed then I automatically want everything indexed, and also insist on running around the clock. Much nicer for my needs to just have one little lightweight indexing program that only runs when I want it to.

Best thing about mairix IMHO is the way it creates a virtual maildir on the fly using symlinks, so not only is it easily viewable on the command line, it's also automatically compatible with all of those IMAP + maildir clients out there... which, last time I looked, was all of them. Useful hack for KMail users here.

Disclaimer: my IMAP server has all its databases on an SSD, so even full text searches from the client are pretty speedy (seriously - the lack of access times on small chunks of random data cuts down search times by at least an order of magnitude), but obviously mairix has the advantage of being able to scale to multiple users with >X GB mailboxes much easier than spending a fortune on fast storage.

If Apple stuff isn't BSD because of the kernel, then I guess Debian is?

http://wiki.debian.org/Debian_GNU/kFreeBSD_why

And yes, LILO is still supported and under development. LILO 23

Well, seeing how the GPL doesn't apply unless you are distributing the code, I assumed it was given that all this talk was about distributing the code.

Sorry, in your post that I replied to, you wrote:

There are restrictions to what code you can link to or use with the programs/*pl'd code, how it can be used and so on. It's not like Lgpl code can link to GPL code and Mycode licenses software at the same time.

I really thought you were talking about "use", not "distribution". Or the actual act of linking (i.e. linking bits of compiled code yourself), not the distribution of linked binaries.

Apologies for misunderstanding you.

Well, the GPL doens't apply to getting copies or using them so I'm not sure how you are equating [the (L)GPL] to end use license agreements in good faith.

I'm trying to get my head around the statement (not yours though) that:

So is GPL more or less free than a commercial license? Usually less free

I was trying to point out that for >99.9% of commercial software that exists, whatever license or permissions you get with it, as far as I can tell, is "less free" than the GPL. This includes commercial redistributable libraries and frameworks, as most of these will not give you the freedom to modify the libraries.

Did I mention debian specifically?

No, you mentioned "some distro". I had to pick one to test, so I picked Debian because I that's the distro I happen to use. *shrug*

Why was it that you didn't want me to select minimal install?

Because the minimal install is specifically for people who want to download as little as possible. That's what "minimal" means. If you want a minimal install, you are almost certainly not interested in the source.

But, still, let's have a look. The minimal install for amd64 points to:

http://cdimage.debian.org/debian-cd/5.0.5/amd64/iso-cd/debian-505-amd64-netinst.iso

So, let's look at:

http://cdimage.debian.org/debian-cd/5.0.5/

Oh yes, there's a "source" directory. But this brings us to:

Is the source for the minimal install in the same place

This is the real point of contention, isn't it.

Well, there I happen to think you're being a bit picky w.r.t. "the same place". It's on the same server (and therefore doesn't activate the "on a different server" subclause of the GPL), as part of a well-organised directory tree, and trivial to find given the filenames involved.

For a binary file called "[base]/amd64/foo.tgz", is it really substantially different to call the corresponding source file "[base]/source/foo.tgz" instead of "[base]/amd64/foo.source.tgz"?

If you're going to be that strict about how you interpret "in the same place", surely you could interpret it to mean that the source must be present in the same file (iso, tar, deb, etc...) as the binary. After all, by your reasoning, if it's in a different file, is that not "a different place"?

By your interpretation, the source has to be in the same directory as the amd64 isos, and again in the same directory as the x86 isos, and in the same directory as the sparc isos, ad nauseum. Do you really think that's the intent of the GPL? Do you think that's practical? (I know, I know; whether something is practical has no bearing on whether it actually adheres to the license. I just balk at impracticality.)

Hmmm....I think we have a real, legitimate difference of interpretation here. The distros happen to agree with me. That doesn't mean I'm right of course (that would be argumentum ad populum) but I will point out that the distros do have lawyers who have gone over this.

Well, seeing how the GPL doesn't apply unless you are distributing the code, I assumed it was given that all this talk was about distributing the code.

Sorry, in your post that I replied to, you wrote:

There are restrictions to what code you can link to or use with the programs/*pl'd code, how it can be used and so on. It's not like Lgpl code can link to GPL code and Mycode licenses software at the same time.

I really thought you were talking about "use", not "distribution". Or the actual act of linking (i.e. linking bits of compiled code yourself), not the distribution of linked binaries.

Apologies for misunderstanding you.

Well, the GPL doens't apply to getting copies or using them so I'm not sure how you are equating [the (L)GPL] to end use license agreements in good faith.

I'm trying to get my head around the statement (not yours though) that:

So is GPL more or less free than a commercial license? Usually less free

I was trying to point out that for >99.9% of commercial software that exists, whatever license or permissions you get with it, as far as I can tell, is "less free" than the GPL. This includes commercial redistributable libraries and frameworks, as most of these will not give you the freedom to modify the libraries.

Did I mention debian specifically?

No, you mentioned "some distro". I had to pick one to test, so I picked Debian because I that's the distro I happen to use. *shrug*

Why was it that you didn't want me to select minimal install?

Because the minimal install is specifically for people who want to download as little as possible. That's what "minimal" means. If you want a minimal install, you are almost certainly not interested in the source.

But, still, let's have a look. The minimal install for amd64 points to:

http://cdimage.debian.org/debian-cd/5.0.5/amd64/iso-cd/debian-505-amd64-netinst.iso

So, let's look at:

http://cdimage.debian.org/debian-cd/5.0.5/

Oh yes, there's a "source" directory. But this brings us to:

Is the source for the minimal install in the same place

This is the real point of contention, isn't it.

Well, there I happen to think you're being a bit picky w.r.t. "the same place". It's on the same server (and therefore doesn't activate the "on a different server" subclause of the GPL), as part of a well-organised directory tree, and trivial to find given the filenames involved.

For a binary file called "[base]/amd64/foo.tgz", is it really substantially different to call the corresponding source file "[base]/source/foo.tgz" instead of "[base]/amd64/foo.source.tgz"?

If you're going to be that strict about how you interpret "in the same place", surely you could interpret it to mean that the source must be present in the same file (iso, tar, deb, etc...) as the binary. After all, by your reasoning, if it's in a different file, is that not "a different place"?

By your interpretation, the source has to be in the same directory as the amd64 isos, and again in the same directory as the x86 isos, and in the same directory as the sparc isos, ad nauseum. Do you really think that's the intent of the GPL? Do you think that's practical? (I know, I know; whether something is practical has no bearing on whether it actually adheres to the license. I just balk at impracticality.)

Hmmm....I think we have a real, legitimate difference of interpretation here. The distros happen to agree with me. That doesn't mean I'm right of course (that would be argumentum ad populum) but I will point out that the distros do have lawyers who have gone over this.

Then Debian and Ubuntu have been completely hypocritical in dropping cdrtools over wodim, and will now admit the error of their ways and go back to including software that actually works, right?"

There are restrictions to what code you can link to or use with the programs/*pl'd code,

No, only if you *redistribute* that code. You can take GPL'd code, and link it with any code you like, no matter what license, for your own use. It's only when you redistribute GPL'd code to another user that you have to give them the same freedoms the GPL gave you.

Im think he is talking about the license to distribute the software and not the EULA

But most commercial software does not even have one of these licenses. Try getting a license for Windows that allows you do distribute copies you've made. Or Photoshop. Or any other commercial app. (Note - not pass on existing copies, which you can also do with GPL'd software, but distribute new copies) Or even if talking about libraries or frameworks (a very small subset of commercial software) try getting a license for a commercial library that allows you to redistribute modified versions at all.

I don't see how, comparing like with like, that for any reasonable definition of "free", the GPL is "less free" than 99.9% of commercial software licenses.

You see, if you offer the binary for download, you need to offer the source on the same server in just as conspicuous of a way. Try finding an ISO with all the source on it on some Distro's download page.

Well, I'm a Debian user, so let's look, shall we?

Go to the Debian homepage, click "CD ISO Images", and then select any "download" option other than the "download a minimal bootable CD image". Hey, look at that. Right there, with the links to the binaries for each architecture, there's a link labelled "source". I wonder what that does. :-)

Hell, just try to find the source code to the updates the package manager automagically installs when you set it to update.

Well, my package manager downloads binaries from:

http://ftp.debian.org/debian/dists/stable/main/

Hmmm...right next to the arch specific directory for my downloads, again there's a "source" directory. Wow!

The GPL says 3 years after the last offering,

No, it's a bit more subtle than that.

GPL2 3 states: If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

GPL3 6d states: Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

So, if you distribute over the internet, you can fulfil your obligations under the GPL by making the source accessible alongside the binaries, for only as long you distribute the binaries. If a client chooses not to get the source from you at the time they get the binaries, you need not offer them the source at a later date. The "3 year offer" is

There are restrictions to what code you can link to or use with the programs/*pl'd code,

No, only if you *redistribute* that code. You can take GPL'd code, and link it with any code you like, no matter what license, for your own use. It's only when you redistribute GPL'd code to another user that you have to give them the same freedoms the GPL gave you.

Im think he is talking about the license to distribute the software and not the EULA

But most commercial software does not even have one of these licenses. Try getting a license for Windows that allows you do distribute copies you've made. Or Photoshop. Or any other commercial app. (Note - not pass on existing copies, which you can also do with GPL'd software, but distribute new copies) Or even if talking about libraries or frameworks (a very small subset of commercial software) try getting a license for a commercial library that allows you to redistribute modified versions at all.

I don't see how, comparing like with like, that for any reasonable definition of "free", the GPL is "less free" than 99.9% of commercial software licenses.

You see, if you offer the binary for download, you need to offer the source on the same server in just as conspicuous of a way. Try finding an ISO with all the source on it on some Distro's download page.

Well, I'm a Debian user, so let's look, shall we?

Go to the Debian homepage, click "CD ISO Images", and then select any "download" option other than the "download a minimal bootable CD image". Hey, look at that. Right there, with the links to the binaries for each architecture, there's a link labelled "source". I wonder what that does. :-)

Hell, just try to find the source code to the updates the package manager automagically installs when you set it to update.

Well, my package manager downloads binaries from:

http://ftp.debian.org/debian/dists/stable/main/

Hmmm...right next to the arch specific directory for my downloads, again there's a "source" directory. Wow!

The GPL says 3 years after the last offering,

No, it's a bit more subtle than that.

GPL2 3 states: If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

GPL3 6d states: Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

So, if you distribute over the internet, you can fulfil your obligations under the GPL by making the source accessible alongside the binaries, for only as long you distribute the binaries. If a client chooses not to get the source from you at the time they get the binaries, you need not offer them the source at a later date. The "3 year offer" is

There are restrictions to what code you can link to or use with the programs/*pl'd code,

No, only if you *redistribute* that code. You can take GPL'd code, and link it with any code you like, no matter what license, for your own use. It's only when you redistribute GPL'd code to another user that you have to give them the same freedoms the GPL gave you.

Im think he is talking about the license to distribute the software and not the EULA

But most commercial software does not even have one of these licenses. Try getting a license for Windows that allows you do distribute copies you've made. Or Photoshop. Or any other commercial app. (Note - not pass on existing copies, which you can also do with GPL'd software, but distribute new copies) Or even if talking about libraries or frameworks (a very small subset of commercial software) try getting a license for a commercial library that allows you to redistribute modified versions at all.

I don't see how, comparing like with like, that for any reasonable definition of "free", the GPL is "less free" than 99.9% of commercial software licenses.

You see, if you offer the binary for download, you need to offer the source on the same server in just as conspicuous of a way. Try finding an ISO with all the source on it on some Distro's download page.

Well, I'm a Debian user, so let's look, shall we?

Go to the Debian homepage, click "CD ISO Images", and then select any "download" option other than the "download a minimal bootable CD image". Hey, look at that. Right there, with the links to the binaries for each architecture, there's a link labelled "source". I wonder what that does. :-)

Hell, just try to find the source code to the updates the package manager automagically installs when you set it to update.

Well, my package manager downloads binaries from:

http://ftp.debian.org/debian/dists/stable/main/

Hmmm...right next to the arch specific directory for my downloads, again there's a "source" directory. Wow!

The GPL says 3 years after the last offering,

No, it's a bit more subtle than that.

GPL2 3 states: If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

GPL3 6d states: Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

So, if you distribute over the internet, you can fulfil your obligations under the GPL by making the source accessible alongside the binaries, for only as long you distribute the binaries. If a client chooses not to get the source from you at the time they get the binaries, you need not offer them the source at a later date. The "3 year offer" is

Why not just link to debian

Obvious troll is obvious. Let's play.

My original point is that evaluating a platform on a single application is asinine. Your point seems to be that you've spent less than five minutes looking at Java, and have concluded that because you can't figure out the reasoning behind its behavior, there is none.

You have to download 100s MB to run your code in a VM

Just like every other interpreted language out there, you have to download an interpreter. Compare this to C#, where not only do you need the interpreter (a few hundred megs included with the OS), you also download the updates from MS, whether you actually need them or not. Maybe your claim would have some weight if Java were like C or C++, where (static) libraries are compiled into the executable, and can be duplicated for each application. It's not like that at all, though. You download a JVM, and almost always have everything you need right there. If you have several Java applications on one box, you're averaging a pretty small library for each. That's not bad.

it runs slower then native apps

Just like every other non-native language! It also uses about a third less code, and doesn't suffer from memory leaks. Again, if you were to compare it to a similar language like C#, you'd get more equal results. This is why I mentioned demoscene in my earlier comment: Demoscene folks have been pushing the limits of hardware for many years, and it comes at the expense of much more difficult programming. I don't doubt that a demoscene programmer could run a 1080p FPS on a phone. It'd take them a few years to make it, and the code would be unmaintainable, but it'd run.

hogs a shit-ton of memory

Here's the part that shows off how little you know of Java. When the JVM starts, it asks for a certain (configurable) amount of memory. The OS happily gives away that much memory, but Java never actually does anything with most of it. If you want a Java program to take up 50-gigabytes of memory, make a 50-gigabyte swap partition and start up a 50-gigabyte JVM. That sets the upper limit on what the JVM can use, just in case some programmer decides that loading a 45-gigabyte array is a good idea. That memory (usually... if you have a decent OS) sits allocated in swap until it's actually used, leaving RAM for other applications. The main benefit here is that there's a hard upper bound on how much memory a program can leak. Having an application crash without taking down the whole system is a good thing.

and you have to type HugeFunctionNamesThatAreStupidlyLong() to get anything done.

Do you have any examples? The longest one I've used lately is GenericValidator.isBlankOrNull(). That's not bad. Now, maybe if by some perverse sense of style you insisted on fully qualifying all names with their packages, you could reach something actually long, but I don't think anyone, not even an AC troll, could be that stupid.

Now you can get sued by Oracle for forking it when it's already GPL code.

No, you can't. You can get sued for using patented software without a license, which is a risk with all GPLv2 software where patents are involved. If you don't want to comply with the Sun patent license, replace those parts of the forked code with something of your own design.

Compared to any other language it's a turd to use and the only people that do use it are too stupid to learn anything better.

Compared to any other language offering similar features, Java is similar. The only people who use it are those who think it's best for their purposes. Such a decision should be the result of careful analysis of the platform's behavior, rather that something ridiculously juvenile, such as counting the number of "good games".

The Book of Revelation ends like this:

[18] For I testify unto every man that heareth the words of the prophecy of this book, If any man shall add unto these things, God shall add unto him the plagues that are written in this book: [19] And if any man shall take away from the words of the book of this prophecy, God shall take away his part out of the book of life, and out of the holy city, and from the things which are written in this book. [20] He which testifieth these things saith, Surely I come quickly. Amen. Even so, come, Lord Jesus.

Not copy-protection, but an "invariant section" definition as in the GFDL. The translation is medieval, but the original and therefore clearly the practice is much older. Since there was no government-provided copyright law with which to enforce this, threatening eternal damnation is pretty much the only resort available. (Right?)

(Sidenote: of course, this was written before that book was commonly bound into a single-volume manuscript, but that doesn't stop people from assuming that they were meant to apply to the entire bible in its current form.)

Race?

The most popular distros already patched it days ago and others are currently in testing.

Redhat patched it 2 days ago.
Ubuntu patched it 2 days ago.
Fedora is currently testing the patches. Not sure if it's already live.
Debian Lenny has patched it.

So in summary they haven't been getting similar improvements in speed.

Perhaps that's because they didn't suck so much in the first place (with the possible exception of MRI)?

After all, Javascript is now faster (except for pi and reverse-complement).

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=yarv

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=python3

Because everyone chooses a language based on raw execution speed, amirite?

You were comparing relative increases between different implementations of one language before; now you're comparing the fastest implementation of one language to the not-fastest implementations of others. =_=

Even if they look vaguely similar on the surface, all of the languages you've mentioned are quite different internally. Some performance changes that would take too much effort to change, some won't happen for philosophical reasons, and a great deal more are not applicable to anything other than the language they were written for.

So in summary they haven't been getting similar improvements in speed.

Perhaps that's because they didn't suck so much in the first place (with the possible exception of MRI)?

After all, Javascript is now faster (except for pi and reverse-complement).

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=yarv

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=python3

Because everyone chooses a language based on raw execution speed, amirite?

You were comparing relative increases between different implementations of one language before; now you're comparing the fastest implementation of one language to the not-fastest implementations of others. =_=

Even if they look vaguely similar on the surface, all of the languages you've mentioned are quite different internally. Some performance changes that would take too much effort to change, some won't happen for philosophical reasons, and a great deal more are not applicable to anything other than the language they were written for.

So in summary they haven't been getting similar improvements in speed.

After all, Javascript is now faster (except for pi and reverse-complement).

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=yarv

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=python3

So in summary they haven't been getting similar improvements in speed.

After all, Javascript is now faster (except for pi and reverse-complement).

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=yarv

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=python3

Debian bug regarding TPROXY, SNAT, DNAT

This site suggests that TPROXY patches are available to support IPv6, though I don't know exactly how that relates to SNAT/DNAT.

HTH,
-l

The main advantage I got out of Debian rapidly approaching 15 years ago was the DFSG Debian Free Software Guidelines

http://www.debian.org/social_contract#guidelines

That saved me from a mighty holy war being brewed up by the IT department. They tolerated it and left the engineering department alone, which worked pretty well.

Y'know, I'm really glad Google wants to provide a new API for managing security. We need somebody to do this for us - somebody who really knows security, somebody who may as well have security as their middle name, to come out with an API framework for Mandatory Access Controls, preferably built right into th operating system kernel of a major distribution.

Yes, I'm really glad Google took the initiative on this.

It does seem strange that Google, rather than using Python, whose creator (Guido van Rossum) is employed by Google, they chose to use Java....

Python runs as slow as molasses in January. Mind you, not as bad as it once was but still very bad.

Excuse my nitpicking, your post sparked some new questions for me:

The problem stems when legitimate applications attempt to use that memory. How long does it take to page (read/wirte) 16GB, 4KB at a time?

Are you sure that's it's only reading/writing 4KB at a time? It seems pretty braindead to me.

The old 1:1+x and 2:1 memory to disk ratios are based on notions of swapping rather than paging (yes, those are two different virtual memory techniques), plus allowing room for kernel dumps, etc. Paging is far more efficient than swapping ever was.

Could you elaborate on the difference between swapping and paging? I have always thought of it (adopting the term "paging") as an effort to disconnect modern Virtual Memory implementations from the awful VM performance of Windows 3.1/9x. Wikipedia mentions them as interchangeable terms and other sources on the web seem to agree.

You might come back and say, one day I might need it. Well, one day you can create a file (dd if=/dev/zero of=/pagefile bs=1024 count=xxxx), initialize it as page (mkswap /pagefile), and add it as a low priority paging device (swapon -p0 /pagefile). Problem solved.

Just mentioning here that Swapspace (Debian package) takes care of that, with configurable thresholds.

You may say the performance will be horrible with paging on top of a file system - but if you're overflowing several GB to a page file on top of a file system, the performance impact won't be noticeable as you already have far, far greater performance problems. And if the page activity isn't noticeable, the fact its on a file system won't matter.

Quoting Andrew Morton:
"[On 2.6 kernels the difference is] None at all. The kernel generates a map of swap offset -> disk blocks at swapon time and from then on uses that map to perform swap I/O directly against the underlying disk queue, bypassing all caching, metadata and filesystem code."

Or, since they said it is a package, you could just uninstall the package...

Really this isn't much new - Fedora and Debian have had things like these... Debian's is called Popularity Contest, and Fedora is looking at doing the same though I could have sworn they already had that in Fedora...

The Debian Popularity Context already provides some of the same kinds of statistics. They ask at installation time whether you want to participate, and I think the interface is evenly weighted between opt-in and opt-out, so the users may be somewhat self-selected.

Debian has a similar usage tracking package: http://popcon.debian.org/ .

Not quite. That's for tracking the popularity of individual packages, not the distro as a whole. (It's available for Ubuntu too, as it is for most Debian-derived distros.)

Furthermore, it's not installed by default, (apparently) unlike the software that the article is about.

That's Debian Popularity Contest, so it's ok, even though it appears to be far more intrusive and suspicious. Debian's not one of those evil for-profit corporations like Canonical or Red Hat or Apple or Novell or Slackware, so you can implicitly trust anything they do. :)

Sounds great. I guess this'll be default in maverick and we'll see some interesting results. but how come they can't just extend Pop-con? http://popcon.ubuntu.com/ http://popcon.debian.org/

Sounds great. I guess this'll be default in maverick and we should see some interesting data? But why couldn't they just extend Pop-con? http://popcon.ubuntu.com/ http://popcon.debian.org/

...which you can see before you install it?

From the source package web page, opening the 0.1 release, we see:

Built packages

canonical-census send "I am alive" ping to Canonical

What did you think it might have done?

Seriously, this is a story? What's next, "ZOMG, popcon!"?

Since ubuntu checks for updates isn't it enough to track the connection to the apt repositories to get a fairly good approximation of ubuntu usage?

Or, why not setting up a popularity contest as debian does and get some more already anonymized usage statistics from that?

I don't like this development, like I didn't like axing gimp while getting tomboy + mono in, and moving the default window buttons around. The System is fighting back, marketing guys take over.

The good thing of FOSS is that if canonical screws up one can fall back on debian or desktop oriented derivatives.

Why not use debian package "popularity-contest"?

Initially released "Sat, 24 Oct 1998 22:33:58 -0400", and it does a heck of a lot more.

http://packages.debian.org/changelogs/pool/main/p/popularity-contest/current/changelog

http://popcon.debian.org/

The Debian package popularity-contest does this along with the added benefit of reporting what packages you use.

You have to opt into it, though.

This would be similar to Debian's popularity-contest but with Debian you have to opt in.

http://popcon.debian.org/

It seems more useful since it tells Debian which packages you have installed in addition to the fact that you have Debian installed.

This would be similar to Debian's popularity-contest but with Debian you have to opt in.

http://popcon.debian.org/

It seems more useful since it tells Debian which packages you have installed in addition to the fact that you have Debian installed.

Debian has a similar usage tracking package: http://popcon.debian.org/ .

As long as such a package is only installed with the users consent, I don't see the problem.

http://www.debian.org/News/2009/20090729

        The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year. To that effect the next freeze will happen in December 2009, with a release expected in spring 2010.

And, on the mailing list the next day: http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html

Based on feedback of the community on the plan to freeze in December
2009 and the ambituous Release Goals we set for ourselves, we are
revisiting the decision to freeze December 2009.

We'll be consulting all key teams within Debian to see how their plans
and schedules can fit into a new timeline. Before the end of August we
hope to have finished this process of consultation and be able to
present the new plan to you.

And, following that consultation: http://lists.debian.org/debian-devel-announce/2009/10/msg00002.html

Proposing a new freeze date is not easy. Taking into account all of
the feedback we have received, both online (by e-mail, IRC) as well as
in person, and some challenging release goals we have set for ourselves,
we propose freezing in March 2010.

So, yes, the release team did propose a December date. The proposal lasted about a day before being dismissed, and was replaced with one in March. Admittedly, this isn't far off the 6 months the OP suggested this was late by.

OTOH, I'd suggest they're still on track to be able to meet their primary original goal, releasing to stable on a two year cycle (i.e. squeeze to be released on or around 26 June 2012), so slipping a few months in the feature freeze for the release is hardly a major problem.

http://www.debian.org/News/2009/20090729

        The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year. To that effect the next freeze will happen in December 2009, with a release expected in spring 2010.

And, on the mailing list the next day: http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html

Based on feedback of the community on the plan to freeze in December
2009 and the ambituous Release Goals we set for ourselves, we are
revisiting the decision to freeze December 2009.

We'll be consulting all key teams within Debian to see how their plans
and schedules can fit into a new timeline. Before the end of August we
hope to have finished this process of consultation and be able to
present the new plan to you.

And, following that consultation: http://lists.debian.org/debian-devel-announce/2009/10/msg00002.html

Proposing a new freeze date is not easy. Taking into account all of
the feedback we have received, both online (by e-mail, IRC) as well as
in person, and some challenging release goals we have set for ourselves,
we propose freezing in March 2010.

So, yes, the release team did propose a December date. The proposal lasted about a day before being dismissed, and was replaced with one in March. Admittedly, this isn't far off the 6 months the OP suggested this was late by.

OTOH, I'd suggest they're still on track to be able to meet their primary original goal, releasing to stable on a two year cycle (i.e. squeeze to be released on or around 26 June 2012), so slipping a few months in the feature freeze for the release is hardly a major problem.

http://www.debian.org/News/2009/20090729

        The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year. To that effect the next freeze will happen in December 2009, with a release expected in spring 2010.

And, on the mailing list the next day: http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html

Based on feedback of the community on the plan to freeze in December
2009 and the ambituous Release Goals we set for ourselves, we are
revisiting the decision to freeze December 2009.

We'll be consulting all key teams within Debian to see how their plans
and schedules can fit into a new timeline. Before the end of August we
hope to have finished this process of consultation and be able to
present the new plan to you.

And, following that consultation: http://lists.debian.org/debian-devel-announce/2009/10/msg00002.html

Proposing a new freeze date is not easy. Taking into account all of
the feedback we have received, both online (by e-mail, IRC) as well as
in person, and some challenging release goals we have set for ourselves,
we propose freezing in March 2010.

So, yes, the release team did propose a December date. The proposal lasted about a day before being dismissed, and was replaced with one in March. Admittedly, this isn't far off the 6 months the OP suggested this was late by.

OTOH, I'd suggest they're still on track to be able to meet their primary original goal, releasing to stable on a two year cycle (i.e. squeeze to be released on or around 26 June 2012), so slipping a few months in the feature freeze for the release is hardly a major problem.

It's a little different, but this page gives you an ordered list of releases. More generally though, if you see news about a new stable, it will be newer than the one you already installed :-)

If you hear that Squeeze is stable and you're running something that isn't Squeeze, it's time to think about upgrading.