Slashdot Mirror

First off, show me the Tablet Monopoly that Microsoft Has.

We are not talking about tablet, unless you can show me tablets using UEFI. As far as I know, none use it (yet?).

Second, I don't see any reason why an OEM couldn't just release the same tablet with Android preinstalled instead of Windows 8.

Maybe because we aren't talking about tablets, but real computers, which are designed to run Windows?

In fact, It would be severely stupid not to do it

It would be severely stupid for OEM makers not to make computers that respect the specs of the OS that more than 90% of their customers is using.

Third, This is no different than Android having a locked bootloader. It will be cracked and people will install other OS'es on it.

Again, did you realize that we aren't talking about tablets, but about UEFI secure boot, which is going to replace (and in some case, is already replacing) your good old MBR by a (mostly, FAT) partition containing the bootloader? Maybe you should read this: http://lists.debian.org/debian-devel/2012/01/msg00168.html

The funny thing is that this is exactly what Linux users have been asking for.

Yeah, right... We all have been asking not to be able to boot our favorite operating system. Do you have some more jokes of the like?

And why not bitch at Apple for locking down OS X

Not to worry here: we do! I will never buy an Apple product.

The most important thing is - Microsoft's OS's have minimal market share on ARM-based device.

NO! We're talking about laptops/netbooks here, running ARM, not just phones and tablets, and it's about (U)EFI booting. This is something new. How many models exactly have you seen around? When I go to computer shops, I can't see any right now, simply because ... windows 8 with ARM support isn't out yet!

But you know, all this finally, may be a good news. Microsoft has been ignoring, then laughing about Linux. Now it's really clear that they FEAR it, and it shows (this is a good example).

Not only you don't understand even a tiny bit about the topic, but you're also very disrespectful about millions of Linux users. If you don't want to be too stupid on your next post about UEFI, then here's some readings: http://lists.debian.org/debian-devel/2012/01/msg00168.html

I would much rather have a Debian Swiss Army knife... mine is somewhere between Switzerland and the US right now...

http://wiki.debian.org/Merchandise/SwissKnives

OpenNTPD just ignored the leap second

OpenNTPD has clearly been written by someone who doesn't understand NTP. For example, it advertises incorrect root delay and disperson values, which can cause clients to fail to achieve a majority vote, or to pick the wrong peer to synchronise against. (Earlier versions were even worse, they advertised themselves as being at stratum 0, which could cause synchronisation loops; this has thankfully been fixed, but it doesn't inspire much confidence in the authors' competence.)

I've also found OpenNTP to fail to regulate the local clock on dodgy hardware (it would oscillate wildly, with an amplitude of 3 seconds or so), in situations where the reference ntpd coped just fine.

Folks, do yourself and everyone a favour -- run the reference NTP, run chrony, heck, run some SNTP client, but please avoid OpenNTPD.

I happened to have scanned my modest book library here (~500 items) with GCstar, which works pretty well. It can download covers and details from Amazon and so on, based on the ISBN (although the latest version in Debian fails to do that properly for some reason). Before deciding on GCstar, I had evaluated multiple solutions, including Koha and custom-based solutions, none of which being simple enough for my uses, which made me settle on GCstar... The full details of the evaluation are in the Koumbit wiki.

Since then I have started looking into e-book readers, and family have pointed me to Calibre, a e-book management software. Now it's not necessarily very good with real libraries, but since I am likely to get such a device in the near future (and therefore accumulate digital books), this looks like a very good choice, especially since it seems to have a more complete interface (especially for batch entering ISBN numbers) and a more robust engine to talk with Amazon and friends. It also seems to be better maintained and have a stronger community.

I am not sure that is so helpful in your case, but I thought I could chime in since, well, I have a small library and most of the work is automated. :) Just need to punch in the ISBN number and choose who to lease the book to (something I will do in a custom field in Calibre). A "standard" barcode reader (that behaves like a keyboard, basically) and judicious use of keyboard shortcuts should do the trick if you are really concerned about speed.

This page asserts that "Xcode 4 is a free download for all members of the iOS and Mac Developer Programs.", continuing "Sign in to your account to begin the download." and according to Apple, an account costs 99$/year.

Maybe I am missing something big here, for example "free" meaning "free" as in "free beer if you buy a subscription", but I have since suggested installing Debian. Proper package management makes it vastly easier to install and develop software.

If you run gnome programs from icewm you may experience odd problems. For example epiphany opens PDF files in GIMP http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526958 since icewm-session does not set XDG_DATA_DIRS or know much about freedesktop.org standards.

While I love to bash on Ubuntu on every (reasonable and merited) opportunity available, and they certainly aren't scarce, this isn't one of them. As others have already pointed out, the packages were removed because Oracle will not license updates, and the latest distributable version has important security vulnerabilities. It would be irresponsible to keep the current packages in the distribution and illegal to update them.

More importantly, this move is exactly what Oracle wants done, and no, it's not any sort of evil move. Dalibor Topic explains in his blog the reasons behind this change in licensing: OpenJDK is (the basis of) the reference implementation for Java 7, and the Sun (now Oracle) JDK implementation is now (going to be) based on OpenJDK; the gratis, non-free licensing for the Sun (now Oracle) JDK was a temporary solution that's reached the end of its applicability:

