Slashdot Mirror

Manufacturer of what?
There's flash plugin for sparc, but they stopped at version 11.2.202.223 while the current one on linux is 11.2.202.310
But surely there are other NPAPI plugins than Adobe ones, like the totem or mplayer plugins.

For a web browser, let's see iceweasel 17.0.9 :
amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc

While we're on the subject of the Debian website (all emphasis added):

Q: How is security handled for testing?

A: If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, there is security support for testing: The Debian testing security team handles issues for testing. They will make sure that the fixed packages enter testing in the usual way by migration from unstable (with reduced quarantine time), or, if that still takes too long, make them available via the normal http://security.debian.org/ infrastructure. To use it, make sure the following line is in /etc/apt/sources.list:

deb http://security.debian.org/ /updates main

and run apt-get update && apt-get upgrade as usual.

Note that this doesn't guarantee that all known security bugs are fixed in testing! Some updated packages might be waiting for transition to testing. More information about the security infrastructure for testing can be found at http://secure-testing-master.debian.net/.

Well I don't know about you but I'm convinced? What Debian realistically needs to do is take what they call "testing" and call it "stable" if they ever want to catch up. Most people who are trying Debian now are trying it because of the constant stream of bad news from Canonical (Mir, Dash Lens and it's reassurance that your searches won't ever be linked to you, thus making them worthless...and of course Unity). Shortly after they realize that the latest NVidia driver available from official repositories is 304.88 and the best of an interface they get is either GNOME 3 four point releases behind mainstream, or KDE 4 at least 2 point releases behind mainstream...and then they start wondering why they installed fucking Debian.

While we're on the subject of the Debian website (all emphasis added):

Q: How is security handled for testing?

A: If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, there is security support for testing: The Debian testing security team handles issues for testing. They will make sure that the fixed packages enter testing in the usual way by migration from unstable (with reduced quarantine time), or, if that still takes too long, make them available via the normal http://security.debian.org/ infrastructure. To use it, make sure the following line is in /etc/apt/sources.list:

deb http://security.debian.org/ /updates main

and run apt-get update && apt-get upgrade as usual.

Note that this doesn't guarantee that all known security bugs are fixed in testing! Some updated packages might be waiting for transition to testing. More information about the security infrastructure for testing can be found at http://secure-testing-master.debian.net/.

Well I don't know about you but I'm convinced? What Debian realistically needs to do is take what they call "testing" and call it "stable" if they ever want to catch up. Most people who are trying Debian now are trying it because of the constant stream of bad news from Canonical (Mir, Dash Lens and it's reassurance that your searches won't ever be linked to you, thus making them worthless...and of course Unity). Shortly after they realize that the latest NVidia driver available from official repositories is 304.88 and the best of an interface they get is either GNOME 3 four point releases behind mainstream, or KDE 4 at least 2 point releases behind mainstream...and then they start wondering why they installed fucking Debian.

http://www.debian.org/

Here you go kid. Go get yourself a better operating system.

Ubuntu is not Linux. And yes, Ubuntu sucks on lot's of things (don't get me started on Unity).
You should try the same Linux NASA is using in space : Debian
Ubuntu is based on it, except they take the unstable development branch and put custom patches on it to make it more unstable.

CPython is a blurry rocket of speed when compared with Jython.

Is Jython an order of magnitude slower than CPython? Because that's my rule of thumb for CPython vs C. (Actually the programming language shootout's numbers are more like 30-40x slower than C, though that needn't be representative.)

And in theory you can write all the compute-expensive routines in C++.

Sure, but then that's not Python being fast, it's C++ being fast. "You could write the expensive parts in C or C++" can be said of nearly any language. :-)

Not to mention backports, which allow you to install on stable newer versions of packages from testing which have been specially prepared and tested for stable (ie which handle any differences in behaviour between stable and testing).

Correct. Here's the full background story of the CD incident for anyone who's interested:

Debian 1.0 was never released: InfoMagic, a CD vendor, accidentally shipped a development release of Debian and entitled it 1.0. On December 11th 1995, Debian and InfoMagic jointly announced that this release was screwed. Bruce Perens explains that the data placed on the "InfoMagic Linux Developer's Resource 5-CD Set November 1995" as "Debian 1.0" is not the Debian 1.0 release, but an early development version which is only partially in the ELF format, will probably not boot or run correctly, and does not represent the quality of a released Debian system. To prevent confusion between the premature CD version and the actual Debian release, the Debian Project has renamed its next release to "Debian 1.1". The premature Debian 1.0 on CD is deprecated and should not be used. [1]

