Slashdot Mirror

wow, this was coordinated
http://www.gentoo.org/news/20110401-canterbury.xml
http://www.opensuse.org/
http://www.debian.org/News/2011/20110401
http://lists.debian.org/debian-user/2011/04/msg00006.html

Here it is. http://www.debian.org/

Only an hour left here of the 1st. One article appears to be new news the rest make it look good.

Though The Canterbury distro is just terrible
http://www.opensuse.org/
https://www.archlinux.org/
http://www.debian.org/

Can you imagine the holy wars at least 3 different packing systems 4 different kenels and everything from stable to sid all in one distro.

Didn't you hear that debian, openSuSE, Arch, Grml and Gentoo are merging?

http://www.debian.org/
http://www.opensuse.org/
http://www.archlinux.org/
http://www.gentoo.org/
http://www.grml.org/

Maybe it is time to cure your Microsoft addiction? Break your Windows!

1) Before doing anything else, back up your data, all of it, off of the computer. Seriously. Do it.

2) Check out:

http://www.ubuntulinux.org/
http://www.debian.org/
http://www.openbsd.org/

(Be sure to completely format the computer's hard drive before or during the installation process).

WARNING: if you do not know what you are doing, ask for help from someone who does.

(P.S. - forget Apple, which is just the new Microsoft.)

Freedom Boxes

micro-games with abysmal graphics

Webgl is real and works today in the latest browsers. Go here (with Chrome 9 or FF4 and a real GPU) to see it right now.

developing for a web browser would [not] be more advantageous

In terms of performance, browsers already provide an environment that has parity with the best stand-alone dynamic languages. Both HTML5 canvas and Webgl are sufficient to solve the rendering problem for a broad class of games. These tools are standards based and free. If you've ever earned a living making games you can't miss the potential.

Large investments into browser development are coming from several competing organizations. Don't be surprised if browsers become superior to traditional techniques.

multilib is the wrong way to go, Debian/Ubuntu/Linaro folks are working on doing it the right way; multi-arch. multilib wouldn't work in (for example) the situation where you have a MIPS CPU that has hardware support for i386 binaries. Or when you want to run things with qemu-user.

More about these here:

http://lackof.org/taggart/hacking/multiarch/
http://wiki.debian.org/Multiarch

1. Debian won two of seven categories at the Linux New Media Awards 2011
2. While the article focuses on Debian with the Linux kernel, it also supports a FreeBSD kernel and (I don't know if this actually counts) GNU/Hurd

Does it matter ? Because Debian is now a BSD-distro now. ;-)

http://www.debian.org/ports/kfreebsd-gnu/

Seriously.

I think OpenBSD might have the most influence, because they created/maintain OpenSSH.

Which is used in many, many if not all Linux, BSD and other Unix based systems, routers and managed switches.

I think FreeBSD is where a lot of drivers are being created for all the BSDs and I think for the Linux kernel as well.

FreeBSD is also used by Juniper as the basis for Junos for their routers, which runs a large percentage of the internet.

OpenSolaris is dead, but OpenIndiana/Illumos will keep it going for that community. Which means there is free code which can do ZFS and Dtrace (which itself is also incorporated in FreeBSD).

The Foundation:
http://www.freedomboxfoundation.org/

The Debian Project Page:
http://wiki.debian.org/FreedomBox

This is a more long-term solution, but think of it as the elegant solution to the problem.

Better. Supply open source support for sourceforge/open source projects.

Probably a hell of a lot simpler to contact one of these 826 people and arrange terms.

http://www.debian.org/consultants

Now something new to the ecosystem, would be a talent agency that handled all aspects of these relationships for a very modest fee. Maybe that already exists, very quietly.

And I may be in the minority, but I would pay X amount of money for open source and free apps that were compiled and packaged. (X being reasonably small.)

We have had this for decades. No kidding.

You could hire one of these guys to produce the exact free app that you want, to the exact packaging specs you want, with the exact compile time options you want. You can't lose, and everyone wins. Kind of the opposite of the banking system where heads they win or tails you lose.

http://www.debian.org/consultants

You can always grab fedora.

Or you can grab debian (which ubuntu is based on), with almost 30,000 packages, and without the fugly Ubuntu wallpapers.

I do have some concerns over this Gnome/Unity fork. Not just how it will effect Gnome but whether Canonical and Ubuntu can handle a significant fork. I am fairly certain bugs like this are a product of the fork, and I wonder who is going to fix them. Canonical has trouble getting good bug reports for packages like cairo, poppler and evince upstream, never mind patching them. I can think of a number of examples, but is the aforementioned bug which was almost certainly probably caused by the fork going to be fixed before 11.04 is released? It is not the only bug caused by the fork either. Who is going to fix these? The fork is small now and these should be easy to fix, who is going to fix them as the fork gets bigger, and Gnome and Unity diverge even more? On the other hand, it's conceivable that Unity will be so awesome, that developers will flock to it, and Gnome shell will to some extent wither away. There are different perspectives, different problems and different possibilities for all of these things. I can tell you right now though that the Unity stuff is breaking stuff in Ubuntu's Gnome, and it is staying broken. Stuff that the Gnome developers will not be fixing either. We'll see what happens...

Yeah - and LuaJIT is mindboggling for a scripted language (admittedly JIT'ed like Java).. http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

According to this benchmark V8 is 4x slower than C/C++. From my perspective that's "somewhere close" to C's performance. Compared to the 10x+ bench for most scripting languages including other Javascript implementations, it's pretty darn respectable. And if they just improved it by another 60% for many applications, that's a big deal..

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

Javascript V8 (v9 presumably) according to this benchmark is 4x slower than C. Not bad at all, IMO.

Perhaps you should read up on the problems with online voting before you make these sorts of comments.
Securing a vote is trivial, as long as you are happy that your ID is attached to the vote.
However this has the problem that you no longer have a secret ballot, apart from potential state sponsored discrimination, you can also be a victim of external intimidation, since others can see how you voted. Vote buying is also possible, since you can now prove how you voted.

If you eliminate any association of your ID from your vote, then you also eliminate you ability to verify that the vote you cast is indeed the vote that was counted.

You need to read up on the Debian voting system and hash functions. Not Condorcet, although thats cool.

Here's the last election tally sheet:

http://www.debian.org/vote/2010/vote_001_tally.txt

Also there is a procedure that you can vote multiple times and only the last counts. That would seem to eliminate all but very last moment intimidation. Which can be eliminated by everyone voting at the same time, more or less. How many can realistically be intimidated by one intimidator?

The tzdata package in debian is not exactly "sent out" every time some government tweaks the rules. Especially if you are running debian stable. You can, however, add the "volatile" repository to your /etc/apt/sources.list which is specifically for packages like tzdata that need to be updated more frequently. Oh, actually, this just changed last week for the latest stable release: Debian volatile replaced by new updates suite

Yeah, lots of very smart people working on making javascript much faster.

Too bad perl, python, ruby aren't getting faster as fast.

Luckily, Lua is. :D

Though I do prefer Python, I've got to hand it to the moonies, they're fricken fast!

There's always a more helpful, more specific URL.

Yeah, lots of very smart people working on making javascript much faster.

Too bad perl, python, ruby aren't getting faster as fast.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=pypy

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

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=python

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=gpp

I suspect the pi digits algorithm used by the javascript bench is not as good as the one used in python.

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=pypy&id=5

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=tracemonkey&id=1

Yeah, lots of very smart people working on making javascript much faster.

Too bad perl, python, ruby aren't getting faster as fast.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=pypy

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

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=python

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=gpp

I suspect the pi digits algorithm used by the javascript bench is not as good as the one used in python.

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=pypy&id=5

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=tracemonkey&id=1

Yeah, lots of very smart people working on making javascript much faster.

Too bad perl, python, ruby aren't getting faster as fast.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=pypy

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

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=python

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=gpp

I suspect the pi digits algorithm used by the javascript bench is not as good as the one used in python.

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=pypy&id=5

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=tracemonkey&id=1

Yeah, lots of very smart people working on making javascript much faster.

Too bad perl, python, ruby aren't getting faster as fast.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=pypy

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

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=python

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=gpp

I suspect the pi digits algorithm used by the javascript bench is not as good as the one used in python.

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=pypy&id=5

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=tracemonkey&id=1

Yeah, lots of very smart people working on making javascript much faster.

Too bad perl, python, ruby aren't getting faster as fast.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=pypy

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

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=python

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=gpp

I suspect the pi digits algorithm used by the javascript bench is not as good as the one used in python.

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=pypy&id=5

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=tracemonkey&id=1

Yeah, lots of very smart people working on making javascript much faster.

Too bad perl, python, ruby aren't getting faster as fast.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=pypy

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

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=python

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=gpp

I suspect the pi digits algorithm used by the javascript bench is not as good as the one used in python.

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=pypy&id=5

http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=tracemonkey&id=1

There _are_ things "wrong" with javascript that make it hard to optimize (lack of typing, very dynamic, etc).

To get a notion of where it is possible to get with a similarly dynamic language, take a look at how the LuaJIT benchmarks compare with optimized C++ and other dynamic languages. Notice it is not far behind a state-of-the-art Java VM.

Another pretty interesting aspect is this code size versus speed comparison.

There _are_ things "wrong" with javascript that make it hard to optimize (lack of typing, very dynamic, etc).

To get a notion of where it is possible to get with a similarly dynamic language, take a look at how the LuaJIT benchmarks compare with optimized C++ and other dynamic languages. Notice it is not far behind a state-of-the-art Java VM.

Another pretty interesting aspect is this code size versus speed comparison.

Does anybody know where we are with Javascript now?

There is always the The Computer Language Benchmarks Game. There you will find V8 competitive with Python, Ruby and other such languages, which is to say slower than the usual compiled suspects by about the same degree.

Because Grub1 is horrible.

See http://bugs.debian.org/grub (the open bugreports against grub) and, especially, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#237 (a particularly telling example) if you don't believe me.

Because Grub1 is horrible.

See http://bugs.debian.org/grub (the open bugreports against grub) and, especially, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#237 (a particularly telling example) if you don't believe me.

Yes, how dare they stick to their principles if it annoys me!

They even host (unofficial) CD images with the non-free firmware, so I don't know what you're complaining about.

Popularity contest statistics for popularity-contest says that 99.76% of the almost hundred-thousand Debian users sending statistics back to the "popularity contest" have installed the application which gathers such statistics.

You've just described the Debian Popularity Contest. It has a lot of users, although probably not a large proportion of all Debian users.

I am happy that they are going to split free and non-free packages in an easy way. If some Stallman-approved free software distro does a fork of Debian, it can now be a small fork, allowing for greater cooperation between Debian and the fork.

I was worried squeeze was going to be released without my bug fix being applied. But with a few days to spare, they managed to get it in there, excellent!

While I use Ubuntu a lot, one of the many nice things about Debian is how agnostic it is. If you want a bare bones system, install one. If you want a robust system, install a lot of packages. Use Gnome if you want, use KDE if you want, use Gnome with both GTK+ and QT libraries installed, or KDE with GTK+ and QT libraries installed. Or use good old FVWM.

I'm amazed that they stuck this release freeze out long enough to get the RC bugs for the testing release down to what looks like the lowest since the graph began tracking testing in 2004 -- I would like to believe that this means squeeze will end up being the most stable/reliable release so far.

Now that the release is done and the freeze is over, an upgrade of the Linux kernel (from 2.6.32 to 2.6.37) in unstable should be soon to follow. Also, Firefox (probably 3.5.9 -> 4) and LibreOffice (OOO 3.2.1 -> LO 3.3).

Any installation that requires additional firmware will need to have the firmware available during installation. See the Debian wiki http://wiki.debian.org/Firmware for installation instructions. They even have a special netinst image that will pull the correct firmware.

As for LibreOffice, it is in the experimental archive and I would imagine will be in sid very soon. Of course it won't hit stable until 7.0 but most desktop users aren't going to wait that long. Especially if/when sid gets a 2.6.38 kernel with the new 200 line patch.

It's interesting to note, that while Debian has traditionally supported more CPU microarchitectures than any other mainstream GNU+Linux distribution out there, they have decided to officially stop supporting multiple microarchitectures with the release of Squeeze. The dropped architectures are alpha, hppa, and arm, the latter of which is replaced by the new "Embedded" ABI of ARM, which Debian calls armel.

Although kfreebsd-i386 and kfreebsd-amd64 have been added, these are not true new CPU microarchitectures in and of themselves, as they are compiled to standard x86 and x86_64 respectively, but obviously with the fairly radical change of not using Linux at all with a different GNU libc requiring all packages to be recompiled. This is the same situation as we have traditionally seen in the never-officially-released hurd-i386 port of Debian (which makes sense to call Debian GNU I suppose, as the Hurd kernel is part of the GNU project already) which seems to be missing so far with Debian 6.0 so far, pending a decision to potentially drop it as well.

All in all, amazing work by all in the Debian project. It remains an incredibly impressive feat that such a project can have no corporate oversight or ownership yet maintain such an impressively influential, relevant, and useful place in the operating system ecosystem. Even with dropping a couple of architectures, Debian still supports more computer types than most people even know exists, and continues to provide package updates that many many other operating systems base their repositories from. Also wonderful to see the website be updated!!

It's interesting to note, that while Debian has traditionally supported more CPU microarchitectures than any other mainstream GNU+Linux distribution out there, they have decided to officially stop supporting multiple microarchitectures with the release of Squeeze. The dropped architectures are alpha, hppa, and arm, the latter of which is replaced by the new "Embedded" ABI of ARM, which Debian calls armel.

Although kfreebsd-i386 and kfreebsd-amd64 have been added, these are not true new CPU microarchitectures in and of themselves, as they are compiled to standard x86 and x86_64 respectively, but obviously with the fairly radical change of not using Linux at all with a different GNU libc requiring all packages to be recompiled. This is the same situation as we have traditionally seen in the never-officially-released hurd-i386 port of Debian (which makes sense to call Debian GNU I suppose, as the Hurd kernel is part of the GNU project already) which seems to be missing so far with Debian 6.0 so far, pending a decision to potentially drop it as well.

All in all, amazing work by all in the Debian project. It remains an incredibly impressive feat that such a project can have no corporate oversight or ownership yet maintain such an impressively influential, relevant, and useful place in the operating system ecosystem. Even with dropping a couple of architectures, Debian still supports more computer types than most people even know exists, and continues to provide package updates that many many other operating systems base their repositories from. Also wonderful to see the website be updated!!

You can find some of the reasons here. Among them are ZFS, jails, and pf. I've used Debian GNU/kFreeBSD in the past and found pf significantly easier to use than iptables and tc.

I'm going to guess that it wouldn't work now either... (If I recall correctly the software is ipw2200, or similar.)

So, you bothered to link to a page explaining in extreme detail both that it works, and exactly how to do it line by line, but you're guessing it wouldn't work?

I think you're trying to write in a very complicated manner that you're not sure if your laptop has a ipw2200? I have second hand knowledge that the instructions on the wiki do work quite well if you're unfortunate enough to own a ipw2200 card.

I'm a Ubuntu user, but I know where it comes from. Debian has been the dream operating system of mine for ages. Easy to install thousands of packages, stable, safe, etc. The only trouble is, when I first tried to install it in 2007, I couldn't get it to work with my wireless card. Ubuntu just worked. I'm going to guess that it wouldn't work now either; my wireless card is one of those Intel ones with the locked up firmware so that I don't start spamming the airwaves... (If I recall correctly the software is ipw2200, or similar.)

Anyway, one thing I note from the press release, is that it is still including OpenOffice.org 3.2.1. I wonder when they'll get LibreOffice (Ubuntu will get it in the 11.4 release).

Great job Debian!

Or is it only me that cannot find the Ubuntu 'Stable' Repo for running things like NGINX?

How to install nginx on debian: apt-get install nginx

How to install nginx on ubuntu: apt-get install nginx

So yes, it is only you.

• Debian: [1], [2]
• Ubuntu: [1]
• Gentoo: [1]

That little gem can be blamed on Debian actually.

I love Debian so this one came as a real blow; but they did a good job disclosing it and worked with any and all who wanted to participate to develop the blacklist package.

The feedback from debian-legal is that, although the code itself is GPL, the H.264 codec is patent-encumbered. This means the package does not meet the DFSG and cannot be included in Debian.

You could give your store a name that makes no sense.

"Synaptic" is not the name of the app store. It's the name of the GUI for APT. And APT isn't the name of the app store either; it stands for Advanced Package Tool.

The real name of the app store? *drum roll* "package repository" that contains the "packages" that make up the "distribution".. Note the conspicuous lack of capitalisation and trademark symbols. Note the fact that no one demands you to use just Debian's (or Ubuntu's, or whoever's) repository; you can add more yourself or even start your own.

BSD (it's not dead, after all!)

This shows a huge amount of ignorance. BSD is alive and fine, in several forms:
- FreeBSD
- NetBSD
- OpenBSD
- DragonFly BSD
These are probably the most important. Take a look at Freebsd Derivates. You'll see there are many commercial products derived from Freebsd too.

Also, there are initiatives of porting different Linux distros on top of the BSD kernel:
- Gentoo/*BSD
- Debian GNU/kFreeBSD
- Debian GNU/NetBSD (abandoned in 2002 it seems)

BSD was, is and will be alive for a long time.