Slashdot Mirror

You can distribute a GPL operating system containing non-free firmware.

You can, but you won't be in compliance with the GPL if you do. Just because people ignore the rules out of practicality doesn't mean the rules aren't being broken.

Debian are very strict GPL observers, yet they distribute an unsupported CD containing non-free firmware

Interesting. I wasn't aware that they were doing this. It is, of course, a compromise on their principles. They went through a big effort to get firmware out of main and into non-free after years of compromising for the sake of practicality.

It looks like they are trying to rationalize this CD as an "unofficial" net install CD only. It might even be OK. However, if there are GPL bits included in this net install CD, then it's still the same problem.

You can distribute a GPL operating system containing non-free firmware. Linux is GPL and still it comes with firmware blobs inside its source code tarball. Debian are very strict GPL observers, yet they distribute an unsupported CD containing non-free firmware ( http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ ).

The problem is when the firmware, beyond being non-free, is not even redistributable. In that case your only option to obtain it legally is to download it from the hardware manufacturer's (or one of its licensee's) web site, or possibly to perform surgery on the Windows drivers that came with the product.

This is not the case for AMD's firmware, which is shipped officially by themselves with the Linux kernel.

Except they do. Languages such as Ada, and really any language that allows compilers to understand what is happening in the code, can optimise out many of the bounds checking.

Excuse my ignorance but where are these benchmarks. All the ones I see have Ada as marginally slower (but i guess not statistically significantly) and everything else not even close. Coding in C you can manually put the bounds checking back in at your digression and if the coder does not know where its needed then the program can hardly be trusted to be secure.

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=gnat&lang2=gcc
If you want to quote me a better/more relevant benchmark feel free. The main issue here is the memory usage. The benchmarks where C is conclusively beaten ada uses multiples more memory (the CPU has a large cache which may be relevant here). And where it uses less it is slower. Averaging two or three times the memory usage of C exes is enough of a reason to not use it.

Also though I have no Ada experience the coding is more verbose so manually choosing bounds checking in is not necessary extra work.

Go investigate the relative performance yourself.

http://shootout.alioth.debian.org/

You are wrong. These comparisons are apples to apples, not “proper” versus “improper” code. I found that link from The Java is Faster than C++ and C++ Sucks Unbiased Benchmark, which satirically demonstrates how people may arrive at flawed perceptions about performance.

Generally speaking, experience teaches engineers that languages are not slow. Algorithms and execution environments are slow. Bad code with good compilers can be fast. Good code with bad compilers can be slow. However, languages do affect developer performance.

In the simplest sense, your belief that any language is slow relative to another is easily refuted. Consider two programs written in language X and Y respectively. Both programs produce identical output for identical input. Suppose we then introduce machine translation that compiles X into Y (or vice versa) before compilation. Or, alternatively, our respective compilers for X and Y produce identical output.

See what I did there?

That will be ready any day now. Packages for Ubuntu are already available. Debian packages for pre-release versions of PostgreSQL 9.1 have been around for some time already.

they were the one major player unable to handle a necessary security task.

I don't know "unable" means in your world, but it my world, it means "not able to be done." Were they slower than others? Yes. Were they the last one? No. Depending on who you consider "a major player", they weren't the last. If you deal with servers, Redhat and Ubuntu also patched the same day. MS only patched 3 days before Apple.

• Ubuntu: September 9, 2011
• Apple OS X: September 9, 2011
• Redhat: September 9, 2011
• FreeBSD: September 6, 2011
• MS: September 6, 2011
• Google Chrome: September 5, 2011
• OpenBSD: August 31, 2011
• Mozilla: August 31, 2011
• Debian: August 31, 2011
• Android: no date
• iOS: no date
• WP7: no date
• BBM: no date

Debian stable is horribly outdated.

You should try debian testing (7.0). I switched to it after the unity mess. Its very easy to install, almost as easy as ubuntu, and the testing repo is reasonably up to date. No problems at all other than having to get intel firmwares for my wifi (which was done through the repo, no hunting for files on the net).

I'm switching any friends that require help and it's easy for them too. The package manager is the same too (synaptic, aptitude, apt-get) so they don't even notice the difference (there is not much).

