Slashdot Mirror

I didn't really know much about systemd being a ubuntu user, but found this giving more background on the story: https://wiki.debian.org/Debate.... The wiki does a good job detailing the technologies. Given the information, the choice of systemd is interesting.

I wonder what RMS would think of a more "business-friendly" license where a commercial entity selling software could take software that's publicly-available, modify it, and then distribute that to paying customers, but not back to the community, but where the license required them only to distribute the modified source code to those same customers, however the customers were not allowed to distribute it themselves.

Any kind of selective-treatment, for people or organisations is, in Free Software terms, a Bad Thing. (Well, with the exception of the actual owner - licensing decisions will always be theirs.)

You'd fail Debian's Chinese dissident test. You'd also fail to provide Stallman's Software Freedoms 2 and 3. The FSF probably wouldn't even consider it to be 'semifree'.

As for whether it would count as Open Source: not by the OSI's definition, no. You wouldn't even meet the first criterion.

I have no problem with them releasing it as steam OS, but it's already in the Debian repo.

The link in the article points to https://lists.debian.org/debia...

The correct link is https://lists.debian.org/debia...

Not that anyone here would ever rtfa.. :)

The link in the article points to https://lists.debian.org/debia...

The correct link is https://lists.debian.org/debia...

Not that anyone here would ever rtfa.. :)

There are plenty of non-free choices... not so many free. I'd like to keep my little free sandbox thanks. Why do you want to take it from me? Obviously many feel the same way or else Debian wouldn't have such a vital community, and perhaps it follows that one of the historical reasons for this vital community is its philosophy and relatively uncompromising attitude (though too compromising for RMS apparently). I have contributed to Debian, though granted in very small ways, and frankly I'd be less motivated with the community soured and schitzophrenic with concerns completely unrelated to the Debian core mission. I have a friend who has abandoned desktop BSD because the community around it as collapsed after Apples involvement... I really don't want to see RMS being right AGAIN, this time about Debian not being strict enough.

It appears that first you must get on an airplane

Whether an airplane is needed rather depends on where you live. In your case it looks like a car would suffice.

https://wiki.debian.org/Keysig...

Note: "Debian Developer" != "any developer who uses/contributes to debian"

Don't expect to be able to achieve full DD status within the year. In order to become a DD (Debian Developer) I believe you typically also have to have been a DM (Debian Maintainer) for at least 6 months prior. Candidates are fairly thoroughly screened and trained. There is a mentoring process and everything.

For more information you can ask in #debian-mentors on irc.debian.org (irc.oftc.net) but I wouldn't recommend going there until you've done some research by first googling up and reading the information about the process and its requirements that are posted on debian.org. They don't have a lot of patience for people who refuse to do the recommended reading. They generally expect you're smart enough to know there IS recommended reading and go looking for it first before you ask for a personalized answer to your questions.

Looks like tepples comment answers my question. The Debian New Member process is outlined here.

But Debian's approval process for developers might get swamped by people trying to gain Debian Developer status just for the free games.

There is a extra 'v' in the link. The real link is https://lists.debian.org/debia...

Drop the v at the end of the link...
https://lists.debian.org/debian-devel-announce/2014/01/msg00006.htmlv

This will find duplicate files in the general sense:
http://packages.debian.org/sid...

whatever you decide on, it could probably be done in a hundred lines of perl

Funny you mention perl.

There's a tool written in perl called "findimagedupes" in Debian. Pretty awesome tool for large image collections, because it could identify duplicates even if they had been resized, or messed with a little (e.g. adding logos, etc). Point it at a directory, and it'll find all the dupes for you.

It requires a non-free compiler (Open Watcom) to build the BIOS.

http://metadata.ftp-master.debian.org/changelogs//contrib/v/virtualbox/virtualbox_4.2.16-dfsg-3~bpo70+1_copyright

Release Info link on the main page

Now if Debian would only do this! Their secret name version mapping is ridiculous. There's nothing on the main page that maps the names to the versions, and people that ask for help with it on the mailing lists are treated horrifically.

Probably because it's extremely easy to find. Quoting debian.org, including links:

The latest stable release of Debian is 7.3. The last update to this release was made on December 14th, 2013. Read more about available versions of Debian.

It's the third sentence on the page, standing alone, very easy to find. The second link in that sentence, which offers to tell you more about available versions of Debian, has the following:

Index of releases

        The next release of Debian is codenamed "jessie" — no release date has been set
        Debian 7.0 ("wheezy") — current stable release
        Debian 6.0 ("squeeze") — obsolete stable release
        Debian GNU/Linux 5.0 ("lenny") — obsolete stable release
        Debian GNU/Linux 4.0 ("etch") — obsolete stable release
        Debian GNU/Linux 3.1 ("sarge") — obsolete stable release
        Debian GNU/Linux 3.0 ("woody") — obsolete stable release
        Debian GNU/Linux 2.2 ("potato") — obsolete stable release
        Debian GNU/Linux 2.1 ("slink") — obsolete stable release
        Debian GNU/Linux 2.0 ("hamm") — obsolete stable release

Numbers with corresponding code names. Anybody cluttering the mailing lists with complaints or questions about that deserve to be slapped with a "STFU and RTFM", considering it's one bloody click away from the main page and plainly presented.

Now if Debian would only do this! Their secret name version mapping is ridiculous. There's nothing on the main page that maps the names to the versions, and people that ask for help with it on the mailing lists are treated horrifically.

Probably because it's extremely easy to find. Quoting debian.org, including links:

The latest stable release of Debian is 7.3. The last update to this release was made on December 14th, 2013. Read more about available versions of Debian.

It's the third sentence on the page, standing alone, very easy to find. The second link in that sentence, which offers to tell you more about available versions of Debian, has the following:

Index of releases

        The next release of Debian is codenamed "jessie" — no release date has been set
        Debian 7.0 ("wheezy") — current stable release
        Debian 6.0 ("squeeze") — obsolete stable release
        Debian GNU/Linux 5.0 ("lenny") — obsolete stable release
        Debian GNU/Linux 4.0 ("etch") — obsolete stable release
        Debian GNU/Linux 3.1 ("sarge") — obsolete stable release
        Debian GNU/Linux 3.0 ("woody") — obsolete stable release
        Debian GNU/Linux 2.2 ("potato") — obsolete stable release
        Debian GNU/Linux 2.1 ("slink") — obsolete stable release
        Debian GNU/Linux 2.0 ("hamm") — obsolete stable release

Numbers with corresponding code names. Anybody cluttering the mailing lists with complaints or questions about that deserve to be slapped with a "STFU and RTFM", considering it's one bloody click away from the main page and plainly presented.

There is already a pretty good collection http://www.99-bottles-of-beer.net/

There is also a website with the implementations of the Perl cookbook in a bunch of languages: http://pleac.sourceforge.net/

Where performance is concerned I'd go for something like the Debian Benchmarks game. The time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads. With enough people participating in the pissing contest you eventually get things optimized to hell and the wheat is separated from the chaff.

http://benchmarksgame.alioth.debian.org/
http://benchmarksgame.alioth.debian.org/play.php

As for productivity, that's harder since this is highly subjective. While you can generally postulate that coding in non typed scripting languages where you don't have to worry about memory management is going to be faster than coding in a typed, manually memory managed language like C. But what happens when you compare more similar languages like Python vs. Perl? Your productivity in a language is highly dependent on your experience with it, how fast you are at typing, how intuitive the syntax is to you.... etc... But different programmers can have different issues with languages. In Perl for example the syntactic freedom can actually lead some programmers to write bugs bugs into their code because they are used to languages with a more nailed down syntax.

There is already a pretty good collection http://www.99-bottles-of-beer.net/

There is also a website with the implementations of the Perl cookbook in a bunch of languages: http://pleac.sourceforge.net/

Where performance is concerned I'd go for something like the Debian Benchmarks game. The time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads. With enough people participating in the pissing contest you eventually get things optimized to hell and the wheat is separated from the chaff.

http://benchmarksgame.alioth.debian.org/
http://benchmarksgame.alioth.debian.org/play.php