Because so much of the world relies on Javascript, the browser vendors are in a performance war and keep upping their investment in Javascript just-in-time compilation. Have a look at this: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=gcc&data=u64 in eight benchmarks, Javascript in Google's V8 is never worse than 20 times slower than C and never uses more than 24 times as much memory. That's a far cry from the "hundreds (or thousands) of times slower than native code" you state above. And the performance wars are far from over, especially since mobile devices are still resource constrained and people keep trying to do more and more things on mobile.

But the real problem is still that skilled developers are more expensive than throwing more hardware at a problem and using easier tools. If a company could feasible sell tablets and smart phones with a huge collection of cute and creative applications written in C, fortran, and assembly, it would have been done already and that company would have taken the world by storm when it let you run 20 times as many apps each 20 times as fast on smart phones that Android doesn't even support any more. The vendors are already taking the most cost-effective path - put some brilliant minds on improving the hardware, put some brilliant minds on improving the Javascript interpreter / Java Virtual Machine / PHP Hotspot / PyPy / etc... and let the hundreds of thousands of developers not brilliant enough to do either work with easier tools.

I don't see your do-over ever happening.

Clarification on how my thinking is wrong? You could argue that there was one "major version" in five years, but not one "release" in five years. Unless for some bizarre reason, probably to stretch the facts and warp reality, you don't consider 3.0 before it a "release."

"The Debian Project is pleased to announce the official release of Debian GNU/Linux version 3.1 codenamed ``sarge'' after nearly three years of constant development."

Source? Right here: http://www.debian.org/News/2005/20050606

I don't know, but my thinking seems a bit more in line with Debian's own press release than your warped view of it. And 4.0/Etch was released in an acceptable amount of time after.

Only TOR's modified version of Iceweasel 17 is at risk -- the ESR version in Debian's repo already has the patch.

Still, people using Debian's repos might want to take the time to grab another version from another repository or distro just for peace of mind. From apt-cache policy on my system (Simply Mepis 12, which is close enough to Debian that their repos are compatible):
iceweasel Version table:
22.0 -------- http://ftp.us.debian.org/debian/ experimental/main i386 Packages
19.0.2 -------- ftp://ftp.mepis.com/mepis/ mepis-12.0/main i386 Packages
17.0.7esr ----- http://ftp.us.debian.org/debian/ unstable/main i386 Packages

Only TOR's modified version of Iceweasel 17 is at risk -- the ESR version in Debian's repo already has the patch.

Still, people using Debian's repos might want to take the time to grab another version from another repository or distro just for peace of mind. From apt-cache policy on my system (Simply Mepis 12, which is close enough to Debian that their repos are compatible):
iceweasel Version table:
22.0 -------- http://ftp.us.debian.org/debian/ experimental/main i386 Packages
19.0.2 -------- ftp://ftp.mepis.com/mepis/ mepis-12.0/main i386 Packages
17.0.7esr ----- http://ftp.us.debian.org/debian/ unstable/main i386 Packages

http://benchmarksgame.alioth.debian.org/u64q/java.php

If you switch from single-core to multi-core, Java's worst performance against C++ goes from 4x the C++ speed to 2x, and in some cases it's equal. That's still behind, I don't dispute that. But it's damn close. If C, C++, and Fortran are the consistent three kings of performance, then Java (when running warmed up) is probably second and in a similar category to Go and Ocaml - close enough behind the kings that many high performance applications might benefit from the enhanced developer productivity more than the extra speedup.

Other people - not you - have tried to group Java performance in line with PHP, Perl, Python, Ruby, etc... that's clearly inaccurate.

Read the benchmarks at http://www.techempower.com/benchmarks/ and http://benchmarksgame.alioth.debian.org/

Well-written Java code running on the JVM long enough for the Hotspot Just-In-Time (JIT) to optimize it consistently runs within 2x of the speed of well-written C++ code. The JVM uses more memory, in some cases as much as 40 times more. But for speed, Java is awfully close to C++ and positively demolishes PHP.

If you don't believe it, find counter-benchmarks.

Really.

Meh.

http://benchmarksgame.alioth.debian.org/u64/java.php