You can also always add the debian repos of chrome or firefox to always get the latest. Its just one extra line in sources.list. http://www.debian.org/releases/testing/

I'd find the source code to this Debian package and start by reading it:

http://ftp.us.debian.org/debian/pool/main/h/hello/hello_2.6-1_i386.deb

Must admit, I don't know how they got it all the way up version 2.6 ... what features did they add? And WHAT bugs did they fix?????

what about Debian and Arch? http://www.debian.org/ports/hurd/ http://www.archhurd.org/

Have you checked the following: http://www.debian.org/ports/kfreebsd-gnu/ ?

How about running this test on a distro that does both Linux and BSD, and then compare? Take Debian, take their latest releases of Linux and kFreeBSD, use the same DE from Debian's sources and the same software for both. Then run the whole thing - either on the same machine, or on 2 identical machines.

Then tell us about it

I assume we are both talking about making a consumer/enterprise OS/kernel here.
Erlang is not even in the same League as C/C++ its about 15 times slower than C and uses roughly 20 times the memory.
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=hipe&lang2=gcc
Haskell might be similar are does not lag by as much but is still completely unusable
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ghc&lang2=gcc

I’m sure I'm practice its not that bad but say your os currently uses 100MB of memory from C programs at start up this is now 2 GB.

There is no way its just the compliers/runtime fault about the performance of these languages they are just no good for C level performance. Erlang was able to distribute the load over the cores better though for all that’s worth but did not gain anything going from 1 to 4 cores.

Not saying I can but I think most Parallelism problems in C/C++ can be solved by programming better or finding/hiring a better programmer and planning beforehand and doing it the best way always helps as well. I cant see the argument for crippling an OS so we can all contribute.

I assume we are both talking about making a consumer/enterprise OS/kernel here.
Erlang is not even in the same League as C/C++ its about 15 times slower than C and uses roughly 20 times the memory.
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=hipe&lang2=gcc
Haskell might be similar are does not lag by as much but is still completely unusable
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ghc&lang2=gcc

I’m sure I'm practice its not that bad but say your os currently uses 100MB of memory from C programs at start up this is now 2 GB.

There is no way its just the compliers/runtime fault about the performance of these languages they are just no good for C level performance. Erlang was able to distribute the load over the cores better though for all that’s worth but did not gain anything going from 1 to 4 cores.

Not saying I can but I think most Parallelism problems in C/C++ can be solved by programming better or finding/hiring a better programmer and planning beforehand and doing it the best way always helps as well. I cant see the argument for crippling an OS so we can all contribute.

D's performance is not worse than C (older version of shoovtout since D's not in the most recent version). And it makes little sense to require the replacement language to be faster; except for things like runtime JIT optimizations, if there's a way to code it to run fast in any other language, you could, with sufficient effort, reproduce that performance with C code, though it might be a heckua lot more complicated.

Your arguments could just as well be used against the introduction of C and Fortran to replace programming directly in assembler: there were libraries in assembler which would be incompatible with some of what people did in C or Fortran, and if you can code something to run fast in C or Fortran you can, with sufficient effort you can get the same performance from code written directly in asm. But moving to higher-level languages had huge benefits for programmer efficiency and program safety, and a C developer may well write something which performs better than what an asm dev can write in the same amount of time. The same kind of advances can be realized by moving from C to a better language.

Nobody is even trying. Most of the effort in programming languages today involves late binding, just-in-time compilation, virtual machines, and complex template and object semantics. The last really serious effort to fix the problems of C as a systems programming language was Ada, and it was just too bulky. (On the other hand, modern C++ makes modern Ada look simple.) Modula 3 was actually quite good, and an OS was written in it. But it died with DEC Research when Compaq bought DEC.

What could you do to C to make it better without effecting performance? As you said ada tried and failed you need at lest one (probably heaps) of brilliant new concepts to stick into a language. Buffer overflows are solved by using functions with checking that slow things down.

Looking at ATS it could work less memory and same speed and no where near as much work on the complier.

On Aug. 24, project developers had promised a fix within 48 hours, then revised the timetable two days later to 24 hours. The security advisory did not explain the delay."

I don't get this part. Even if we everything in the previous statement, 2d + 2d + 1d = 5 days. The 24 was 9 days ago.