As for productivity, that's harder since this is highly subjective. While you can generally postulate that coding in non typed scripting languages where you don't have to worry about memory management is going to be faster than coding in a typed, manually memory managed language like C. But what happens when you compare more similar languages like Python vs. Perl? Your productivity in a language is highly dependent on your experience with it, how fast you are at typing, how intuitive the syntax is to you.... etc... But different programmers can have different issues with languages. In Perl for example the syntactic freedom can actually lead some programmers to write bugs bugs into their code because they are used to languages with a more nailed down syntax.

Simon Peyton Jones points out that doing 'clinical trials' for programming languages is hard, because it's expensive, and because "programming language is weak on that score.....culturally we're not well adapted to it."

He also points out that Microsoft does something similar, they do usability testing for their APIs and languages, where a researcher sits behind a glass window, and watches programmers try to figure things out.

For pure efficiency, the benchmark game at least gives some data points. From a gut feeling, I would say LISP is rather good at letting you do the most in the least number of lines (dependency injection is insanely easy, for example, compared to Java where it's painful if you haven't planned for it).

> I wonder how younger generations do appreciate Emacs

Someone said that to me in 2002. I was a new Emacs user then, and I'm still using it now.

Debian's package install stats suggest the Emacs user base is steadily growing:

http://qa.debian.org/popcon-graph.php?packages=emacsen-common

And the developer mailing list is very active and high-quality:

https://lists.gnu.org/archive/html/emacs-devel/

However, Hip-Hop's future is looking less certain:

http://www.theonion.com/video/there-are-people-in-world-who-are-concerned-about,32163/

My iMac G4 begs to differ. It's stuck on 10.4.

And that's why I like Linux. When Apple discontinues support for that old machine, Linux is there for you.

From what I muster, it's far from exploitable in real-life scenario. Still impressive though, and this might broaden the way peoples see side-channel attacks on general computers, and not only on specific hardware.
Still, http://www.debian.org/security/2013/dsa-2821

"While I love the ideas behind systemd, and it undeniably works very well (it wouldn't have been adopted otherwise), it does have it's disadvantages. One of the most important ones is it is Linux-exclusive, which means that any distribution and any software that wants to be available for other platforms, simply cannot use it. That is the case, for example, for Debian."

That doesn't appear to be correct. Debian is currently actively considering a switch to systemd, which I don't think it'd be wasting time on if it couldn't use it.

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

I'm not the OP, but thought I'd correct a few misconceptions you seem to have.

It is the distro with the best packaging system.

While this is mostly a subjective matter, Debian's apt/dpkg is pretty archaic. .debs are nothing but glorified tarballs which get unpacked when installing, (therefore have to be created with fakeroot(1)) to name a random point at which it is inferior to a semi-decent system like Portage you can't use it to install packages from source (unless you use 10 debianisms to build a package beforehands). Searching for something with apt-cache is a joke.

You say that like tarballs are a bad idea. It worked well for Slackware. ;-)

Anyway, more to the point, debs are much more than glorified tarballs. That one deb package file contains control information, which specify version information, dependencies, basic package information, installed size, and much more. It also contains scripts to preinstall, postinstall, preremove, and postremove the package. It really is a one-stop shop when it comes to installing programs under Linux. Other than dependant packages, of course.

You can use apt to install packages from source, but the source code must come from the Debian repository. It needs to contain all the info above, and more. A source install is relatively simple to do. Basic process is "apt-get source package; cd package; debuild -us -uc; dpkg -i ../package.deb". So, that's three "debianisms" to download, build, and then install the package. Not as convenient as Portage, but apt/dpkg was not designed to be a source distribution. It probably could work as one, though. Should be simple enough to create a script which does everything automatically for you. If you want a source distro, then Gentoo is definitely the way to go.

Unsure what you find so funny about apt-cache. I use it regularly to search for packages. It works well for me.

It is the distro with the best variety of packages.

Name one relevant package which isn't available on any relevantt distro.

Unsure what you mean by "relevant package" or "relevant distro". I just did a search for a package called "clipit", on packages.gentoo.org. It's a program I like to use to copy between X clipboards, and store a clipboard history. Gentoo doesn't seem to have it. Debian does.

