 DistroWatch Weekly |
| DistroWatch Weekly, Issue 358, 14 June 2010 |
|
Welcome to this year's 24th issue of DistroWatch Weekly! The question of binary firmware is a contentious issue in many Linux circles. Although many freedom-loving users accept the position of the Free Software Foundation (FSF) which advocates removing any drivers that require proprietary firmware from the Linux kernel, there are those who challenge this view as naive and even hypocritical. Our feature story, an opinion of an expert with years of experience in the electronics industry, offers an alternative position to that of FSF. In the news section, Fedora project reveals roadmap and early feature list for version 14, Eric Hameleers presents the recently released Slackware Linux 13.1, the developers of Peppermint OS talk about their vision of Linux-based cloud computing, and Lawrence Livermore National Laboratory ports parts of the Solaris ZFS file system to Linux. Also in this issue, a brief tutorial on creating an encrypted file system for storing sensitive data. Finally, for those readers who enjoy checking the package versions in our distribution tables, we'd like to hear your suggestions for the annual package database update. Happy reading!
Content:
Listen to the Podcast edition of this week's DistroWatch Weekly in OGG (32MB) and MP3 (44MB) formats
 Join us at irc.freenode.net #distrowatch
|
| Feature Story (by Patrick Van Oosterwijck) |
Binary firmware and your freedom
Introduction
In the world of technology, there is a continuous battle between forces promoting freedom and forces trying to take it away. The Free Software Foundation (FSF) has been a vigilant guardian of freedom that constantly has brought issues to our attention that, if left unchecked, could threaten our freedom as it relates to our use technology. Due to their efforts and the GPL license, we can benefit from such marvellous pieces of software as the Linux kernel, GCC and many more. I am convinced that the open source landscape wouldn't look nearly as good as it does if it hadn't been for the GPL protecting the rights of users of free software.
While I am very supportive of the FSF in most areas, one area where I disagree with them is the issue of binary firmware used in hardware drivers. The FSF explains its position on binary firmware on this page. The page admits the drivers themselves are free, but states that "it is a good idea to avoid hardware that requires these drivers" and that "hardware that relies on them is not compatible with free software" because they require proprietary firmware. Then it goes on to show a list of offending drivers found in the Linux kernel, and explains that these drivers have been removed from their own gNewSense distribution. Other projects like Debian GNU/Linux keep the binary firmware files out of the default kernel installation but make them available in a separate package that is not installed by default. This package needs to be loaded separately from the non-free repository if the user has any hardware requiring these files.
Why do I disagree with the FSF position on binary firmware? It is my opinion that in the best case, their position could be called somewhat naive, in the worst case it could even be called hypocritical. In either case, it also draws attention away from the real issue. Those are pretty strong statements, I know. Because of my professional involvement with the electronics industry, I do have a somewhat different perspective, a perspective from the "other side" you might say: that of the hardware manufacturers. (As a disclaimer, I am not employed nor have any business relation with any of the companies making the devices on the FSF's black list. I am merely a user of chips that require firmware to be loaded in one way or another, so I am more aware than most users of how these things work.)
What is binary firmware?
Most of the peripherals that can be connected to a PC have a brain of their own. This can be in the form of a microcontroller, a microprocessor or an FPGA. In any of these cases, the basic hardware parts in the peripheral are programmable, and the manufacturer of the peripheral must implement algorithms to make the peripheral do its task and communicate with the PC. These algorithms can be implemented in software code, as in the case of microcontrollers and microprocessors, or even in code describing programmable hardware connections, as in the case of an FPGA-based peripheral. This code is referred to as "firmware".
An important characteristic of this firmware is that it runs completely on the peripheral. The PC's microprocessor does not execute any of the instructions in the firmware. In most cases, it would be even impossible for the PC's microprocessor to execute any of the code in the firmware, since peripherals generally use chips with comparatively simple architectures and instruction sets that are different from the PC's own instruction set.
I want to make this very clear: the opinion expressed in this article only relates to binary firmware executing in the peripheral device, not to binary drivers that are loaded as kernel modules by the Linux kernel and execute within the kernel. Binary kernel modules present major issues that are completely different from those presented by binary firmware.
In recent years, more of the microcontroller and microprocessor architectures used in peripherals have become supported by free software compilers like GCC and SDCC, and the situation continues to improve. But as things stand today, many of these chips are still only supported by proprietary development tools, most of which do not run on Linux. If it was even possible for the Linux kernel build system to automatically build firmware from source during the kernel build process, it would obviously not be possible in all cases. Hence, the firmware for different peripherals is distributed with the Linux kernel as a set of binary files and is referred to as "binary firmware".
Now I do realize that it would be possible for manufacturers to make the source code of the firmware for their devices available, even if the kernel would have to include the firmware in binary form due to compiler limitations. It would still not be trivial to alter the code in that case, but it would be possible for a person with the right skills and access to the right tools. I do not know this for sure, but I would think the FSF might not have a problem with the firmware in that case. Unfortunately we do not live in a world where this is commonly done, as far as I'm aware.
If having source code available for all binary firmware was the center of the FSF's policy, I would not disagree with them in any way (although I would not have much hope of achieving this goal). My problem is with the fact that the FSF is blacklisting specific drivers based on how their binary firmware is distributed, instead of focusing on the real issue of whether firmware source code is available at all. And by targeting the wrong issue, they are at the same time giving their blessing to devices that use firmware that is just as locked up, or even more locked up, than those they are blacklisting. Let me explain.
How does the peripheral chip get the firmware it needs?
- One possibility is that the firmware is programmed directly into the target chip that needs it. This is the case for many microcontroller-based and Flash-FPGA-based solutions. Often, the internal memory is protected in such a way that it is virtually impossible to access it or change it from the outside world. In some cases, with ASIC's or re-branded parts, it is impossible to even tell what architecture the chip uses, let alone what firmware it runs.
- Another possibility is that the firmware is programmed into a memory chip that is part of the peripheral board, but external to the target chip that needs the code. Some microprocessor, microcontroller and SRAM-FPGA-based devices use this option. Usually it is possible to read out the code from the memory chip and, if you had the right software tools for the target chip and a programmer for the memory chip, you could load your own firmware code if you wanted to.
- The third option is that the target chip has a boot loader that asks the PC to provide it with the firmware it needs to do its job. If the PC is running Linux, the Linux kernel will see this request and try to find the firmware. Then it will send the firmware to the chip, and once it is loaded, the chip will start to execute the firmware. Many manufacturers like this option because it provides the flexibility to update the firmware if necessary, just by changing a file on the PC, while at the same time saving cost because no non-volatile storage is needed on the peripheral.
What about your freedom?
Which of the above methods to store and deliver binary firmware seems more free to you? Remember, none of them qualify as free software, because no source code is available. But some are definitely more accessible than others.
In case of option 1, there is usually no way for you to access or change the code. In option 2, with the right tools, you have the ability to read out the binary code, and you might be able to disassemble the existing firmware code, or write entirely new code, which you can load into the device if you have a programming tool. In option 3, you can do the same thing, but you don't even need any tool to read out the binary code, because it is sitting right there in a file on your computer. There is no need for a programming tool, because the kernel takes care of loading the firmware for you. You can disassemble the existing code, or start from scratch, and change the firmware running on the peripheral just by replacing the firmware file.
I think it is obvious that option 3 grants you the most freedom, because it makes it the easiest to see what's there and make changes. No specialized hardware is needed. All you need is a disassembler and assembler for the target device and you can make changes to your hearts content. Yet this is exactly the option the FSF actively discourages and labels incompatible with free software! Why? Because of its distribution method. The firmware is distributed with the Linux kernel, instead of on the circuit board of the device. That is the only difference. Meanwhile, the FSF encourages us to buy other hardware, hardware that chooses a less accessible way of distributing its firmware: locked up inside the device. Firmware for which no source code is available either, and which is significantly harder to access and change. Yet, these devices get the FSF blessing, even though there is no source code available for their firmware either.
In my mind, this is totally wrong. Since no firmware source code is available, all these devices should be treated in exactly the same way. Either they're all okay or they're all bad. How the firmware is stored and delivered is irrelevant. Of course, declaring all devices running binary firmware unacceptable is not really an option, since that would mean you would have practically no hardware available to run your totally free OS on. Because at one level or another, you always run into a wall where things become proprietary and you lose control. After all, computing is just the execution of algorithms--whether this is done in hardware or software is merely an implementation detail. Why should it make a difference if one peripheral implements its functional algorithms totally in hardware, in a totally inaccessible way, and its associated driver is declared "free", and another peripheral implements the exact same algorithms partially in software, and its associated driver is declared "non-free" because the peripheral needs to be given a bunch of bits representing its algorithm first?
To any embedded software developer, the second option is the one that's significantly more free. To anyone else, who doesn't have the skill set or necessary tools, the two options are exactly the same when it comes to their freedom. They only have access to the PC side of the driver either way. In fact, the driver could look and act exactly the same for both devices, except for the part where one of them needs to send a file to the peripheral first before it can start to talk to it. There isn't more freedom to the kernel developer one way or the other. There isn't more freedom to the user one way or the other. They are the same.
How to rate hardware devices as related to our freedom
I suggest the following rating scheme for determining how "free" a device is and how friendly the manufacturer is to open source:
- The most freedom-friendly device is one that uses an architecture supported by open tools and for which the source code of the firmware is available.
- The next best case is that the source code of the firmware is available, but the device uses an architecture not (yet) supported by open tools.
- The next best case is either a device that has its firmware built-in or that takes a binary firmware file from the kernel, and the manufacturer allows the firmware to be distributed with the Linux kernel. This is the case the FSF makes a big deal about, promoting the built-in firmware implementation as "free" and labeling the loaded-from-the-kernel implementation "incompatible with free software". As explained above, in practice it makes no difference to our freedom and is just a minor implementation detail. In either implementation, we don't have access to the source. In either implementation, it is very easy to use the device with our free OS of choice. [Except of course if this freedom is arbitrarily taken away, not by the hardware manufacturer, who should be commended for allowing their firmware to be freely distributed with the kernel, but by a distribution under the guise of "protecting your freedom".]
- The next best case is that binary firmware needs to be loaded from the kernel, but the manufacturer does not allow the firmware to be distributed with the kernel. This is very inconvenient and the user has to jump through hoops to download the firmware and install it separately or even use some cutter tool to extract the firmware from the Windows driver. No kudos for the manufacturer here. But can you blame them? The FSF would put their device on the blacklist whether they made their firmware available for distribution with the kernel or not. So why would they bother?
- The worst case is if binary firmware needs to be loaded from the kernel, but no one has found a way to get the firmware. If public documentation on the device architecture is available, it is conceivable that someone could write firmware to support the device. If no documentation is available, someone might figure things out by reverse engineering, but the chances are rather slim. It is likely that the device cannot be used with a free OS.
Conclusion
Freedom, including software freedom, is important. However, it is a fact that total freedom does not exist in any area of life. When it comes to computers, unless you have completely open software and hardware, all the way down to the design of the chips used, you will lose your freedom at some point. It is worth fighting for the ability to hold on to this freedom as long as possible, but making arbitrary rules about how something non-free happens to be distributed is not going to help anyone. Instead, it distracts from the real issue. The reality today is that just about every device out there runs binary firmware internally. Acting as if there is no issue if this firmware doesn't touch your hard drive by having it stored conveniently out of sight elsewhere in your PC is extremely naive.
The current position of the FSF is akin to a defending army making bold claims that they are fighting an invading army, but they are only attempting to stop enemy soldiers that have their guns in their hands. At the same time they let multitudes of others who have their guns slung over their shoulders pass along without interference. Then when asked about it, they claim all the ones they let pass were harmless civilians, since they weren't using their guns. It is just a token fight, and the real issue is ignored.
As a result of this senseless rule, users of devices requiring firmware loaded by the kernel get inconvenienced by having to hunt down these files on distributions that adhere to the FSF policy, or worse, they get encouraged to buy devices with the same closed source firmware locked up in the hardware. Either way, the closed source firmware is running in the user's devices. The only difference is that the user who buys devices where the firmware is distributed inside the hardware is diluted into thinking that they have somehow gained freedom. Then they can go brag on Internet forums that they are running a "totally free system", which couldn't be further from the truth.
I suggest that instead of these scapegoat tactics and acting as if they solve any real issue, efforts should be focused on encouraging manufacturers to publish open specifications for their chips and open the source code for their firmware, whether it lives inside the hardware or gets loaded by the kernel. And let's commend those manufacturers that allow their binary firmware to be conveniently distributed with the Linux kernel instead of punishing them by blacklisting their devices. That could be a first step toward improved communication with hardware manufacturers, which in turn might make truly free firmware more likely in the future.
|
| Miscellaneous News (by Ladislav Bodnar) |
Fedora 14 features, Slackware and Peppermint OS interviews, ZFS for Linux
 Fedora 13 was released barely three weeks ago, but the developers of this popular distributions are already making plans for the next version (see the Upcoming Releases section below). Although these are still early days, Rahul Sundaram is happy to reveal three new features approved for Fedora 14 - more content in live images, faster picture browsing and multi-path device support: "Fedora is replacing the old and stagnant libjpeg library with libjpeg-turbo library by default. It contains numerous performance related enhancements and is at least twice faster in JPEG compression and decompression than original libjpeg on platforms with MMX/SSE instruction set. It has same API/ABI like original libjpeg and also runs on non-SSE platforms where it is around 25% faster. Adam Tkac is leading the fork effort as part of his involvement in the TigerVNC. As you might recall, Fedora switched over to using TigerVNC for Fedora 11 and this is a logical next step. Instead of multiple software components bundling patched versions of a library, Fedora will have a better maintained and faster equivalent. libjpeg-turbo is currently in the Fedora package review queue and looking for a reviewer. Hopefully someone volunteers to do that and we will see it in Rawhide soon."
* * * * *
 Last week's link to Slackware Linux interview with Robby Workman resulted in a number of interesting comments here, so let's continue in the same spirit this week. Slackworld's new interview, entitled Slackware does exactly what I want it to do, is with Eric Hameleers: "Another thing I want to do is to investigate into the possibility to write a script that takes a Slackware DVD ISO (or a package tree) and creates a live DVD image out of that, for promotional purposes. The linux-live scripts are nice, but too complex for my needs, plus it requires that you already have a running system. Having a script that I can throw at a development tree and gives me back a live DVD would be very nice to have. And finally, I have ideas for a modified initrd.gz (this is the file on the Slackware boot disk that contains the installer) which lets you start a PXE server running right off the installation DVD. That would make it easy to install Slackware over a network on other computers that lack a DVD drive. I may have some time for all that, hopefully in the next few months."
* * * * *
 While on the subject of interviews, here is another one - this time with the developers of Peppermint OS. This is a new Ubuntu-derived distribution with a number of web-based applications and other "cloud" features. Kendall Weaver and Shane Remington talk about the project's beginnings: "Originally the concept was rather simple, we were going to take Linux Mint and make it 'spicier' (hence the name Peppermint) by adding clean social network integration. I love the look of sidux so we decided on a color scheme in that general neighborhood. I guess the single biggest inspiration is the fact that with more applications moving to the cloud, your OS serves less purpose as an OS and more of a portal. We decided that we wanted to build the best portal. ... What we really wanted was that anyone with simple computing skills could use the software right out of the box. So, providing a very familiar workspace for the beginner was at the front of the design and operation. We want very young children to use Linux. We want to show those who are tired of overpriced and unstable operating system software that there is an alternative that works. When people hear the word 'Linux' they have a tendency to feel that they would never understand how to operate a Linux based system. We created Peppermint to lay that notion to rest once and for all and pull as many new users into Linux as we can."
* * * * *
 Something more technical, but since several readers have suggested this topic for today's news section, here we go. It's about the port of ZFS, the famous file system developed by Sun Microsystems and used in Solaris, which is now being ported to Linux: "Developers at the Lawrence Livermore National Laboratory have cooperated with Oracle to port large parts of Solaris' ZFS file system to the Linux kernel. Their aim is to make the distributed Lustre file system available under Linux with ZFS. This narrow target also explains why the Native ZFS for Linux port is incomplete. Lustre is able to directly use the ZFS DMU (Data Management Unit), which connects to the Storage Pool Allocator (SPA, storage hardware interface) rather than go through the ZFS Posix Layer (ZPL) which provides an interface for the operating system. The developers therefore have not ported the ZFS Posix Layer to Linux and this currently makes it impossible to mount ZFS volumes under Linux. However, other developers are apparently already working on the ZPL. Native ZFS for Linux can be compiled with kernel versions up to 2.6.32; among the tested platforms are the 2.6.32 kernel in Fedora 12 and in the beta version of Red Hat Enterprise Linux 6, as well as the 2.6.18 kernel in RHEL 5. The build requires the Solaris Porting Layer and a 64-bit Linux system."
|
| Questions and Answers (by Jesse Smith) |
Encrypting hard disk partition
Worried-about-private-data asks: How do I encrypt a partition?
DistroWatch answers: First, you need a partition to work on. In this example, we'll assume you have a free partition on your hard drive called sda4 (/dev/sda4). If you don't have a spare partition you can use tools such as GParted to shrink an existing partition and create a new one with the free space. (Remember to always backup your data before adjusting your partitions.)
Once you have a spare partition we need to set up encryption on the available space. To do this, we use the cryptsetup command to prepare our partition. If you don't have the cryptsetup program on your machine, you will probably be able to find it in your distribution's software repository. Please note that to perform the commands shown in this example, you'll need to have administrative privileges on your machine. This first command sets up the partition to be encrypted:
cryptsetup luksFormat /dev/sda4
At this point the system will ask you for a pass-phrase. This is the pass-phrase which will protect your data, so make sure it's something hard to guess yet easy to remember. The next step is to access your newly encrypted partition and assign it a name. Once again we use cryptsetup, this time to open the partition:
cryptsetup luksOpen /dev/sda4 secret
You will be asked to supply the pass-phrase you created in the previous step. If all went well, we'll now have opened our encrypted partition, located on sda4, and assigned it the name "secret". Our next step is to write a Linux file system to our encrypted partition. We can do that by running:
mkfs.ext3 /dev/mapper/secret
Our encrypted partition now uses the ext3 file system. Once the partition has been formatted, we can move on to using it. We'll need to create a mount point:
mkdir /mnt/encrypted
And now we can mount our partition:
mount /dev/mapper/secret /mnt/encrypted
We can now save any sensitive data we have to the file system under /mnt/encrypted. When we're finished, we need to unmount the partition and then close the encrypted device:
umount /dev/mapper/secret
cryptsetup luksClose /dev/mapper/secret
It's important to close the partition, otherwise someone else can re-mount it without needing your pass-phrase. From now on, if you want to manually access your encrypted data, you can run:
cryptsetup luksOpen /dev/sda4 secret
mount /dev/mapper/secret /mnt/encrypted
However, doing that at each boot-up can get tedious, so if you wish to mount the partition automatically and have the system prompt you for your pass-phrase at boot time, you can add entries to your /etc/crypttab and /etc/fstab files. The entry in /etc/crypttab will look like this:
secret /dev/sda4 none luks,check=ext3
And the entry in /etc/fstab, following our example, will look like this:
/dev/mapper/secret /mnt/encrypted ext3 defaults 0 0
Of course, if you're serious about keeping your data hidden from the prying eyes of the world, you shouldn't actually name your devices and mount points things like "encrypted" and "secret". That's a good way to advertise there is something special to find. You should probably pick something boring like "temp", "cdrom" or "sys", which will blend in better if anyone is looking over your shoulder. I also recommend reading the cryptsetup manual (man cryptsetup). The documentation is well laid out and offers useful options and tips.
There are some other interesting things you can do to keep your data hidden. If you're worried someone might notice your encrypted partition and try to access it, you can try a different tactic, such as creating a loopback device with a local file and encrypt the loopback file. The loopback file can be stored anywhere, including in a hidden directory. For the really paranoid, you can keep encrypted files inside a hidden, encrypted file. But, as with most security matters, there's a point where you're inconveniencing yourself more than accomplishing anything practical.
|
| Released Last Week |
Syllable Server 0.4
Kaj de Vos has announced the release of Syllable Server 0.4, a small (but extensible) server distribution built on top of a recent Linux kernel and the Linux From Scratch (LFS) base system: "We are pleased to announce that we have released the new Syllable Server 0.4. This release focuses on maturing existing functionality, improving security, ongoing system restructuring, and making the system a suitable base for third-party package managers. About half the packages in the system were upgraded, including key components such as the Linux kernel, udev, the LFS init scripts, DirectFB, SDL, Bash, Packager, OpenSSH, REBOL/Core, the Cheyenne web server and cdrtools. Other important packages such as Ruby, Midnight Commander, Links and Transmission were also updated. XZ-Utils was added, providing the same LZMA compression as in 7-Zip." See the release announcement and changelog for further details.
linuX-gamers Live 0.9.6
Marko Kaiser has announced the release of linuX-gamers Live 0.9.6, an Arch-based live CD/DVD/USB image containing a large collection of popular Linux games: "We recently released a new version of our games distribution. New features: host system in local network. New games: Osmos demo, LinCityNG, OpenTTD. All other games are based on their most recent versions. You will notice that there are two editions now. Lite ISO: a small CD image (700 MB) containing a limited games selection suitable for children and older computers. Burn it to a blank CD-R/CD-RW using regular Linux or Linux tools like Nero, K3B, Infrarecorder, etc. Alternatively, you can write it to a USB device (at least 1 GB capacity). Big ISO: a big DVD image (4.7 GB) containing the full games selection for adults and more recent computers. Burn it to a blank DVD-R/DVD-RW using any burning tool of your choosing or write it to a USB device (at least 5 GB capacity)." Here is the brief release announcement.
linuX-gamers 0.9.6 - an Arch-based live DVD designed for gamers
(full image size: 200kB, screen resolution 1280x1024 pixels)
KANOTIX 2010
Jörg Schirottke has announced the release of KANOTIX 2010, a desktop distribution and live DVD with KDE 3/4 based on Debian GNU/Linux 5.0: "Just in time for LinuxTag 2010, updated KANOTIX 'Excalibur' versions are available. All based on Debian 5.0 'Lenny' with all the latest security updates and many extras. In short they contain: Linux kernel 2.6.32-ck2 (BFS powered); KDE 3.5.10; OpenOffice.org 3.2.1; GRUB 2 (1.97 beta 4); wicd 1.6.2.2; Pidgin 2.7.1; NTFS-3G 2010.5.22; WINE 1.2-rc2; Iceweasel 3.0.6 (XULRunner 1.9.0.19); Icedove 2.0.0.24; Kano scripts for installing NVIDIA or ATI graphics drivers, as well as FlashPlayer plugin." Read the release announcement for further information.
Absolute Linux 13.1.1
Paul Sherman has announced the release of Absolute Linux 13.1.1, a lightweight Slackware-based distribution with IceWM: "Absolute 13.1.1 released. New kernel and a boatload of updates from Slackware. Almost replaced Firefox with Google Chrome (which I really like) but due to an endless 'upload' bug that keeps crashing Chrome when you try to upload a file, it'll be in the CD2 directory for testing/playing. The 13.1.0 release was a naming snafu as it pre-dated Slackware's update. This release (13.1.1) incorporates Slackware 13.1 as well as several re-compiled packages on Absolute and a couple of scripting changes. Some add-ons in the CD2 directory of the FTP sites (Google Chrome and Picasa for example), gmail-notify added and incorporated into email notification setup as an option. Add/Remove programs (PERL script) updated." There is a brief release announcement on the project's home page and slightly more detailed one in the forum.
Zorin OS 3
Artyom Zorin has announced the release of Zorin OS 3, an Ubuntu-based distribution designed for Linux beginners: "Welcome to Zorin OS 3. The Zorin OS team is very proud to release this software to you. We hope you will enjoy your experience with this new Zorin OS release. We have also provided you with some material about what's new and different in Zorin OS 3, what you'll need to watch out for, system requirements and other release information. What's new? Zorin OS 3 now comes pre-installed with a brand new exclusive program called the Zorin OS Look Changer. This allows you to use your desktop in not only a Windows 7 style, but also Windows XP and GNOME interface. During the installation of Zorin OS 3, you will see a slideshow that shows you around Zorin OS. This slideshow will get you familiar with Zorin OS and its advantages, programs and features." Read the detailed release notes for additional information.
Zorin OS 3 - an Ubuntu-based distribution for Linux beginners
(full image size: 1,110kB, screen resolution 1280x1024 pixels)
Zenwalk Linux 6.4 "GNOME"
Frédéric Boulet has announced the release of the "GNOME" edition of Zenwalk Linux 6.4, a Slackware-based distribution featuring the GNOME desktop: "We are proud to announce the release of Zenwalk Linux 6.4 GNOME edition. As always, Zenwalk features the latest Linux technology, including the Linux kernel 2.6.33.4 and the GNOME 2.28.2 desktop environment. The GNOME 2.28.2 desktop includes a number of new features: Totem has an asynchronous parsing API now, GNOME Power Manager now has support for laptops with multiple batteries and has added disk spin-down support for DeviceKit disks. The GNOME panel comes back to the origin layout. You will find the same software base as in the standard edition: Pidgin 2.7.0, Totem 2.28.6, Brasero 2.28.3, Goobox 2.1.1, Geany 0.8.1, gedit 2.28.4, OpenOffice.org 3.2.0, GStreamer 0.10.29; X.Org 7.5. Others GNOME applications are available in the extra repository." Read the rest of the release announcement for more information.
sidux 2010-01
sidux 2010-01, a new version of the desktop distribution with KDE or Xfce based on Debian's unstable branch, has been released: "Now that KDE 4.4.4 and kernel 2.6.34 have entered the archive, we have the pleasure to announce the immediate availability of the final sidux 2010-01 'Hypnos' release. While waiting for the availability of KDE 4.4.x, 'Hypnos' development concentrated on overhauling the early boot sequence for live and installed systems with regards to concurrent dependency-based booting and the integration of kernel 2.6.34. sidux now uses CONCURRENCY=makefile and continues to embrace GRUB 2 on the installed system, with isolinux and an improved gfxboot theme on the live system. KDE-based ISO images can now make use of Partition Manager instead of GParted. As usual, a large number of individual functionality enhancements and bug fixes have been applied to the full package line-up." Read the detailed release notes for further information.
sidux 2010-01 - featuring the latest additions from Debian 'unstable'
(full image size: 455kB, screen resolution 1280x1024 pixels)
* * * * *
Development, unannounced and minor bug-fix releases
|
| Upcoming Releases and Announcements |
Fedora 14 release schedule
The Fedora project has published a release schedule for Fedora 14. Like the development of its current stable release, the upcoming version will have two public test releases, scheduled for 17 August 2010 (alpha) and 21 September 2010 (beta). The final release is set to arrive on 26 October 2010. A detailed schedule is available here.
* * * * *
Summary of expected upcoming releases
|
| DistroWatch.com News |
Package database update
The month of June is usually the time when we update the list of packages tracked by DistroWatch on the individual distribution pages and this year will be no different. Several package changes are currently under consideration, notably the replacement of VNC with TigerVNC (an actively developed and non-commercial project that is now part of Fedora and other distributions), and the switch from F-Spot to Shotwell (the Mono-based F-Spot has fallen out of favour in both Fedora and Ubuntu). Other requested packages that are likely to enter the database are lzip and Wordpress. On the list of to-be-removed packages there are currently DeviceKit and Zope.
As always, you are welcome to submit suggestions for packages that you want us to track - either by commenting below or by emailing to distro at distrowatch.com. Those packages that get most requests will be added to the package database by the end of this month.
* * * * *
New distributions added to database
- Alpine Linux. Alpine Linux is a community developed operating system designed for x86 routers, firewalls, VPNs, VoIP boxes and servers. It was designed with security in mind; it has proactive security features like PaX and SSP that prevent security holes in the software to be exploited. The C library used is uClibc and the base tools are all in BusyBox. Those are normally found in embedded systems and are smaller than the tools found in GNU/Linux systems.
* * * * *
New distributions added to waiting list
- Business OS. Business OS is a German Ubuntu-based distribution designed for self-employed people and small businesses. The project's web site is in German.
- CIITIX-WiFi. CIITIX-WiFi is a Debian-based distribution that makes it easy to set up a secure WiFi hotspot.
- vatlator. vatlator is a simple Ubuntu-based operating system with Tor (a privacy protection tool) set up for anonymous Internet surfing.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 21 June 2010.
Patrick Van Oosterwijck, Jesse Smith and Ladislav Bodnar
|
|
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 0, value: US$0.00) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Re: Binary firmware and your freedom (by Jonathan Wolff on 2010-06-14 10:04:48 GMT from United Kingdom)
An excellent feature story, just a pity that the sorts of people for whom software freedom's a major concern are often the ones most inclined to outsource their intellectual conscience to Stallman and the FSF.
2 • RE: 1 (by Landor on 2010-06-14 10:30:26 GMT from Canada)
I found it a pity that you had to degrade a good article by bringing up your obvious bias about a man and a foundation.
Just to be clear on things, "if" the FSF had their way there would be no need for an article such as this since all firmware/hardware would be open. I like to outsource my conscience to the fact that it is a good thing "if" that ever came to be, regardless of any foundation or a figurehead behind it. We as a community can see what kind of innovation comes from things being open.
Keep your stick on the ice...
Landor
3 • Good weekly (by Barnabyh on 2010-06-14 10:57:11 GMT from United Kingdom)
Interesting article and opinion piece and a welcome change from the reviews, thanks. Myself I would ideally prefer everything free in the sense of the FSF, but it's an imperfect world, and with the myriads of aspects that make up a computer system from hardware to software and drivers etc we'll probably never completely get there, unless we have a true cultural shift and change in opinions worldwide induced by more dramatic events that will require a response and to seriously re-evaluate our values as a society, a sort of Gaian revolution.
Until then I use a USB adapter that I got for only £6,- regardless of non-free firmware. I'ld prefer not to but it does the job.
4 • hardware issues (by Tom on 2010-06-14 11:02:06 GMT from United Kingdom)
Fantastic to hear some detail about firmware and hardware issues there. Thanks DW and Patrick Van Oosterwijck.
I think a simple 3 colour traffic-light on hardware showing it's potential for linux usage would be more intuitive and easier for most people but a score out of 5 is extremely simple too. 3 stars is better than 5 stars unless they promise not to sing.
It does seem quite clear the FSF have taken the wrong approach but has anyone discussed this with them? Could we hear the opposition view-point briefly next week (or in a couple of weeks)?
Hardware issues do seem to be one of the main critical blockers to widespread linux adoption along with the related issue of graphics and gaming both of which seem to be improving. Thanks for improving our understaning of the issues here.
Happy Monday all! Regards from Tom :)
5 • No.3 (by Barnabyh on 2010-06-14 11:11:44 GMT from United Kingdom)
With everything free I actually mean everything open sourced.
6 • colours (by Tom on 2010-06-14 11:13:08 GMT from United Kingdom)
Last week there was some mention about aversion to shades of MicroSquish blue being so prevelant.
Fantastic to see Sidux taking a stand and using rich colours that are not the default blues that people seem to pick almost everywhere for almost everything these days.
Regards from Tom :)
7 • Binary firmware and your freedom (by Alan on 2010-06-14 11:16:02 GMT from United Kingdom)
Fantastic article, although he could of toned down his emphasis on personal feelings as the lead up to the suggestions and the suggestions themselves were good enough without this as they already had the backing of a good technicial understanding of the issue within the article.
Also think the personal touch aspect normally leads to flames, so might hinder the article with other, more sensitve readers...
Also thought the rest of DW weekly seemed to have a bit of spark in it compared to previous weeks with the writing style, keep up the good work.
8 • Firmware/Open source (by jadecat09 on 2010-06-14 11:16:52 GMT from United Kingdom)
Open source is a whole new can of worms for Richard Stallman and FSF
All the best from Craig
9 • Package database (by Pumpino on 2010-06-14 11:16:59 GMT from Australia)
How about tracking Deluge? It's the best GTK-based BT client.
10 • 2 & 3 (by Unome on 2010-06-14 11:17:23 GMT from Denmark)
I agree with both of you. Very nice article. Attacking Stallman is really unnecessary. I didn't understand anything much about the Solaris ZFS article because I don't use Solaris. Also, nice "how to" on encryption. I won't ever use it but whatever. Thumbs up this week on DW :)
11 • package list revamp? (by Tom on 2010-06-14 11:41:32 GMT from United Kingdom)
Hi :)
I like the package list idea but find it difficult to navigate at times when i most need it (rather than just curiosity). Would it be easy to have a small table listing such defaults as
text editor gedit
web-browser chrome
office package gnome
torrent client deluge
Something like that covering about 10 main areas would be incredibly helpful to me & perhaps to noobs too.
Regards from Tom :)
12 • Mandriva Spring (by yves on 2010-06-14 12:14:39 GMT from Belgium)
Hello, is anyone know when Mandriva 2010.1 will be released? Or does anyone know what is happening at Mandriva?
13 • The pricing aspect (by Barnabyh on 2010-06-14 12:27:30 GMT from United Kingdom)
I said above in comment no. 3 that the adapter was cheap. I would not have purchased an encumbered piece of hardware like this for 19.99 or more, the price at which wireless USB adapters usually retail here, when I cannot even be sure it will work with my system (sure you can bring it back, but the hassle, and the threshold that I am already philosophically inclined against it).
Which leads us to another aspect in technology, the price. If the average consumer was more aware of the potential benefits of openness and the pitfalls of closed source this would influence their purchasing behaviour, and in time there will be more money to be made with 'Guaranteed Open-Source' products than with the traditional/ current model. It could become a stamp of quality, with closed hardware having to retail for less.
In that sense an educational campaign like that of the FSF is still very much valid, should actually be broader. Not sure people are interested enough to listen, but it is slowly, very slowly, sinking in, with a few more people at least vaguely aware of the issues, at least that's my impression.
14 • Binary firmware (by Sergio on 2010-06-14 12:33:57 GMT from Greece)
I don't think any article about the binary subject is good, when you put your personal feelings on the line. Whether it's practical or not we always have to support FSF, cause the ultimate goal is all software and drivers to be not just open, but totally free .
15 • Binary firmware and your freedom (by Richard Dymond on 2010-06-14 12:39:27 GMT from Canada)
I don't agree that a hardware device in which the firmware is "baked in" (cannot be accessed or changed) is more objectionable than a device for which firmware is supplied as a file and loaded by the kernel. If the firmware is baked in, nobody can change it, so access to the source code of the firmware is of no practical benefit. However, if the firmware is delivered as a binary blob that is loaded by the kernel, that means the developer *could* supply the source code too, but instead chooses to withhold it. And if you use such firmware, you are tacitly consenting to this behaviour, which violates the core principles of free and open source software.
Ideally, for maximum freedom and hackability, all hardware would be programmable by kernel-loadable firmware for which the source code is made available. Until then, it's a mistake to state that hardware with baked in firmware is somehow "less free" (in the FSF sense) than hardware with loadable firmware blobs. It's less hackable, certainly, but not less free.
16 • Free Software (by Anonymous on 2010-06-14 12:45:35 GMT from France)
I see the point in the article but I'm not sure I fully agree.
First hypotheses is that the code is either wired in the hardware or distributed as a software binary firmware.
My second hypotheses is that hardware vendors are not concerned about freedom. They are concerned about their bottom line only.
Some vendors are distributing their firmware in soft form when they could distribute it wired into the hardware. Why do they do that? They don't do it to make it more convenient for you to disassemble. They must do it for another reason. Such reason may be technical or because it is more convenient for them.
If I'm not wrong about that, I believe the FSF would be right to use the GPL as a levy to force the hardware vendors to release the code.
If hardware vendors ignored the FSF they would miss a big chunk of the current market and an even bigger chunk of the future market with linux device pool ever growing.
If they chose to wire their software into the hardware instead, they would loose convenience and their cost would increase.
If they choose to comply and free up their source, everybody wins.
Am I wrong about all this?
17 • @12 Yes I know (Humor) (by Pepe le Pew on 2010-06-14 13:27:41 GMT from United States)
I saw it listed on Craigslist today. French distribution for sale.
18 • Kanotix's back (by Smaug on 2010-06-14 13:55:13 GMT from Brazil)
Good to know that Kanotix is back.
Hi, Kano, welcome.
Coincidentally, sidux (a Kanotix spin-off) launches a new version this very week, too.
19 • ZFS news (by gord-s on 2010-06-14 13:56:59 GMT from United Kingdom)
It's excellent to hear that ZFS "crossing the gap" to Linux natively. Heavy storage users will love it. Most linux users won't have heard of it, but for the last 4 years it's been one of the main//only? choices for storage of >10TB hanging from one box.
We haven't lost a single file in 4 years with over 400TB now of spindles :)
20 • An Inconvenient Truth (by merlin on 2010-06-14 14:05:45 GMT from Canada)
The best article I've read on Distrowatch for awhile. Very articulate and eye opening. Maybe this is GNU/Linux' "Inconvenient Truth". This article should be distributed to the FSF and many distro leaders, and maybe they should start a working committee on this subject. The world isn't black and white (or 0:0:0 and 255:255:255) after all...
Great topic!
21 • Binary blobs and stuff (by davemc on 2010-06-14 14:16:55 GMT from United States)
What an awesome article! Of course, this is one side of an argument and the jury is still out. Still, it smacks of the truth we all know and happily ignore so long as we can have our cake and eat it too with our distro's of choice. Here is that truth -
1. Linux is an OS that requires real and actual hardware to run.
2. No hardware in this world is fully free. I am speaking of Computers taken as a whole entity.
3. The FSF knows these facts and chooses to "poo poo" on the non-free bits, which makes us all feel bad for half a second when #1&2 above strikes us.
Which leads us to..
4. The only real and actual way to be free is to not use Computers at all!
Its kind of a "dog chases the cat which chases the dog" approach tightrope act the FSF embraces and I think its high time they seriously reevaluate the whole thing from scratch based upon modern standards and theories.
22 • Re: Binary firmware (by Duderino on 2010-06-14 14:20:54 GMT from Brazil)
@14
Disagree, we might support FSF, but that doesn't mean that we should blindly agree with all their ideas, discussions belong to the evolution of any project, institution, political movement etc. If we simply accept everything without even thinking about, it becomes a religion, and the main problem of religion is that at some point people abdicate from their inteligence and freedom to interpret the world with their own eyes.
23 • tigervnc (by Scott on 2010-06-14 14:23:24 GMT from United States)
Unfortunately, tigernvnc doesn't yet work as well as tight vnc in many cases. I'm not quite sure what the reasons for the replacement were, but at present, there is a long standing tigervnc bug, at least in Fedora, where, when connecting to a Windows machine, the mouse shows up as a 1 pixel gif, which only sometimes works. See
https://bugzilla.redhat.com/show_bug.cgi?id=509000
Therefore, hearing about how it's becoming the new standard sounds like more of a regression than anything else.
24 • @21 - binary blobs and stuff (by Anonymous on 2010-06-14 14:49:57 GMT from France)
I don't fully agree with all your points. I believe GNU/linux works so well exactly because the FSF choose to "poo poo" as you put it. Look at the BSDs or OpenSolaris and their driver status. The FSF's stance on non-free bits has led us to where we are. Many vendors have freed their drivers because they were forced to. Accepting non-free binary blobs is a short term convenience that may not work too well in the long term. Vendors will abuse your naivety.
I agree this was an excellent article though.
25 • The trouble with Firmware (by Ivan on 2010-06-14 14:55:28 GMT from United States)
The problem I see with firmware distributed within the linux kernel is that it technically meets the four freedoms:
The freedom to run the program, for any purpose (freedom 0)
Without working hardware you can't do much of anything, that should be common sense.
The freedom to study how the program works, and change it to make it do what you wish (freedom 1)
There is nothing stopping anyone from learning what the tables of numbers that make up the firmware being distributed along with the linux kernel mean or even how to write their own. While more complicated than C and C++, it is still just another machine language and is licensed under a gplv2 compatible license, otherwise it couldn't be distributed.
The freedom to redistribute copies so you can help your neighbor (freedom 2)
Again this is explicitly granted by the gplv2, there is nothing in the licenses of firmware included in the kernel that prohibits redistribution.
The freedom to distribute copies of your modified versions to others (freedom 3)
Again there is nothing stopping anyone from doing this other than their lack of knowledge of that language.
Now if the FSF has an issue with non-human readable code, they should explicitly state such. Otherwise I would much rather have my hardware function in the manner intended by the manufacturer.
26 • FSF comments and @15 (by Patrick on 2010-06-14 15:02:37 GMT from United States)
First, thanks for the comments everyone! I want to make sure everyone understands I am not attacking the FSF or "the man" (Richard Stallman). I fully realize how indebted we all are to him. I just felt the need to "rock the boat" on this issue I feel is not generally understood clearly. In the end, the goal should be to have as much open and free hardware and software as possible, and I feel that the current FSF position is not helping to attain this goal.
@15
"""If the firmware is baked in, nobody can change it, so access to the source code of the firmware is of no practical benefit. However, if the firmware is delivered as a binary blob that is loaded by the kernel, that means the developer *could* supply the source code too, but instead chooses to withhold it."""
As I explain in the article, baked in firmware can potentially be changed by someone with the right equipment, but you are right that this is an unlikely scenario. Still, I think having source code available would be beneficial to know and understand how the device works and how to write a good kernel driver for it. It would be a bit similar to open-source hardware like the BeagleBoard, etc: most people couldn't change it, but it is still of benefit to the community.
"""It's a mistake to state that hardware with baked in firmware is somehow "less free" (in the FSF sense) than hardware with loadable firmware blobs. It's less hackable, certainly, but not less free."""
Intriguing comment. Could you explain the difference between "free in the FSF sense" and "hackability"? Would you say a device with baked in firmware is "more free" (in the FSF sense) than one with loadable firmware blobs, and if so, why? Or do you consider them the same?
27 • Add chromium to package tracking plz. (by Geek on 2010-06-14 15:06:01 GMT from Israel)
this is THE browser for linux systems today...
28 • Encryption (by tom on 2010-06-14 15:13:31 GMT from United States)
Thank you for the overview of how to use LUKS.
You mention that one should not use names such as "secret" or "encrypted" or what not, and that is not necessarily bad advice.
I would just add that encrypted partitions stand out like a sore thumb (if someone looks for them).
That is not the same as reading the data or advertising their presence, but they do stand out.
29 • package list suggestion (by forlin on 2010-06-14 15:18:23 GMT from Portugal)
Although this is not exactly about updating the listed items, the suggestion is about the possibility to create sub divisions that would try to closely resemble the trend how software use to be presented in the various distro menus:
Part x - accessories, graphics, internet, office, programming/development, sound/video, system/administration ...
Part y - the "under the hood items (the main files inside Linux, windowing system and drivers), like: grub.. gtk+... kdebase... linux kernel... xfce... xorg-server, ...
30 • Feature Story (by Cliff on 2010-06-14 15:19:31 GMT from United States)
@Sergio: "Whether it's practical or not we always have to support FSF..."
That's a very dangerous way to think, my friend. Very dangerous, indeed. Blind allegiance to someone, or something, is utter foolishness.
31 • FSF and Encryption (by Jesse on 2010-06-14 15:40:58 GMT from Canada)
@Patrick,
Nice work on the article. It's an interesting topic and I think it's good you're "rocking the boat" and getting people thinking about the issue.
@Tom in 28,
>> "I would just add that encrypted partitions stand out like a sore thumb (if someone looks for them)."
That's why my last paragraph on encrypting partitions mentions "If you're worried someone might notice your encrypted partition and try to access it, you can try a different tactic,.." Security is often a matter of layers.
32 • Packages (by Jordan on 2010-06-14 16:04:46 GMT from Australia)
For the packages list I'd recommend tracking:
Midori (http://en.wikipedia.org/wiki/Midori_(web_browser))
Chromium
gnome-desktop
Cheers! :)
33 • Firmware (by Davey on 2010-06-14 16:05:36 GMT from United States)
Excellent article that should provoke some thinking on a topic that we tend to just let slide. Patrick makes a strong case, but I think it's essential to hear the other side, either from FSF or a knowledgeable person who sees things differently.
I'd also be interested whether anyone's made a hardware list that conforms to Patrick's standard.
34 • Binary firmware (by Sergio on 2010-06-14 16:08:11 GMT from Greece)
@Cliff: I didn't tell you not to use it, I'm saying we have to support FSF in order to improve free software always. And this not a "Blind allegiance to someone", FSF is a foundation and a big community it's not just Richard Stalman, FSF started from early 80s and GNU existed way before the linux kernel. GNU/Linux would never reached this status of freedom without the FSF.
35 • Logical fallacy detected. :) (by Felix Pleșoianu on 2010-06-14 16:30:09 GMT from Romania)
An interesting point of view, and a welcome change from the usual distro review. BUT. The author seems to ignore the simple fact that a device with the firmware baked in onboard ROM is effectively self-contained. There is no separate binary file that third parties might or might not have permission to redistribute; it's all right there on the iron.
Whoops, did I say 'permission to redistribute'? Do check the EULA for Broadcom Wi-Fi drivers. They don't even give third parties the right to redistribute the binary blob. Which is why e.g. Fedora offers tools for users to cut it out their own copy of the official driver... but that doesn't work with any copy of the driver that I could find. And their new open firmware isn't good for my model. So I'm stuck with a perfectly good Wi-Fi board that only works with the few distros willing to question the validity of an EULA. So much for a separate binary firmware being more free.
That said, I do agree that the FSF's position is naive. If it was for them, I couldn't use my external Wi-Fi adapter either. Sorry guys, I can't afford to run around cherrypicking components (or full laptops...) because of some ideal. I need to work with what I have.
36 • FSF vs. actual practise (by SilverBear on 2010-06-14 16:43:58 GMT from United States)
Hey, Patrick!
Great article!
I'm a real supporter of the FSF, but I realise that in practise, I go for "what works" over what I'd prefer the world to be like. Your article, IMO, captures this objective situation quite well.
BTW: points to Landor (#2). Yeah, I always do "keep my stick on the ice." "If the women don't find you handsome, they should at least find you handy." Well, I'm not a woman, but I'd say you're handy. Some of us south of the border are members of Possum Lodge, too!
The point is that there are plenty of very economically powerful forces that would like to impose a neo-feudal system on 21st Century technology. We NEED people WAAYYY over on the oppposite side of that to give us some hope of a balance in our everyday options.
37 • Re: Binary firmware and your freedom (by Doc Atomic on 2010-06-14 17:04:00 GMT from Canada)
Comment deleted (off-topic). For corrections please email me directly.
38 • @35 (by Patrick on 2010-06-14 17:06:22 GMT from United States)
I think you need to read the article again. I am only calling separately loaded binary firmware for which the manufacturer gave permission to have the firmware distributed with the kernel "more free" (to those with the necessary tools and skills), or at the same level of freedom (to everyone else). They should be treated the same as devices that have their firmware built-in, but they are blacklisted by the FSF and their convenient firmware is removed by distributions adhering to the FSF policy.
Devices that need firmware but where the manufacturer makes it hard to get the firmware by their EULA and you need to use a cutter tool or whatever to get it, are ranked lower on my scale of freedom-friendliness. I don't call those more free.
39 • about Mandriva (by FBZ on 2010-06-14 17:19:07 GMT from United States)
http://olivier-mejean.fr/WordPress/?p=87
40 • @37 (by Patrick on 2010-06-14 17:22:38 GMT from United States)
Ladislav, could you fix the two places where I committed the unforgivable sin of typing an extra 'o' and in the process turned myself into the scum of the earth? ;)
@37
1. English is not my native tongue. Thanks for helping me improve my skill in such a kind way.
2. My spell checker shows 'civilisation' should be spelled 'civilization'. How dare you.
3. You need to learn a thing or two about making an ass of yourself in public. :)
41 • Zenwalk and Salix ... more comparisons please (by Anony Moss on 2010-06-14 17:32:39 GMT from India)
In the last DWW comments section there were some very useful reviews & comparisons of Slackware derivates for older, low-spec machines.
Any more experiences to share about the latest releases of SalixOS and Zenwalk? Especially, about UI latencies, ability to handle some flash (youtube, etc). I'm trying to revive an older Pentium III PC with 4400 rpm Quantum HDD.
Also, the Zenwalk 6.4 has the BFS scheduler. Any comments on the responsiveness given the new scheduler? By the way, Zenwalk's torrent link does not work as listed on the bottom of this page-
http://www.zenwalk.org/modules/tinycontent/index.php?id=1
The said server only lists & tracks 6.0 and 6.2 releases.
thanks!
42 • #37 (by RC on 2010-06-14 17:38:52 GMT from United States)
Wow!! And he took the time to copy and paste the quote before completely proving it. Great job!
43 • in programming, spelling is not an option; it is an essential requirement. (by Doc on 2010-06-14 17:45:14 GMT from Canada)
Comment deleted (off-topic).
44 • On this Weekly (by meanpt on 2010-06-14 17:58:46 GMT from Portugal)
Congratulations to the team. I miss the reviews but there is't any specialty or breakthrouhg to review either.
Regarding the drivers, I recognize linuxers have a huge problem. But, in my opinion, the FSF should keep their position, to minimally counter the biased weight of manufacturer's. This isn't a matter of good sense, but of a starting political and pre-bargaining position. That's what will allow for real agreements at the present and in the future. But there are more ways to skin a cat. Suppose some entity launches an international procurement of multimillion dollars of equipment compatible with a set of Linux flavours, I bet the tenders will submit hardware and compatible drivers without any intervention from the FSF. Do linuxers have such an entity? Maby not or not so many as needed. But then that's what our taxes are for too. That's why we cast our vote too in tow government and other public services. Meaning all the alternatives should be used to enforce freedom, meaning free access from linux to hardware. FSF is only one piece of a wider picture creating a needed manouvering space with its political position. And yet new ideas should be explored. Hacking is one of them but must be protected against any law infrigement. MS Windows isn't a military secret and if the manufacturer does not provide for alternative OS's compatibility, there should be no legal infringement by hacking the bynary code. This is also political standing to protect a minimally fair market competion as a regulated issue. On the kernel development side it would be nice to stop chasing solutions for every piece of peripheral hardware a linuxer wants. It may be time to further develop and exhaust the virtualization alternatives. Because we are not living in a static world, it may be expected that linuxers critical mass will also increase, taht linux based OS's may have a better market share in the mobile world and that may positively affect the desktop market.
In short, FSF only provides the equivalent of a political and altruist constituition, and will be up to linuxers and their closer organizations to get as close as possible to those values with whatever agreements or bargainings they can achieve in the real world, either in the polical or in the corporate environment. And this is valid if Linux or any other OS is is to mean freedom.
45 • firmware and distribution (by Reuben on 2010-06-14 18:00:44 GMT from United States)
I don't think many distros actually listen to the FSF when it comes to distributing binary firmware, so I don't think it makes much of a difference.
However, it makes me scratch my head when hardware manufacturers like broadcom and haupauge restrict the distribution of their firmware. What is the big idea?
46 • FSF-free v. hackable (@26) (by Richard Dymond on 2010-06-14 18:17:17 GMT from Canada)
"""Intriguing comment. Could you explain the difference between "free in the FSF sense" and "hackability"? Would you say a device with baked in firmware is "more free" (in the FSF sense) than one with loadable firmware blobs, and if so, why? Or do you consider them the same?"""
By "free in the FSF sense", I mean that any distributed software (firmware, in this case) comes with the four freedoms stated in the FSF free software definition - which includes access to the software and the freedom to modify it and use and redistribute any modifications.
By "hackable" I mean, well, hackable. :)
So a piece of hardware with baked in firmware is neutral as far as FSF-freedom goes. The firmware is not distributed as software, and the firmware cannot be modified by end users in any case. Software freedom doesn't come into it, because there is no (modifiable) software being distributed. Thus, the FSF does not object. (Though as you say, being able to inspect the firmware source code could be useful for academic purposes.) Such a device is also not hackable.
On the other hand, a piece of hardware for which the firmware is distributed in binary-only form is decidedly non-free, because the distributor is withholding the source code. In this case, software freedom we might otherwise have is being artificially restricted - which is perhaps why the FSF objects. Such a device is potentially more hackable than one with baked in firmware, but is less hackable than it could be because the source code is not available.
47 • package tracker (by z3r0 on 2010-06-14 18:23:50 GMT from United States)
I know it is a small and relatively unknown package but I would love to see Guayadeque added to the tracker. It is a wonderful lightweight music player.
48 • firmware FSF etc. (by Jan Bakke on 2010-06-14 18:51:59 GMT from Netherlands)
Does anyone really believe that the vast majority of Linix or even Windows users give a damn about these esoteric theories? In my opinion, people just want to push a button and have their computer up and running.
49 • @46 (by Patrick on 2010-06-14 18:58:04 GMT from United States)
I guess that depends on how you define "distributed". If I buy a piece of hardware with binary firmware built-in, the distributor is also withholding the source code. That is my issue with the FSF policy: it makes a judgment based on a technicality (how I get the firmware and where it lives in my system), instead of on the more important issue (is the firmware source available or not).
I don't think there is any more freedom if I get the binary firmware in a chip from the hardware manufacturer or in a file from the Linux kernel. So saying that it is fine because it is locked up in hardware and not distributed as "software" is just sweeping the whole software freedom issue under the rug by claiming it is out of their jurisdiction. :)
50 • Freedom v. access to source code (@49) (by Richard Dymond on 2010-06-14 19:39:45 GMT from Canada)
"""That is my issue with the FSF policy: it makes a judgment based on a technicality (how I get the firmware and where it lives in my system), instead of on the more important issue (is the firmware source available or not)."""
I suppose I'm more concerned with the potential practical benefits of software freedom than with whether the source code is available.
If I have the source code to some baked in firmware, that's all well and good, but of no practical use - I can't install/run a modified version of it. So lack of access to the source code is pretty much irrelevant to me, and I don't consider my software freedoms to be deliberately restricted in this case. The manufacturer can't fix bugs in it or apply updates, and neither can I. The manufacturer is not trying to ensure any kind of advantage or protection by withholding something that would be genuinely useful.
Contrast the situation where the firmware is available as a binary file only. Presumably there is some source code for it, but the manufacturer withholds it. Here my software freedom is directly affected; the source code could be genuinely useful, but I am not allowed to have it. In my opinion, withholding the source code to user-modifiable firmware is worse (on the freeness scale) than withholding the source code to unmodifiable firmware, because access to the source code to user-modifiable firmware would have more practical benefits.
Anyway, I think I'm starting to repeat myself now...
51 • @50 (by Patrick on 2010-06-14 20:10:18 GMT from United States)
If I understand correctly, your position is: "If the kernel loads the binary firmware, I have the ability to change this file. I resent not having the source code because then it would be much easier to actually use this ability in a useful way."
My position is: "If the kernel loads the binary firmware, I have the ability to change this file. Having the right software tools, I might actually be able to change this file, even though it won't be easy for lack of original source."
I guess those positions aren't all that different. :)
52 • Where does my computer begin and the FSF end? (by merlin on 2010-06-14 20:27:42 GMT from Canada)
This firmware issue seems to open up all kinds of questions. What about microcode running on the CPU itself? Is that open? If I really want a FSF operating system then wouldn't I want open source software for all hardware devices on the motherboard including the CPU, as well as add-on devices such as PCI cards, and even pluggable devices such as USB thumb drives which I'm pretty sure have built-in microcode for wear-levelling, etc. Or does the FSF form a philosophical bubble around any discrete hardware device larger than a chip, and expect any that software that runs on the device to be open?
OK, I'll put my foot back in my mouth. :-)
53 • @48 (by Anonymous on 2010-06-14 21:20:21 GMT from France)
People may not be aware or care about the political and technical issues involved, it does not mean it doesn't affect them. Look at our modern democracies for instance. People take for granted that they can vote instead of having a king dictating its rule for his own benefit. They don't even care to go cast their vote on sunny Sundays. All they care about it that they can watch football or soccer on TV. Nonetheless, they could not watch TV if people didn't fight for them for centuries. And if they stay asleep for too long they may well loose everything. The FSF is fighting for freedom and even if people do not care, they are still fighting for those same people.
54 • On the FSF etc (by Adam Williamson on 2010-06-14 21:28:10 GMT from Canada)
People seem to be mixing up various arguments here, with regard to the FSF.
The old canard 'the FSF should be less ideological!' is being waved about, with the belief that this article supports it. It really doesn't. Patrick is not subscribing to the poorly thought-out point of view that the FSF should just relax and say 'yeah, sure, using some closed software if you need it for your job / your hardware / whatever is fine'. He's talking about one specific point of the FSF's position and suggesting that the FSF has argued itself into a corner and wound up in the odd position of being okay with firmware you can never see, but not okay with firmware you can see but can't modify. He's not voicing any kind of disagreement with the FSF's actual principles, just about how they're being applied.
On the canard itself - it's a silly way of thinking. It's as if you'd told Lenin 'well, look, the real world is just *full* of capitalism, so maybe you should just relax and allow a bit of private ownership of the means of production, it's the only practical way forward!' It completely misses the point. The FSF exists solely for the purpose of promoting free software. It was formed out of the belief that all software ought to be free, and it exists to further that aim. Telling the FSF it should just relax a bit and not be so darn strict about non-free software is really just betraying a lack of understanding about what the FSF is *for*.
I see a lot of people saying 'well, look, I want to run closed software for Purpose A, so the FSF is wrong!', which is an argument missing a lot of steps. You don't *need* the FSF's approval to run whatever software you like on your computer. You can run the closed software if you like. If you go out and ask the FSF whether they think you're doing the right thing, then of course they'll say no. But why are you asking them? It's like deciding you want to eat a beefburger and then declaring that the Vegetarian Society ought to relax a little and give you their approval. Of course they're not going to. They're the fricking *Vegetarian Society*. But you can still eat your burger, and no-one will stop you. Why would you want the Vegetarian Society to approve of your action?
So it is with software. If you want to use non-free software, then just go ahead and do it. But don't proclaim that the FSF - that's the Free Software Foundation, in case you'd forgotten - should officially approve of you doing it. That's just silly.
55 • @53 (by Jan Bakke on 2010-06-14 21:39:50 GMT from Netherlands)
Your equating dictators and political freedom or lack thereof, to the FSF and binary firmware is ludicrous.
56 • yet again. (by Doc Atomic on 2010-06-14 21:50:43 GMT from Canada)
@53: "And if they stay asleep for too long they may well loose everything."
So; lack of education is now pandemic? Why? What'll happen when it all falls apart completely? Why doesn't everyone DO something, before it *does* fall apart completely?
57 • RE: 36 - 54 (by Landor on 2010-06-14 22:00:14 GMT from Canada)
#36
Actually, mine's directly from hockey. :) I grew up with a hockey family, though I didn't play myself that much, bad ankles and such. My brother did and a cousin played for Washington. I am a firm supporter of possum lodge though. :)
#54
Our views are usually (from what I see) at the opposite ends of the spectrum but you actually beat me to pretty well what I was going to post. Well said.
----
A huge point that Patrick has missed, especially in his comments, and no offense intended Patrick, is when he pointed out that he "might" be able to change this file. This opens up a huge hornet's nest, possibly. With current laws there very well could be legal issues surrounding the reverse-engineering of firmware, or using the firmware and its calls to create a new firmware. Which is almost exactly the same thing, but not. This is a strong point of the FSF's issues with closed source firmware and the kernel. While some companies allow (and have created options for) open source "hooks" into their firmware, some of the said firmware is still closed source and proprietary and/or patent encumbered. Which by no means makes the firmware itself GPL'd, just the hooks that allow it to function via the kernel. That's my understanding of the issue at hand.
I'll also like to point out one more thing in addition to Adam's excellent comments. While the users here are waving the "I can't stand the FSF/Richard Stallman's views flag", they easily forget that it was both that made it possible for the Linux kernel to be GPL'd, since they created the GPL and the infamous copyleft system. Rallying against the FSF and Stallman as fanatics and oppressive and blah-blah-blah makes your usage of anything GPL'd hypocritical at best.
Keep your stick on the ice...
Landor
58 • @54, 57 (by Patrick on 2010-06-14 22:34:23 GMT from United States)
@54
Thanks Adam. You seem to have managed to clarify my position better in one paragraph than I did in a whole article. ;)
@57
I appreciate the potential legal issues involved with reverse engineering. Maybe I should have stressed more the case where the kernel loads the firmware and I can just replace the closed source binary file with a new firmware file built from scratch, with open sources available. This is a possibility with some chips for which datasheets are publicly available, and would bypass any reverse engineering concerns. Having the firmware burned into a chip would make this scenario significantly harder.
I kind of regret having brought up this side point that firmware loaded from the kernel is slightly more free/hackable than firmware burned in a chip, because it is only a minor advantage to very few people, and it seems to be distracting from my main argument. The main point is that for all intends and purposes, these two cases provide the same level of freedom (or lack thereof) to the user or software developer and it makes no sense for the FSF to vilify the one case where the firmware is visible and encourage the other case where the firmware is hidden, as if that's going to benefit software freedom in any way.
59 • RE: 58 (by Landor on 2010-06-14 23:11:29 GMT from Canada)
I may take this view differently than others, but I think RMS (at least) makes his view on firmware quite clear by using the Lemote Yeelong. I think that's what your part of the argument is about, no? Am I missing something?
The use of the Yeelong sends quite a clear message to me. Open/Free, even at the bios level.
I'd love to buy one that's actually a notebook size.
Keep your stick on the ice...
Landor
60 • @58 (by Barnabyh on 2010-06-14 23:44:43 GMT from United Kingdom)
No regrets Patrick, it's a fascinating discussion. I've deluded myself into thinking I actually understand what you're talking about, but I think I do. ;)
61 • Something everyone's missing. (by jake on 2010-06-15 02:08:51 GMT from United States)
There is no such thing as "software" or "firmware". Both are merely the current state of the hardware. In essence, they are the the way the manufacturer/coder(s) set the switches for the hardware to perform a particular task.
In essence, hardware manufacturers who keep their code "close" (in the legal meaning), are telling you, the consumer, that you're not allowed to set the switches yourself. Same for so-called "software houses".
Why? A few possibilities ... My guess is sloppy code, with holes in it large enough to drive my Peterbilt thru', hitch up to to the keys to the kingdom & drive back out without anyone knowing I was ever there. Granted, it could be so-called "intellectual property" issues ... but seriously, does *any* largish hardware manufacturer seriously believe that the competition doesn't reverse engineer their code? If so, they are deluding themselves ... or their lawyers are.
Code is a widely distributed written language, just like books & magazines. Everyone should be allowed to read it, as they see fit.
Likewise, everybody should be allowed to set the switches of their own, personal hardware to suit themselves. And to take suggestions from third parties as to how, exactly, to set those switches.
Copyright issues are a whole nuther kettle of fish ... and in the hardware world borders on religious fanaticism, IMO. It certainly doesn't exist for any sane reason (are you listening, Broadcom?).
62 • @59 (by Patrick on 2010-06-15 02:50:39 GMT from United States)
Did a quick google search on the hardware in the Leemote Yeelong. It sure looks like a good effort to have a "totally free" system, but only superficially, to satisfy the naive FSF rules. I'm pretty sure it does have binary firmware locked in the hardware just like any other computer. For instance, it uses a RTL8187B wifi card, which "does not require firmware from userspace", but likely has it built-in (I just can't imagine a device as complex as a wifi-card not running software of any kind--I don't have proof of that though). What I am sure about is that at least the hard drive is running proprietary binary firmware, covered by a plethora of patents.
I'm happy that RMS can have hardware that makes him feel good because his Linux kernel doesn't need to hand his hardware any binary blobs. The binary blobs are still stored and running inside his system though, with all their unknown bugs, patented algorithms and associated royalties. Would it really have made any difference to his freedom if these were loaded from his hard drive instead of baked into his hardware? At least then he would have been aware of their existence.
63 • #41 (by Ti on 2010-06-15 02:56:16 GMT from Sweden)
If you want the best experience please use Puppy. It will run on ANYTHING better than anything else. Not a hater, not a fanboi just telling it as my experience dictates.
This may help: http://www.heavensgate.com/
64 • RE: 61-62 (by Landor on 2010-06-15 03:14:28 GMT from Canada)
#61
Yes, you're completely correct, but only to a point. It does exist because we created it. Hear me out here. It may be philosophical but it's no different than the naming convention for fruit on a tree, or even naming it fruit for that matter. We can't go around calling every piece of fruit the current state of the tree in its production of seed(s). We give it a name to specifically define what we're talking about. :)
#62
My understanding is that the RTL8187B is completely open. I may be wrong in that understanding though. I believe they fully opened it a number of years ago. You also have to remember the RTL8187B is fairly old technology by today's standards and there would be no reason to not open it given the advances of technology. I may be wrong on this as I've stated. I'd have to go dig into the topic to find out more.
Also, the Lemote Yeelong that he's running doesn't have a hard drive, it's an SSD drive. I don't know if they created their own SSD drive, I'm to understand their CPU design is built in-house as well as their motherboard, with careful consideration to Open/Free hardware. It's quite possible they did in fact design their own SSD drive as well. Again though, as both of us are unsure without further study, it's pure speculation at this point.
But I'm sure we can keep points out of the discussion that border on mild contempt for the ideals/view of the man and the FSF as in, "I'm happy RMS can have hardware that makes him feel good because his Linux kernel doesn't need to hand his hardware any binary blobs", that doesn't to anything to cement a point of view either way. :)
Keep your stick on the ice...
Landor
65 • @61 (by Patrick on 2010-06-15 03:14:41 GMT from United States)
There is no such thing as hardware. It is merely a particular arrangement of atoms. There is also no such things as atoms, it is merely the name we give to a certain arrangement of subatomic particles in a particular quantum state. Etc, etc.
I don't think anyone has a problem with giving a particular arrangement of atoms the name "hardware" and I don't think it is too far-fetched to give a particular state of hardware over time the name "software". They're all just labels so we know what we're talking about.
Anyway, in my article I wrote: "After all, computing is just the execution of algorithms--whether this is done in hardware or software is merely an implementation detail." Which kind of goes along with your line of thinking. At some level, limiting the effort to achieve computing freedom to just software and totally ignoring hardware [and even software because it happens to be stored inside hardware] is totally arbitrary and does not make much sense.
66 • @64 (by Patrick on 2010-06-15 04:07:50 GMT from United States)
You are correct that without more data it is all speculation that doesn't get us very far. I was surprised that it seemed kind of hard to find detailed information on this open system. I has expected to find a wiki page or something describing the system but I couldn't find it in my quick search. If you pursue this further, I'd be interested in any pages with good info you may find.
The page I found specified a 160GB hard drive (no manufacturer specified). But I can imagine they have different variants, including ones with SSD. If it is anything like other netbook low-end SSD's it probably has some simple Flash Translation Layer firmware built-in, but this service can also be provided by the kernel on a bare metal NAND.
At work I have done some work on a system I believe to be completely free as far as software goes. The system uses an Atmel ARM9 chip with 32MB of SDRAM and 8MB of serial NOR flash. The boot loader is the open source U-Boot, and with just a wired Ethernet connection, it would serve as an embedded controller with web server capability.
I just recently acquired a BeagleBoard (new xM version), which is interesting because it is open source hardware. Very powerful for an embedded system (1GHz, 512MB RAM, 3D accelerator, DSP), but not fully open source in software as the 3D accelerator driver is closed. As a rule it seems hard to get both software freedom and high performance in the same package. Usually you pay for freedom with lower performance.
67 • Language. (by jake on 2010-06-15 04:56:39 GMT from United States)
I don't have any issues with describing certain aspects of hardware using specific terminology (including "software" and "firmware" and "file system format", or even "adaptive differential pulse code modulation with dynamic bandwidth allocation"). It helps when having a conversation.
However, remember that hardware can only see three things:
1) executable (machine code, for want of a better name in this context)
2) data (bits that machine code can manipulate for various reasons)
3) I/O (getting machine code & data into & out of the hardware)
That is it. Really. And it's all ones & zeros, no more and no less. Implemented with transistors (or rusty magnetic domains, or holes in paper, or delay lines, or phosphor on a screen, or pits on optical media, or ferrite beads (but I repeat myself), or whatever). It's all hardware. A bunch of on/off switches.
My point in 61 is more that it's contra-indicated to tell me that I can't decide to set those switches for myself, for whatever reason that I want to set those switches. It's patently obvious that the entire concept is invalid. I own the hardware outright ... I can set the switches to speed it up, or brick it (with or without the help of my .44 Ruger Carbine), as I see fit.
Laws saying otherwise are a remnant of the Industrial Revolution, and not only outdated, but ridiculous when you take modern reality into account..
Big Business needs to realize that they have NEVER controlled the distribution channels for their "Digital Intellectual Property" ... Copyright & Trademark laws (as currently written) are meaningless in the modern, digital era. Note that I'm not saying this is a good thing, nor am I saying it's a bad thing ... Just stating what is (to me) the bleedin' obvious.
The sooner Big Business gets off it's ass and enters the modern world with regard to this kind of thing, the better off we'll all be. Including Big Business.
68 • RE - Zenwalk and Salix ... more comparisons please (by Urubu on 2010-06-15 06:24:22 GMT from France)
Zenwalk and Salix shouldn't be compared : Salix is a nearly an unmodified Slackware, with some improvements including the Zenwalk System tools.
Zenwalk, Vector, Salix, and Slackware are targeting modern computers. It's not because they are faster than most Debian derivative that they are for old computers only :)
U
69 • 68 • RE - Zenwalk and Salix ...(by Urubu) (by meanpt on 2010-06-15 09:10:29 GMT from Portugal)
"Zenwalk, Vector, Salix, and Slackware are targeting modern computers. It's not because they are faster than most Debian derivative that they are for old computers only :)"
:) seems you're forgetting they lag either in the choice available either in the convenience of package installation regarding "some" Debian derivatives. Nonetheless when an updated version of a heavier application is available I always consider to run them first in zenwalk or salix, the friendlier ones of the four that seems more supported, despite the zenwalk suppot ... well ... there is an ongoing world cup and we can't expect the same forum support :)
70 • ECDL, European Union (by Tom on 2010-06-15 10:31:34 GMT from United Kingdom)
Hi :)
Someone commented that the EU has just made public declarations in support of OpenSource but i forgot to bookmark it. Does anyone have a good link to anything proving this or did i dream it?
Also if the EU is supporting OpenSource does anyone know of anywhere offerign courses such as ECDL based on non-MicroSquish products? Ideally internet courses using Moodle but links to any providers using pretty much any method of training would be well received. If you right-click on my name you can email me quite easily if reqired
Many thanks and regards fromTom :)
71 • Firmware and freedom (by Mike on 2010-06-15 10:44:14 GMT from Netherlands)
As long as Linux has the marketshare it has today, hardware builders have no reason to create open source firmware or open source drivers. They have to make money and therefore cannot show (in their drivers/firmare) how their firmware functions. This would be quite useful for their competitors!
I believe it is an illusion to expect anyone that wants to make good money by creation hardware components will create open source drivers or firmware. There will be a few people that will do it, but that is only because they are followers of the religion called free software. Not because they are businessmen.
72 • @ 70 • ECDL, European Union (by Tom (by meanpt on 2010-06-15 11:23:00 GMT from Portugal)
Tom, without the endorsement or the sponsorship of a powerfull country or group of countries, or even of a corporate lobby, all you get from the E Comission are non actionl words for the street man. You know to whom govenments are sold.
73 • @71 (by Anonymous on 2010-06-15 12:13:43 GMT from France)
I disagree completely with what you wrote. If you are talking about hardware manufacturers that only make hardware for the desktop PC with windows, you might have a point (heavy gaming PCI express graphic card). If you are doing anything beyond that, your point is just silly. Can you imagine any vendor doing network hardware and ignoring 70% of the server market and 40% of the router market? You think it is good business decision? You think you can make mobile hardware and not make a driver for linux? Who are you going to sell it to?
I believe the error you made is to think linux marketshare is tiny because you only considered the desktop PC market. In the broader market, it is not so tiny and most hardware vendors want to be on broader market. Those who only want the desktop are actually few.
74 • @ 73 • @71 (by Anonymous on 2010-06-15 12:13:43 GMT from France) (by meanpt on 2010-06-15 12:23:25 GMT from Portugal)
I wonder where you got those numbers from. By the way, implicit to the problem being discussed is the desktop linuix market. Not sure if servers need Nvideas for gaming and so on ...
75 • What is Freedom and what is a computer (by merlin on 2010-06-15 12:32:12 GMT from Canada)
I completely agree with Patrick on all his points. I think maybe the FSF should re-evaluate it's criteria, considering the speed with which computers and electronic devices are changing and even merging.
My television and cable STB are two examples. Both are digital devices and basically just specialized computers. My TV even came with a copy of the GPL and several other open source licences. If I'm not mistaken, some tv's can even connect to the internet now. I also noticed the youtube logo on some DVD players recently. Even another example is a digital picture frame - they have all sorts of ports. I'm sure a clever electronics person and hacker could attach a keyboard and interface some sort of storage device and presto, they have a computer!
Does the FSF consider these devices? Do they only care about a digital picture frame if a hacker lets the cat out of the bag and hooks up a keyboard to it and posts his how-to on the internet, allowing others to make their own $75 computer? To the typical person, we have no freedom with these devices because we just don't have the expertise to exploit them for other than what they are marketed for. And yet it appears at least some of them are running open source software.
I don't know for sure, but perhaps the FSF's criteria are based on old-school technology, when a TV was just a TV and a computer was just a computer. The lines are definitely blurred now. Maybe they should be renamed the FDWF - Free Digital Works Foundation.
I'm definitely no expert on any of these subjects, but something just doesn't add up. Lie any reasonable organization, the FSF has to evolve with time, and hopefully they will. In the meantime, the cat is out of the bag and we can all question ourselves about how much freedom we really have with our computers and other digital devices.
76 • @62 (by Adam Williamson on 2010-06-15 14:57:57 GMT from Canada)
Interestingly, you can do firmware updates on some modern hard disks (and SSDs). It makes me wonder if RMS would happily use such a disk, but never install a firmware update, because it doesn't come with the source?
BTW, I think the most valid counterpoint to your argument is comment #16: that burned-in firmware is much more like part of the hardware than firmware that gets uploaded at every boot. But in the end I'm not convinced that one quite flies; see the above issue with firmware that's sort of burned in but still updateable, which is most firmware these days. It's definitely a tricky area, though.
77 • RE: #68 - Salix system tools (by gapan on 2010-06-15 15:02:56 GMT from Greece)
"Salix is a nearly an unmodified Slackware, with some improvements including the Zenwalk System tools."
Wrong. The system tools in Salix have been coded from scratch in python/GTK. Some screenshots here: http://picasaweb.google.com/salix.artwork/SystemTools#
78 • @75 (by Adam Williamson on 2010-06-15 15:10:08 GMT from Canada)
Yeah, I've had the same thought; one of the main weaknesses of the current FSF is it hasn't really explicitly engaged with the additional challenges that come with virtually everything being, more or less, a computer these days. They occasional side comments that of course the PS3 is evil incarnate and so on, but they don't seem to have developed a comprehensive position / action plan for anything but traditional desktop / laptop computers.
79 • Package requests (by Anonymous on 2010-06-15 15:54:17 GMT from New Zealand)
I will again offer my suggestions on packages to be added, even though they routinely get ignored.
cmake
dvd+rw-tools
hdparm
lm_sensors
net-tools
pciutils
procps
shadow
smartmontools
syslog-ng
usbutils
wireless-tools
wpa_supplicant
xz-utils
I hope you will consider what makes sense rather than just "[the] packages that get most requests."
Cmake is now just as important as automake.
Why track cdrkit without dvd+rw-tools?
Lm_sensors in incredibly important for hardware monitoring (my number one pick to add), and some distributions still only offer version two (there where very significant changes between version two and version three).
Shadow is a very important (and basic) package on most systems.
Again, having a suitable version of the wireless networking packages (my second pick to add) is vital for someone trying to get connected that way.
How can you not include xz-utils (not quite as important as bzip and gzip yet, but it will be)?
80 • Running 64-bit Linux? No Flash for you! (by Caitlyn Martin on 2010-06-15 18:23:20 GMT from United States)
If you're running a 64-bit distro and have Adobe Flash installed you are undoubtedly running a version with a known, gaping security hole. Adobe has issues patches (version 10.1) for 32-bit but is, at least temporarily, no longer supporting 64-bit Linux. See: http://linux.slashdot.org/story/10/06/11/1338207/Adobe-Temporarily-Kills-64-Bit-Flash-For-Linux?art_pos=2
SalixOS has added gnash to their 64-bit repository and an "upgrade" to Flash is actually a dummy package with gnash as a dependency. In other words, it will rip out Flash and install the Open Source gnash alternative. gnash is far from perfect but for the moment this seems the best solution. It will be interesting to see what other distros that offer Flash do.
81 • SalixOS announcement on 64-bit Flash (by Caitlyn Martin on 2010-06-15 18:25:55 GMT from United States)
Here is a link to the announcement for SalixOS: http://www.salixos.org/forum/viewtopic.php?f=17&t=921
82 • Binary firmware could cause instability (by nutjob16 on 2010-06-15 19:02:23 GMT from United States)
Although I agree with the points expressed in the opinion piece, I would still side with the FSF on this. If I have the choice of having my firmware baked into the kernel or having it baked into the device, I would prefer the latter. Binary blobs in the kernel could introduce vulnerabilities or system instability. Having it baked into the device mitigates that risk.
83 • Where is my Chromium 6.0.424.0? (by meanpt on 2010-06-15 19:31:07 GMT from Portugal)
Parted Magic in their release announced lists the inclusion of Chromium 6.0.424.0 in their applications. Instead of it, all I got was FF 3.5.3. . Is this some sort of a gypsy fair?
84 • Mandriva 2010.1 (by DEEPAK on 2010-06-15 20:24:31 GMT from India)
When is Mandriva 2010.1 getting released??? or its been already released??
85 • @ 80 • Running 64-bit Linux? No Flash for you! (by meanpt on 2010-06-15 20:28:10 GMT from Portugal)
Why can't you people downgrade it to a 9 something? ... or ,,, just tell adobe to open source the code :)
86 • Downgrading Flash? Only if you like having a vulnerable system (by Caitlyn Martin on 2010-06-15 20:44:35 GMT from United States)
Re: #85: Downgrading to Flash 9.x would be no better than remaining at 10.0.x: you'd have known security vulnerabilities on the system. Open Source advocated have been telling Adobe to open things up for years. It just isn't going to happen.
For right now gnash is the best solution.
87 • Come to think of it... (by Caitlyn Martin on 2010-06-15 21:13:05 GMT from United States)
I don't think there was a Flash 9.x for 64-bit Linux. I don't think 64-bit Linux was supported by Adobe until the 10.0 beta.
88 • @82 (by Patrick on 2010-06-15 21:34:01 GMT from United States)
"""If I have the choice of having my firmware baked into the kernel or having it baked into the device, I would prefer the latter. Binary blobs in the kernel could introduce vulnerabilities or system instability. Having it baked into the device mitigates that risk."""
Part of the point of the article was to explain what binary firmware is and to dispel this very common myth. Because this is firmware we're talking about, it runs on the peripheral device, not in the kernel. The kernel does not execute any of the code. The only thing the kernel does is take this opaque bunch of bytes, and give it to the device, using open source code to do so. There is zero difference in vulnerabilities or system stability whether the kernel has to do this or not.
You seem to be confusing this with binary drivers--closed source code running on the PC's CPU, in kernel mode. This is a totally different thing and I fully support the FSF's stance on that, exactly for the reasons you mention.
Unfortunately, the generic term "binary blobs" is often used for both cases and people confuse them all the time. They couldn't be more different in how they can affect your system's stability though.
89 • RE: 79 Package requests (by ladislav on 2010-06-15 21:38:46 GMT from Taiwan)
ll again offer my suggestions on packages to be added, even though they routinely get ignored.
They don't get ignored. They are added to the list of requested packages, but since you are usually the only one asking for them, they don't make it to the final round. What is "important" to you might not be important enough for other readers who use this site.
There is one trend I observed recently. As more and more "normal" computer users visit DistroWatch, I tend to get more requests for end-user applications than for base packages. This week is a good example - I've had several emails asking for Google Chrome, but nobody (except you) has asked for cmake (or any other package you've mentioned).
90 • Mandriva 2010.1 ## 12 & 87 (by kilgoretrout on 2010-06-15 21:48:09 GMT from United States)
To quote Lao Tzu:
Those who know do not speak; those who speak do not know.
In short, the upper management of Mandriva who know what's going on aren't talking and everyone else is just speculating. The consensus of the speculation is that Mandriva is in the midst of negotiating a sale of its assets to a French open source company and that the release of 2010.1 has been delayed pending the outcome of those negotiations.
91 • Mandriva (by Phil Smyth on 2010-06-15 22:08:34 GMT from United States)
I cut my Linux teeth on Mandrake. Four years ago, when they dumped Gael Duval, I dumped Mandrake / Mandriva. I hope Herve Yahi is proud of what he has done. I also hope that both Mandriva and Yahi inpersonate the French fleet of July 3, 1940.
92 • @ 86 • Downgrading Flash? (by Caitlyn Martin (by meanpt on 2010-06-15 22:13:52 GMT from Portugal)
ok, ok ... don't shoot me ... I just remembered I used to have some old (more than 3 months) 64 bit virtual machines around with firefox and flash (already deleted cause couldn't see much running speed diference on this virtual thing) ... so ... what firefox instalations were those? 32 bits? ... I guess I'm missing somethging ... or not?
93 • Response to #90, 91, 92 (by Caitlyn Martin on 2010-06-15 22:45:30 GMT from United States)
#92: I'm not going to shoot you :) LOL. Yes, you could have been running the 32-bit version. It is possible to do that on a 64-bit OS, though neither desirable nor without problems for some people, hence the desire for native 64-bit code.
There may actually be something good coming out of this. If it speeds development and acceptance of gnash, which is Open Source, that would certainly be a good thing. If it pushes more web developers to move to HTML5 and away from Flash that would also be a good thing, IMHO.
#91: M. Yahi is no longer CEO of Mandrake. I certainly don't wish ill on the 50 or so employees they still have in France and Brazil, nor do I want to see what is still a very good distribution disappear. The best outcome would be a successful sale to a company who might just come up with a sane business plan for Mandriva, something neither M. Duval or M. Yahi was able to do.
I agree with #90: the information we have seen from employees is colored by worry and internal rumor. Only upper management knows what is really happening.
94 • package request - mythtv (by reuben on 2010-06-15 22:49:00 GMT from United States)
I'd like to see mythtv added to the list. It would be nice to see at a glance which distro uses which version since different version are incompatible.
Talking about tracked packages, I was wondering why bash isn't considered a major package. Would you consider changing it's status?
95 • Mandriva and Martin and Yahi post #93 (by Phil Smyth on 2010-06-15 22:58:13 GMT from United States)
I am fully aware that Yahi is not the CEO. He is the CSO.
It seems that his strategy has failed. I still hope he and Mandriva sink like proverbial rocks to the deepest depths of the sea.
96 • package suggestions (by Anonymous on 2010-06-15 23:15:38 GMT from United States)
I would like to see MythTV, privoxy, and possibly tor as tracked packages.
97 • Package suggestions & Mandriva (by Barnabyh on 2010-06-16 01:08:04 GMT from United Kingdom)
I'ld second privoxy and tor, and would add terminator as request.
Re. Mandriva, looks like some of the long awaited and oft talked about consolidation is about to take place.
98 • Flash heck (by Anonymous on 2010-06-16 04:49:19 GMT from United States)
The open source one just makes the message "You need to upgrade to 10.1" to pop up then the 10.1 fails to install because the open (gnash dummy) program installer tries to run the real 10.1 upgrade. Depending on the site (and computer & browser) I have to run 3 different versions of Flash. I still haven't figured a way around some computers with Iceweasel. It seems to have another problem with some websites reporting the wrong version of flash.
99 • package stuff (by meanpt on 2010-06-16 08:10:05 GMT from Portugal)
Gnoe Planner, Chromum and XMIND open source
100 • RE 91,95 (by Danse du Scalp on 2010-06-16 08:51:44 GMT from France)
"I still hope he and Mandriva sink like proverbial rocks to the deepest depths of the sea."
Well, it would be difficult : there is no sea near Paris and there is only an ocean for some Brazilian towns...
"Four years ago, when they dumped Gael Duval, I dumped Mandrake / Mandriva."
Well, I suppose when a distributions founder dies/gets fired, one should put:
a) tons of CD's /DVDs
b) hair tearing, crying blonde typists
c) (if he is dead) the copse of the founder, else those who fired him
on a drakkar, in a fjord, put the drakkar into fire and make a film out of it...
101 • #98: gnash so far (by Caitlyn Martin on 2010-06-16 15:23:44 GMT from United States)
Re: #98. It seems to really depend on the websites you visit. gnash works perfectly for watching YouTube videos, for example. I haven't run into a problem yet but I have no doubt that on some sites I'll see the kind of thing you describe. Like so many things, YMMV.
102 • Feature Article (by Cliff on 2010-06-16 18:15:19 GMT from United States)
@Sergio I understand. I'm quite familiar with the FSF and am very grateful to them for all they have provided us. All I am saying is that there is nothing wrong with Patrick's article, and his questioning the FSF's philosophy regarding this matter. It promotes discussion and new ideas. To say that you question someone's idea, isn't to say that you no longer support them. It's good to stop and look at where you are, where you've been, and where you're headed.
103 • My two cents on non-free firmware (by Rubén Rodríguez on 2010-06-16 19:20:19 GMT from Spain)
To Patrick Van Oosterwijck
You claim that firmware being non-free is not an issue since it is run by the peripherals and not by the main processor. That argument fails in two points: first, it is hard to say that computers have only one processor nowadays, as the GPU can even be more powerful than the main processor. Second, that main processor has a binary only non-free firmware too. The common consumer processors this days are fed with a blob during the BIOS stage.
So, the firmware is just another program designed to be run by a processor, being it the CPU or any of the other processors in a computer. And if you don't have the four freedoms over that software you can't know what such software does, and you cannot modify it or improve it. What happens to a perfectly fine peripheral which just gotits warranty expired and the vendor doesn't want to keep supporting it? If you have the code you can keep using your hardware forever. Don't forget that a printer with no modifiable drivers started all this free software thing 30 years ago.
A practical example might be the firmware included in the ATI Radeon driver -which is listed as free software almost anywhere-. It is run by a command processor in the card -not by the actual GPU- and it is required for 3D and 2D support... it also manages the DRM (Digital Restrictions Management) of the card, from a deep level. It is designedto take away your freedom, to limit what you can do with your card.
It is needless to say that ATI cards show no 3D support on fully free operating systems like gNewSense or Trisquel.
The other main claim is that the difference between embedded firmware and user-loadable firmware is unimportant. If it is the same binary blob, why being unable to change it improves the user's freedom? If you need to load a binary blob yourself, then you need to get a copy of it first, so you need to get non-free software to make your hardware work. It sounds pretty bad to me. The worst thing is that in the GNU/Linux world a free software provider -your distro- will need to provide such non-free program to you. And if they don't, people like you will undermine both the user and the distributor effort towards freedom. By the way, the current FSF policy states that the kernel should not load those binaries anyway, so there is no need for the users to hunt.
Besides, I see nothing wrong in saying to the users: your hardware vendor doesn't respect your freedom. Buy from one that does. Also, this policies are showing those vendors that they are doing wrong. To lower the prices they are embedding more and more software inside the hardware, it is cheaper than actually wiring the thing the proper way. Now it is the moment to say the vendors: if you want to do that, give me the code or I'll buy from someone else.
104 • @103 (by Adam Williamson on 2010-06-16 20:41:26 GMT from Canada)
"You claim that firmware being non-free is not an issue since it is run by the peripherals and not by the main processor. That argument fails in two points: first, it is hard to say that computers have only one processor nowadays, as the GPU can even be more powerful than the main processor. Second, that main processor has a binary only non-free firmware too. The common consumer processors this days are fed with a blob during the BIOS stage."
Those are two very weak arguments. It doesn't matter that the GPU may be more powerful, by some very limited measurements, than the CPU; on a typical computer it could not possibly be seen as the 'main processor', because all it handles is graphics. There isn't yet a configuration in widespread use where it would be hard to identify which is the 'host CPU' in a machine. Only a few clusters which use CUDA would be in a bit of a grey area here.
"Second, that main processor has a binary only non-free firmware too."
So what? That doesn't invalidate Patrick's argument at all, it's completely orthogonal to it. Patrick isn't talking about that. It's perfectly possible to talk about that point too, but it's not the subject under discussion, and it doesn't have any particular bearing on the subject under discussion. So why bring it up?
105 • Binary firmware and your freedom (by Darryl Gardner on 2010-06-16 21:26:50 GMT from United States)
Interesting article.
I too would like to see what those on the other side of this issue have to say.
It looked like the bickering which unfortunately creeps into discussions was fortunately missing, but it didn't turn out that way.
I realize many readers/participants in this - and in most other discussions I've seen - do not necessarily use English as their primary language. Sometimes it's obvious and at others it's through pointed comments.
Frankly I don't care what language anyone is most familiar with; nevertheless I would hope they attempt to express themselves, as best they can, in the language of the forum. i.e., if it is in English, try to use English; if in some other language, use that.
But regardless of a person's native language, if they get their point across well enough to be understood, that's all I care about.
Spelling errors are commonplace, so don't get excited about that either.
And what if a sticking keyyyyyyyyy on their keyyyyyyyyyboard causes a few extra keyyyyyyyyystrokes?
Please refrain from making two asses obvious - mine for doing something dumb someone else's for pointing it out.
Thanks, and best wishes.
106 • Other side (by Jesse on 2010-06-16 22:12:47 GMT from Canada)
Out of curiosity I have contacted the FSF and asked if they'd be interested in expressing their opinion on this topic. If they send me a statement, I'll share it here in a future issue.
107 • @103 (by Patrick on 2010-06-16 23:27:47 GMT from United States)
"""You claim that firmware being non-free is not an issue since it is run by the peripherals and not by the main processor."""
I did not say that. Quote: "If having source code available for all binary firmware was the center of the FSF's policy, I would not disagree with them in any way (although I would not have much hope of achieving this goal). My problem is with the fact that the FSF is blacklisting specific drivers based on how their binary firmware is distributed, instead of focusing on the real issue of whether firmware source code is available at all." I would love to have source code available for all firmware. That is at the core of my argument. I just do not think that it is right to want sources *only* for firmware loaded by the kernel and not for firmware built-in to the device. The effect on your freedom is the same either way--no software freedom at all. In effect, I'm asking: why do vendors that build the firmware into their devices get off the hook?
"""If you need to load a binary blob yourself, then you need to get a copy of it first, so you need to get non-free software to make your hardware work. It sounds pretty bad to me."""
I'm not sure what you are referring to as "bad" here. If it is the fact that you need a file with "bad (non-free) bytes" to make your hardware work, well I've got news for you: in the case of built-in firmware you already received the "bad bytes" when you bought the hardware. But somehow the FSF doesn't care about them then. If you're referring to having to go somewhere to get the file: not if the manufacturer graciously allows distribution of the firmware file with the Linux kernel. But that's what the FSF doesn't like, of course.
"""The worst thing is that in the GNU/Linux world a free software provider -your distro- will need to provide such non-free program to you. And if they don't, people like you will undermine both the user and the distributor effort towards freedom."""
Neither the user's nor the distributor's effort towards freedom is served by encouraging the use of devices that have non-free firmware built-in over devices that need to have non-free firmware loaded. It is a smokescreen, a ruse, a distraction from the real issue. I want the FSF to focus on a real effort toward free firmware, no matter how that firmware is stored and loaded, instead of distracting everyone with arbitrary requirements on how it is OK or not OK to have non-free firmware delivered to your system. Really, that is what their current policy amounts to: They find it OK for you to run non-free firmware, as long as you buy it stored inside your device. Do you find that a good way to promote free software?
"""By the way, the current FSF policy states that the kernel should not load those binaries anyway, so there is no need for the users to hunt."""
I am aware of that. That is exactly the policy I oppose. Because it is a policy that makes no sense. Either the kernel needs to load the offending bytes, or the offending bytes are already present. Either way they run in your computer. All I want is consistency. Is running non-free firmware in your device OK for the FSF? At the moment, their answer is "yes, as long as your free software doesn't need to load it". That policy does not in any way help the user's or the distribution's effort towards freedom.
108 • My two cents on non-free firmware (by Rubén Rodríguez on 2010-06-16 23:27:57 GMT from Spain)
@103 I bring that up because Patrick's argument is that as the firmware isn't software run by the main processor, it is not relevant to the user's freedom. It is relevant because it is becoming ubiquitous, even the main processor itself needs a firmware blob to run. That is clearly a loophole: you need to provide your computer a non-free software piece to be able to use it.
And it is even worse if you think that in most cases you can't even write a replacement for that software -as we do with the OS and userland apps-, because it is meant to be run by a misc processor with unknown specs -which is the underlying problem beneath all of this, and it needs to be addressed instead of ignored-.
110 • Free (by Anonymous on 2010-06-17 00:03:04 GMT from United States)
What ever happened to the project to design and produce a totally free CPU?
I will search for it, but if anyone knows, let us all know...
111 • Free CPU (by Anonymous on 2010-06-17 00:06:08 GMT from United States)
here's a link:
http://f-cpu.seul.org/
Looks like they froze in 2004 and never thawed out.
112 • MINIX 3.1.7 USB stick (by zygmunt on 2010-06-17 07:26:12 GMT from United Kingdom)
Anyone care to point me to the MINIX 3.1.7 USB stick image? I don't see one!
113 • RE: 112 (by Landor on 2010-06-17 10:22:46 GMT from Canada)
I haven't tried it, but shouldn't dd work from the standard iso?
dd if=/pathofyourimage/image.iso of=/dev/sdx (where "sdx" is the device you're putting it on)
Keep your stick on the ice...
Landor
114 • packages list (by Tom on 2010-06-17 11:21:19 GMT from United Kingdom)
Hi :)
Is there any chance of a slight style change or addition? KDE desktops default to different packages than Gnome desktops so having 1 list to cover all DEs/WMs seems odd.
Often distros don't all use the same defaults for such things as text-editors and office suites and it can be difficult to find out which are used on a particular distro. Even within a distro a newer release may switch which packages it has by default.
Without an indication of which packages are actually being used i find the package list a total waste of time although it is charmingly quaint.
Regards from Tom :)
115 • @108 (by Patrick on 2010-06-17 15:18:33 GMT from United States)
"""Patrick's argument is that as the firmware isn't software run by the main processor, it is not relevant to the user's freedom"""
I really hope that this is a case where our comments crossed, otherwise I seem to have a real problem making myself understood. Again, no, that is NOT my argument. It is pretty much the opposite.
"""And it is even worse if you think that in most cases you can't even write a replacement for that software -as we do with the OS and userland apps-, because it is meant to be run by a misc processor with unknown specs -which is the underlying problem beneath all of this, and it needs to be addressed instead of ignored-."""
And then there is the case where, even if you could write a free replacement of that software, you couldn't load it because it is baked into the hardware. This is the case the FSF totally ignores, and the reason I wrote this article.
116 • Elementary, the birth of yet another distro. (by RollMeAway on 2010-06-17 20:16:00 GMT from United States)
Nice article by Christopher Smart concerning a new distro about to release:
http://www.linux-mag.com/cache/7811/1.html
117 • @115 (by Rubén Rodríguez on 2010-06-17 20:17:37 GMT from Spain)
The FSF ignores that case because if the firmware is embedded so it cannot be modified -or accessed in any way- , then it makes no difference if it was wired logic instead. The user can't even know if the firmware is there, and more important, she doesn't need to know, because it is not a serviceable part.
The main point of this is that you don't even need a software license to use such hardware, but you need to agree to a non-free software license to use binary-only firmware files. That's a huge difference.
118 • Firmware (by Jesse on 2010-06-17 21:22:45 GMT from Canada)
@117:
I think you're skipping over a few items. You're talking strictly about two types of firmware. One, which is distributed with the kernel and is loaded into the device. The other, which is embedded into the device and cannot be changed. There are other types too, which Patrick covered in this article, that are contained in the hardware and could be modified in certain situations. As the article points out, the FSF seems to ignore any type of firmware which isn't shipped the with kernel. This includes the kind you were talking about, the kind that is baked in, and the kind which could be modified.
The article raises the question why firmware which could be modified isn't addressed. Or, I suppose, why the FSF okay with firmware that is baked into the hardware that we can't change. Why are they against one kind of firmware and not the others? Each is non-free and binary-only
It might be a language barrier thing, but I disagree with the second statement about needing to agree to a non-free software license to use binary-only firmware. Copyright licenses cover distribution, not use. I don't need to agree to a non-free license to use firmware in the kernel, just if I want to distribute it.
119 • Feature article (by Steve on 2010-06-17 22:24:20 GMT from United States)
The feature article was very good!
120 • @117, referencing @25 (by Patrick on 2010-06-17 22:36:31 GMT from United States)
"""The FSF ignores that case because if the firmware is embedded so it cannot be modified -or accessed in any way- , then it makes no difference if it was wired logic instead. The user can't even know if the firmware is there, and more important, she doesn't need to know, because it is not a serviceable part."""
This policy of ignoring embedded firmware (can you provide a reference to where it is documented?) does not seem to apply when there happens to be GPL code used inside said firmware. The Busybox lawsuits show that in those cases, embedded firmware, which many users wouldn't know was even there and would have considered wired logic instead, was subject to the GPL license, and the license of the firmware did matter here, even if the code was not readily accessible.
So a device containing firmware that is subject to the GPL license has to comply to the GPL license by providing the 4 software freedoms. Similarly, a device containing firmware under a non-free license does not grant the user any of these software freedoms (sometimes explicitly taking them away by prohibiting reverse engineering). You buy the hardware, you buy the firmware with it and you agree with this non-free license.
If the FSF really intends to limit the reach of the GPL to accessible, serviceable firmware, they have to realize what a slippery slope this is. As another commenter brought out, devices nowadays come in every shape and form, and many store binaries compiled from GPL code in flash memory which is often just as inaccessible as the non-free firmware in your peripheral. The Busybox cases made it obvious that the GPL extends out to "envelop" the device it is used in, and the device was still covered under the GPL, even if it was opaque. The same applies to non-free licenses: you also accept those when you use the device that runs them.
Also, at what point would firmware become considered accessible or serviceable? How about binary code on your hard drive? FSF says non-free, even if it is a binary file just as opaque as one burned into flash. How about binary code in a chip on your peripheral? FSF says that's fine. How about a removable and exchangeable flash ROM chip? Not so sure here, do you consider this hardware or software? How about if this flash chip would be an SD card instead? Would it matter if the SD card was formatted as a file system and the binary firmware would take the shape of a file, or if it was used as raw storage without file system?
As you can tell, the distinction becomes very vague here. It becomes a matter of "who is capable of accessing and servicing the binary firmware?" At what skill level do you draw that line? As brought out in the article, an embedded engineer can change the firmware in many devices you'd consider not serviceable. So his freedom is restricted by not having source code. On the other hand, there are millions of people who don't even know what a binary file on their computer is. To them, it is just as inaccessible and opaque as if it was a bunch of bytes burned into their hardware.
"""The main point of this is that you don't even need a software license to use such hardware, but you need to agree to a non-free software license to use binary-only firmware files. That's a huge difference."""
From the information I found (for instance http://wiki.debian.org/KernelFirmwareLicensing), this doesn't seem to be true. Many of these firmware files are distributed under a free license. What seems to be the hangup is that many of them contain just tables of bytes (assumed to be executable code), without the corresponding C or assembly code that MIGHT have been used to produce them.
Someone may argue this is GPL code with source available, the FSF would probably decide it is not. So here there is a question of how you define source code. Does it need to be C code? Can it be assembly code? If assembly code is acceptable (requiring significant skill and knowledge of the target device architecture), one might argue executable code should be acceptable too (as there is pretty much a one-to-one correspondence between assembly language and the executable, and if you know an architecture well enough to know its assembly language you usually would have the skill to deal with the executable code too). And then there are cases where chips just need to be given a bunch of configuration parameters, which might be produced directly as binary code without any "human readable" form available. [BTW "human readable" is a relative term. Hex editors make binary code "human readable" too. And a "human readable" character "0" is just a binary number 0x30.]
I really like the comment made by Ivan in @25, which mentions these points as they relate to the 4 freedoms. I also wholeheartedly agree with his statement: "Now if the FSF has an issue with non-human readable code, they should explicitly state such." Because that seems to be at the root of the rejection of many of these kernel-loaded firmware files.
So for the FSF position on firmware to make more sense, they would have to clarify three things:
1. In what way does the rejected kernel firmware not obey the GPL (see comment @25). Is "human readable" code required?
2. If human readable code is required, how do they define "human readable" code? What if the firmware in a device never had a more "human readable" form than binary?
3. At what point do they consider software to be part of the hardware and thus "out of their jurisdiction"? How do the binary bytes that make up the firmware need to be stored (format and media) to make them care or nor care about them (and this should be a consistent policy for both GPL and non-free code).
121 • Firmware (by Landor on 2010-06-17 22:53:38 GMT from Canada)
I think Ruben's hit on a point that's been missed by the article and should pretty well be common sense when you look at it from the right angle, anyway.
Adam's arguement is flawed when he stated that it's not the subject under discussion, it actually is. Here's my reasoning.
Every day each of us picks our fights, whatever they be (fights is a loose/subjective term here of course). First what defines software? Anyone know? My perception of software is something that's outside of the hardware and as Jake has commented a number of times, that sends signals to the hardware to change its state, as I said, "outside" of the hardware. That makes anything with firmware embedded on the chip no longer software, but actually part of the hardware. That's my opinion of course. A CPU is a fine example.
Back to picking our fights. What's the name of the Foundation? Free "Software" Foundation, no? (This is where the article and Adam's view is incorrect in my opinion only of course). Should the FSF and Stallman outlaw CPUs? I don't think that's a viable solution and I'm sure they don't either. If I decide I want to be rich today (in financial wealth), do I say, "Today I'm going to become a billionaire"? Of course I don't, not realistically. I make plans and take the most realistic steps to get where I intend to go in that regard. The FSF in my opinion has to do the same. They have to pick their fights and bite off only what they can chew. If they told me that all firmware (which includes on a CPU) was evil and I shouldn't use it, I'd agree totally with the people that think they're a little off the mark at times. What they do those is pick their battles and say, "Hey, firmware blobs which is "software outside of the hardware" is against your freedoms. To me that's sensible. When you take a step at a time you can eventually climb the stairs. So is it hypocritical for the FSF to only target actual software when their goal is to eliminate non-free software, no. Anything embedded on hardware is the next step after the battle for software is won.
Keep your stick on the ice...
Landor
122 • @121 (by Patrick on 2010-06-17 23:27:36 GMT from United States)
"""That makes anything with firmware embedded on the chip no longer software, but actually part of the hardware. That's my opinion of course."""
As I explained in @120, the Busybox lawsuits did not follow this reasoning.
"""What they do those is pick their battles and say, "Hey, firmware blobs which is "software outside of the hardware" is against your freedoms.""""
I have never seen any software that can exist outside of hardware, have you? If you had, you probably could well make that claim: "Today I'm going to become a billionaire". ;)
In all seriousness now, I agree they have to pick their fights and they have started with "software running on the main CPU" first, which is a big enough fight in itself. But then let them stick with that and not half-heartedly drag in a subset of firmware just because it happens to be stored a little bit farther away from the device that it ends up running in. They are not the "Device Firmware Physical Unification Foundation" after all. They are the Free Software Foundation. The Busybox cases have proven that they DO care about firmware baked into hardware. Their stance on binary firmware loaded from the kernel proves they DO care about firmware running inside peripherals. Putting the two together should mean they DO care about binary firmware baked into hardware too, if they're at all interested in having a consistent policy on eradicating non-free software.
If they want to make sure they don't want to bite off more than they can chew, sure, let them target software first, but leave firmware alone and don't make a big stink about how it happens to be stored/loaded, inconveniencing users that want to run a free OS.
If they feel they need to take on firmware too, then let them take it all on and make no distinctions about where the non-free stuff is stored.
123 • RE: 122 (by Landor on 2010-06-17 23:47:38 GMT from Canada)
My question is this then, When is it firmware? Can you tell me that? I know what firmware is and why it's defined firmware, but when is it firmware? I say it's firmware when it's embedded on the chip. That's only a personal view though. It's software until then, a view which fits nicely with their current action(s) in its regard I might add. ;-)
If they took on all firmware then, would you totally agree with them? Would you shut down your computer and never use it again because a CPU has embedded firmware? I don't think you would, nor would I. I'd tell them to kiss something, as most would. ;-) So it's not honestly fair, nor realistic, to say you think they should take on all firmware when you would definitely oppose their ideals. :-)
Keep your stick on the ice...
Landor
124 • RE: 122 again (by Landor on 2010-06-18 00:20:40 GMT from Canada)
I have another question too. See, the article is opinion and it's obvious you're not in line with their views on the exclusion non-free firmware. But how does it inconvenience someone who wants to use a a free OS? (Oh and I find it ironic you consider something non-free part of a free OS.. :P ) I would think that too is only opinion. If someone tells me I have to, or only should, use non-free items in my choice of OS it doesn't inconvenience me at all. It only would if they had the power to make that happen (which the FSF currently doesn't). But as luck would have it there's totally free software everywhere, including kernels, so I'm not inconvenienced at all. The same is for OS' that have non-free components, there's more of them than there are totally free OS'. So in essence (at this point in time), it's your philosophy that's inconvenienced, not the use of any OS. That's not an attack on your views either, just a valid point to your statement.
Keep your stick on the ice...
Landor
125 • Re: 121 (by jake on 2010-06-18 03:09:29 GMT from United States)
"My perception of software is something that's outside of the hardware and as Jake has commented a number of times, that sends signals to the hardware to change its state, as I said, "outside" of the hardware."
But so-called "software" and "firmware" are never outside the hardware. They are the current state of the hardware. For various values of hardware. (Think about it ... mag tape, hard drives, (E)EPROMs and NVRAM are all hardware. Etc.)
Code, on the other hand, is printed and readable by humans[1]. And there is a part of me that wants to think that even ink on paper is a state of hardware ... I've spent entirely too much time with embedded systems, can you tell? ;-)
[1] Yes, ones & zeros are readable and understandable by humans ... most of us don't go there these days, but I have toggled front panel switches to get one of my old DEC systems to boot into a sane state in the last year or so ... Not from memory, I hasten to add, but from a printout I made decades ago. Without access to that code on paper, the system would now be on a scrap-heap, instead of delighting my nieces & nephews with printouts of ASCII-art Snoopy, "Happy Birthday" banners & the like on blue or green & white 15X11 inch fan-fold paper.
126 • @120 (by Rubén Rodríguez on 2010-06-18 11:23:23 GMT from Spain)
"This policy of ignoring embedded firmware (can you provide a reference to where it is documented?)"
I don't think they write a list of the things that are not a problem ;) But you can find texts saying "[unaccessible embedded firmware] may as well be hardware", like this one:
http://www.fsf.org/campaigns/free-bios.html
"does not seem to apply when there happens to be GPL code used inside said firmware. The Busybox lawsuits show that in those cases, embedded firmware".
Wait, now that's misleading. Portable devices are often called "embedded devices" although we carry them outside our bodies (by now), and the software within them is called "firmware", while they are just talking about small computers and small operating systems. This model has nothing in common with loading a firmware file into -let's say- a wireless card to run it.
"From the information I found (for instance http://wiki.debian.org/KernelFirmwareLicensing), this doesn't seem to be true. Many of these firmware files are distributed under a free license.
Someone may argue this is GPL code with source available, the FSF would probably decide it is not. So here there is a question of how you define source code. Does it need to be C code?"
It needs to be understandable and modifiable by a programmer. An hex dump of a binary is not the source code of it, in fact it is the other way around. The programmer who made the binary used a different source code, one which can be modified, and with useful comments and documentation. It can be assembler code, but even that would be very different than compiling the code and then disassembling it.
"I really like the comment made by Ivan in @25, which mentions these points as they relate to the 4 freedoms. I also wholeheartedly agree with his statement: "Now if the FSF has an issue with non-human readable code, they should explicitly state such." Because that seems to be at the root of the rejection of many of these kernel-loaded firmware files."
Is it needed for anyone to state that software written by humans must be readable my them? Also, the root of rejection isn't that but the absence of source code.
1. In what way does the rejected kernel firmware not obey the GPL (see comment @25). Is "human readable" code required?
It is not the code used to obtain the binaries. The source code for a work means the preferred form of the work for making modifications to it (point one of the GPL, definitions). A hex dump or a disassembly of the binary does clearly not qualify.
2. If human readable code is required, how do they define "human readable" code? What if the firmware in a device never had a more "human readable" form than binary?
The programmer who made it obviously used something better than a huge array of numbers, like well commented assembler code.
3. At what point do they consider software to be part of the hardware and thus "out of their jurisdiction"? How do the binary bytes that make up the firmware need to be stored (format and media) to make them care or nor care about them (and this should be a consistent policy for both GPL and non-free code).
The IEEE defines firmware as "The combination of a hardware device and computer instructions and data that reside as read-only software on that device". That marks a clear boundary, because if you replace such programmed logic with wires the user would not even notice the change.
127 • #112,#113 (by zygmunt on 2010-06-18 13:37:38 GMT from United Kingdom)
NO
128 • @Landor (123, 124) (by Patrick on 2010-06-18 16:57:54 GMT from United States)
"""So it's not honestly fair, nor realistic, to say you think they should take on all firmware when you would definitely oppose their ideals. :-)"""
I was merely presenting what to me seem to be the two choices they have that would make logical sense (either you do, or you don't take on firmware, but don't do it halfway based on an arbitrary requirement to determine what is "acceptable non-free firmware" and "unacceptable non-free firmware"). You are right that with the current state of affairs, taking on all non-free firmware is likely too big a chunk to bite off, because there would be hardly any hardware to run our free OS on. Like you said, it makes sense to fight this battle with small steps at a time. But it is important that your requirements are solid and logical for each step of the way, otherwise people will stop taking you seriously.
I am convinced that in the electronics industry, most people just don't get the current policy, finding it completely arbitrary and ridiculous. Sometimes the best chip for a design doesn't give you any other option than to load firmware from the kernel. It has nothing to do with "greedy manufacturers" as so often is stated. In fact, sometimes profit margins are so razor thin that adding a flash chip to the board would wipe out any profit that's left. So let's say a nice manufacturer DOES care about having his hardware supported in Linux. So he graciously makes his firmware available. What does he get in return? Appreciation? No, his device gets blacklisted! So he wants to find out what he did wrong. He is told: "Oh, it's your firmware. No, you don't really need to change it or open it. Just don't give it to us, but hardwire it into your board next time, and you'll be fine. We'll happily use your hardware with its non-free firmware as long as we don't have to see it's there." Honestly, he'll think that's a bad joke and likely not take anything from the FSF seriously after that.
"""So in essence (at this point in time), it's your philosophy that's inconvenienced, not the use of any OS. That's not an attack on your views either, just a valid point to your statement."""
That might be true, but I like to think this is about more than just my philosophy. On a personal level, I have been inconvenienced in a practical way when my hardware didn't work on a Debian system, and it took me a while before I realized I had to install the non-free firmware package. Minor, I know. Inconvenient, yes.
I obviously do not mind using hardware the kernel needs to load firmware into. It makes no difference whatsoever to the stability and security of my system if the firmware happens to be stored in a chip or on my hard drive. I DO resent the binary in-kernel driver I need to load for my video card, and I am well aware of the stability issues it introduces into my system. But there are stronger forces involved that force this upon me (my 4-year-old demands to "play with gooballs" ;)).
What is more important to me (and the main reason I wrote this article) is that I really feel that what the FSF is doing is wrong, and that the whole binary firmware story needs to be brought into the open. The FSF policy makes so many people think they are running a "totally free system", while they are not. I feel like their ideology is being violated, because they think they are free of non-free firmware and they are not.
Let's compare it to vegetarians. Let's assume for a second the food industry was like the electronics industry. Manufacturers would not have to list ingredients on their products and people in general would not know how food was made. Let's say I work in the food industry, and I know how food is made. I go to the grocery store and there are all these people with shirts on that indicate they are vegetarians ("Stop eating animals", etc.). They are even giving out pamphlets to people buying meat and making a big deal about how evil it is to kill animals for food. Then I see one of them buy Jello. So I ask: "Excuse me, do you know that contains gelatin made from animal bones?" He just laughs at me and says: "Come on man, does this look like meat or bone to you?" A little further the one who looks like the leader of the group buys a TV dinner with turkey gravy. I ask him: "You do know there is turkey in there right?" And he says: "Sure. The Vegetarian Association doesn't care about that, because it's processed. I just need to make sure there is nothing that's obviously meat in here." Confused, I ask: "But I thought you cared about animals, and they need to be killed to make this gravy too!" And he says: "I do care about what I eat as long as it still looks like an animal product. Once it gets processed into something unrecognizable I don't care much anymore. I mostly want to make sure I follow the rules of the Vegetarian Association so I can be called a vegetarian."
As someone aware of how food is made, I would not think very highly of this Vegetarian Association and its policy. I would in fact be quite appalled, knowing that there must be many people out there thinking they were eating vegetarian, naively thinking their existence was not harming any animals, because they were unaware of how food is made and were putting their trust in the Vegetarian Association to have a sensible policy, aligned with their own philosophy. At the same time, the Vegetarian Association would be giving the food industry the veiled message: "We know there aren't many practical ways to get people the protein they need to have a healthy diet. So if you need to add some animal product, make sure it's hidden well enough and don't put obvious pieces of meat it it." I would feel compelled to make this known to all vegetarians so they would be aware of the whole story related to animal products in food.
This is how I feel about this firmware issue. Many many people are misled into thinking they have a "totally free system", and very very few actually do. Then they go around telling me and others that non-free binary firmware is evil and I shouldn't run it on my system, while they have it running on their system too. So this is about more than just my own philosophy being inconvenienced, this is about making facts public to other people whose philosophy may be more than just inconvenienced. The reality is that it is very hard today to avoid running non-free software on your system. The only thing the FSF covers is whether it gets stored on your hard drive, NOT whether it is stored elsewhere in your system, NOT whether it runs on your system or not, NOT whether your 4 freedoms are violated by it or not.
129 • @128 (by Rubén Rodríguez on 2010-06-18 18:48:39 GMT from Spain)
So, you think the FSF is not going deep enough because they don't think there is a problem with inaccessible embedded firmware. You feel like the free software user's ideology is being violated, because they think they are free of non-free firmware and they are not.
But then you don't care to use hardware which requires non-free binaries to run, because there are more important forces -like your 4th year old's games- involved. You are aware of the stability issues such binaries may cause to your system -none that I know-, but ignore the freedom restriction it certainly causes.
I'm starting to think you just like to argue. (I do too, BTW ;)
I'm guessing your advice to a vegetarian would be: "You can't know if the cake we have for dessert has animal gelatin anyway, so eat your meatballs".
130 • @126 (by Patrick on 2010-06-18 19:20:23 GMT from United States)
"""I don't think they write a list of the things that are not a problem ;) But you can find texts saying "[unaccessible embedded firmware] may as well be hardware", like this one:
http://www.fsf.org/campaigns/free-bios.html"""
Thank you for that link. It definitely clears up for me where the FSF is historically coming from. Unfortunately for them, as they bring out: "Since that time, the situation has changed. Today the BIOS is no longer burned in ROM; it is stored in nonvolatile writable memory that users can rewrite." They have recognized the BIOS as a part of the system that is different than it used to be, because now it is changeable. What used to be a simple PC with one processor and a bunch of dumb hardware peripherals, where you could clearly define what the "software" was, is now turning into a hodgepodge of interconnected processors of various sizes and capabilities, all running software in one form or another. And more and more of this software, formerly unchangeable, now lives in user rewritable flash devices. It is going to be interesting to see how they adapt to that.
"""Wait, now that's misleading. Portable devices are often called "embedded devices" although we carry them outside our bodies (by now), and the software within them is called "firmware", while they are just talking about small computers and small operating systems. This model has nothing in common with loading a firmware file into -let's say- a wireless card to run it."""
If you look through some of the information on the Busybox lawsuits, they cover devices ranging from Blu Ray players to HDTV's to network routers, DSL modems, etc. Many of these uses are very much embedded, and have very much in common with the firmware running in a wireless card. Generally they are fixed-function and the user is not able to run their own applications on them. Some of them can be used as peripherals to a PC. Heck, it is perfectly possible to make a wireless card running Linux and Busybox. Do you think they wouldn't come after me if I made a network card that happened to run Busybox and I didn't release the source? They sure would. Even if the firmware was stored in a ROM chip that could not be updated, they still would. In that case they consider the license of the software embedded in the hardware important. In case I run proprietary code on it, they consider it equivalent to hardware wiring and none of their business. It is a valid comparison and not misleading in any way.
"""The source code for a work means the preferred form of the work for making modifications to it (point one of the GPL, definitions). A hex dump or a disassembly of the binary does clearly not qualify."""
Thanks for clarifying that. Now I wonder: let's say I make a peripheral with an FPGA on it, and the only "source" I have is a circuit diagram in a proprietary format, created by the FPGA manufacturer's proprietary tool, that happens to be the only tool to support the chip. Would availability of this source be valid?
"""The programmer who made it obviously used something better than a huge array of numbers, like well commented assembler code."""
I know I'm talking about corner cases now, but there are some chips that just require a bunch of configuration bits for various registers to be loaded. Would this be considered "non-free firmware"? There really is no other "source" than the tables of numbers. Would they be considered the source?
"""The IEEE defines firmware as "The combination of a hardware device and computer instructions and data that reside as read-only software on that device". That marks a clear boundary, because if you replace such programmed logic with wires the user would not even notice the change."""
I find that an extremely vague boundary, honestly. There is nothing clear about it. It vaguely says "instructions and data that reside as read-only software on that device". What is the "device"? Is it the PC? To most people, the PC is a black box device. To most readers here, the peripheral card in their PC is a black box device. To many embedded developers, the chip would be the device. If it is the PC, as would be true for most users, then firmware stored on your hard drive should be no issue. You'll likely say "No, it means the peripheral", but then, does it need to be on the same chip, or is on the same circuit board good enough? And would you still give the same answer if you shrink that Linux PC to the size of a Linux phone?
The wikipedia article on firmware (http://en.wikipedia.org/wiki/Firmware) recognizes how vague the term "firmware" is and says that as of 2010, "The concept of "firmware" has evolved to mean almost any programmable content of a hardware device, not only machine code for a processor, but also configurations and data for application-specific integrated circuits (ASICs), programmable logic devices, etc."
In other words, the Linux system on my Nokia N900 or my DSL modem can be called firmware now just as much as the configuration parameters loaded into my TV tuner chip or the microcode for my processor. Firmware and software are blending together and are really becoming the same thing. It is hard to find ANY chips nowadays that have true ROM storage, flash has largely displaced the use of ROM and thus the software in most devices has become changeable. The FSF seems to use an old notion that if something is stored in a chip, it is fixed and not their concern, but if it is on a hard drive, it is important to them. That notion is outdated as we speak, with so much of our systems, both big and small, converging toward flash storage. They seem to have recognized this change as it applies to the PC BIOS, I hope they will recognize the other changes that are happening too.
131 • @129 (by Patrick on 2010-06-18 20:19:03 GMT from United States)
"""You feel like the free software user's ideology is being violated, because they think they are free of non-free firmware and they are not.
[...]
But then you don't care to use hardware which requires non-free binaries to run"""
The intended target of this article and discussion was neither you nor me.
I know I need some proprietary stuff to run on my system to get the functionality I need, sad but true. I also know that if I installed a "totally free" (as in the FSF definition) OS, I'd lose functionality, and I'd STILL have proprietary stuff running on my system. So I have to accept proprietary stuff, because I know it is not possible for me to have a totally free system at this point in time. I am like a person who likes the concept of being vegetarian to avoid hurting animals but knows I cannot buy food that is completely devoid of animal products and still get the nutrition I need. So I live with that and eat the meat of the cow that also provided the gelatin for the cake I was eating already anyway.
You seem to know and understand you have proprietary firmware running in your hardware, and you are fine with that, but you will not accept anything non-free if it is loaded from your hard drive. That is fine, you have made up your mind based on solid information. You're like the guy who eats the TV dinner with turkey gravy. You are aware of what is going on, and you choose not to eat meat, but accept the gravy. And note I'm not judging that stance: one might imagine less turkeys need to be slaughtered and that could be considered a noble thing.
This article was intended to inform the people who thought that if they'd install a "totally free" OS, they'd have no non-free code running on their system. They're like the vegetarians who thought they would never ingest any animal products, no animal was going to die because they needed to eat. I wanted to tell them that at this point that was only a "best effort" policy, with the current state of the food market (read: electronics market) making such an ideal as good as impossible. I wanted them to know that sadly, even if they were only eating Jello and no meat, that still required animals to die.
The article was also intended for the FSF, to make sure they understand there is a lot of confusion around non-free firmware loaded into devices by the kernel, and that calling everything a "binary blob" is unnecessarily muddying the waters. I wish they'd make clear to their user base that even with a "totally free OS", there will likely be non-free stuff running on their system, and they're just making sure they're not "accomplices" in the crime by loading the nasty stuff into a device. It's like encouraging the Vegetarian Association to make sure their members know they are still going to be eating some animal products with the current state of the market, in my illustration.
"""I'm starting to think you just like to argue. (I do too, BTW ;)"""
Maybe you're right. :P
"""I'm guessing your advice to a vegetarian would be: "You can't know if the cake we have for dessert has animal gelatin anyway, so eat your meatballs"."""
No, not at all, and I'm sorry if I came across that way. My advice to the vegetarian would be: "Sure you can have this cake, but be aware it has animal gelatin in it. You still want to eat it? All right, but don't complain about me eating my meatballs then." :)
132 • debate (by david on 2010-06-18 21:00:09 GMT from United States)
@ Patrick and Ruben. - NERDS!!!! and I was a geek. Ummm! Meatballs are good, Jello is good.
133 • **sigh** (by Billy Bob on 2010-06-18 21:23:10 GMT from United States)
Why is it that the "carnivores" are willing to let the "vegetarians" be vegetarians, but many/most/all(?) of the "vegetarians" try to convert the "carnivores" to a non-meat existance?"
134 • Numbers (by fernbap on 2010-06-18 22:29:36 GMT from Portugal)
Sorry for being offtopic, but i thought you would like me to share these numbers.
I just upgraded my websites hit counter (it still didn't recognized windows 7, so not sure if it was counted as Vista or not).
All websites show similar numbers, and that's why i think the "Linux on the desktop 1%" is indeed a hoax. The numbers regard the website's visitors for the last 2 years roughly.
Operating systems:
Windows XP - 55.44%
Windows Vista - 12.95%
Mac OSX - 6.77%
"Other" - 6.09%
Windows NT - 3.57%
"Linux" - 3.54%
Ubuntu - 3.54%
...
Debian - 0.78%
windows 98 - 0.39%
Fedora - 0.30%
Suse - 0.28%
...
PCLinuxOS - 0.12%
....
Gentoo - 0.08%
FreeBSD - 0.05
The data regarding browsers is also overwhelming:
Firefox - 53.53%
Explorer - 25.73%
Safari - 7.00%
Opera - 4.49%
Take these numbers for what they're worth. However, they are completely incompatible with the "Linux on the desktop is 1%" hoax.
135 • About the feature article... (by Kenneth Malac on 2010-06-18 23:39:28 GMT from United States)
Your statement of Debian being 100% free is wrong...
The linux kernel contains proprietary "blobs" of code inside of it so therefore it is proprietary itself. The linux-libre project makes a version of the kernel that removes these blobs. http://www.fsfla.org/svnwiki/selibre/linux-libre/
136 • @129 (by Rubén Rodríguez on 2010-06-19 00:29:35 GMT from Spain)
"If you look through some of the information on the Busybox lawsuits, they cover devices ranging from Blu Ray players to HDTV's to network routers, DSL modems,"
For this discussion to have some sense we will have to explicitly define what firmware is. I don't care if the vendors of everything which is not a PC call the OS "firmware" because it is written in a flash disk instead of a spinning one. Firmware is a piece of software required for a processor to make it work, not a program run by that processor itself -I apologize for using such a broad definition before-. Linux+Busybox is run on top of a -usually arm- processor that -AFAIK- needs no firmware to work.
"let's say I make a peripheral with an FPGA on it, and the only "source" I have is a circuit diagram in a proprietary format, created by the FPGA manufacturer's proprietary tool, that happens to be the only tool to support the chip. Would availability of this source be valid?"
Yes. From the GPL FAQ: Which programs you used to edit the source code, or to compile it, or study it, or record it, usually makes no difference for issues concerning the licensing of that source code.
The fact of the source code being hard to understand isn't really a problem, you can be a lousy programmer, or be developing a very weird platform. The requisite is that you provide the _real_ source code, not one made from the compiled results. Also, code obscured on purpose would not be OK.
"there are some chips that just require a bunch of configuration bits for various registers to be loaded. Would this be considered "non-free firmware"? There really is no other "source" than the tables of numbers. Would they be considered the source?"
No, initialization values are not software. Some documentation about what the values do is good to have, but not required.
About your vegan/gravy comparison, it just doesn't match the problem. I can go to a store, buy just pieces of hardware, build a PC, throw the cd drivers away and install a 100% free distro on it, and it will work. I can do my computing without the need to get myself a copy of a non-free piece of software. That is indeed an achievement for the user freedom regarding to software. I just need to be aware not to buy certain components, or I'll need to get myself a copy of the non-free firmware and load it in my computer. You can't ignore the difference between those two scenarios.
Yes, almost any computer I can buy will come with modifiable non-free firmware in the bios... but not me nor the FSF is ignoring that! Thats why they support the coreboot project, to replace those bioses with free software too. The fact that they support non-free distros doesn't mean they close their eyes to the problem with the bios, they just recognize what free distros can do: allow you to run your computer without getting a single piece of proprietary software.
The only loose piece you might point then is non-modifiable, embedded firmware. That's the only piece of software the FSF actually says it doesn't matter, because if you think of firmware using the definition above, it is just a piece of hardware made in an abstract way. The final user can't know if it is even there: I know the Intel graphic cards have a firmware burned inside because an AMD engineer told me so. But if I had one Intel card with firmware and one made with wired logic they would work exactly the same for me, using my fully free distro.
And now about myself as an user, the only compromise I can make regarding my freedom is to use a computer with a non-free bios. I bought my laptop, got it out of the box, removed windows and installed a free distro, so I needed to provide no proprietary software myself to run it. But I'm aware that I could not modify the bios if I wanted, so I'll move to a coreboot powered machine ASAP.
Funny story -not really-, but I needed to replace the Intel wireless card which came with the laptop and install an atheros card to be able to use my free distro. The thing is, the bios checks if the card's pciid is in a "approved hardware" list or it doesn't work. So, I'm very aware that the non-free bios is getting in the way of my freedom. (But the firmware inside the graphic card isn't).
137 • Numbers (by Jesse on 2010-06-19 00:30:04 GMT from Canada)
@134:
What sort of website is it? I'm curious because the number of users of a given OS/browser tends to change a little depending on the focus of the website.
Also, is there an "other" web browser column? Unless I forgot to carry the "1", the browsers listed provide 90% of the traffic.
138 • @134 (by Rubén Rodríguez on 2010-06-19 00:37:52 GMT from Spain)
I don't know what your page is about, but there is no need for it to be about floss, If it is IT related then the stats are biased in some direction. But I have some reports -from 2007 IIRC- that would back that 3% you have.
My stats show a 64% of GNU/Linux users... :)
139 • what-next-ware (by merlin on 2010-06-19 00:45:25 GMT from Canada)
Well one thing is perfectly clear to me now... nothing is perfectly clear to me any more.
Early computers = single cell organism, simple and self-contained.
Modern computers = multi-cell organism, complex, distributed, can function even if some of the appendages are cut off, but can't function without the brain (CPU)
140 • @137, 138 (by fernbap on 2010-06-19 01:08:24 GMT from Portugal)
All my websites are about web design or related issues. This is the website of an open source PHP CMS i wrote.
Yes, it's a bit IT related, but neither of my websites are about Linux (or any other OS), and all of them show similar results.
The only surprising number is that of OSX, perhaps mac users are not so many after all. However, it shows that Steve Ballmer was right after all when he said that Linux userbase had surpassed Apple, about 2 years ago.
Just checked, windows 7 appears as Windows Media Center - 1.29% (not surprisingly, as 7 appeared only recently).
But my point is that everyone i know that has websites show similar results to those. Hardly compatible with the 1% "official number".
As to browsers, next are
"other" - 3.32%
Mozilla - 2.87%
Netscape - 0.58%
SeaMonkey - 0.37%
etc.
"My stats show a 64% of GNU/Linux users... :)"
Lol, i have no doubt on that
So, where does that 1% come from?
141 • @136 (by Patrick on 2010-06-19 04:35:15 GMT from United States)
"""Firmware is a piece of software required for a processor to make it work, not a program run by that processor itself -I apologize for using such a broad definition before-. Linux+Busybox is run on top of a -usually arm- processor that -AFAIK- needs no firmware to work."""
Yikes. What you are defining here seems to be microcode, not firmware. I don't think you'd find any people in the trade that would accept that definition of firmware. Firmware IS most of the time a program run by the processor itself. Code running on peripheral processors is what the article is about anyway, whatever you want to call it. The normal thing to call it is firmware.
"""I can do my computing without the need to get myself a copy of a non-free piece of software."""
I am getting tired of repeating myself, so I'll say one last time: you did get a copy of a non-free piece of software, and it is running in your computer. Inside your hard drive, your network card, your wifi-card, etc. It was there when you bought it.
I do not understand the fixation of the FSF and their adherents with the "getting", the "loading", the "storage" of software in determining if it matters if software is free or not, while apparently totally ignoring the "executing" of non-free software. Software means nothing, does nothing, IS nothing, unless it is being executed by a CPU. Only while it is being executed can it do anything, and have any effect whatsoever on your computer system and any freedom associated with it. Yet, running non-free software seems to be perfectly fine for the FSF, as long as it's already there and you don't need to load it.
Makes me wonder: if the FSF were computer-illiterates like the majority of people, they would probably be perfectly fine with running a pre-loaded Windows... but when it broke, you wouldn't be allowed to reload it. ;)
142 • @140 (by Patrick on 2010-06-19 04:46:40 GMT from United States)
My website, not aimed at technical users at all, gets:
83.2% Windows
9.6% Mac
3.4% Linux
3.8% other and unknown
I get a few hits from this site (which would contain a higher than average number of Linux users), but still, I think >3% Linux hits for a non-technical/IT/Linux site is way better than the 1% we keep hearing.
143 • @136 (by Rubén Rodríguez on 2010-06-19 11:38:06 GMT from Spain)
"Yikes. What you are defining here seems to be microcode, not firmware. I don't think you'd find any people in the trade that would accept that definition of firmware. Firmware IS most of the time a program run by the processor itself. Code running on peripheral processors is what the article is about anyway, whatever you want to call it. The normal thing to call it is firmware."
Well, then we have a problem! Because the Linux and Linux-Libre developers, the FSF and the free distro's people use those two words as synonyms. You can also look at places like the OpenFWWF project -a free replacement for the Broadcom b43 non-free blob- and see how they call it microcode or firmware: http://www.ing.unibs.it/openfwwf/specification.php Or the Intel blob download page: http://intellinuxwireless.org/?n=downloads
And so on.
That's why I said the code in TiVo isn't firmware but an OS instead, and that's why the FSF says it doesn't matter if it is inaccessibly embedded, because it might as well be hardware.
That being said, I think you made a point by telling that "firmware" has nowadays a broader meaning like "software stored in a flash", while "microcode" retains the meaning "firmware" had in the old days. Maybe they aren't synonyms anymore, so I think I'll call the binary blobs "microcode" from now on.
Using that definition, the FSF does only not care about inaccessible microcode. Everything else must provide the 4 freedoms.
About the rest of your comment, the test for a blob not to be an issue is not just "it is inaccessible". It needs to be inaccessible and replaceable with wired logic -so, indistinguishable from hardware-. And I'm also getting tired of saying that ;)
144 • GPL freedom, what? (by Belanger on 2010-06-19 13:24:57 GMT from Canada)
The fact of the matter is that for the vast majority of us, the GPL does not offer as much freedom as the FSF would like it to. Freedoms 1 and 3 don't do much for us non-programmers. I feel the GPL offers the most freedom to programmers, and it was probably conceived in that light too. I think everything has to be put in it's context.
I used to be a programmer many years ago, but my programming skills are long diminished and were in a 4GL language that would never be used in OSS. I can open up a program and sometimes even have an inkling of how it works, but without weeks or months of study, there's just not a heck of a lot I can do to it. Sure, I can report bugs and make feature requests, but guess what? I've submitted several of each over the past few years and none of them have been fixed or implemented!
If you're going to toe the FSF party line 100%, then I can see that it's beneficial to be a programmer. But for me, I'll take the binary blobs, microcode and firmware - kernel loaded, embedded, baked or fried, because I want my computer to actually work - right now. Having said that, I do see the benefit of my distro using open source components where possible, because I'm sure some of the bugs and feature requests would be addressed, even if they're not from me. And to support that angle, I don't have any hardware that violates the current FSF stance on proprietary blobs. But after reading Patrick's article and comments, I wouldn't feel *as* dirty if I did. For me, and many others like me, the decision to run Linux was based on factors other than it was free as in freedom.
145 • Hard Drives (by Anonymous on 2010-06-19 15:53:46 GMT from United States)
Correct me if I am wrong, but;
The micro-code or firmware on the purchased hard drive only executes on the hard drives controller card, not on your computers cpu.
The code never leaves the drive and you normally never see any of it, only the effects of its' operation/executing.
This is true for many computer peripherals.
The bios however is in fact executed by the computer's cpu.
Does this help?
146 • RE:144 (by Anonymous on 2010-06-19 16:00:50 GMT from United States)
Copied from:
http://www.gnu.org/philosophy/free-sw.html
* The freedom to run the program, for any purpose (freedom 0).
* The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
* The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
147 • Numbers (by Tom on 2010-06-19 20:36:05 GMT from United Kingdom)
Those hit counters stats are really good to see but it hardly suggests that linux has reached saturation point, nor does it show that Windows dominance (of the subset of a subset of the IT industry market) is over.
Regards from Tom :)
148 • Binary firmware and your (lack of) freedom (by Lobo Mau on 2010-06-19 23:07:46 GMT from Brazil)
-
"Now I do realize that it would be possible for manufacturers to make the source code of the firmware for their devices available, even if the kernel would have to include the firmware in binary form due to compiler limitations."
Better yet: We consumers should realize that all decent manufacturers always disclose their hardware specs in order to enable programmers to make solid (open-source) device drivers. And I think we have the moral duty to boycott each and every nasty manufacturer which just keeps their hardware specs fully closed, not allowing anyone to squash bugs in their sucky (closed-source) device drivers.
-
"I want to make this very clear: the opinion expressed in this article only relates to binary firmware executing in the peripheral device, not to binary drivers that are loaded as kernel modules by the Linux kernel and execute within the kernel. Binary kernel modules present major issues that are completely different from those presented by binary firmware."
It seems to me there's a big difference between firmware inside a piece of hardware and firmware inside a kernel module. For instance, who would dare to complain of a highly efficient external modem just because it has a proprietary firmware built-in? (The own motherboard BIOS clearly shows how we depend on closed-source firmware.) In contrast, what OpenBSD user would feel comfortable using a proprietary kernel module? (Apparently the same situation, but quite an opposite point-of-view.)
-
"The next best case is either a device that has its firmware built-in or that takes a binary firmware file from the kernel, and the manufacturer allows the firmware to be distributed with the Linux kernel. This is the case the FSF makes a big deal about, promoting the built-in firmware implementation as "free" and labeling the loaded-from-the-kernel implementation "incompatible with free software". As explained above, in practice it makes no difference to our freedom and is just a minor implementation detail. In either implementation, we don't have access to the source."
FSF made no senseless statement, IMO. Just consider the Linux kernel as being an immaculate vestal virgin devoted to serve the gods. Would they accept a "polluted" gift? Nooooooo... Gods are exigent!
Thus FSF is right: Free software in the form of a binary blob loaded as a kernel module is incompatible with freedom because it suppresses the power to examine/modify source code, while free software in the form of built-in firmware (no matter whether a binary blob or not) is acceptable because it's nothing more than a local means of implementing hardware functions (i.e., it doesn't mess with the kernel).
-
"I suggest that instead of these scapegoat tactics and acting as if they solve any real issue, efforts should be focused on encouraging manufacturers to publish open specifications for their chips and open the source code for their firmware, whether it lives inside the hardware or gets loaded by the kernel."
I partially agree. BTW, refusing to buy their products is the most effective providence to make them understand that Linuxers are not suckers. Sooner or later, all those nasty Linux kernel modules with closed-source firmware would magically turn into open-source, fully scrutinizable code.
Either way, it's sad we are once again wasting time, discussing cheap philosophy instead of focusing on the really hot stuff: how to defeat Microsoft in the desktop arena.
-
"And let's commend those manufacturers that allow their binary firmware to be conveniently distributed with the Linux kernel instead of punishing them by blacklisting their devices. That could be a first step toward improved communication with hardware manufacturers, which in turn might make truly free firmware more likely in the future."
I'd like Mr. Van Oosterwijck was right, but I'm pretty sure he isn't. Just THINK: When a hardware manufacturer wants to help the *nix community, it promptly releases specs. It doesn't delay to collaborate with us. Only evil companies eventually do their homework some day in a very distant future.
But there are plenty of well supported devices made by good manufacturers. So don't be fool enough to buy any badly supported piece of crap. The rule of thumb is: If you need a binary blob from the Linux kernel, then you bought the wrong hardware.
This is a tip to newcomers who wanna build a new PC: Choose your distro first. Home-build the new PC using hardware devices at least two years old (to garantee reasonably mature drivers). Support freedom-friendly products ONLY, and just forget everything Mr. Van Oosterwijck told us. He simply tried to convince us that a "closed" manufacturer (such as NVIDIA) can become an "open" manufacturer (such as ATI) if we buy their freedom-unfriendly hardware.
Hey Caitlyn, you've found a real comedian writing articles for Distrowatch. Start laughing: Har! Har! Har!
-
149 • Numbers @147 (by fernbap on 2010-06-19 23:15:09 GMT from Portugal)
Perhaps we could speculate a little about "windows dominance".
XP is still more than half of the installed windows, as all numbers indicate. A windows version that was replaced by its successor (Vista) 8 years ago.
Worldwide, much more than half of all XP desktops run on pirated copies of windows ("the best long term marketing strategy", according to Steve ballmer).
What is important is how M$ is selling today, and although 7 seems to be doing OK, it is very far from dominating the market.
The map or "present sells" would show a very different picture. And there is no doubt that Linux is the only one that is on the rise.
150 • still about peripheral firmware (by forlin on 2010-06-20 04:33:52 GMT from Portugal)
"efforts should be focused on encouraging manufacturers to publish open specifications for their chips and open the source code for their firmware"
I agree and I think this is still more relevant in those cases where the firmware needs some sort of implementation inside the kernel. The reason is because that does represent an overhead to the system usage. Even that it may not be high today for known hardware, we never know what that overhead will be in the future. That said, the developers should have the freedom to adapt the firmware to their distro, in the same way as they do with the kernel and all other free software.
151 • @143 (by Patrick on 2010-06-20 04:36:46 GMT from United States)
I'm going to leave the "firmware" term issues alone. All that matters is that we establish that I wrote the article with the term "firmware" referring to software code running on a peripheral processor, not your main PC processor.
"""About the rest of your comment, the test for a blob not to be an issue is not just "it is inaccessible". It needs to be inaccessible and replaceable with wired logic -so, indistinguishable from hardware-. And I'm also getting tired of saying that ;)"""
Ok, I thought I was finally getting my head wrapped around the FSF reasoning related to not caring about non-free if it is inaccessible, but it seems I'm not. :)
"Replaceable with wired logic and indistinguishable from hardware" is a requirement that is pretty much always met. Any system running software can be replaced with pure hardware. It is just a matter of complexity. Any system running software can also be thought of as being pure hardware at some level of abstraction (there is nothing magical about a microprocessor or the code it's running--it is all just a giant state machine). The separation between hardware and software is only an abstraction so we can wrap our minds around it. Or is that requirement again just based on the distinction of something being "loaded" externally? If so, please be aware that hardware (connections) can also be "loaded" from and external source in case of an FPGA. I do not understand how this requirement could possibly be established in a consistent manner.
But anyway, from a practical point of view: software in peripheral devices is getting more complex every day, and taking into account the generally accepted separation between hardware and software, I think a lot of software in devices could not practically be replaced with wired logic, without the use of what we know as software. I'm thinking about the software running on hard drive controllers for instance, some of that stuff is incredibly complex and I doubt anyone could build a terabyte level hard drive with "wiring".
For the accessibility and changeability issue. I was thinking that if this was what made the key difference for the FSF to determine if they consider it their business to make it free or not (which seems to be the case both from the kernel loaded firmware issue and the BIOS issue), then the next couple of years may turn out to be very interesting. As was brought out, they're already considering the BIOS to be an issue, now it has become possible to change and update it. Someone else brought out that some hard drives now make it possible to update their firmware. Between the complexity of the hard drive system resulting in the practical need for firmware to run in the hard drive controller (i.e. not being able to replace it with simple wiring), and the ability for this firmware to be updated, there should soon appear some hard drives on the list of non-free devices. That is, if the FSF is going to apply its rules consistently.
In fact, more and more devices should start to appear on its black list of non-free devices. ROM is going the way of the dinosaur, being replaced by flash. Since flash makes it possible to update firmware, more and more manufacturers are going to make use of this possibility. With devices getting more complex every day, many of them could not possibly be conceived with "wiring" without software involvement in practice.
I am very curious how the FSF is going to handle these, and I really hope it is going to be a fair and consistent policy. Interesting times ahead. :)
152 • @148 (by Patrick on 2010-06-20 04:51:41 GMT from United States)
"""It seems to me there's a big difference between firmware inside a piece of hardware and firmware inside a kernel module. For instance, who would dare to complain of a highly efficient external modem just because it has a proprietary firmware built-in? (The own motherboard BIOS clearly shows how we depend on closed-source firmware.) In contrast, what OpenBSD user would feel comfortable using a proprietary kernel module? (Apparently the same situation, but quite an opposite point-of-view.)
[...]
...free software in the form of built-in firmware (no matter whether a binary blob or not) is acceptable because it's nothing more than a local means of implementing hardware functions (i.e., it doesn't mess with the kernel).
[...]
He simply tried to convince us that a "closed" manufacturer (such as NVIDIA) can become an "open" manufacturer (such as ATI) if we buy their freedom-unfriendly hardware.
"""
Hmm. The above comments make me think you really don't understand what I'm talking about here. The difference between binary firmware and a binary in-kernel driver seems to escape so many people, and I don't seem to know how to make it more clear.
"""Support freedom-friendly products ONLY, and just forget everything Mr. Van Oosterwijck told us."""
*lol* Honestly, that opinion would carry much more weight if you wouldn't have shown so clearly that you don't understand what I'm talking about. Please, try to understand what I'm saying before you tell people to ignore me.
"""Hey Caitlyn, you've found a real comedian writing articles for Distrowatch. Start laughing: Har! Har! Har!"""
And what exactly does Caitlyn have to do with this? :)
153 • Re: 151 (by jake on 2010-06-20 05:54:45 GMT from United States)
"Any system running software can also be thought of as being pure hardware at some level of abstraction (there is nothing magical about a microprocessor or the code it's running--it is all just a giant state machine). The separation between hardware and software is only an abstraction so we can wrap our minds around it."
Exactly. Kinda my point all along, no?
"Or is that requirement again just based on the distinction of something being "loaded" externally?"
Define "externally". I suspect this is a way to narrow this down ...
"If so, please be aware that hardware (connections) can also be "loaded" from and external source in case of an FPGA."
Why the hang-up on field programmable gate arrays? Shirly ASICs are more inline with this particular conversation?
"I do not understand how this requirement could possibly be established in a consistent manner."
The devil is in the details ...
154 • @148 - Two years old stuff (by meanpt on 2010-06-20 11:31:01 GMT from Portugal)
"This is a tip to newcomers who wanna build a new PC: Choose your distro first. Home-build the new PC using hardware devices at least two years old (to garantee reasonably mature drivers). Support freedom-friendly products ONLY, and just forget everything Mr. Van Oosterwijck told us. He simply tried to convince us that a "closed" manufacturer (such as NVIDIA) can become an "open" manufacturer (such as ATI) if we buy their freedom-unfriendly hardware."
Buying 2 years old stuff it's not a free option and lacks strategic sense. We all know applications are getting heavier and if you buy old stuff you may be investing in already dead crap. That's the kind of things that doesn't suit linuxers but the either the lovers of old crap, either those who can afford to buy a new system every two years cause even linux may not be that forgiveable with older metal.
Regarding this:
"Hey Caitlyn, you've found a real comedian writing articles for Distrowatch. Start laughing: Har! Har! Har!"
Well, that's the kind of stuff where the lack of reasonable arguments is revealed. and hopefully it wont make its way to the current FSF freedoms. Frankly speaking, this wasn't needed.
155 • @153 (by Patrick on 2010-06-20 18:45:51 GMT from United States)
""""Why the hang-up on field programmable gate arrays? Shirly ASICs are more inline with this particular conversation?"""
I'm just bringing up FPGA's because SRAM FPGA's produce a hardware circuit defined by an external bitstream. This might result in an interesting case for the FSF policy. The bitstream can not be viewed as software, because there is no code being executed, the bitstream just configures hardware connections. At the same, the chip is not stand-alone and needs to have this bitstream loaded from an external source. I wonder how this would be viewed in case the configuration was loaded from the kernel.
ASIC's are not of much interest in this discussion, since they can be purely hardware and as such not of much concern when it relates to free software.
156 • Re: 155 (by jake on 2010-06-21 01:01:37 GMT from United States)
I've been out of the embedded systems and computer peripheral design game for a few years now, I hadn't realized that the line between FPGAs, ASICs, PALs, CPLDs and the like had blurred as much as it has. Thanks for the heads-up, and a good "read up on modern techie stuff" this Father's day. :-)
"The bitstream can not be viewed as software"
Correct. The bitstream is data. A system that manipulates the data is code.
"I wonder how this would be viewed in case the configuration was loaded from the kernel."
Why put it in the kernel? It's not a driver, it's data for setting up a very specific piece of hardware. Data that can change between hardware revisions. Instead, put it in NVRAM ((E)EPROM, whatever) onboard the hardware device.
"ASIC's are not of much interest in this discussion, since they can be purely hardware and as such not of much concern when it relates to free software."
Totally disagree. For example, I re-programmed the engine-control chips in the sports cars & the tow rigs (for speed and economy, respectively). The engine control modules are ASICs. Do most people dive that deep into their hardware? No ... But it can be, and is being done.
157 • @156 (by Patrick on 2010-06-21 04:30:18 GMT from United States)
""""I wonder how this would be viewed in case the configuration was loaded from the kernel."
Why put it in the kernel? It's not a driver, it's data for setting up a very specific piece of hardware. Data that can change between hardware revisions. Instead, put it in NVRAM ((E)EPROM, whatever) onboard the hardware device."""
Why? Cost savings of course! Getting an EEPROM off the board can save a lot of money in high volumes. In fact, at work I'm involved in a project right now to do just that and save half a million dollars a year (this is an appliance though, not a PC peripheral, so it has nothing to do with the article). You can call it greed, but being in the middle of it during tough economic times, I call it "making sure no one else will get laid off".
And no, it is not a driver, it does not run in the kernel, it's just loaded into the device by the kernel. The kernel gives the device the bytes that would otherwise be stored in the EEPROM. Because it is loaded by a driver though, it is okay that it is data for a very specific piece of hardware, because the driver is written for a very specific piece of hardware too. This loading of config data and/or firmware by the kernel into a peripheral device is the subject of the article and should not be mistaken for the driver actually running in the kernel.
""""ASIC's are not of much interest in this discussion, since they can be purely hardware and as such not of much concern when it relates to free software."
Totally disagree. For example, I re-programmed the engine-control chips in the sports cars & the tow rigs (for speed and economy, respectively). The engine control modules are ASICs. Do most people dive that deep into their hardware? No ... But it can be, and is being done."""
I wrote: "can be purely hardware". :) You are correct that some ASIC's can also run software, depends on application and implementation. All I was trying to say that ASIC or general purpose chip doesn't make much difference for this discussion. There exist both ASIC's and general purpose IC's that run no software and are just hardwired circuitry. There are also ASIC's and general purpose IC's that do run software. The "Application Specific" part of the name does not imply anything about running software or not. I was just contrasting this with FPGA's where there is always some configuration that needs to be loaded, usually from an external source (though there are flash FPGA's too). And the FPGA can implement or contain a microprocessor that needs code also, but it is the configuration data that makes it a sort of special case, as opposed to general purpose IC's and ASIC's.
158 • Re: 157 (by jake on 2010-06-21 05:04:23 GMT from United States)
"Getting an EEPROM off the board can save a lot of money in high volumes."
False economy. True, the hardware costs drop ... but the total cost of the package go up when playing the politics to get the data-loader into the kernel, and then keep it there.
"I call it "making sure no one else will get laid off""
Why? It's a business, isn't it? LAY 'EM OFF, FFS! If you can throw a couple bucks/unit at the hardware to get rid of a couple-five designer/coders, a program manager, and a couple of middle managers (if you're unfortunately in the kind of corporation where middle management exists to keep itself employed) THERE is your true cost savings ... and if you have a good product, your consumers won't even notice the sub-1% rise in the cost of the product's hardware.
Good original DWW article, Patrick ... and good, entertaining commentary from the punters, too ... Come back with another article soon :-)
159 • Patrick & everyone at DW (by Tom on 2010-06-21 08:35:17 GMT from United Kingdom)
Thanks for another excellent week at DistroWatch. An excellent and very provocative article!! Thanks everyone that put in another good week's work here :)
It is good to see these issues being discussed! I just wish we could all manage to do this a little more calmly and logically but then where would the energy come from? I now feel a lot less clueless about all this than i was before although mostly that is an awareness of complexities beyond my current reach. Good to know! :)
Patrick deserves our thanks for putting himself in the firing-line and responding so well to comments even tho they often seemed to be a bit too personal and lacking in substance.
I hope everyone had a good weekend and has a good week ahead :)
Good luck and regards from Tom :)
Number of Comments: 158
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
| • Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
| • Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
| • Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
| • Issue 1065 (2024-04-08): Dr.Parted Live 24.03, answering questions about the xz exploit, Linux Mint to ship HWE kernel, AlmaLinux patches flaw ahead of upstream Red Hat, Calculate changes release model |
| • Issue 1064 (2024-04-01): NixOS 23.11, the status of Hurd, liblzma compromised upstream, FreeBSD Foundation focuses on improving wireless networking, Ubuntu Pro offers 12 years of support |
| • Issue 1063 (2024-03-25): Redcore Linux 2401, how slowly can a rolling release update, Debian starts new Project Leader election, Red Hat creating new NVIDIA driver, Snap store hit with more malware |
| • Issue 1062 (2024-03-18): KDE neon 20240304, changing file permissions, Canonical turns 20, Pop!_OS creates new software centre, openSUSE packages Plasma 6 |
| • Issue 1061 (2024-03-11): Using a PinePhone as a workstation, restarting background services on a schedule, NixBSD ports Nix to FreeBSD, Fedora packaging COSMIC, postmarketOS to adopt systemd, Linux Mint replacing HexChat |
| • Issue 1060 (2024-03-04): AV Linux MX-23.1, bootstrapping a network connection, key OpenBSD features, Qubes certifies new hardware, LXQt and Plasma migrate to Qt 6 |
| • Issue 1059 (2024-02-26): Warp Terminal, navigating manual pages, malware found in the Snap store, Red Hat considering CPU requirement update, UBports organizes ongoing work |
| • Issue 1058 (2024-02-19): Drauger OS 7.6, how much disk space to allocate, System76 prepares to launch COSMIC desktop, UBports changes its version scheme, TrueNAS to offer faster deduplication |
| • Issue 1057 (2024-02-12): Adelie Linux 1.0 Beta, rolling release vs fixed for a smoother experience, Debian working on 2038 bug, elementary OS to split applications from base system updates, Fedora announces Atomic Desktops |
| • Issue 1056 (2024-02-05): wattOS R13, the various write speeds of ISO writing tools, DSL returns, Mint faces Wayland challenges, HardenedBSD blocks foreign USB devices, Gentoo publishes new repository, Linux distros patch glibc flaw |
| • Issue 1055 (2024-01-29): CNIX OS 231204, distributions patching packages the most, Gentoo team presents ongoing work, UBports introduces connectivity and battery improvements, interview with Haiku developer |
| • Issue 1054 (2024-01-22): Solus 4.5, comparing dd and cp when writing ISO files, openSUSE plans new major Leap version, XeroLinux shutting down, HardenedBSD changes its build schedule |
| • Issue 1053 (2024-01-15): Linux AI voice assistants, some distributions running hotter than others, UBports talks about coming changes, Qubes certifies StarBook laptops, Asahi Linux improves energy savings |
| • Issue 1052 (2024-01-08): OpenMandriva Lx 5.0, keeping shell commands running when theterminal closes, Mint upgrades Edge kernel, Vanilla OS plans big changes, Canonical working to make Snap more cross-platform |
| • Issue 1051 (2024-01-01): Favourite distros of 2023, reloading shell settings, Asahi Linux releases Fedora remix, Gentoo offers binary packages, openSUSE provides full disk encryption |
| • Issue 1050 (2023-12-18): rlxos 2023.11, renaming files and opening terminal windows in specific directories, TrueNAS publishes ZFS fixes, Debian publishes delayed install media, Haiku polishes desktop experience |
| • Issue 1049 (2023-12-11): Lernstick 12, alternatives to WINE, openSUSE updates its branding, Mint unveils new features, Lubuntu team plans for 24.04 |
| • Issue 1048 (2023-12-04): openSUSE MicroOS, the transition from X11 to Wayland, Red Hat phasing out X11 packages, UBports making mobile development easier |
| • Issue 1047 (2023-11-27): GhostBSD 23.10.1, Why Linux uses swap when memory is free, Ubuntu Budgie may benefit from Wayland work in Xfce, early issues with FreeBSD 14.0 |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • Issue 1045 (2023-11-13): Fedora 39, how to trust software packages, ReactOS booting with UEFI, elementary OS plans to default to Wayland, Mir gaining ability to split work across video cards |
| • Issue 1044 (2023-11-06): Porteus 5.01, disabling IPv6, applications unique to a Linux distro, Linux merges bcachefs, OpenELA makes source packages available |
| • Issue 1043 (2023-10-30): Murena Two with privacy switches, where old files go when packages are updated, UBports on Volla phones, Mint testing Cinnamon on Wayland, Peppermint releases ARM build |
| • Issue 1042 (2023-10-23): Ubuntu Cinnamon compared with Linux Mint, extending battery life on Linux, Debian resumes /usr merge, Canonical publishes fixed install media |
| • Issue 1041 (2023-10-16): FydeOS 17.0, Dr.Parted 23.09, changing UIDs, Fedora partners with Slimbook, GNOME phasing out X11 sessions, Ubuntu revokes 23.10 install media |
| • Issue 1040 (2023-10-09): CROWZ 5.0, changing the location of default directories, Linux Mint updates its Edge edition, Murena crowdfunding new privacy phone, Debian publishes new install media |
| • Issue 1039 (2023-10-02): Zenwalk Current, finding the duration of media files, Peppermint OS tries out new edition, COSMIC gains new features, Canonical reports on security incident in Snap store |
| • Issue 1038 (2023-09-25): Mageia 9, trouble-shooting launchers, running desktop Linux in the cloud, New documentation for Nix, Linux phasing out ReiserFS, GNU celebrates 40 years |
| • Issue 1037 (2023-09-18): Bodhi Linux 7.0.0, finding specific distros and unified package managemnt, Zevenet replaced by two new forks, openSUSE introduces Slowroll branch, Fedora considering dropping Plasma X11 session |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Random Distribution | 
Rocky Linux
Rocky Linux is a community enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux. It is available for the x86_64 and AArch64 processor architectures.
Status: Active
|
| Tips, Tricks, Q&As | | Tips and tricks: What being free, stable and light-weight mean |
| Tips and tricks: Simple rsync examples |
| Questions and answers: Clarifying how init and service managers work together |
| Tips and tricks: More utilities via moreutils |
| Tips and tricks: How to check the licenses of kernel modules |
| Tips and tricks: Command line weather, ionice, rename files, video preview snapshot, calednar, ls colour settings |
| Questions and answers: AppArmor, home movies, tabs in Vim, syntax highlighting |
| Questions and answers: Display log files in reverse order |
| Questions and answers: Adjusting system swappiness |
| Tips and tricks: A safer way to use dd |
| More Tips & Tricks and Questions & Answers |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
0x969CD4E778C7b6549A2B00e34114e0168c86A542 