What did I miss?

Debian, on the other hand, gave a fix 5 days later (4 days ago), way before the upstream.
http://www.debian.org/security/2011/dsa-2298

None of the major distros use vanilla kernel.org kernels, so most Linux users won't be affected either way. Their update programs get kernel updates from their distro's servers, not from kernel.org. The distros are usually a few versions behind, so most won't be affected by this at all.

You can bet there's people at Debian, Ubuntu, Red Hat, etc. who are taking this very seriously. They aren't going to take any chances.

The only users out there who are potentially in danger are the ones that use kernel.org source directly, the ones who run bleeding edge distros (like Debian Sid), or the ones that use a distro that automatically downloads and compiles kernel.org code. These guys should already know the risk they're taking.

Anyway, as far as your second question - what OS could act as a drop-in replacement for the Linux kernel - check out kFreeBSD. Sure, it's not exactly the same - FreeBSD has always had different priorities than Linux, and it's reflected in what the kernels support - but it's close enough for the important stuff.

Speaking of squid, its 2011, is squid ever gonna support ipv6? There's not much software out there that doesn't support v6, and squid is probably the most famous.

http://wiki.squid-cache.org/Features/IPv6

Thank you for researching that.

Hurray for squid-dy... I'll mosey on over to http://packages.debian.org/search?keywords=squid and install it... Oh... I see.

Apparently ver 3.1 will probably be release with the next version of Debian, but not yet available, not even in unstable. Till then its 2.7..

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

Speaking of squid, its 2011, is squid ever gonna support ipv6? There's not much software out there that doesn't support v6, and squid is probably the most famous.

http://wiki.squid-cache.org/Features/IPv6

Thank you for researching that.

Hurray for squid-dy... I'll mosey on over to http://packages.debian.org/search?keywords=squid and install it... Oh... I see.

Apparently ver 3.1 will probably be release with the next version of Debian, but not yet available, not even in unstable. Till then its 2.7..

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

I don't think I've missed a single story since I started reading Slashdot all those years ago. Seriously! Erinn Clark used to call me, "The walking Slashdot" since at any moment I would reference recent news posted to Slashdot in my arguments with fellow Linux-users at Jacksonville Linux User's group (we had lots of post-meeting social gatherings). Before RSS I would keep track of the last article I read before leaving the site so I could return and pick up where I left off--even if it was weeks later.

So thank you for not only keeping me (mostly) up-to-date with all the latest geek news and controversies but for also making a site with the best comment moderation system that ever existed. I don't think my philosophical beliefs would be where they are today if it weren't for the thousands of +5 insightful comments I've read on Slashdot over the years. Many times I've had my beliefs shattered by some meanie injecting reality into any given discussion... So long libertarianism, I hardly knew ye! (just one example).

Good luck in your future endeavors. May Slashdot be but one of many bountiful legacies you bestow upon the earth.

yes, those are serious bugs but they put out a patch. Things have been much better for me since I applied that patch to my hard drive.

Is there a quality download site left?

Yes, http://packages.debian.org/ .

The internal crypt() function of PHP is only there whenever the system function doesn't exist. So for example, in Debian, only the blowfish encryption is affected, all other encryption are using the system. Here's Ondrej post about it:

http://lists.alioth.debian.org/pipermail/pkg-php-maint/2011-August/009328.html

I am guessing that this will be the case in most Unix distribution, but it will be an issue on platforms like Windows. So, maybe this is just too much buzz...

So does Hurd, and there's orders of magnitude more software you can run on it.

Of course. Debian?

And yes, linux distros are generally dependent on repositories, but you get to pick which mirror, including your own internal one.

You can always just download the entire repos in one shot and have them at the ready whenever you want. All of Debian, for example, can be downloaded to something like 8 DVD's.

Linux users might be in trouble for sure and this is a great way to kill Linux at the desktop at work

Note that until the end of time, iceweasel will be at 3.5.16 in Debian Squeeze release (currently Squeeze is aliased to stable; some day "soon" wheezy will be released and that is currently 5.0 and then may remain forever after at 5.0)

http://packages.debian.org/squeeze/iceweasel