It is the distro with the best package maintainers.

No. Last time i had the pleasure, the maintainer in question didn't reply for 4 months, finally apologizing for not replying and (redundantly) suggesting i follow up with a patch (which i did 3 months ago, at that time). Guess I'll have to wait another couple months until it finally get applied.

One anecdote does not a conclusion make. I've had some very good experiences when dealing with Debian maintainers. In any case, this is subjective. I'm sure other distributions have some great and enthusiastic maintainers, but Debian ranks highly in my experience.

It is the distro with the best reliability.

Stupid and wrong piece of uneducated gibberish. What exactly is Debian's role in Linux' or GNU's reliability? How is Debian more reliable than, say, Gentoo? Fanboyism at its finest.

Not quite. Debian Stable achieves its high reliability by subjecting packages to a good testing period. It suffers jokes from the Linux community for being out of date, but that's what you have to do to achieve that level of reliability. Package maintainers even backport security patches to older package versions, to make sure that they don't install newer package versions on a Stable system.

Debian Testi

Ubuntu isn't especially bloated. It runs at least as good as WindowsXP out of the box, as far as performance is concerned.

To my layman's eyes, Linux has been suffering from a bit of "X distro is/once was good and is slowly dying from lack of funds or internal politics".

Then your layman's eyes are suffering from selection bias (a common problem). There are several distros that have been running solid for a very long time. Such distros are Ubuntu's own granddaddy, Fedora, Gentoo, Arch, and more recently SUSE.

As always, Debian will run on it

I'd think it were a system tray.

The original article seems to be Slashdotted (hey, can we still do that?!), but from the MATE blog:

http://mate-desktop.org/blog/2013-11-08-debian-mate-packaging-team/

"The MATE Team is very happy to say hello to the new Debian MATE Packaging Team, that is working hard to get MATE included into the next release of Debian...First packages are already in the repositories and there are many others in ftp-master NEW queue."

which links to:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708385#31

"The plan is to provide MATE inside the Debian archive before the end of the year (if the FTP master time will find enough time to review our uploads)."

Of course if you don't mind using the upstream repository, you can install it right now:

http://wiki.mate-desktop.org/download

GNU/Linux didn't work?

Nothing is stopping you running your init scripts in parallel if you need it.

Quite true, actually I think in Debian this is already supported for the system boot sequence at least since Squeeze.

Together with dash being the default /bin/sh now, it already boots pretty fast, I don't see the startup time being a major factor in this decision.

It's probably more because of the fact that systemd now reaches into areas beyond pure service control that forces Debian to either follow that move or switch to another alternative that has enough manpower behind it.

Harshly stated, but in essence, true: Linux has to generate income. Android does it with massive, unavoidable invasion of privacy. Ubuntu does it with a minor, transparent and easily disabled intrusion into some of your online life.

Debian does it with volunteer work where possible, and donations for stuff (e.g. hosting) that needs money.

Arch does it with a similar volunteer/donation scheme.

Uncle Pat does it with stability and simplicity, to the exclusion of modernity (e.g. still no PAM, no sysv init scripts, and you bet your life no systemd/upstart) -- and enough people want this option to remain available that they voluntarily buy CD sets (in lieu of downloading ISOs) or slackware-branded merchandise, in sufficient amounts to pay the bills for Pat.

But yeah, if you're making a distro that doesn't appeal to either the sort of people who can volunteer useful help, or the sort who are willing to donate money (whether structured as a "donation", or as the "purchase" of physical media), I guess maybe you have to hope they're the sort who'll barter away their privacy for software. Since I am the sort who has donated and will continue to donate to projects I'd rather didn't die, I by definition don't care about projects that need to monetize my privacy to continue existing.

Or if you're greedy^Wprofit-oriented, and therefore want more income than people are willing to donate, you might have to seek alternate income sources such as users giving up their privacy. But I don't care about that, because IMO I'm a lot better off using a distro made by people focusing on making a good distro, than one made by people focusing on making a big profit. But what do I know, I'm one of those crazy* right-libertarians who believes the only thing better than a (reasonably small) company, driven to make a good product by competition and the greed/profit motive, is a (reasonably small) co-op, driven to make a good product by the members' individual motive to benefit from the goodness of the product they themselves both make and use.

