Slashdot Mirror

FYI: Debian lenny (the current stable) ditched apache 1.3 and only includes 2.2 now.

Even the previous version of stable (etch) offered Apache 2.2 as an option. The release before that (sarge) had Apache 2.0 as an option.

that's obviously not true.

For "small challenge" however, i do agree that C can always be the fastest language. This comes from the fact that you understand the C compiler very well and how it can translate to assembly language.

Now look at programs that deal with complex algorithms on complex data structures. You have to understand how the compiler will optimize the generated assembly code of these complex algorithms. Now guess what? On many complex examples the assembly generated is way suboptimal. So what do you think? You can actually imagine a higher-level language that has a better compiler for this particular task. This language will lead to faster code than yours, no matter how good you are.

But does this happen in real world application? The answer is simply yes. Just have a look at the computer languages shootout and you will see that C is beaten on some tasks by *some* higher-level language. Most of the time the language is OCaml, which is a very very higher-level language than C.

Conclusion: what makes a language fast is not the language syntax or semantics, but the compiler

I noticed that a Canadian company was selling machines with Debian pre-installed when I was browsing the other day. http://debian.org/distrib/pre-installed

There is currently no Haskell implementation of regex-dna. Challenge met.

1) The question is about functional programming languages versus imperative programming languages- not high-level versus low-level.

2) Can we agree on a platform? If I get to name it, its going to be the Xerox 1109, and you're toast.

3) The computer language shootout has some numbers that don't look so good for C. Maybe you'd care to re-implement the thread-ring test? Cause right now it's taking C 164+ seconds to do it, and 9 on haskell. Same thing on the k-nucleotide test.

That's a good question, but not quite the right question. What the heck is it doing in _Debian_, which is the codebase for Ubuntu?

While Ubuntu usually draws from Debian Unstable, that isn't the case with Amarok. Debian Stable, Testing, and Unstable all have Amarok 1.4.10 *. The Experimental repository has 2.0.96. According to the Debian Wiki, Experimental "contains packages and tools which are still being developed, and are still in the alpha testing stage. Users shouldn't be using packages from here, because they can be dangerous and harmful even for the most experienced people."

That's a good question, but not quite the right question. What the heck is it doing in _Debian_, which is the codebase for Ubuntu?

While Ubuntu usually draws from Debian Unstable, that isn't the case with Amarok. Debian Stable, Testing, and Unstable all have Amarok 1.4.10 *. The Experimental repository has 2.0.96. According to the Debian Wiki, Experimental "contains packages and tools which are still being developed, and are still in the alpha testing stage. Users shouldn't be using packages from here, because they can be dangerous and harmful even for the most experienced people."

The truly interesting number for most people is the consumer or home user market.

Actually for me the interesting number is the number of schools and educational institutions that have, or are, implementing Skolelinux or Debian-Edu. Because in a way that means students at a, sometimes, early age starts out using Linux through their education.

Skolelinux, or other Liunux based educational operating systems, might not be widely adapted in a major way; but there are a growing number of schools in, and a few outside, Europe using it at the moment. I'd say that anyone gaining familiarity with a Linux based system through years of basic and advanced education could, given time, contribute to a far higher marked share for Linux based home operating systems a few years down the line.

But the credit removal requirement in even CC-BY might cause license incompatibility if a free program under a GNU license uses CC-BY images, audio, etc.

As far as I can tell, that was an issue with CC v2 licenses, but it's been fixed in v3:

• http://en.wikipedia.org/wiki/CC-BY#Criticism
• http://creativecommons.org/weblog/entry/7249
• https://wiki.debian.org/DFSGLicenses#CreativeCommonsShare-Alike.28CC-SA.29v3.0

It actually doesn't seem to even be talking about a known Debian version, because the stable releases never shipped a 4.7. It looks like the the 2006-2008 RNG fuckup made security-minded people want to talk about Debian, apparently because that's when a lot of people listen up. Which is annoying because it reminds of Microsoft in similar context, but also a nice reminder of just how many users there are, which is much better than obscurity (heh).