That non-open-source license was introduced by Sun Microsystems back in 2006, when the open-sourcing of Sun's Java SE implementation was announced at JavaOne, as a stop-gap measure until OpenJDK matured. It was a way to enable Linux distributions to take Sun's JDK 5.0 and provide their own 'native packages' based on Sun's non-open-source bits.

It was always intended to be a temporary solution, and the final solution has always been migrating to OpenJDK. Yeah, it sucks, compatibility is far from complete, and things will break as a result of this move, but it's always been the plan, and it's not Canonical fucking it up this time. For reference, as one of the comments in TFA points out, Debian did it too.

In short: nothing to see here; move along. If this makes you lose sleep, maybe you shouldn't have used Java, and maybe you should migrate to something better.

Yes it is opensource, the but code look very ugly : http://anonscm.debian.org/gitweb/?p=arm-netbook/arm-netbook.git;a=commit;h=fe9f45a106b84dacf86117a5953b5efa57bae223 Good luck to people that will work with these drivers !

So based on this chart, the assertion that the best Java program will be half as fast as the worst C++ program is false.

From the website you linked to, found at http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

C GNU gcc 1.00 1.00 1.00 [1.02] 1.26 1.65 3.24
C++ GNU g++ 1.00 1.00 1.01 [1.07] 1.29 1.72 4.31
Java 7 averaged 1.05 1.05 1.24 [1.47] 1.94 2.04 2.04
Java 7 -server 1.11 1.11 1.36 [1.65] 2.04 3.07 5.94

The [] bracketed numbers are the median of all the tests.
The C and C++ average is 1.02 + 1.07 = 2.09 / 2 = 1.045
The Java 7 averaged and Java 7 -server average is 1.47 + 1.65 = 3.12 / 2 = 1.56

The average performance ratio of Java/Server vs C/C++ is 1.56 / 1.045 = 1.492823 ... or in other words ... 49.2823 % slower.

My original statement was

Which is at least 50% slower on its best day, than C/C++ on it's worst day.

Which is not what you remembered incorrectly and then misrepresented it to be as

the best Java program will be half as fast as the worst C++ program is false.

So in summary, my comment was within a 2% margin of error accurate, based on statistics you presented as valid, and you suck at reading comprehension and math, and you post falsehoods as a result. The evidence bears this out, no need to kill the messenger.

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

Here is a nice benchmark. It is interesting because it is based on a competition of "write the fastest program you can in language X", open to anybody and with a wide diversity of problems.

Those results aren't unique to that benchmark. You can find several that get nearly the same figure by searching, but I coulnd't find any one that is better.

Here's the thread on debian-arm: http://lists.debian.org/debian-arm/2011/12/msg00008.html and the corresponding one on arm-netbook: http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/thread.html

The problem that's been made clear time and time again is that if you want low-cost mass-produced hardware, you normally have to go with GPL-violating products (see list here http://www.codon.org.uk/~mjg59/android_tablets/) and that means that you will spend the majority of your time reverse-engineering the product for anything between two weeks and two years, depending on luck and skill, before getting something useful. By the time you're done, the product is usually end-of-lifed: thus if it breaks, you're back to square one.

The reason for the GPL violations is that the low-cost China-based Factories simply have zero software skills: they're provided with binary-only firmware from an ODM who themselves usually had to sign an NDA from the SoC manufacturer, itself in direct violation of the GPL, in order to get access to the source code. Normally there's a chain of at least *five* companies with whom you have to negotiate with for several days or weeks - each - in order to explain the situation to them, against a precarious balance of them basically not giving a stuff because there's no financial incentive for them to give you anything at all: they're already making money, selling product, so why should they care?

thus, we logically concluded that the only way to get non-GPL-violating product out there is to go directly to the factories and be the supplier of their software.

so for the past two years i've been contacting and vetting China-based factories, directly, to find at least one which is prepared to work with us (RH Technology - http://www.rh-technology.com./ the basis of the deal is, "we won't charge you for software expertise if you won't charge us for hardware design costs", and after two years we finally found _one_ factory willing to do a deal, and are looking for more.

we've also found an absolutely great CPU, called the Allwinner A10, which in mass-volume quantities is only about $7: that means that a PCB similar to the raspberrypi with similar features can be made for about $15 (not $25) and, because the Allwinner CPU is an ARM Cortex A8 not an ARM11 it is at least three times quicker than the raspberrypi's CPU.

now we have at least 15 Debian Developers who are willing to support the project by buying beta hardware samples, and we're looking for more people to help support this effort, by committing to buy product (just like with the OpenPandora http://openpandora.org./ we have set up a CIC (http://en.wikipedia.org/wiki/Community_interest_company) because it's a better vehicle than a non-profit, charity or profit-maximising company. the CIC is called Rhombus Tech - http://rhombus-tech.net./

we also have the full support of the Board of Directors of the Allwinner CPU: they released full source code to us in advance. we've made it available and found it to compile successfully.