I believe both preceeding cases describe Canonical, a for-profit company making an OS that's wildly popular with freeloading "end-user" types -- so I don't question the economic sense (for Canonical) of resorting privacy-monetization, and I don't really mind that they and their non-privacy-valuing users make that voluntary trade. OTOH, for the reasons stated, I also don't care whether Canonical disappears from the face of the Earth, so if I find myself, for whatever reason, using an Ubuntu machine, you can bet I'm turning it off.

*craziness measured relative to my fellow US right-libertarians, to most of whom "co-op" is a four-letter word. I have seriously heard the sentence "I can see why you'd want such a thing, but a co-op just feels too socialist for me." Yeah, we're all about the individual liberties, economic freedom of voluntary association, etc., but the moment a few guys want to voluntarily associate into a certain class of organization, without imposing it on anyone else, we knee-jerk and cry "socialist"?! </political-rant>

No, just use the same compiler version. Timestamps are a problem but this can be dealt with. The real question is, when will Debian/Ubuntu/Redhat/Suse be verified? There is no point in running verified crypto software if your OS is not verified.

Some Debian people are working on this, but it does not seem to have much priority overall:

https://wiki.debian.org/ReproducibleBuilds

The non-commercial licensing violates the first of the Debian Free Software Guidelines, so Debian won't package it.

The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.

You can.

1) Use OpenBSD

2) Use FreeBSD

3) Use Debian with a FreeBSD kernel. This is debian and the kernel has PF. You get everything you want.

Shuttleworth: "'So yes, I am very proud to be, as the Register puts it, the Ubuntu Daddy. My affection for this community in its broadest sense â" from Mint to our cloud developer audience, and all the teams at Canonical and in each of our derivatives, is very tangible today.'"

Read: http://www.debian.org/intro/organization

Debian's Organizational Structure

Occasionally people need to contact someone about a particular aspect of Debian. The following is a list of different jobs and the e-mail addresses to use in order to contact the people responsible for those tasks.

Please be made aware that mails sent to some of these addresses are publicly archived, especially but not limited to those with the term "lists" in the mail domain part.

        Leader
                  current Lucas Nussbaum
        Technical Committee
                  chairman Bdale Garbee
                  member Russ Allbery
                  member Don Armstrong
                  member Andreas Barth
                  member Ian Jackson
                  member Steve Langasek
                  member Colin Watson
        Secretary
                  current Kurt Roeckx
                  assistant Neil McGovern

Can we expect Nussbaum to say he is proud of derivatives, like Ubuntu?

I'm in the Java camp myself and while I'd like it to perform better the reality is that it simply doesn't. But the reality for me and my line of work is that it easily performs "well enough"

I appreciate that "well enough" often applies in the real world, and if you have a lot of Java, know it well, etc., it would be silly to switch (though Scala sounds more interesting, is interoperable, and about the same speed). I also believe you can speed up Java number crunching a lot by using some of the packages where C/C++ has Java wrappers.

I understand the whole warmup thing w/ the JVM, but it's simply a drawback (even if it doesn't matter much on servers).

The only thing that irks me is when Java advocates say it "can be faster, is just as fast, or within a hair's breadth of C/C++". I'd love to see some benchmarks that show that, but no one ever seems to produce them.

'D' might be a good number crunching language, though I haven't tried it. I'll be the first to admit that C++ is a Rube Goldberg, C is primitive, and both give you all the rope you need to hang yourself with (though I rarely find that a problem w/ number crunching). D is kind of C++ done right, and it's a lot safer. It's come a long way, though it still has some rough edges. For instance, it still uses a "stop the world" garbage collector, though there's at least an alpha of a decent generational GC. "The Computer Language Benchmarks Game" that I often cite dropped D for an interesting reason. To reduce the work of maintaining the site they had to drop some languages, and amongst others, chose D because it was so similar to C++.

For numeric-intensive work, I can get within 20% of the speed of C++