It actually doesn't seem to even be talking about a known Debian version, because the stable releases never shipped a 4.7. It looks like the the 2006-2008 RNG fuckup made security-minded people want to talk about Debian, apparently because that's when a lot of people listen up. Which is annoying because it reminds of Microsoft in similar context, but also a nice reminder of just how many users there are, which is much better than obscurity (heh).

I can't find a reference to it. Certainly they submitted a bug report. They mention they found it on debian, so it seems like they would have file one.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506115 is what you're looking for I believe.

I know who Debian is and what they're about and have pretty high confidence that I'm getting quality software from 'em. (No ssh jokes, please.)

I know who Apple and Microsoft are, and what the criteria for their stores is: the apps are required to not be too good and functional.

Sun? Who is Sun? What's your gimmick? Are you here to maximize my freedom, or just to keep me in a long-term billing arrangement with AT&T, or what?

I've found several articles about the Extremadura LinEx project but I have been unable to find any information about exactly which schools were migrated.
One article (http://lwn.net/Articles/41738/) from 2003 states one computer for every two children were installed so I would say a substantial amount of all schools were running LinEx by June 2003.
An other article (http://www.osnews.com/story/12611) from November 2005 states that 66000 computers in schools and education centers and an additional 14000 in public administration buildings.
According to a third article (posted August 2006) on debian.org, all schools were migrated to Linux during 2004 ((Article in Swedish) http://www.debian.org/News/2006/20060803.sv.html)

It's worth checking out Ubuntu Netbook Remix, an official ubuntu thing. Myself, I use debian and have no complaints. But then I use it on nearly every computer I own or have access to :)

Guidance/instructions for the eee range are here:

http://wiki.debian.org/DebianEeePC

I don't know how well it works on other netbooks, but I'm sure it's just a quick google away.

Debian may do this with Iceweasel, but Debian doesn't do this with Debian. Parens implicitly acknowledges that on some level, you need a way to establish and verify trust. Debian says, "We'll do the verification for you. If you trust us, you can trust the untrademarked software we use." In essence, Mozilla(TM) Firefox(TM) becomes "Debian(TM) Iceweasel."

this doesn't preclude them from including new functions like strlcpy and strlcat

While that's true, including those functions would break the ABI, so they aren't going to be added. Although, it's very possible they will be added at some point in a future release.

Look at the bottom of the announcement.
http://lists.debian.org/debian-devel/2009/05/msg00175.html

You can get a QEMU image for Hurd. Or a live cd. Or install Debian with the Hurd kernal.

Hardly vapor.

http://www.debian.org/ports/hurd/hurd-install

The following survey disagrees with your perception of Debian not having a significant presence in the embedded market: http://www.linuxdevices.com/articles/AT7065740528.html . I suggest you back up your statement with relevant information if you wish to use it as an argument.

Also, Ulrich Drepper does not have "every right" to disregard the ARM platform as long as it is listed as a supported architecture. My request to the steering committee can be seen here: http://lists.debian.org/debian-glibc/2007/10/msg00038.html

If Debian users want to use the strl* functions and others from BSD libc they can get them from the libbsd* packages, but of course that's far from ideal.

Name: cult of debian
Established: 1993
Major Deity(s): Bruce Perens & people called Ian
Sacred relic: Debian 1.0 discs
Antichrist: ubuntu

Bzzzt fail.

I was "around" back then (although I didn't join until a couple years later) and the 1.0 disks were an epic fail. Not a sacred relic at all. If anything, the opposite of a sacred relic...

Check out:
http://www.debian.org/doc/manuals/project-history/ch-releases.en.html

Debian 1.0 was never released: Accidently InfoMagic, a CD vendor, shipped the 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.

Also if anything would be Debian's "antichrist" it would be Debian's own non-free repository of software with licenses too icky to be in the real "main" Debian. The fact that I like the devilish non-free repository probably means I listened to too much heavy metal in the 80s.

For high-profile applications like you quote it is clear that FreeBSD (as many other source based OSs) would generally provide newer version of packages.

Yet, as Debian package statistics shows, there are lots of minor applications in active used which are not really maintained anymore by their creators - essentially only Debian Developers perform maintenance on the packages.

I'm using number of such obscure, hard-to-find packages since old times. (E.g. "cons" build system). Only once stepping outside of Debian universe for a short time, I have understood how hard it is other-wise to find the applications. Some such packages do not have home pages anymore and Googling leads directly to packages.debian.org.

No, it don't.

http://www.debian.org/ports/

Linux does work on other platform than the x86 and those other platforms do not have a BIOS. You could build some other computer that is not BIOS-compatible and would be open source from the bottom-up.

This is newer (and GNU-er): http://www.debian.org/ports/kfreebsd-gnu/

Don't forget to use Debian GNU/NetBSD ;-)

In case you prefer something more than a preconfigured appliance: http://buffalo.nas-central.org/wiki/Main_Page

Debian is also available, in fact it officially supports devices like this.

not cross-distribution
http://packages.debian.org/unstable/admin/yum yum can make mistakes (e.g. move your config files around)
rpm saves modified files, and sends a warning. What more do you need?
you'll have to restart your services eventuall
any good post installation for a service comes with a 'service X restart' command.
if there is a critical kernel patch, you'll even have to reboot
So critical kernel patches are the only thing requiring a single ssh reboot command.

I'd say that it depends on a lot of factors really.

First of all it depends on how mission critical the services that run on that system are considered and what kind of chances you're willing to take that a particular package might break something. The experience and available time of your system administrator also plays a significant role.

There's also the very highly unlikely scenario that a certain update might include "something bad", for example when the update servers are compromised. See Debian's compromises at Debian Investigation Report after Server Compromises from 2003, Debian Server restored after Compromise from 2006, and Fedora's at Infrastructure report, 2008-08-22 UTC 1200.

I currently manage just a single box (combination of a public web server and internal supporting infrastructure) for the company I work at and have it automatically install both security and normal updates.

I personally trust the distro maintainers to properly QA everything that is packaged. Also, I don't think any single system administrator has the experience or knowledge to be able to actually verify whether or not an update is going to be installed without any problems. The best effort one can make is determine whether or not an update is really needed and then keep an eye on the server while the update is being applied.

In the case of security updates it's a no-brainer for me, they need to be applied ASAP. I haven't had the energy to setup a proper monitoring solution and I've never even seen Red Hat Network in action. So if I had to manually verify available updates (or even setup some shell scripts to help me here) it would be just too much effort considering the low mission criticality of the server. If there does happen to be a problem with the server I'll find out about it fast enough then I'll take a peak at the APT log and take it from there.

I'd say that it depends on a lot of factors really.

First of all it depends on how mission critical the services that run on that system are considered and what kind of chances you're willing to take that a particular package might break something. The experience and available time of your system administrator also plays a significant role.

There's also the very highly unlikely scenario that a certain update might include "something bad", for example when the update servers are compromised. See Debian's compromises at Debian Investigation Report after Server Compromises from 2003, Debian Server restored after Compromise from 2006, and Fedora's at Infrastructure report, 2008-08-22 UTC 1200.

I currently manage just a single box (combination of a public web server and internal supporting infrastructure) for the company I work at and have it automatically install both security and normal updates.

I personally trust the distro maintainers to properly QA everything that is packaged. Also, I don't think any single system administrator has the experience or knowledge to be able to actually verify whether or not an update is going to be installed without any problems. The best effort one can make is determine whether or not an update is really needed and then keep an eye on the server while the update is being applied.

In the case of security updates it's a no-brainer for me, they need to be applied ASAP. I haven't had the energy to setup a proper monitoring solution and I've never even seen Red Hat Network in action. So if I had to manually verify available updates (or even setup some shell scripts to help me here) it would be just too much effort considering the low mission criticality of the server. If there does happen to be a problem with the server I'll find out about it fast enough then I'll take a peak at the APT log and take it from there.

Here you go.

Argh, it's much worse than I thought. I thought we had weeded this crap out yonks ago.

Hopefully Lynx can't be convinced to output arbitrary escape sequences.

the best technique is still to prevent people from getting root in the first place.

Which is why on most decent distributions root is not the primary account (default setup) and sometimes root is locked out altogether (eg, SELinux). This is also why most people still (justifiably) claim that Linux is more secure than Windows in just about every way possible: Windows' default user is root![1]

Footnote[1]: I don't know about more recent versions of Windows; I try not to touch the stuff unless I have to, and the most recent times I've had to (2000 and XP), Windows still seemed to have this problem. Even in the hands of highly skilled Windows admins, Windows seems to wallow in its insecurity.

I agree with you that Linux in general isn't a very safe bet when you want to be secure, especially not if you are worried about targeted attacks.

However, that does not mean that ``open source software, in it's current form, cannot defend against a concerted attack by any large groups of individuals. It can't be done.''

There is a project called OpenBSD which does exactly what you suggest open source projects don't do: conduct security audits of their whole system.

Personally, I would trust OpenBSD much more than I would any closed-source vendor. Also, OpenBSD has a number of security features that limit the impact of any vulnerabilities not caught by the audit process.

Also, Debian has an audit process that looks not only at the base system, but also at the packages that are included in the distribution. This does not cover all packages, but goes a whole lot further than what many vendors (particularly Microsoft) offer.

On the whole, I think you are being overly negative about security in the open source world, and too optimistic about security in the closed source world. From personal experience, I can tell you from personal experience that the idea that code in closed-source projects has to make it past "at least one code review" is simply wishful thinking. By contrast, the idea that code has to pass at least one review before being accepted is an actual reality in at least some open source projects (including Linux and OpenBSD).

So, while certainly not claiming that using Debian or even OpenBSD is a panacea for security, I have much more faith in those projects than in any closed source project.

I agree with you that Linux in general isn't a very safe bet when you want to be secure, especially not if you are worried about targeted attacks.

However, that does not mean that ``open source software, in it's current form, cannot defend against a concerted attack by any large groups of individuals. It can't be done.''

There is a project called OpenBSD which does exactly what you suggest open source projects don't do: conduct security audits of their whole system.

Personally, I would trust OpenBSD much more than I would any closed-source vendor. Also, OpenBSD has a number of security features that limit the impact of any vulnerabilities not caught by the audit process.

Also, Debian has an audit process that looks not only at the base system, but also at the packages that are included in the distribution. This does not cover all packages, but goes a whole lot further than what many vendors (particularly Microsoft) offer.

On the whole, I think you are being overly negative about security in the open source world, and too optimistic about security in the closed source world. From personal experience, I can tell you from personal experience that the idea that code in closed-source projects has to make it past "at least one code review" is simply wishful thinking. By contrast, the idea that code has to pass at least one review before being accepted is an actual reality in at least some open source projects (including Linux and OpenBSD).

So, while certainly not claiming that using Debian or even OpenBSD is a panacea for security, I have much more faith in those projects than in any closed source project.

I agree with you that Linux in general isn't a very safe bet when you want to be secure, especially not if you are worried about targeted attacks.

However, that does not mean that ``open source software, in it's current form, cannot defend against a concerted attack by any large groups of individuals. It can't be done.''

There is a project called OpenBSD which does exactly what you suggest open source projects don't do: conduct security audits of their whole system.

Personally, I would trust OpenBSD much more than I would any closed-source vendor. Also, OpenBSD has a number of security features that limit the impact of any vulnerabilities not caught by the audit process.

Also, Debian has an audit process that looks not only at the base system, but also at the packages that are included in the distribution. This does not cover all packages, but goes a whole lot further than what many vendors (particularly Microsoft) offer.

On the whole, I think you are being overly negative about security in the open source world, and too optimistic about security in the closed source world. From personal experience, I can tell you from personal experience that the idea that code in closed-source projects has to make it past "at least one code review" is simply wishful thinking. By contrast, the idea that code has to pass at least one review before being accepted is an actual reality in at least some open source projects (including Linux and OpenBSD).

So, while certainly not claiming that using Debian or even OpenBSD is a panacea for security, I have much more faith in those projects than in any closed source project.

TPB has perfectly legal uses.
Linux distros are usually transferred via TPB, so are amateur authorized releases (Lamont, Familjen, Timbuktu). Also I was conducting a few experiments with TPB regarding distribution of own files to friends.

If these are not legal uses, then something is really wrong.

I can't answer for apt-get but yum is simple, just add the package you want ignored to the "exclude" line in your repo conf file. I'm sure apt-get is just as easy.

This assumes you want the command line instead of the GUIs.

Ok, So my "don't be so damn lazy" conscience got me this time... look into pinning a package.

Although GFDL can be a free license, it can also be a non-free license if you choose to use it with some of the optional parts like invariant subsections.

This statement deliberately confuses what it means to be "free". Free doesn't mean "I can do anything I want." Free means "I have all the basic freedoms required to take advantage of this data, while at the same time it is guaranteed that others will have these freedoms as well."

No, the statement means "the GFDL is not necessarily a free license by the definitions of OSI, Debian, etc.". It's possible to put severe restrictions on derivative works: prohibiting end users from removing or modifying parts of the work, for instance. There are also dodgy restrictions on the use of things like DRM. Because of this, Debian has concluded that the GFDL is a non-free license.

Debian & Ubuntu have both been signing all their packages for quite a few years, this page would make it look like Debian has since at least '02 ... I remember that the packages were signed for a while before checking the signatures was made default, not sure of timeframe though.

As for the packages themselves, run a local apt proxy like approx, especially if you have more than one Debian or Ubuntu system. It keeps a copy of every .deb you download, and automatically purges the ones that are outdated.

How is that different from running a normal http proxy?

Currently on 8.04, I'll be upgrading to 8.10 sometime after 9.04 is released.

Staying 6 months behind is a reasonable compromise. Let the lab rats (er, enthusiasts!) debug the new stuff first. Last time I checked 8.10 in a VM there was something like 320MB worth of updated packages.

As for the packages themselves, run a local apt proxy like approx, especially if you have more than one Debian or Ubuntu system. It keeps a copy of every .deb you download, and automatically purges the ones that are outdated.

Both Java and PHP are interpreted languages because this is how you create a cross-platform language.

Each gets compiled to bytecode which gets executed in a OS specific VM.

Java is JIT compiled to native code, whereas PHP is bytecode interpreted. The difference is more than an order of magnitude. In fact, judging by this comparison, in many cases Java is about 100 times faster than PHP.

Frankly, most websites do not need an app server. Wikipedia uses PHP, not Java. It is not a 'simple' website that you say PHP is suited for.

Wikipedia is presenting uncustomised content to most users. It runs a huge squid cache in front of its PHP servers. If it tried to run PHP for each user it would crawl. I run mediawiki locally on an AMD Athlon64 2200+. It takes ~0.2 seconds of 100% CPU time to process a simple request. There is simply no way Wikipedia could run without content cacheing.

This is not to say that the task of serving that content is cheap. But they're doing a lot better than facebook; they're serving 30,000 requests/sec with only 350 servers. The difference, I suspect, is mostly down to the amount of cacheing they prform.

Facebook is much less able to cache content. It doesn't have a squid front end because relatively few users see the same exact content, unlike for wikipedia; most users are logged in most of the time and see pages customised for themselves.

I'm a rabid Debian GNU/Linux user and will never again use a Micro$oft product but I'm the first one to admit the Xandros thingy the asus guys had available on the eee was a miserable failure. It looked like something for retarded kids.

If I ever bought an eee unit, I'd instantly slap a real OS on it, such as http://wiki.debian.org/DebianEeePC

Like, there's only one Linux kernel, only one C compiler, only one bash shell.. only one Perl, only one Java...

You are correct that there are only one Linux kernel, but there are other free UNIX kernels you could use instead. When it comes to compilers both LLVM and GCC are widely used. (LLVM is used in Gallum3D, the new acceleration architecture for X, and in Shark, a CPU agnostic JIT for OpenJDK. A C frontend not based on GCC is in development) There are many shells. Ubuntu, a quite popular Linux distro, actually uses dash as default /bin/sh. While it's true that only OpenJDK (if I recall correctly) passes the TCK for Java you also have competing implementations like Harmony, what Google uses on Android. You have more competition on the parts of the Java stack that takes less time to implement.

Like, there's only one Linux kernel, only one C compiler, only one bash shell.. only one Perl, only one Java...

You are correct that there are only one Linux kernel, but there are other free UNIX kernels you could use instead. When it comes to compilers both LLVM and GCC are widely used. (LLVM is used in Gallum3D, the new acceleration architecture for X, and in Shark, a CPU agnostic JIT for OpenJDK. A C frontend not based on GCC is in development) There are many shells. Ubuntu, a quite popular Linux distro, actually uses dash as default /bin/sh. While it's true that only OpenJDK (if I recall correctly) passes the TCK for Java you also have competing implementations like Harmony, what Google uses on Android. You have more competition on the parts of the Java stack that takes less time to implement.

Sure, Java is more efficient than Python. But is it more efficient than native code? http://shootout.alioth.debian.org/ has statistics and comparisons for many languages. They wrote the best programs they could to perform different tasks in each language and compared the results.

Your claim that "[t]hey wrote the best programs they could to perform different tasks in each language and compared the results" is incorrect. That is not how the Language Shootout works, unfortunately.

From the FAQ (emphasis theirs):

We are trying to show the performance of various programming language implementations - so we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.

To me, at least, this makes the test results quite useless, unless you want to compare two languages that are very similar to begin with. Thus, comparing a functional language that is amazing at dealing with parallelism (e.g. Erlang) to a procedural one (e.g. C/C++), for instance, is likely very unfair if the same algorithm must be used.

The question, then, is whether Java and C/C++ are similar enough so a comparison like this one can be made. Given their close score (for time consumption, not memory usage) I would say yes, but that is also the only thing these tests show.

Sure, Java is more efficient than Python. But is it more efficient than native code? http://shootout.alioth.debian.org/ has statistics and comparisons for many languages. They wrote the best programs they could to perform different tasks in each language and compared the results.

Your claim that "[t]hey wrote the best programs they could to perform different tasks in each language and compared the results" is incorrect. That is not how the Language Shootout works, unfortunately.

From the FAQ (emphasis theirs):

We are trying to show the performance of various programming language implementations - so we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.

To me, at least, this makes the test results quite useless, unless you want to compare two languages that are very similar to begin with. Thus, comparing a functional language that is amazing at dealing with parallelism (e.g. Erlang) to a procedural one (e.g. C/C++), for instance, is likely very unfair if the same algorithm must be used.

The question, then, is whether Java and C/C++ are similar enough so a comparison like this one can be made. Given their close score (for time consumption, not memory usage) I would say yes, but that is also the only thing these tests show.

Sure, Java is more efficient than Python. But is it more efficient than native code? http://shootout.alioth.debian.org/ has statistics and comparisons for many languages. They wrote the best programs they could to perform different tasks in each language and compared the results.

Java compared to Python
Java compared to C
Java compared to C++

C++ is slightly faster on all the tests, but not by as much as I'd expect, and Java is faster than some of the C implementations. At best, C++ is 3x faster and at worst it's about the same. Java does have a 10 to 30x memory footprint, though.

So I hope GAE charges by the CPU hour and not the amount of memory used :)

Sure, Java is more efficient than Python. But is it more efficient than native code? http://shootout.alioth.debian.org/ has statistics and comparisons for many languages. They wrote the best programs they could to perform different tasks in each language and compared the results.

Java compared to Python
Java compared to C
Java compared to C++

C++ is slightly faster on all the tests, but not by as much as I'd expect, and Java is faster than some of the C implementations. At best, C++ is 3x faster and at worst it's about the same. Java does have a 10 to 30x memory footprint, though.

So I hope GAE charges by the CPU hour and not the amount of memory used :)

Sure, Java is more efficient than Python. But is it more efficient than native code? http://shootout.alioth.debian.org/ has statistics and comparisons for many languages. They wrote the best programs they could to perform different tasks in each language and compared the results.

Java compared to Python
Java compared to C
Java compared to C++

C++ is slightly faster on all the tests, but not by as much as I'd expect, and Java is faster than some of the C implementations. At best, C++ is 3x faster and at worst it's about the same. Java does have a 10 to 30x memory footprint, though.

So I hope GAE charges by the CPU hour and not the amount of memory used :)