Or not. Benchmarks are a game and everyone likes to play, except the users of brainfuck for whom creating a program which completes is essentially winning.

The thing is people have been trumpeting "blah is as fast as C/C++/Fortran" since nearly the inception of C and C++ and probably shortly after the inception of FORTRAN.

I think there is a kernel of truth in that the reason C, C++ and FORTRAN/Fortran are always the targets is because they are almost always either the fastest or with a few percent of the fastest.

When people start comparing execution speeds of Haskell, Python, C#, C++, $NEWLANGUAGE etc consistently against Java then I'll believe that Java is indeed king of the hill.

You haven't been paying attention, have you?

The Debian kfreebsd-gnu port has been available for a while.

Debian GNU/kFreeBSD. Now you know what to search for, you can find out as much as you ever might need.

As for why: https://wiki.debian.org/Debian_GNU/kFreeBSD_why

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

It has been part of the official release for some time now.

arandr is a standard package in Debian and can be used with Xfce too. http://packages.debian.org/unstable/main/arandr

More reliable than Google-Trends: Debian "popcon", a program that Debian users are offered to install and report their program usage.

http://qa.debian.org/popcon.php?package=gnome-shell (40k installed / 20k votes)
http://qa.debian.org/popcon.php?package=xfwm4 (16k installed, 8k votes)
http://qa.debian.org/popcon-graph.php?packages=kde-window-manager (14k installed, 8k votes)
http://qa.debian.org/popcon-graph.php?packages=xserver-xorg (80k installed, 25k votes)

The stats being what they are, you can't really compare the 40k gnome-shell installs with the 16k xfwm4 (gnome-shell is installed by default, which makes the 16k xfwm more impressive, I guess), but you can make some conclusions.

And yeah, I like gnome-shell / Gnome3. Sometimes after a crash (I run debian-experimental packages), I return to fvwm for a few hours, but I always end back onto gnome-shell. "it works", is pleasant to use, and if necessary, there are ways to customize it.

A few months ago, I had forked and published an extension for hiding the top panel. I was surprised of all the feedback and number of users it got. Better yet, someone else stepped up to maintain it and does a great job.

Seriously.. way too many trolls, and most of the rest don't bother to comment.

More reliable than Google-Trends: Debian "popcon", a program that Debian users are offered to install and report their program usage.

http://qa.debian.org/popcon.php?package=gnome-shell (40k installed / 20k votes)
http://qa.debian.org/popcon.php?package=xfwm4 (16k installed, 8k votes)
http://qa.debian.org/popcon-graph.php?packages=kde-window-manager (14k installed, 8k votes)
http://qa.debian.org/popcon-graph.php?packages=xserver-xorg (80k installed, 25k votes)

The stats being what they are, you can't really compare the 40k gnome-shell installs with the 16k xfwm4 (gnome-shell is installed by default, which makes the 16k xfwm more impressive, I guess), but you can make some conclusions.

And yeah, I like gnome-shell / Gnome3. Sometimes after a crash (I run debian-experimental packages), I return to fvwm for a few hours, but I always end back onto gnome-shell. "it works", is pleasant to use, and if necessary, there are ways to customize it.

A few months ago, I had forked and published an extension for hiding the top panel. I was surprised of all the feedback and number of users it got. Better yet, someone else stepped up to maintain it and does a great job.

Seriously.. way too many trolls, and most of the rest don't bother to comment.

More reliable than Google-Trends: Debian "popcon", a program that Debian users are offered to install and report their program usage.

http://qa.debian.org/popcon.php?package=gnome-shell (40k installed / 20k votes)
http://qa.debian.org/popcon.php?package=xfwm4 (16k installed, 8k votes)
http://qa.debian.org/popcon-graph.php?packages=kde-window-manager (14k installed, 8k votes)
http://qa.debian.org/popcon-graph.php?packages=xserver-xorg (80k installed, 25k votes)

The stats being what they are, you can't really compare the 40k gnome-shell installs with the 16k xfwm4 (gnome-shell is installed by default, which makes the 16k xfwm more impressive, I guess), but you can make some conclusions.

And yeah, I like gnome-shell / Gnome3. Sometimes after a crash (I run debian-experimental packages), I return to fvwm for a few hours, but I always end back onto gnome-shell. "it works", is pleasant to use, and if necessary, there are ways to customize it.