I don't know if windows is capable of this kind of rollout, where you prevent upgrading and whatever you put in the repo just works. But for "linux on the desktop" this is pretty trivial.

A few days ago, I had a really nasty virus that held my computer hostage (it wouldn't stop unless I paid them $50)! I was desperate for solutions, and no product seemed to work! Then I found my computer works better now...

Can we get Anon to go after this idiot?

Too late - they've already taken over his computer, maxed out his ISP account, got him kicked off the net for spamming, and drained his bank account of his affiliate commissions.

MS is exposing the core problem with general development today.

A lot of [older] hard code programmers learned C++, and only skimmed the newer higher level languages in the beginning--which they deemed inferior and went back to C++. Since we're talking hard code programmers, we're talking solid knowledge of development, algorithm & data structures, and performance.

Now granted a lot of newer higher level programmers lack the breath of development I described above (let's face it, it's a fact) due to the great APIs and frameworks developed using higher level languages, newer [younger] programmers are really API, Application devs. That is who MS sells to, but doesn't want internally unless they "change the game" (namely move the Windows core into .NET and force Intel to write a higher level instruction set API for their CPUs). With the boat load of C++ programmers out there, it's too costly to move to .NET for a kernel.... much like why COBOL and FORTRAN are still around: alive and kicking. The only best example I can think of gaming the kernel game is none other than AndroidOS (a hybrid).

Then there's the fact the higher level languages have evolved to be just as good or even better than C++, but only the few that jumped the C++ bandwagon in the late 90's in favor of the newer languages and retain excellent development skills can exploit those advantages. That's a small circle of folks. Since no employer is willing to train employees out of C++ into another language, we are still stuck with a huge C++ base of devs. This is no different from the early C++ days, when the best devs went back to C (Linux comes to mind). And this will happen to Java as well with its huge dev base.

History says you can program the same performance and capability as C++ in .NET, Java, C#, Scala, Ada, and Haskell, and more likely win in the maintenance game long term. And with the pace of development, cost and feature set needs, higher level wins hands down as long as Moore's law applies. That why I say, "Good luck with that MS", this architecture decision could be the nail in the coffin.

There are not many Linux distributions that would use BSD kernels. I don't really know why :D

Well, there is at least one: http://www.debian.org/ports/kfreebsd-gnu/

There are not many Linux distributions that would use BSD kernels. I don't really know why :D

Uh.. That would be because if they didn't use Linux, they wouldn't be a Linux distro.. by definition.

Also, the Debian operating system (generally considered to be a Linux distro) does run on the FreeBSD kernel, and GNU Hurd.

There are not many Linux distributions that would use BSD kernels. I don't really know why :D

Uh.. That would be because if they didn't use Linux, they wouldn't be a Linux distro.. by definition.

Also, the Debian operating system (generally considered to be a Linux distro) does run on the FreeBSD kernel, and GNU Hurd.

Nah, the internet is already closed down and under surveillance. Let's build a people to people Mesh network and they can go fuck themselves. We have the power to do anything we want, but we don't do it. There is always someone who has to do it for us.

If you want to protect the internet you are still protecting THEIR internet, not ours.

http://wiki.debian.org/FreedomBox

I'm not sure where you're pulling this idea of "decades" from...development of HURD began in 1990, and Linux was released in 1991. That's a difference of one year. HURD wasn't heavily developed after the release of Linux because there was no need for it. If Linux hadn't stepped into that role, there would have been a need for it, and all the effort that's currently going into Linux would just have gone into HURD or some other free software kernel. There's also no reason the BSD kernels couldn't have been bundled with the GNU userland to create a standard free software operating system. In fact, such systems exist today.

.NET abstracts away dealing with low-level pointers, everything is "managed" by the framework so it is freed when no longer used (it is still possible to leak memory by keeping references to things you don't use anymore, but the framework can only do so much for you), and various attempts to attack your program with buffer overflows etc to run shellcode wouldn't work because your high-level program doesn't deal with pointers, and .NET internals will stop buffers from overflowing (etc)

Then welcome to the world of interpreted languages. Replace .NET with Perl, Python, Java, Ruby or a ton of other languages that existed prior to C#, and this sentence makes the same sense.

Plus you have a ton of useful libraries already included. Want to pull a file from the web? No problem, create an object to represent your request, a callback to handle the response object, then send it out. Want to parse XML? One function call and you're left with a tree of XMLNode objects to walk. Maybe you can find amazing libraries for C++ but you're starting from scratch (well you had to at one point, at least) and have to check licenses on them all, etc. With .NET you start off with a good base of libraries you can use in your apps for free.

So what? Do you really think that there aren't awesome libraries with permissive licenses that can be used in any language or framework? I don't have much experience with Python, Perl, Ruby or Java, but a quick search on the list of Debian packages with "aptitude search language | wc -l" reveals more than 900 names with Ruby, 2800 with Python, 2700 with Perl and 1200 with Java (of course, not every library is packaged, and many results are bogus). This list of course includes XML and networking (and other importang things), but also more esoteric use cases, like an IRC bot or colorizing logs. All of this in a more cross platform way than .NET.

I'm not saying that .NET is bad. Probably for some specific use cases is the best. But overall, I doubt it's better than others, and I'm pretty sure it isn't worth the effort of creating it, unless you are Microsoft and have tons of cash to spare in an endevour to lock-in applications to your OS.

Is it, or are you just used to dealing with NUL-terminated strings?

Nope, they are simpler. Re-read all of the questions I asked regarding design decisions that could be made around address+length formatted strings and tell me that they are just as simple. Now I think higher-level languages should be using lengths, because their libraries abstract the details (e.g., C++ or Java). But in a language where programmers fabricate their own strings, simplicity is best.

They are simpler IFF you never use the null value. Do you have any files on your system which have NUL bytes in them? Hint: yes. See for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574104 . I would actually argue that the additional complexity in the design of the address+length formatted strings would wind up resulting in simpler code because with a good system library implementing it, nobody would ever be tempted to just do it themselves. C might be a low level language, but that doesn't mean every wheel has to be reinvented over and over again.

As for your example of concatenating 3 strings: of course you can copy it yourself without a stringstream or StringBuffer or what have you. Just make yourself a string of the right size, then fill the byte ranges by hand.

string concat (string a, string b, string c) {
    string ret = strnew( strlen(a)+strlen(b)+strlen(c) );
    strfill(ret, 0, a);
    strfill(ret, strlen(a), b);
    strfill(ret, strlen(a)+strlen(b), c);
    return ret;
}

What's so hard about that?

I can't to speak to that specific poster, but, in general, the reason people are dumping Ubuntu for Mint or Debian is that Ubuntu is dropping the classic desktop choice in 11.04.

And that fact has been hashed out in almost every Slashdot discussion of Unity, including this one.

Check out and join the Debian project, Freedombox :-)

http://wiki.debian.org/FreedomBox

A) The rest of the solution would be to use reputations, cryptographic keys (optionally), and so forth. Reputations seems to be sufficient, most of the time.