in-advance GPL-compliant hardware really is very very unusual. even USA-based companies typically release GPL source code on or after the day that a product is announced. Archos for example made a tablet that used the Telechips TCC8900 series of CPUs, and complied with the GPL (in direct violation of the standard NDA available at the time from the SoC manufacturer!).

other than that: about the only existing product on the market that i can really recommend to you is the alwaysinnovating touchbook: http://alwaysinnovating.com/ - it's about $300.

Not to mention Ruby 1.9 is statistically the same speed as Python 3 (if not just very slightly faster).

It is? Shootout makes it marginally faster in 2 tests, marginally slower in 5 tests, and 2-3x slower in two tests. Still close enough that speed shouldn't be a deciding factor though; if number crunching is so important that a 10% difference is important you'd be using C anyway :-P

"Debian" was trademarked in 1999, long before Canonical came along anyway. While Canonical and Mint must use the term "Debian" in compliance with the Debian licensing policy, Canonical gets to determine Ubuntu trademark policy. Whether "Koha" can be trademarked seems a similar question to whether "Ubuntu" can, since it's also a generic word in several languages.

Please stop spreading FUD. There have been 0 remote security holes discovered in djbdns.

Please lay off the crack, wake up, and smell the coffee. This kind of denial is flat-out dangerous.

I have a blog entry detailing the three security holes in djbdns and DJB paid the $500 security hole prize for djbdns years ago.