A few months ago, I had forked and published an extension for hiding the top panel. I was surprised of all the feedback and number of users it got. Better yet, someone else stepped up to maintain it and does a great job.

Seriously.. way too many trolls, and most of the rest don't bother to comment.

More reliable than Google-Trends: Debian "popcon", a program that Debian users are offered to install and report their program usage.

http://qa.debian.org/popcon.php?package=gnome-shell (40k installed / 20k votes)
http://qa.debian.org/popcon.php?package=xfwm4 (16k installed, 8k votes)
http://qa.debian.org/popcon-graph.php?packages=kde-window-manager (14k installed, 8k votes)
http://qa.debian.org/popcon-graph.php?packages=xserver-xorg (80k installed, 25k votes)

The stats being what they are, you can't really compare the 40k gnome-shell installs with the 16k xfwm4 (gnome-shell is installed by default, which makes the 16k xfwm more impressive, I guess), but you can make some conclusions.

And yeah, I like gnome-shell / Gnome3. Sometimes after a crash (I run debian-experimental packages), I return to fvwm for a few hours, but I always end back onto gnome-shell. "it works", is pleasant to use, and if necessary, there are ways to customize it.

A few months ago, I had forked and published an extension for hiding the top panel. I was surprised of all the feedback and number of users it got. Better yet, someone else stepped up to maintain it and does a great job.

Seriously.. way too many trolls, and most of the rest don't bother to comment.

Possibly, but there are a lot of tasks that only see about a doubling of speed. A C++ port is only likely to speed things up, while a GPU one is certain to. (Presuming the assumption about parallel execution is correct)

You cannot run an interpreted language faster than a compiled language on the same hardware unless you cheat.

I'm going to assume you are honestly ignorant, and not trolling, despite that I even mentioned JIT compilation in my previous comment.

HotSpot, the canonical JVM, has had a JIT compiler (i.e. has not been a purely interpretive VM) since 1998.

You're cheating semantically; anything is rhetorically "comparable" to anything else.

No. I meant what I wrote. They really are comparable. If we look at the shootout, where benchmarks are generally very short-running and thus considerably penalise Java compared to C, we see Java still beats C performance in two of the benchmarks.

It gets outpaced pretty roundly by C in certain other benchmarks, admittedly.

In the early days, Java performance was truly awful as it was interpreted. It was especially awful in GUI applications, as Swing was a total mess for quite a long time.