B) Well, an easy way would be to prevent one IP address from registering more than one username per, say, a day -- which would be fine for a household of users that want accounts, but not useful to spammers.

If someone is willing to put up the effort to run a botnet and register on that many different accounts -- well, why wouldn't they just use automated software like Rig to create 1,000,000 fake identities that are equally acceptable as a real name (leaving aside impractical requirements like presenting a passport to get an account). Not much you can do to stop someone determined enough to spam, but then you just rely on reputation to weed out the bad accounts, as per A) above.

After all Disney has done for cultural freedom, it's nice to see Debian is still honoring their properties with its OS names.

Couple of things: Bruce Perens, who used to work at Pixar, and developed Electric Fence while there, was once a Debian Project Leader and started the convention of codenaming Debian releases to Toy Story characters. This was all before Disney bought Pixar. HTH.

TheCaseForMultiarch mentions ppc64 + ppc. They actually mention a whole bunch of other scenarios, examples:

32/64 Architectures
- i386 / x86_64
- ppc / ppc64
- mips / mips64

Mixed instruction sets
- i386 on ia64 (hardware emulation)
- arm on any (via qemu user emulation)
- s390 on any (via Hercules)
- ia64 on i386 (via ski)

Mixed OS environment (Running binaries from one OS on another via a compatibility layer)
- Linux/i386 on FreeBSD/i386
- Solaris/sparc on Linux/sparc
- Wine/DosEmu on Linux