The most dangerous hole in an unpatched djbdns 1.05 install is the TCP "packet of death" that forces dnscache to restart (since SIGPIPE isn't caught by dnscache). I really should file a CVE for that security problem.

There is also CVE-2008-4392 as well as CVE-2009-0858; more information is in Debian's security page on djbdns.

Then run *bsd on Debian.

If you ship free software as defined by the FSF or by the Debian project, or you ship open source software as defined by Open Source Initiative, then do you "ship" only the copies you make, or do you also "ship" the copies people make from those copies?

Before people respond to lkcl (517947), let me point out that, as a fact, he is somewhat unstable (and I am not saying "he is an epic troll" because he actually believes everything he writes).

Observe how he absolutely hates proper capitalisation. In my 18 years of working with free software types, I find that the ones that never use uppercase letters are also the ones that are quick to anger. Naturally, there are hotheads that take the time to write properly. So while emotional immaturity can present as any number of symptoms, aversion to the shift key is one of them, and that symptom is strongly indicative of the diagnosis.

Another symptom is uncovered in his writings. In this analysis, we need to address a small subset of his posts to various mailing lists, because most of his posts are ordinary (like many other free software people's writings). One of his recent postings in particular[1] is very concerning. It weaves a complicated conspiracy story, referring to the supposed state of Linux on ARM, alleging GPL violations so severe that vendors "lost the right to use linux[sic] kernel source code," that China was trying to subvert freedom, that the United Kingdom is censoring the Internet, that the United States "continues to take illegal control of DNS zones," that global warming is going to end the world, and he tops it off by saying the unfortunate suicide of a Debian maintainer is proof for some of this (and he had the courage to post this to a Debian list!)

This is typical of some of lkcl's posts. And he is very quick to anger when he is challenged on them.

I am not saying lkcl is bad, per se. He clearly isn't a troll. He does, however, have many signs of serious mental illness. He doesn't need contempt, instead he needs some compassion and perhaps a polite urging to seek significant help. In the meantime arguing with him will just frustrate everyone and perhaps make lkcl worse off.

(Posting Anonymous Coward because I want to be insulated from lkcl's backlash).

[1] http://lists.debian.org/debian-arm/2011/08/msg00155.html

Since most people consider the firmware part of the driver, I didn't think that distinction was important to make. Bug report, and yes the situation is the one you described where I am not full of shit--non-free firmware plus free driver that doesn't fully work without it, not fglrx. Thanks for the benefit of the doubt though, conversation filled with baseless accusations of blame is a key part of the Linux community's reputation for friendly support.

Hey submitter, you are forgetting about the Debian/kFreeBSD project! http://www.debian.org/ports/kfreebsd-gnu/ Complete with apt and everything. I've been running it on a laptop with pretty decent success for almost a year now.

GNOME is a perfect study in how not to architect a software system. Everything about it is wrong.

The first mistake they made was trying to cobble half-assed object-oriented support onto C, rather than just using C++ or Objective-C. Everything about GObject is stupid and counterproductive. It makes writing code a real pain in the ass, since you need to use typecasting macros all over the place. Worse, this sort of code promotes library design that's slow and inefficient. To make it even worse, this style of C code is so convoluted that it is not optimized well by compilers, resulting in binaries that are far slower than they should be.

I don't think the overhead resulting from using C is substantial at all. Maybe you get more overhead than C++ by always using virtual calls but that is offset by not doing C++ magic like unnecessary constructor/destructor calls. You'll have to back this up if you want me to believe you.

You are incorrect here. In C++, if you choose to make virtual calls, you pay the price of indirection via a vtable (this pointer). That's it. You only pay the price in classes which have virtual methods. With GObject, all classes contain a vtable, i.e. all class methods take a pointer to the type instance, which contains within it a pointer to the vtable. Every GObject instance contains this overhead, which makes instantiation of GObject expensive, and additionally increases the memory required for every object. In comparison, you don't pay this overhead for C++ classes unless you actually require it. This isn't including the overhead of additional GObject features such as properties, which are both inefficient to process and are type-unsafe, and the use of "construction properties" in object instantiation. What makes it truly awful is that all this work to implement OO in C is mostly done by hand! You have to manually create your own vtables; you have to manually cast all types to the correct type, and if you get it wrong the compiler won't typically tell you. You have to understand the intricacies of how a C++ compiler works to implement an inferior version in C! Why would anyone willingly inflict this upon themselves?

But this is only the beginning of the GObject problems. When using GObject, the type resolution is done at run-time. Not only does this make programming unsafe--the many typecasts can hide typing issues, leading to failure at run-time rather than at compile-time, it has additional run-time overheads. Here are a few reasons: G_TYPE_CHECK_INSTANCE_CAST, G_TYPE_CHECK_CLASS_CAST, G_TYPE_CHECK_INSTANCE_TYPE, G_TYPE_CHECK_CLASS_TYPE, G_TYPE_INSTANCE_GET_CLASS. And you'll also need to check every function argument taking a GObject to make sure it's of the correct type with G_TYPE_CHECK_INSTANCE_TYPE (or commonly using a wrapper around it). This is not a cheap operation, it has to check the GType type register, which involves a string lookup in a hash table (GQuark, at least last time I looked). So you have several of those for every function call if you actually investigate the use of all the uppercase casting macros, and again inside the function. This is mostly absent for C++ code (the type checks and casts are done at compile-time), and C++ RTTI involves simple pointer comparisons of typeinfo objects; much faster, and again type-safe.

Here's an example of class using GObject: header source

This is the same class using C++

GNOME is a perfect study in how not to architect a software system. Everything about it is wrong.

The first mistake they made was trying to cobble half-assed object-oriented support onto C, rather than just using C++ or Objective-C. Everything about GObject is stupid and counterproductive. It makes writing code a real pain in the ass, since you need to use typecasting macros all over the place. Worse, this sort of code promotes library design that's slow and inefficient. To make it even worse, this style of C code is so convoluted that it is not optimized well by compilers, resulting in binaries that are far slower than they should be.

I don't think the overhead resulting from using C is substantial at all. Maybe you get more overhead than C++ by always using virtual calls but that is offset by not doing C++ magic like unnecessary constructor/destructor calls. You'll have to back this up if you want me to believe you.

You are incorrect here. In C++, if you choose to make virtual calls, you pay the price of indirection via a vtable (this pointer). That's it. You only pay the price in classes which have virtual methods. With GObject, all classes contain a vtable, i.e. all class methods take a pointer to the type instance, which contains within it a pointer to the vtable. Every GObject instance contains this overhead, which makes instantiation of GObject expensive, and additionally increases the memory required for every object. In comparison, you don't pay this overhead for C++ classes unless you actually require it. This isn't including the overhead of additional GObject features such as properties, which are both inefficient to process and are type-unsafe, and the use of "construction properties" in object instantiation. What makes it truly awful is that all this work to implement OO in C is mostly done by hand! You have to manually create your own vtables; you have to manually cast all types to the correct type, and if you get it wrong the compiler won't typically tell you. You have to understand the intricacies of how a C++ compiler works to implement an inferior version in C! Why would anyone willingly inflict this upon themselves?

But this is only the beginning of the GObject problems. When using GObject, the type resolution is done at run-time. Not only does this make programming unsafe--the many typecasts can hide typing issues, leading to failure at run-time rather than at compile-time, it has additional run-time overheads. Here are a few reasons: G_TYPE_CHECK_INSTANCE_CAST, G_TYPE_CHECK_CLASS_CAST, G_TYPE_CHECK_INSTANCE_TYPE, G_TYPE_CHECK_CLASS_TYPE, G_TYPE_INSTANCE_GET_CLASS. And you'll also need to check every function argument taking a GObject to make sure it's of the correct type with G_TYPE_CHECK_INSTANCE_TYPE (or commonly using a wrapper around it). This is not a cheap operation, it has to check the GType type register, which involves a string lookup in a hash table (GQuark, at least last time I looked). So you have several of those for every function call if you actually investigate the use of all the uppercase casting macros, and again inside the function. This is mostly absent for C++ code (the type checks and casts are done at compile-time), and C++ RTTI involves simple pointer comparisons of typeinfo objects; much faster, and again type-safe.

Here's an example of class using GObject: header source

This is the same class using C++

Debian do a net install that can be anything from just 30MB. http://www.debian.org/CD/netinst/

Do Ubuntu have a simialr installing from network version?

www.debian.org

Actually, perhaps increasing the diversity of directories might come in handy (like in /usr/i686/lib + /usr/x86-64/lib + whatever you might need, and with eventual optimizations, and with eventual debug).

Actually, what you want is multi-arch support.

Interesting to hear about the drivers you mentioned. I haven't had any troubles myself at home with Ubuntu & Gnome3. At work I have Debian Sid sitting in a virtual machine. Sid is running Gnome3 right now by default and it seems to have a better default configuration than Ubuntu. In Ubuntu, you only get to see the poweroff function when you press ALT, which feels as if the configuration was written for a laptop. It's a minor difference but still... As for multimedia in Debian, I'm not sure it's that hard. They have a wiki page about it and it seems that the same packages as in Ubuntu are available. http://wiki.debian.org/MultimediaCodecs The procedure to install them also seems the same as for Ubuntu. What's called mediabuntu i.r.t. Ubuntu is called multimedia-keyring i.r.t. Debian. But if you want to install it, make sure you install Debian Sid. Not the stable branch, that one is *really* stable, somewhat like CentOS I guess. It doesn't even have the Gnome3 packages yet.

This is how you install Openbsd. You can download a small iso for your usb/cd, and that will download anything needed thru the net.

Back in the version 3 days, you needed only a floppy or two to start such an install, nowdays is the same, but ppl mostly use usb sticks now (the floppy image still exists).

Going for randomly made iso images on bittorrent was a very stupid idea. The only reason i could see someone needing a whole iso is if they lack connectivity.

You can compare this install method to Debian netinstall, or Ubuntu minimal iso images.

TIP: The installation and configuration guide is called "FAQ" for some reason.

You could argue that software uses more memory and cpu-cycles, but apart from that how has quality decreased? Letting Java (or any other language/libraries) do stuff for you decreases the number of errors you make. Surely using a library is better than everyone writing their own string comparison algorithms? People make mistakes, for every n lines of code not written, a bug is averted.

You seem to hate Java but it's not that much slower than other languages such as C despite the 'bloat'. http://shootout.alioth.debian.org/

Are you trolling?

To give Pascal the win perhaps would could try something with a tight loop with string length operations.

I would expect in both cases they would win buy large amounts, Pascal more so.

I assume by string length perpetrations you mean c arrays vs pascal strings. Or otherwise my string structure in C has the length written before the string as well. Neither of these tests are fair.

To me once you start turning things off you prove C was right all along.

Have a look at the shootout though i expect modern complier optimisations may no longer be added to the compiler.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=fpascal&lang2=gcc
I guess you do avoid the bloated glibc using pascal. Pascal gets worse with more cores and x64.

Disclaimer: I was not around when Pascal was still being used.

>Yes, we definitely want to stimulate a new movement, and put both thought and experience into it.

I'm keen. Is the current action concentrated in any one spot, or distributed around the net?

My gut feeling is that given the activity of the last couple of years the "new movement" already exists. If what already exists was focused, documented and disseminated, there would be a substantial body of work. (IMO) What is needed is a distribution mechanism/platform: an opencollector on sterioids; a Debian for hardware.

There's also the question of whether open hardware is a new movement or a progression of the free software movement, in which case we don't create a Debian for hardware, but extend Debian to include hardware.

CentOS is fine if you just need an office file-server or print-server.
If you are running an e-commerce website, then you need to be PCI compliant and up-to-date with the latest security patches *QUICKLY*.
CentOS updates can be unpredictable as to when they will be released. Look at Wikipedia's "Delay" column for CentOS releases.
https://en.wikipedia.org/wiki/CentOS
Due to extremely slow 2011 updates and releases, I switched to an alternative OS out of fear a CentOS update might never arrive. It did release eventually.

Does your IT staff have the time and knowledge to create their own RPM files for updating CentOS, when the closed group of CentOS volunteers fail to deliver?
If not, I would suggest either pay for RHEL updates or use current free releases of Fedora, OpenSuse, Ubuntu LTS, or Debian instead.

extra note:

You've seen these paths right?

http://cdimage.debian.org/debian-cd/current/i386/iso-cd/
http://cdimage.debian.org/debian-cd/current/i386/iso-dvd/

The amount of software available in "main" is staggering. That's 52 CDs / 8 DVDs just to cover the binaries.

extra note:

You've seen these paths right?

http://cdimage.debian.org/debian-cd/current/i386/iso-cd/
http://cdimage.debian.org/debian-cd/current/i386/iso-dvd/

The amount of software available in "main" is staggering. That's 52 CDs / 8 DVDs just to cover the binaries.

Screw that, there are lingering issues with the way Unity clobbers up some files. Instead, apply the patch ( i386 version here )and everything will be good. It fixed all my Ubuntu systems at home and at work, took the suck right out of them

Screw that, there are lingering issues with the way Unity clobbers up some files. Instead, apply the patch ( i386 version here )and everything will be good. It fixed all my Ubuntu systems at home and at work, took the suck right out of them

Nope, the Unity files screw up GNOME and KDE. But, there's a patch that fixes all that. Everything has been good since I applied that patch to my Ubuntu systems at work and home

Please, let me know exactly where you have read that we recommend people not to use testing!

http://www.debian.org/doc/FAQ/ch-choosing.en.html [debian.org]

Go down to 3.1.5. The relevant quote is:

My personal order of preference is Stable, Unstable and Testing.

You could also have decided to cut/past, from the same page, just before the sentence you quoted:

This is a rather subjective issue. There is no perfect answer but only a "wise guess" could be made while deciding between unstable and testing.

Of course, you read it as well, so I wonder why you decided to post the only one sided part of the paragraph. In Debian, we try to promote the use of testing and unstable, because this helps testing the next release if you do bug reports!

Please, let me know exactly where you have read that we recommend people not to use testing!

http://www.debian.org/doc/FAQ/ch-choosing.en.html [debian.org]

Go down to 3.1.5. The relevant quote is:

My personal order of preference is Stable, Unstable and Testing.

You can of course make the argument that this isn't a "recommendation" and that they are not specifically recommending that people not use Testing but here's the reality. The guy that wrote the Debian FAQ put in the faq that he prefers Stable first then Unstable and lastly Testing. Considering there are only three (experimental?) choices and Testing is dead last with the caveat that breakage might not get fixed for months and that is in the official FAQ for the project it is for all intents and purposes a recommendation for regular users (and that's who we are talking about) not to use Testing.

So I went ahead and downloaded http://archive.debian.org/debian/dists/etch/non-free/source/Sources.gz. And guess what? THE FIRMWARE WAS THERE!

The non-free repos weren't turned on with the install. You had to edit the relevant line in /etc/apt/sources.list. For a newb just feeling his way around, this is not an option. Which is really the whole point. Saying somebody that is new should just take the time to tweak, etc. is flat out hand waving. It can take some people months of exploration before they stumble upon how to do certain things or they can happen on it in a day. That is not even remotely close to what you are arguing which is that the "right default setting wasn't to their liking". It's two completely different things. Critical hardware not working and me not having a clue how to fix it is not equal to not liking "the default setting". You are trying to argue that it is which is ridiculous. I did what many Ubuntu users do. I moved on to something (Ubuntu) that I could make work then when I was more competent, I moved back to Debian or did you miss the part where I said all of my servers use Debian? The reason I use it on the desktop is because I happen to like Unity, I like the Ubuntu community and a whole lot of other things about the distro. Slandering me by saying I am a "lost cause" and won't ever understand choice is completely false and unjustified.

By the way, don't get me wrong, I'm ok with people using Ubuntu, derivatives are a good thing, and I'm happy they are around.

Real funny quote when considered next to your previous statement.

You are talking to Ubuntu users, the same guys that left Debian because the "right default setting" (tm) (r) wasn't to their likings. It's a lost cause, they wont ever understand the word "choice"...

Emphasis mine.

Please, let me know exactly where you have read that we recommend people not to use testing!

http://www.debian.org/doc/FAQ/ch-choosing.en.html [debian.org]

Go down to 3.1.5. The relevant quote is:

My personal order of preference is Stable, Unstable and Testing.

You can of course make the argument that this isn't a "recommendation" and that they are not specifically recommending that people not use Testing but here's the reality. The guy that wrote the Debian FAQ put in the faq that he prefers Stable first then Unstable and lastly Testing. Considering there are only three (experimental?) choices and Testing is dead last with the caveat that breakage might not get fixed for months and that is in the official FAQ for the project it is for all intents and purposes a recommendation for regular users (and that's who we are talking about) not to use Testing.

So I went ahead and downloaded http://archive.debian.org/debian/dists/etch/non-free/source/Sources.gz. And guess what? THE FIRMWARE WAS THERE!

The non-free repos weren't turned on with the install. You had to edit the relevant line in /etc/apt/sources.list. For a newb just feeling his way around, this is not an option. Which is really the whole point. Saying somebody that is new should just take the time to tweak, etc. is flat out hand waving. It can take some people months of exploration before they stumble upon how to do certain things or they can happen on it in a day. That is not even remotely close to what you are arguing which is that the "right default setting wasn't to their liking". It's two completely different things. Critical hardware not working and me not having a clue how to fix it is not equal to not liking "the default setting". You are trying to argue that it is which is ridiculous. I did what many Ubuntu users do. I moved on to something (Ubuntu) that I could make work then when I was more competent, I moved back to Debian or did you miss the part where I said all of my servers use Debian? The reason I use it on the desktop is because I happen to like Unity, I like the Ubuntu community and a whole lot of other things about the distro. Slandering me by saying I am a "lost cause" and won't ever understand choice is completely false and unjustified.

By the way, don't get me wrong, I'm ok with people using Ubuntu, derivatives are a good thing, and I'm happy they are around.

Real funny quote when considered next to your previous statement.

You are talking to Ubuntu users, the same guys that left Debian because the "right default setting" (tm) (r) wasn't to their likings. It's a lost cause, they wont ever understand the word "choice"...

Emphasis mine.

I did no such thing.

Yes you did! You simply can't see it...

Nawww...Really? You should probably educate yourself on the fact that if a binary blob module is compiled for one particular kernel and the OEM doesn't support it on any other ones, you are stuck on that kernel unless you reverse engineer a new driver.

Please stop your condescending tone with things like You should probably educate yourself on the fact that...". I think every DD knows about ABI issues. You are only talking about drivers here. Things have changed. Absolutely all OEM buyers impose that drivers are in main line kernel, and they even expect them to be in stable before they buy. So the only thing you need to do, 99% of the time, is just get a newer kernel. That's unless you have some really wacko parts in your PC, which by the way, will be an issue in Ubuntu as well. If you don't trust me, ask Ben from the Debian kernel team (he did a conference about it at latest debconf, and we had a conversation about it). I never heard about any single device supported by Ubuntu that isn't in main line kernel. If you find one, please let me know!

Did you even read what I said? It worked out of the box with Ubuntu. I didn't say it only works with Ubuntu.

And that proves my first point to be right! You want the "right default setting" (tm) (r) for you, and you aren't ready to do the necessary tweaking for your specific usage, or searching in the non-free repositories if you bought some crappy hardware with non-free firmware. Having my distro and kernel full of non-free crap isn't a healthy choice, it's pushing OEM to continue to miss-behave. You just aren't ready to do anything because of the bad hardware choice you made, even searching for a CD with the necessary drivers (which really, aren't that hard to find, plus the wiki is full of advise how to get the non-free firmware in by yourself). That's ok, but please just admit it!

Not too long after that, I discovered the issue was the lack of the zd1211 firmware in the Debian repos that was present in Ubuntu.

Oh, you're talking about that: http://packages.debian.org/search?keywords=zd1211&searchon=names&suite=all&section=all
Took me few seconds to find out it's there since Etch, which is now quite a long time ago, first uploaded on the 2005-09-13, migrated to testing on the 2006-03-15. Etch was released in April 2007. So I went ahead and downloaded http://archive.debian.org/debian/dists/etch/non-free/source/Sources.gz. And guess what? THE FIRMWARE WAS THERE! So please find a better example, that one doesn't work.

What a pathetic loser you must be.

Continue with such astonishing argumentation, and I'll soon call for a godwin point!

What about people that want actual up to date supported packages that aren't in backports? What should they do?

Most of the time, it's there (all major software have backports nowadays, including Firefox, LibreOffice, X-Window, etc.). If it's not, make your useful point and argue about it on the backport mailing list, and most likely, the backport will be made.

Use Testing? Barring the fact that most of the packages in testing are months out of date, Debian themselves recommends people not use Testing as bug fixes aren't merged fast enough.

Please, let me know exactly where you have read that we recommend people not to use testing! That's what we release, and of course, we encourage as many people as possible to use testing. As for package supposedly unsuitability because they are too old for you, please give a valid example of what you are talking about. I read/hear often people talking about it, but I've

I did no such thing.

Yes you did! You simply can't see it...

Nawww...Really? You should probably educate yourself on the fact that if a binary blob module is compiled for one particular kernel and the OEM doesn't support it on any other ones, you are stuck on that kernel unless you reverse engineer a new driver.

Please stop your condescending tone with things like You should probably educate yourself on the fact that...". I think every DD knows about ABI issues. You are only talking about drivers here. Things have changed. Absolutely all OEM buyers impose that drivers are in main line kernel, and they even expect them to be in stable before they buy. So the only thing you need to do, 99% of the time, is just get a newer kernel. That's unless you have some really wacko parts in your PC, which by the way, will be an issue in Ubuntu as well. If you don't trust me, ask Ben from the Debian kernel team (he did a conference about it at latest debconf, and we had a conversation about it). I never heard about any single device supported by Ubuntu that isn't in main line kernel. If you find one, please let me know!

Did you even read what I said? It worked out of the box with Ubuntu. I didn't say it only works with Ubuntu.

And that proves my first point to be right! You want the "right default setting" (tm) (r) for you, and you aren't ready to do the necessary tweaking for your specific usage, or searching in the non-free repositories if you bought some crappy hardware with non-free firmware. Having my distro and kernel full of non-free crap isn't a healthy choice, it's pushing OEM to continue to miss-behave. You just aren't ready to do anything because of the bad hardware choice you made, even searching for a CD with the necessary drivers (which really, aren't that hard to find, plus the wiki is full of advise how to get the non-free firmware in by yourself). That's ok, but please just admit it!

Not too long after that, I discovered the issue was the lack of the zd1211 firmware in the Debian repos that was present in Ubuntu.

Oh, you're talking about that: http://packages.debian.org/search?keywords=zd1211&searchon=names&suite=all&section=all
Took me few seconds to find out it's there since Etch, which is now quite a long time ago, first uploaded on the 2005-09-13, migrated to testing on the 2006-03-15. Etch was released in April 2007. So I went ahead and downloaded http://archive.debian.org/debian/dists/etch/non-free/source/Sources.gz. And guess what? THE FIRMWARE WAS THERE! So please find a better example, that one doesn't work.

What a pathetic loser you must be.

Continue with such astonishing argumentation, and I'll soon call for a godwin point!

What about people that want actual up to date supported packages that aren't in backports? What should they do?

Most of the time, it's there (all major software have backports nowadays, including Firefox, LibreOffice, X-Window, etc.). If it's not, make your useful point and argue about it on the backport mailing list, and most likely, the backport will be made.

Use Testing? Barring the fact that most of the packages in testing are months out of date, Debian themselves recommends people not use Testing as bug fixes aren't merged fast enough.

Please, let me know exactly where you have read that we recommend people not to use testing! That's what we release, and of course, we encourage as many people as possible to use testing. As for package supposedly unsuitability because they are too old for you, please give a valid example of what you are talking about. I read/hear often people talking about it, but I've

The source is so widely replicated it would be difficult to truly retract, for example it's here for those who are interested in looking at it to look for potentially infringing pieces.

Thank you. I guess I should create a list of templates to install by default on other people's computers. The Professional Template Pack English II looks very promising.

The LanguageTool extension is not provided with the with the Debian packages. Actually, LanguageTool is not yet in the Debian repository. There has been a bug report filed, since LibreOffice ships with LanguageTool by default. So, it should probably ship with the Debian package as well. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403619

Any insight on whether LibreOffice and OpenOffice extensions will remain interchangeable as the two projects migrate away from each other?

Debian has documentation in numerous languages. See http://www.debian.org/international/

The book referenced in this article is written by Debian developers but is not part of Debian.

...And I love it.

I consider my books basically sacred. I never underline or write on their borders, unlike many people.

I do a lot of note-taking with my (regular, 3G, keyboarded) Kindle. It has really changed my way to interact with a book - So much that it even prompted me to write a program (or do you prefer the Debian package?) to be able to more easily use my annotations from the computer.

I may get flamed by the Ubuntu/Fedora crowd for this, but for servers I use and recommend Debian stable.

There are two major reasons for this: great support and things don't change unexpectedly. Because of its long release cycle you rarely see the latest and greatest versions of anything in the repos, but if anything mission-critical is needed these can be installed manually. Some recent python libraries or Firefox builds come to mind. See http://bugs.debian.org/release-critical/ for a graphical view of recent Debian releases.

The current Stable release ("Squeeze") meets your MySQL and PHP version requirements (5.1 and 5.3.3 respectively).

3.1.5 Could you tell me whether to install testing or unstable?

This is a rather subjective issue. There is no perfect answer but only a "wise guess" could be made while deciding between unstable and testing. My personal order of preference is Stable, Unstable and Testing. The issue is like this:

Stable is rock solid. It does not break.

Testing breaks less often than Unstable. But when it breaks, it takes a long time for things to get rectified. Sometimes this could be days and it could be months at times.

Unstable changes a lot, and it can break at any point. However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian.

But there are times when tracking testing would be beneficial as opposed to unstable. The author such situation due to the gcc transition from gcc3 to gcc4. He was trying to install the labplot package on a machine tracking unstable and it could not be installed in unstable as some of its dependencies have undergone gcc4 transition and some have not. But the package in testing was installable on a testing machine as the gcc4 transitioned packages had not "trickled down" to testing.

the first problem is that the cost of the whole system's components is actually, as the RaspberryPi shows, somewhere around the $40 mark. also, if you look closer at the Tegra 250 which is used in the TrimSlice, it doesn't have SATA-II. and as i mentioned in another post here, the number of modern ARM CPUs with PCI-e on the market is less than 5.

so you can't expand it (ARM systems aren't designed that way), and it happens not to have the _exact_ set of features which make it truly desirable to free software developers, which is why free software developers are plumping (reluctantly) for the OpenRD Ultimate, and wishing that there was something better.

right now, it's all a big big compromise. and that's why i started the EOMA initiative, so that those "compromises" do not impact on the development of a product: you can always go swap out the CPU card for something better when it comes along. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA

there was a discussion of the features available (and desired) on debian-arm a few months back, let me give you a link to jump somewhere into the middle of that:
http://lists.debian.org/debian-arm/2011/08/msg00012.html

New development stopped because the devs actually had to go back and FINISH THE SHIT THEY STARTED AND NEVER COMPLETED. A faster release cycle can not solve this problem, only make it worse.

The dropped features ... were features they never finished.

That's my point, actually, except for the part where you say the faster release cycle can not solve this problem. You see, it actually makes development slower (IMO), but everything that makes the cut from a nightly build to a aurora release will be released. You don't get to the point where you have tons of stale, crashy features that need to be finished "yesterday" and keep holding up the release date. Even traditionally unstable nightly can be used as a main browser now because big features are being developed in parallel synched branches (ux, ti, ...) that are only merged to the nightly if they are stable enough.

So it works perfect all the time ... except those times when it doesn't and you have to use 3.6.

I'd love to know why FF6 doesn't work for you.

Stop being such a pathetic fanboy.

Instead of defending them like an idiot, why don't you take a look at the writing on the wall. Everything you've tried to use to defend this release cycle is a shining example of how they don't know how to manage a development project.

You still have FF3.6. What are you complaining about? You still have chrome, opera, IE6~9 as alternatives. Heck, you like stability so much why aren't you using debian? Their fully supported browser version is based on firefox 3.5, and I'm sure you'll prefer lenny's release because it's based on Firefox 3 and fully patched.

This anti-fanboy atitute is what makes me go into fanboy mode.