No benchmark is flawless, but look at the computer language shootout ( http://benchmarksgame.alioth.debian.org/ ) or the TechEmpower web benchmarks ( http://www.techempower.com/benchmarks/ ) Java does very well in both. In the computer language shootout, in all eleven micro-benchmarks Java finishes within a factor of two of C++ - it uses dramatically more memory, but it runs very nearly as quickly.

In the TechEmpower benchmarks, in a few places the lone C++ entry has a strong lead, but nowhere does it trump the well-written Java entries by as much as a factor of three, and in some places it loses soundly to some Java entries.

Now there are a large number of applications when a 2-3x loss of speed are unacceptable and a much larger number of applications when a 5-40x increase in required memory are unacceptable. And the Java Virtual Machine HotSpot Just-In-Time compiler starts optimizing functions that have been entered 10,000 times, so for the first few seconds or minutes of operation a Java program runs more like an interpreted language than not.

So you have to ask yourself whether Java occupies the sweet spot between the execution speed of C++ and the developer productivity of, say, Python, Ruby, Perl, and PHP. I would say... no. But that's a much more complex topic to debate. I suspect the real sweet spot might be languages like Clojure and Scala, which hit all of the strengths of the Java Virtual Machine, tie in easily to existing Java libraries, but are much nicer to work with than Java itself.

You make interesting points, AC. The reason my wife originally chose Google App engine originally (chosen in 2008, when Google has a better reputation) was to make something any community could use for free, and because my wife was comfortable with Python. It is open source, and the code coudl be ported, or the ideas reimplemented. See:
http://www.storycoloredglasses.com/2010/08/steal-these-ideas.html
"In my lessons-learned document I said that I'm more interested in the ideas from Rakontu moving on than the actual software surviving as is. Since then a few people have asked me to elaborate on that statement. So I've reviewed and thought, and I've come up with a list of six pieces of advice for anyone who would like to incorporate ideas from Rakontu into their own effort to support online story sharing."

I had suggested using the Pointrel system I was working on, but Google was the bright big-name shiny thing, and I could not guarantee my experimental stuff was production ready. Neither could Google though for App Engine, apparently, at least back then.

She now thinks that App Engine approach was a mistake for several reasons, including that, say, a Drupal add-on would have been a better approach (as much as PHP is a crummy language).

Later work by me toward Rakontu 2.0 has been in other directions, including code you can run locally or on some server of your choice (like with the GitHub stuff). But we ran out of money funding it ourselves, so now I do unrelated stuff, but at least Cynthia still works towards finishing her free book on how communities can collect and organize their own stories in a variety of ways, available as a work-in-progress here
http://www.workingwithstories.org/

Still, if you want to be concerned about privacy, and you assume the NSA monitors all internet traffic, then it really does not matter who hosts your content if you access it through the internet.

The distributed approach I was working towards included the option to exchange info via direct exchange like on flash drives (like is happening now in Cuba).
http://politics.slashdot.org/story/13/03/19/2351234/cubans-evade-censorship-by-exchanging-flash-drives

But even that is not really secure, since any collection of information can be compromised by an informant. So, ultimately, finding an innovative way to work within the system is still probably a safer bet.

This social transition may well all be over in twenty years with the pace of technological and social advancement -- in the sense of our employment-based economy imploding from advanced automation like AI-powered robotics, various group spreading Vinge-like (Deepness in the Sky) networked "smart dust" around the world (probably developed ironically by the NSA or CIA) some of which probably makes it into the NSA and CIA headquarters and all government offices by random chance (making Wikileaks and Snowden revelations seem tame by comparison), and tons of other trends.

Who knows for sure how it will all end? We can just do our best from a hopefully moral-enough strategic foundation and keep updating our tactics as we get new information or the world changes around us as it constantly does. But what that moral foundation should be for the 21st century might make for a good exploratory Slashdot discussion (my sig being a nod in that direction).

By the way, something I wrote about Schmidt and Knol:
http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-February/000401.html
"""
Gold Leader: Pardon me for asking, sir, but what good are semantic wikis and desktops going to be against [that]?
General Dodonna: Well, the Empire doesn't consider a small cgi script on a

If I want to do video or image editing, that shit gets turned off even faster, if I don't just reboot into a real OS.

Ubuntu inherits Debian policy. Anything--supported or not--is not updated in any way that breaks things. You might not be able to get security patches for stuff in Universe or Multiverse in a timely manner without rolling and submitting it yourself; but they won't go releasing a package that no longer does X when X worked before. The idea is that, if your configuration works, it will continue to work *exactly* the way you have it without modification no matter which version of the package you have across the entire lifecycle of a stable release--if it doesn't, that's a bug and they need to undo that breakage. Extending is fine, breaking is *not* acceptable.

I call bullshit. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561578#61

Common Lisp is faster, and at least as dynamic as Javascript. Not that JS compilers aren't good, but they are not the leading edge.

There are a few types of overhead involved in firmware distribution, and making that part of your system software pushes that work toward open source communities in a way they resent. If you look at things like Debian's policy, none of these blobs fit their guidelines. That means those firmware blobs go into their non-free repository. That wart is annoying enough that people regularly try to eliminate it altogether. All of that means some of the overhead manufacturers are saving by not having flash on the board is being passed on to free software packagers instead.

Similarly, there's also a very real cost involved with building, maintaining, and distributing the firmware updates and flashing code. Why should the Linux community pay for that? They'll do it, sure, but don't be surprised when people prefer options that avoid it.

How many Linux kernels are there, for instance? Only one. (There's some different versions, but they're all compatible with each other as far as running application code.) (There's also *BSD and HURD, but those aren't used nearly as much, and at least one of the BSDs actually has a Linux compatibility layer to run binary Linux applications.)

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

Because we use Glibc the portability problems are very simple and most times it's just a matter of copying a test case for "k*bsd*-gnu" from another Glibc-based system (like GNU or GNU/Linux).

So, not really a problem if you have similar POSIX interface. How do you think Cygwin works?

If Mir becomes superior to X, X may get replaced. But I would not hold my breath.

There is an organization that is supposed to be enforcing the FreeBSD trademark: http://www.freebsdfoundation.org/documents/guidelines Supposedly. Except there is a project, http://www.debian.org/ports/kfreebsd-gnu/ that is only using parts of FreeBSD, that is nonetheless calling itself FreeBSD. Actually, for something like grub 2, FreeBSD no longer exists, it's kFreeBSD. Either you own the trademark or you don't. Which is it? And since when is it such a big deal to require someone to rename their project?

Probably not 1TB, but the whole of the python modules maintained in the team are stored using SVN. That's quite a lot. And Git wouldn't play well with that much. That's 520 packages currently: http://qa.debian.org/developer.php?login=python-modules-team@lists.alioth.debian.org

That being said, the only reason why we still continue to run with SVN, is that nobody is willing to make the effort to switch everything to Git.

Consider if the FSF merges with a different organization with a different charter; like the often more corporate-friendly Open Source Initiative.

I don't see how a merger between FSF and OSI would pose a problem. The Open Source Definition published by Open Source Initiative is worded nearly identically to the Debian Free Software Guidelines on which it was based, and each of the OSD's conditions maps to one of the FSF's four freedoms.

Would be nice if such a guarantee could be written into the license itself.

I agree. But given how some countries appear not to recognize a dedication of a work to the public domain as irrevocable, charters are the best we have.

Yeah, exactly. Mozilla asking for approval for every single patch is a violation of the Debian Free Software Guidelines paragraph 3 as seen here: http://www.debian.org/social_contract and which every DD has signed off. Mozilla is evil here, not Debian.

Except, of course, that the request wasn't pointless:

Not only that, but please go a find a better example of excellent communication skills in an easily flammable thread:
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-May/027482.html

My tip of the hat to Stefano Zacchiroli for keeping it so cool and on point. This looks like a childish behavior that hurts the same project Debian Multimedia maintainer seems to be wanting to help.

Bullshit.
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-May/026678.html

Thinking about it, I think we should choose one of the two possible way
forward:

1) You and the pkg-multimedia team reach an agreement on
      which-packages-belong-where. One way to settle would be that for
      every package that exist in the official Debian archive, the same
      package should not exist in d-m.o, unless it has a version that does
      not interfere with the official packages in "standard" Debian
      installations. Another way would be to rename packages and sonames.

      I understand that such agreements would give a sort of "advantage" to
      the pkg-multimedia people over d-m.o, but that seems to be warranted
      by the fact that they are doing the official packaging, while you're
      not. If, as I hope, you could start doing your packaging work
      (wherever possible) within Debian as well, things would be different
      and we could consider solving potential technical conflicts in the
      usual Debian way.

2) You stop using "debian" as part of the domain name of your
      repository, which is confusing for users (e.g. [2,3]). That would
      allow each part to keep on doing what they want in terms of
      packaging, but at least would remove any of the existings doubts
      about the official status of d-m.o.

      [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660924#20
      [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668308#47

      I can imagine that would be a painful step for you to take, given the
      well established domain name. But it seems fair to ask you to do so
      if we couldn't manage to find an agreement between you and the
      official Debian packaging initiative of software you're maintaining
      in an unofficial repository.

TLDR version: rename all packages that collide with debian package names or drop the domain name.

Except, of course, that the request wasn't pointless:
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-May/026678.html

The name actually caused real problems for Debian maintainers and users.

See discussion on debian.legal here for detail, but the general gist is that Adobe recently changed their terms; the package you link was released after that change, but debian tends to value stability more than most other Linux distros and therefore does not yet include a version of flash that dates from after the change in licensing terms.

Adobe also grant redistribution permission to named organisations, which may have allowed some Linux distros to include it previously, but debian is unable/reluctant to do so primarily due to its distributed nature (unlike, say, red hat or ubuntu, debian is not released by a corporation that could enter into a contract with Adobe).

The benchmarks game is the first link that comes to mind.

Feel free to compare it against other languages on the benchmarks game. Python, Ruby and PHP are the slowest languages in widespread use and to make it even worse Python and Ruby both have global interpreter locks because their implementations aren't thread safe. They're terribly slow even when most of their libraries are thin wrappers around C libraries.

No, C++ is faster by as much as 3x. There are plenty of apps where that doesn't matter much, and plenty of others where it does.

I'll check out the books, thank you. I have read some of Paul Graham's blog posts before.

I think a point which you allude to is that most developers aren't willing to travel very far outside their comfort zone to learn something new. I believe James Gosling (the father of Java) said something to the effect that they were trying to pull C++ developers towards Common Lisp, and Java was as far as they could safely go.

Clojure has the practical advantage that it plugs into the JVM ecosystem. That's good for using existing libraries, but it's great for getting Java developers who wouldn't look at Common Lisp to give Clojure a try. Most of the tools in their arsenal (IDEs, Maven, Java Servlet Containers, etc...) are still relevant, so instead of learning a new ecosystem and a new syntax it's just some new syntax. But also, Clojure has immutability by default which you can work around as-needed - which I think is a good default to adapt, and seems to be a nice compromise between Scheme (which if I remember right has immutability everywhere) and Lisp. This could be the thing that pulls enough people into Lisp territory that many developers might get comfortable with Clojure and then decide the next step is Common Lisp. At least that's my hope for me. :)

I also don't think Clojure is "several orders of magnitude slower". If you look at benchmarks between a warm Java Virtual Machine (i.e. one that has executed a program long enough for the just-in-time compilation and optimization to kick in), it often uses dramatically more memory than an equivalent C++ program but generally executes within 2x of the time. ( e.g. http://benchmarksgame.alioth.debian.org/u64q/java.php ) Clojure isn't too far behind Java for performance, so I suspect against most equivalent Lisp applications Clojure is well within one order of magnitude for performance. Since that's nicely ahead of PHP, Python, Ruby, and Perl, and those four seem to dominate the internet, I'd say Clojure's performance is adequate.

Thanks for responding to me.

Would it, in principle, be possible to to provide cinnamon or mate as packages for other distributions, e.g. Ubuntu?

Sure, both Mate and Cinnamon provide these packages (right now I'm running Mate 1.6 on Ubuntu 12.04 and it works very well):

http://wiki.mate-desktop.org/download
http://cinnamon.linuxmint.com/?page_id=61

However, you won't them in the official Ubuntu repository. I suspect Mate at least will make it into Universe after Debian adopts it, which now looks like it's going to happen:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783

There is Debian, with its GNU/BSD version:

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

And Gentoo has their variant:

http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/

Those are the only two I know about :)

For those of you who don't know, asm.js is a subset of JavaScript that's meant to be easy to compile. In other words if you use asm.js the code your will work in all browsers, but should run faster in some. In that FAQ they say their compiled asm.js runs at about 1/2 the speed of C, making it roughly twice as fast as JavaScript V8.

Which is wonderful, except that JavaScirpt is a prick of a language, and so I'd imagine that asm.js is a tedious, prick of a language. But Dart compiled to asm.js - sounds like a marriage made in heaven.

If you use Linux, and other open source software, you can do a lot of learning and paid work in the software industry without having to pay expensive licences - while still being strictly legal!

word processor & other office software:
http://www.libreoffice.org/

database:
http://www.postgresql.org/

compilers:
http://gcc.gnu.org/

operating system & sufficient software to do useful things (2 of over 100 offerings, pick one that suites you best!):
https://fedoraproject.org/
http://www.debian.org/

network diagnostic:
http://www.wireshark.org/ ... and many others ...

Debian - the wellknown Linux distribution - did the same on the last stable version just recently released, Wheezy - http://www.debian.org/releases/stable/

The addon Adblock Plus is installed and enabled by default on the Iceweasel (ie Firefox) browser, with EasyList filter activated :
http://i.imgur.com/g0pMEaX.png - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693160

Even if I use some ads and tracking blockers, too (when there are animated banners, or sound, or to protect my privacy), IMHO it should be only the user who decides to put them, not the OS supplier, because it has an incidence on the web sites and numeric economy...

Debian - the wellknown Linux distribution - did the same on the last stable version just recently released, Wheezy - http://www.debian.org/releases/stable/

The addon Adblock Plus is installed and enabled by default on the Iceweasel (ie Firefox) browser, with EasyList filter activated :
http://i.imgur.com/g0pMEaX.png - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693160

Even if I use some ads and tracking blockers, too (when there are animated banners, or sound, or to protect my privacy), IMHO it should be only the user who decides to put them, not the OS supplier, because it has an incidence on the web sites and numeric economy...

Here you go: http://cdimage.debian.org/debian-cd/7.0.0/multi-arch/iso-cd/debian-7.0.0-amd64-i386-netinst.iso