Did you measure it? No snark - I'm curious.

I would like to see some benchmarks that support the claim that Java is almost as fast as C/C++ for number crunching. I'm in the C/C++ camp, but am willing to openly entertain what you get from good benchmarks. These benchmarks show C++ consistently beating Java.

What those benchmarks don't cover, but I'd love to see, is a comparison of pure C++, pure Java, Java w/ some wrapped C/C++ (I understand there are some nice packages like that), and NumPy/SciPy/Cython (we know straight Python is glacial compared to Java).

P.S. This is not necessarily an answer to the author's question, as he isn't clear (and may not be clear himself) about how speed critical his stuff is.

For numeric-intensive work, I can get within 20% of the speed of C++

Did you measure it? No snark - I'm curious.

I would like to see some benchmarks that support the claim that Java is almost as fast as C/C++ for number crunching. I'm in the C/C++ camp, but am willing to openly entertain what you get from good benchmarks. These benchmarks show C++ consistently beating Java.

What those benchmarks don't cover, but I'd love to see, is a comparison of pure C++, pure Java, Java w/ some wrapped C/C++ (I understand there are some nice packages like that), and NumPy/SciPy/Cython (we know straight Python is glacial compared to Java).

P.S. This is not necessarily an answer to the author's question, as he isn't clear (and may not be clear himself) about how speed critical his stuff is.

From http://lists.debian.org/debian-legal/2006/06/msg00295.html:

That discussion is about an older version of the TrueCrypt license. While the newer version hasn't been submitted for OSI certification, some say it does meet the Open Source Definition.

...if you distribute modified versions of TrueCrypt, you cannot charge for copies. That is non-free...
...nothing in the license constitutes a promise not to sue for copyright infringement. Our counsel advises that a plain reading of this indicates that if Fedora complies with all the requirements of the TrueCrypt license, we would nonetheless have no assurance that TrueCrypt will not sue me for my acts of copying, distribution, creation of derivative works, and so forth...
TrueCrypt seems to be reserving the right to sue any licensee for copyright infringement, no matter whether they comply with the conditions of the license or not. Based on this, our counsel advised that above and beyond being non-free, software under this license is not safe to use...
Our counsel advised us that this license has the appearance of being full of clever traps, which make the license appear to be a sham (and non-free).

Given all of this, plus the problems with TrueCrypt authorship etc. I think the best course of action is replacing with a free implementation, maybe starting with something like this?

From your link:

The Mines Java Toolkit (JTK) is a set of Java packages and native (non-Java) code libraries for science and engineering.

In other words, there is C/C++ wrapped in Java. That may be a good idea for many applications, but it's not a measure of Java's speed.

Ye olde Computer Language Benchmarks Game has pure Java vs. pure C++. There is one test where Java is slightly faster than C++ (and even that advantage disappears depending on which of the four processors they tried). Otherwise C++ is up to 3x faster, and an average, from glancing at the graphs, of about 2x faster.

I tend to trust these benchmarks because anyone is free to defend their favorite programming language by submitting a faster program. Hence you don't get the bias that's all too common in benchmarks, where someone tries to write Java in C++, or vice versa. Those benchmarks are also running pretty up-to-date versions of g++ and the Java HotSpot Server VM, so you don't have "five years ago A was X tines faster than B, but it's changed".

Do you trust them to audit their random number generator?

So here's a port for you to run.

apt-listbugs. I found somehow a few months ago and it's a must-have package for running Debian unstable. (If you don't want to even think about your upgrades randomly breaking stuff, then Debian unstable is not the distro you want.)

Yes.

And yes again.

Although I'd be interested in an opposite project, with a Linux kernel and a BSD userland (especially the BSD libc).

Yes.

And yes again.

Although I'd be interested in an opposite project, with a Linux kernel and a BSD userland (especially the BSD libc).

What kthreadd says. Also, remember that it's based off of Debian. Debian stable (and testing) does not use bleeding-edge items. Go read.

Now let me rephrase my question: For which of these platforms are NPAPI plug-ins still released?

Like he said, if you could be bothered to read what you're replying to.