Quite flexible and impressive I think.

Multiarch is not gonna let you run ARM binaries on an Intel chip or anything like that

Sure it wil, with a little help from QemuUserEmulation. The Debian wiki mentions other cases:

- i386 on ia64 (hardware emulation)
- arm on any (via qemu)
- s390 on any (via Hercules)
- ia64 on i386 (via ski)

the second one is obviously interesting - transparently cross-building (to arm) and testing on your desktop is going to make a few people happy, I think. And I can see them running three or more flavours on one machine (amd64, i386, armel, ...)

nor will it let you run Windows code on Debian

Again, multiarch will help Wine to do that too - right now we need ia32-libs and lib32XXX for Wine. So yes, Debian multiarch on its own isn't enoght but it does help with the necessary emulators and/or runtimes to make it quite transparent.

Multiarch is not gonna let you run ARM binaries on an Intel chip or anything like that

Are you sure?

Both http://wiki.debian.org/Multiarch/TheCaseForMultiarch and https://wiki.ubuntu.com/MultiarchSpec appears to disagree with you.

The summary is terrible. And not just the invalid link.

Here's a more informative link than the one posted by lnunes.

Multiarch is not gonna let you run ARM binaries on an Intel chip or anything like that - nor will it let you run Windows code on Debian. What it will do, however, is let you run x86 compiled binaries on an x64 system. It will also allow for things like mixing armhf and armel code on modern ARM, but for the most part, running 32-bit x86 code on 64-bit x64 (amd64) systems will be the benefit most of us will get.

How will we benefit? You'll be able to run binary-only x86 code on your x64 system. This means Adobe Flash and Skype. Any open source code is fine, because it can be compiled for your own architecture - but for binary-only proprietary software, it may not be available for your architecture.

"But this is already possible" you may be thinking. It is, but it's a nasty kludge at the moment. These packages, when installed on 64-bit systems, depend on 32-bit versions of several system libraries, which are separate packages. There's a series of kludges to make them work, and it's not very flexible.

The heart of multiarch support is a re-designed file system layout which accounts for the architecture of any binaries. So instead of putting some binary libraries in /lib/, it puts it in /lib/amd64/ or /lib/i386/. This is the first step for allowing the same package to be installed for different architectures. Then, dpkg will have to be modified to track packages from more than one architecture on the one system.

So they are doing it in a stupid way to be different?

No, they're doing it a different way to solve a broader set of problems, as their rationale says. Feel free to debate whether the problems they claim to be solving are worth solving, or whether their solution is the right one for those problems, but don't claim they're just being stupid until you've read the rationale. (I don't have a dog in this fight; the OS I use and develop for/on uses fat binaries for the multi-architecture part of that. I'm just noting that there's a rationale to read before concluding that they're just being different to be different.)

The proposed solution appears to be needlessly more complicated than how Fedora handles it, for minimal benefit. It looks like they just want to be different. From TheCaseForMultiarch, they say they didn't adopt the lib and lib64 system because it would have been too much work changing their package management tools (remember RPM dependency hell, and how apt is so much better?).

We have both the case of a mostly 32bit system with some 64bit libs/binaries and a mostly 64 bit system with some 32bit libs/binaries. Ideally they would be treated the same. So what goes in /lib? It may need to exist for legacy reasons, should it be a symlink to /lib32 or /lib64?

Well, lib has the 32 bit libraries as usual and lib64 has the 64bit libs. It's the same in either case. And you don't even need to invent lib32. But that solution isn't complicated enough, and is already used by other distributions, so fuck that, let's invent something else.

It's even stupider than the FatELF idea of combining 50 different binaries into the same file.

Read about it here: http://wiki.debian.org/Multiarch

The link wasn't forgotten. It's Debian and as such the community is supposed to provide the links.

I guess the best way to prevent people from reading TFA is to not post a proper link...

Anyway, here is the Debian announcement.

Read about it here: http://wiki.debian.org/Multiarch

... to help support your position: It's also absurdly easy to create such a fake identity with cross-referencing information... ... and if you should be running something other than Debian, enjoy.