Re: on firmware (possible proposal)
On Sat, Nov 15, 2008 at 04:39:04PM +, Stephen Gran wrote: This one time, at band camp, Robert Millan said: If we get closer to the free side, and provide a 100% free main like we used to, When precisely was that? Yeah, it's funny. We never did. Let us say, like we used to promise we would. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
This one time, at band camp, Robert Millan said: On Sat, Nov 15, 2008 at 04:32:08PM +, Stephen Gran wrote: It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. Of course you can. Adding paranoid fantasies to the debate doesn't really help much. Can you? Would you explain how? (and no, I run wireshark in my gateway and dig through several GiBs of data doesn't really tell me anything) Disregarding standard diagnostic tools doesn't really add to your credibility in this. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: on firmware (possible proposal)
On Sun, Nov 16, 2008 at 12:14:30PM +, Stephen Gran wrote: This one time, at band camp, Robert Millan said: On Sat, Nov 15, 2008 at 04:32:08PM +, Stephen Gran wrote: It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. Of course you can. Adding paranoid fantasies to the debate doesn't really help much. Can you? Would you explain how? (and no, I run wireshark in my gateway and dig through several GiBs of data doesn't really tell me anything) Disregarding standard diagnostic tools doesn't really add to your credibility in this. Ad hominem doesn't really work as a stock replacement for justifiing things. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Sat, Nov 15, 2008 at 04:32:08PM +, Stephen Gran wrote: It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. Of course you can. Adding paranoid fantasies to the debate doesn't really help much. Can you? Would you explain how? (and no, I run wireshark in my gateway and dig through several GiBs of data doesn't really tell me anything) -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
This one time, at band camp, Robert Millan said: On Sun, Nov 16, 2008 at 12:14:30PM +, Stephen Gran wrote: This one time, at band camp, Robert Millan said: On Sat, Nov 15, 2008 at 04:32:08PM +, Stephen Gran wrote: It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. Of course you can. Adding paranoid fantasies to the debate doesn't really help much. Can you? Would you explain how? (and no, I run wireshark in my gateway and dig through several GiBs of data doesn't really tell me anything) Disregarding standard diagnostic tools doesn't really add to your credibility in this. Ad hominem doesn't really work as a stock replacement for justifiing things. Your use of 'ad hominem' seems to imply that you think that I made the argument personal at a point when it was not personal. You told me that pcap output wouldn't tell _you_ anything, at which point you made the discussion about what was relevant to you. pcap output is in fact a relevant diagnostic tool for this, just as gdb or an oscilloscope are relevant diagnostic tools in their areas. Whether or not they're useful to you isn't all that interesting or even really my problem. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: on firmware (possible proposal)
On Fri, Nov 14, 2008 at 06:54:52PM +0100, Frans Pop wrote: On Friday 14 November 2008, you wrote: I believe Debian has remained important over time because, despite our various social failings, they *respect* our ideology. And I believe that Debian is becoming increasingly marginal because users are driven away to other distros. Ironicaly, it is possible that both are right. It is staying in this middle stage that harms us the most, since we're heavily criticized from both sides. Furthermore, we can't really satisfy everyone. If we get closer to the non-free side, we'll still be beaten by distributions which go further. If we include firmware, they will include Nvidious blobs. If we include Nvidious blobs, they will include Adobe Flash. Etc. This is a big part of how Ubuntu earned this reputation of being easy to setup (they used our code to betray our goals, and now somehow we're looking at them for inspiration..). If we get closer to the free side, and provide a 100% free main like we used to, we'll still be criticised for having a non-free repository, or for having unofficial non-free installers. This is why I think that worriing so much about what _others_ think is a pointless exercise. Heck, if people think our stance on freedom is wrong, they most likely have already abandoned us in favour of other options (be it e.g. Ubuntu or Gnewsense). Those who have stayed with us to this date is because they _like_ our current compromise, because they care about freedom, even if they sacrifice their beliefs for practical reasons, and install non-free software. But when they do, they want to know they did. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
This one time, at band camp, Robert Millan said: On Fri, Nov 14, 2008 at 12:29:20AM -0600, Manoj Srivastava wrote: - code uploaded into another cpu (a device cpu, not a SMP cpu of some kind) does not run in the same memory space, and can thus not impact the main software running on the host CPU. Impacting other software has very little to do with the desirability of freedom of software. It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. Of course you can. Adding paranoid fantasies to the debate doesn't really help much. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: on firmware (possible proposal)
This one time, at band camp, Robert Millan said: If we get closer to the free side, and provide a 100% free main like we used to, When precisely was that? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: on firmware (possible proposal)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manoj Srivastava wrote: -- [Forward] - From: Sven Luther [EMAIL PROTECTED] Date: Thu, 13 Nov 2008 21:01:13 +0100 - code uploaded into another cpu (a device cpu, not a SMP cpu of some kind) does not run in the same memory space, and can thus not impact the main software running on the host CPU. Impacting other software has very little to do with the desirability of freedom of software. - code uploaded on a device cpu, is in no way less free than the case where said code would be found in a flash rom or something, on the contrary in some way it is more free than those cases. But debian does not distribute the latter, so the fact that the software being distributed is more free than some very non-free software not distributed by debian has dubious value. Manoj, Please read my post [1]. I suggest that the firmware is distributed outside 'main', but within a new section: 'sourceless'. 'sourceless' is not free software, but instead is a rather restricted sub-set of 'non-free'. See it like this: it gives users the option of using sourceless firmware without opening the full Pandorra's box of 'non-free'. Nothing will be installed without explicitly informing the user and asking for her/his consent to install the sourceless stuff. It won't happen behind the user's back and they have the choice of yes or no. I really don't like the idea that there are 'official' and 'unoffical' installation media and that d-u will be consequently flooded by users with installation issues. A typical response might look like: Oh, yes it's well known that the official disks won't work with your hardware. Just download the unofficial ones from www.foo.bar [*] and add 'non-free' to your 'sources.list' I'd rather see the debian project supporting their users and offering a truly debian way of installing debian on both 'good' and problematic hardware. Just MHO. What shall we do with the cell, BTW? It has multiple processing units, and the central processing usint, if one may call it that, si the dispatcher, which does little work. Would the software that runs on the other processing units be considered to have different needs of freedom? Why In my first draft of [1], I actually had a formulation that said that the sourceless stuff is not allowed to add new functionality to the OS. What I mean with this is best explained with an example, actually two: A wireless network interface provides network functionality to the OS like some ordnary network interface. For the CPU or the hard disk or the OS per se it is just the same, whether the data arrive via a cable connection or a wireless connection; for the user of the computer, of course both are not the same. If a GPS module just sends qualified plain ascii data (or any other set of standardized data) over a serial port or via an usb cable, it does not provide extra fuctionality to the OS and its firmware need not be open source in order to qualify for inclusion in 'sourceless'. If the GPS module, however, talks binary gibberish and thus requires some other closed source software or firmware in order to be interpreted by the OS, than it DOES NOT qualify for the 'sourceless' section and has to remain in 'non-free'. You could also view this from the other way around: There must not be any software in 'main' that would not work (at least on some hardware) if the 'sourceless' stuff is not present. I don't notice any difference, if my laptop is connected via the free ethernet card or the non-free wireless (the transfer speed is limited by my dsl-provider). On the other hand, compiz functionality is different with or without 3D. I considered this to be to cumbersome to be added. If anyone has better means of expressing this simple and unambiguously: Please go ahead! The addition of a 'sourceless' section just supports our priorities for free software. Some non-free firmware, unfortunately, is required on some hardware just to install all the free software in 'main'. Cheers, Johannes [1] http://lists.debian.org/debian-vote/2008/11/msg00132.html [*] Replace www.foo.bar with the typical result of a google search on 'I'm feeling lucky'. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkdRz0ACgkQC1NzPRl9qEUUQgCfQSiSQdMMIuCNPVlO7og+budC 71AAnjUtA9pXeoULl/vqMiwS8q8IpASa =jtlX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
This one time, at band camp, Peter Palfrader said: | Firmware is data that is uploaded to hardware components, not designed to be | run on the host CPU. Often this firmware is already required at install time | in order to use network or storage devices. | | Unfortunately such firmware often is distributed as BLOBs, with no source or | further documentation that lets us learn how it works or interacts with the | hardware in question. By excluding such firmware from Debian we exclude | users that require such devices from installing our operating system, or | make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. This one time, at band camp, Peter Palfrader said: | Firmware is data that is loaded into hardware components in order to | make the component function properly. It is not code that is run on | the host CPU. I would second this with the amendement noted. Cheers, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: on firmware (possible proposal)
Peter Palfrader wrote: I'm considering formally proposing this GR (option): I'm certainly in favor of Debian going in this direction. Ideals are fine, but castrating the distribution for them is taking things to far. IMO we can still strife and work to have more source made available to the community without alienating users by making it needlessly hard to install Debian or find important pieces of software. One comment on the proposed text. | Firmware is data that is uploaded to hardware components, not designed | to be run on the host CPU. Often this firmware is already required at | install time in order to use network or storage devices. Firmware is data [...] This has been the source of much discussion in the past IIRC. In some cases it is true and firmware is merely some data tables with settings, but in many cases firmware is executed on some CPU in the device. Would you consider s/data/software/ to avoid discussions on that point? For reading the DFSG the general viewpoint seems to be anything that's not hardware is software. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: on firmware (possible proposal)
On Fri, Nov 14, 2008 at 12:29:20AM -0600, Manoj Srivastava wrote: - code uploaded into another cpu (a device cpu, not a SMP cpu of some kind) does not run in the same memory space, and can thus not impact the main software running on the host CPU. Impacting other software has very little to do with the desirability of freedom of software. It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Fri, 14 Nov 2008, Frans Pop wrote: | Firmware is data that is uploaded to hardware components, not designed | to be run on the host CPU. Often this firmware is already required at | install time in order to use network or storage devices. Firmware is data [...] Firmware is like porn, I know it when I see it. :) This isn't meant to be an exact definition, but more of a guideline. That being said, if s/data/software/ makes you happy then we can do that. Also, I was asked to s/BLOB/blob/ which seems fine to me too. Unless anything comes up I'll propose this later today. Thanks, -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Fri, Nov 14, 2008 at 04:56:38PM +0100, Peter Palfrader wrote: Firmware is data [...] Firmware is like porn, I know it when I see it. :) This isn't meant to be an exact definition, but more of a guideline. That being said, if s/data/software/ makes you happy then we can do that. Why not refer to it as microcode instead? This is far less ambigous, as microcontroller is a more specific term than processor. Also, I was asked to s/BLOB/blob/ which seems fine to me too. May I suggest so-called \blobs\ or some indication that blob is an informal term? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan wrote: May I suggest so-called \blobs\ or some indication that blob is an informal term? Informal like http://en.wikipedia.org/wiki/Binary_blob ? - From there it appears it is better described as 'binary blob' in order not to confuse it with the 'Binary Large OBject' [1] of databases. Johannes [1] http://en.wikipedia.org/wiki/BLOB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkdpbkACgkQC1NzPRl9qEUhHwCeJvcS2neZ3O+rqHK+j1HQHqoi +jEAniWnKsu9Ljds0SfOC+v0GOks/Gzs =AGKW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
- Frans Pop [EMAIL PROTECTED] wrote: I'm certainly in favor of Debian going in this direction. Ideals are fine, but castrating the distribution for them is taking things to far. IMO we can still strife and work to have more source made available to the community without alienating users by making it needlessly hard to install Debian or find important pieces of software. But you have to see that castrating the ideals of the project is just as damaging as these distribution problems are. I believe Debian has remained important over time because, despite our various social failings, they *respect* our ideology. We remain relevant because we assert a standard and have managed to mostly provide a useful product while complying with those standards. If we bend the rules too much it becomes an open question on why we are better or different than any of the many other distributions out there. We shouldn't be bullheaded, unrealistic or unyielding but we should be strong and true. If distributing proprietary binaries is inescapable then, again, I'll say that we should leave that distribution to others and create some ground rules for identifying how those others should play nice with us. If we have an army of third party value-add distributors who fill in these proprietary gaps then we will be well armed to deal with the emerging spectrum of platforms that will be coming down the pipe in the coming years. Things that look like phones and other appliances will be the wave of the future and those devices will have many strange legal obligations. A partner program that enables the vendors of these devices to supply the necessary proprietary baggage and still guarantee a Debian Compatible environment will serve us, them and our users. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Friday 14 November 2008, you wrote: But you have to see that castrating the ideals of the project is just as damaging as these distribution problems are. I believe Debian has remained important over time because, despite our various social failings, they *respect* our ideology. We remain relevant because we assert a standard and have managed to mostly provide a useful product while complying with those standards. And I believe that Debian is becoming increasingly marginal because users are driven away to other distros. Sure, it is nice that a lot of those users go to derived distros instead of real competitors, but IMO it is still unhealthy if Debian's own user base becomes too small. After all, we largely depend on having that user base for a healthy turnover in DDs and having motivated translators and such. IMO nobody here is promoting indiscriminate distribution of proprietary binaries as you call it, nor to change our ideology. IMO we can still work towards a perfect world while being a bit more pragmatic and serving the needs of our users, especially the kind of professional or large scale users that really need to able to install a distro on hardware and have it working without having to jump to hoops. Reality is that _more_ hardware, and especially more _common_ hardware is becoming hard to use because of our ideals. You can also wonder if the DFSG would be written exactly the way they are if the were written from scratch in the current time frame. I doubt it. If we are selective in our concessions to pragmatism and careful in the way we implement things (which always has been one of the strengths of Debian), I personally don't see the problem. I'm well aware that what I tend to think of as the DFSG hardliners in the project do not like this, but why not discuss things openly (and hopefully without too much flaming) and vote on it? Let's see what the project as a whole thinks. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: on firmware (possible proposal)
- Frans Pop [EMAIL PROTECTED] wrote: And I believe that Debian is becoming increasingly marginal because users are driven away to other distros. Sure, it is nice that a lot of those users go to derived distros instead of real competitors, but IMO it is still unhealthy if Debian's own user base becomes too small. After all, we largely depend on having that user base for a healthy turnover in DDs and having motivated translators and such. If we handle things properly, it is like the GSM standards body worrying that it doesn't actually build phones. Ubuntu has helped us suck the air out of Red Hat and Novell in a way that no one would have thought possible. Now, to your point, I would like to see them be a little more direct about co-marketing with us and it seems that they are coming around to that way of thinking as time goes on. I think they've eventually come around to the idea that Debian done right doesn't fly nearly as well as Debian + Added Value. Being derogatory about the foundation of your product is backwards and nonsensical. What we need to do is get these distributions to view co-marketing with Debian as a positive thing, like the Real Milk products or the Java (gah! dare I say it!) brand. To me, real Debian derived distros would provide users with the core Debian value of choice and then add value on top of that. What we need to do is make some formal rules about how choice is provided. For instance, a Debian based platform that locks the user out of root and has cryptographically secured firmware would not meet the criteria of an official derived distro. The kind of protections I'm outlining here will become far more important than the bits of firmware in the main distribution as time goes on. If, in the future, there are no computers to install Debian on (ie. everything becomes more embedded and network based) then it won't matter a bit what is on our CDs. Engaging the platform manufacturers and other value-added resellers is going to become ever more critical. If we are selective in our concessions to pragmatism and careful in the way we implement things (which always has been one of the strengths of Debian), I personally don't see the problem. I'm well aware that what I tend to think of as the DFSG hardliners in the project do not like this, but why not discuss things openly (and hopefully without too much flaming) and vote on it? Let's see what the project as a whole thinks. I'm not disagreeing with you on the fact that bundles of proprietary bits are going to become harder to get away from as we move towards more embedded looking platforms. I'm just saying that distributing those bits through the core development process is a mistake and that value-added distributors are the way to go. That's what we're already doing and it works. What we should do is increase the effectiveness of our current process by making it more formal and explicit. Martin Michlmayr actually proposed some similar ideas under the name Debian Labs, which I immediately reserved as a means of making a point about trademark infringement. That URL could still be a good place to do this kind of work and I'm happy to hand it back to SPI if someone is serious about doing that kind of work on it. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ean Schuessler wrote: Johannes Wiedersich [EMAIL PROTECTED] wrote: I would propose to create a new section of the archive, called 'sourceless' or such. Stuff within this archive doesn't have full sources. It is legally distributable and follows the DFSG with the only exception of missing sources. On top of the DFSG it is required that software in 'sourceless' _must not be executed_ on the host CPU. 'sourcless' therfore applies to firmware as well as eg. documentation pdfs or images without source. For the sake of argument, what if we created a distribution of Debian that only runs on architectures with more than one CPU. We will designate one of the CPUs to be the non-free CPU. This CPU will run all sourceless software. For this distribution we can move all of non-free into the sourceless designation since it does not run on the host CPU. Well, even if at some time in the future all architectures supported by debian will require multiple CPUs and thus make it possible to move 'non-free' stuff to 'sourceless' without breaking the package for any single CPU architecture... - 'sourceless' still won't be 'main' - the user has to acknowledge each installation of 'sourceless' packages I guess by the time this happens, the very idea of what an OS is and what it does will have changed so much, that many other parts of debian's policy will be affected as well... Cheers, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkb4b4ACgkQC1NzPRl9qEWBvQCeNJtWMz0iX+msxFW5WUgMIqjI Ic4An0y5jxnCe+PsNK0BeIeJAByGqZg/ =8tna -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Wed, Nov 12, 2008 at 04:20:33PM +0100, Martin Michlmayr wrote: * Robert Millan [EMAIL PROTECTED] [2008-11-12 15:29]: For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. The problem with this is that we'll end up shipping official Debian CDs that won't work on many systems and eventually we'll end up telling people take the unofficial one, you know, the one that actually works. I've been doing that for NSLU2 and there it's not such a big deal because everyone uses netboot images, but it's more of a problem with CDs/DVDs. I know people who use Debian themselves, but when asked tell take the Ubuntu one, it supports more hardware. Sure, we can try to compete with that if that's more practical than either not recommending non-free or shipping two build sets. If we go this route, expect that we will either go half-way and not actually make any difference, or push further and bundle our default setup with Nvidious blobs, a restricted devices daemon, Adobe flash, etc, etc. In the end, you can't out-Ubuntu Ubuntu. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Wed, Nov 12, 2008 at 03:49:44PM +0100, Patrick Schoenfeld wrote: On Wed, Nov 12, 2008 at 03:29:30PM +0100, Robert Millan wrote: For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. well, as you say for yourself non-free is not Debian, which basically means that we provide infrastructure and such, but if in doubt the user is left alone with his problems. We don't have any rules saying that non-free users have to be left alone with their problems. Some of us aren't going to help supporting non-free, but this doesn't mean you can't do it if you like. Isn't this what we had SC #4 and SC #5 for? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
[Johannes Wiedersich] I would propose to create a new section of the archive, called 'sourceless' or such. Stuff within this archive doesn't have full sources. It is legally distributable and follows the DFSG with the only exception of missing sources. On top of the DFSG it is required that software in 'sourceless' _must not be executed_ on the host CPU. 'sourcless' therfore applies to firmware as well as eg. documentation pdfs or images without source. You know what, I think this distinction about running on the host CPU is rather silly, and I'm starting to believe it is entirely artificial. By this I mean that the distinction itself would not matter, except that it sounds a little better than just saying firmware is necessary enough to compromise our principles on, but the Flash plugin is not. But really, is there a principle of software freedom that distinguishes device firmware from, say, a [EMAIL PROTECTED] client using an NVidia GPU for compute cycles? What about the ability to install a whole OS on a router - if you plug the router into the PC with a USB cable, could you consider the router to be not the host CPU? The other day we were told d-i RC1 now supports certain NAS devices. Would those be hosts or merely devices or appliances? What about proprietary abandonware console game ROMs? Those can run in an emulator but they're intended for real hardware that isn't the host CPU. Someone also mentioned Postscript, roughly the same situation. Good thing Z80 daughterboards to run CP/M applications are no longer popular. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
-- [Forward] - From: Sven Luther [EMAIL PROTECTED] Date: Thu, 13 Nov 2008 21:01:13 +0100 On Thu, Nov 13, 2008 at 01:43:32PM -0600, Peter Samuelson wrote: [Johannes Wiedersich] I would propose to create a new section of the archive, called 'sourceless' or such. Stuff within this archive doesn't have full sources. It is legally distributable and follows the DFSG with the only exception of missing sources. On top of the DFSG it is required that software in 'sourceless' _must not be executed_ on the host CPU. 'sourcless' therfore applies to firmware as well as eg. documentation pdfs or images without source. You know what, I think this distinction about running on the host CPU is rather silly, and I'm starting to believe it is entirely artificial. By this I mean that the distinction itself would not matter, except that it sounds a little better than just saying firmware is necessary enough to compromise our principles on, but the Flash plugin is not. But really, is there a principle of software freedom that distinguishes device firmware from, say, a [EMAIL PROTECTED] client using an NVidia GPU for compute cycles? What about the ability to install a whole OS on a router - if you plug the router into the PC with a USB cable, could you consider the router to be not the host CPU? The other day we were told d-i RC1 now supports certain NAS devices. Would those be hosts or merely devices or appliances? What about proprietary abandonware console game ROMs? Those can run in an emulator but they're intended for real hardware that isn't the host CPU. Someone also mentioned Postscript, roughly the same situation. Good thing Z80 daughterboards to run CP/M applications are no longer popular. The important point here is the following (and these are not necessarily my opinion, but the arguments used here) : - code uploaded into another cpu (a device cpu, not a SMP cpu of some kind) does not run in the same memory space, and can thus not impact the main software running on the host CPU. = The argument is here that it is not as important that this is free software, since it cannot corrupt the software running on the main cpu. - code uploaded on a device cpu, is in no way less free than the case where said code would be found in a flash rom or something, on the contrary in some way it is more free than those cases. - the third point, is that the fact that the code runs in a separate device CPU, create a clear interface barrier, and make it clear that the the uploaded firmware is not a derivative work of the kernel or driver or whatever that uses it. This means that you are able to use these points (especially the last one) to respond to most of your question, and explain why the position of considering it ok to have non-free firmware in main is one that can be considered. That said, the above argumentation sheed some light on the issue, but do not constitute my opinion on what we should do, and anyway, my opinion doesn't count since i can't vote since i was expulsed as so much garbage from debian :/ Please forward this mail to the list, since i am being censored. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd second the proposal as quoted below. | Firmware is data that is uploaded to hardware components, not designed to be | run on the host CPU. Often this firmware is already required at install time | in order to use network or storage devices. | | Unfortunately such firmware often is distributed as BLOBs, with no source or | further documentation that lets us learn how it works or interacts with the | hardware in question. By excluding such firmware from Debian we exclude | users that require such devices from installing our operating system, or | make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. Cheers, Bernd - -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkct5kACgkQBnqtBMk7/3kl4QCcCxdv1R8GTrehUF5Q3R6rDNOC jJcAn30u09aAqYBnyMMSMI0ZbS/qzXW5 =1coL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
Peter Palfrader [EMAIL PROTECTED] writes: I'm considering formally proposing this GR (option): | Firmware is data that is uploaded to hardware components, not | designed to be run on the host CPU. Often this firmware is already | required at install time in order to use network or storage | devices. | | Unfortunately such firmware often is distributed as BLOBs, with no | source or further documentation that lets us learn how it works or | interacts with the hardware in question. By excluding such | firmware from Debian we exclude users that require such devices | from installing our operating system, or make it unnecessarily | hard for them. | | Therefore […] This gives no argument for why such bitstreams should be held to different standards of freedom for its recipients. The property “not designed to be run on the host CPU” is mentioned, but seems to be irrelevant to the argument. Can you re-write this so it's clear why this particular class of bitstream should not be held to the same freedom standards as everything else in Debian? -- \ “Pinky, are you pondering what I'm pondering?” “Well, I think | `\so, Brain, but I can't memorize a whole opera in Yiddish.” | _o__) —_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Thu, Nov 13 2008, Peter Samuelson wrote: -- [Forward] - From: Sven Luther [EMAIL PROTECTED] Date: Thu, 13 Nov 2008 21:01:13 +0100 - code uploaded into another cpu (a device cpu, not a SMP cpu of some kind) does not run in the same memory space, and can thus not impact the main software running on the host CPU. Impacting other software has very little to do with the desirability of freedom of software. = The argument is here that it is not as important that this is free software, since it cannot corrupt the software running on the main cpu. Again, corruption or lack thereof is not why I want freedom in software. - code uploaded on a device cpu, is in no way less free than the case where said code would be found in a flash rom or something, on the contrary in some way it is more free than those cases. But debian does not distribute the latter, so the fact that the software being distributed is more free than some very non-free software not distributed by debian has dubious value. - the third point, is that the fact that the code runs in a separate device CPU, create a clear interface barrier, and make it clear that the the uploaded firmware is not a derivative work of the kernel or driver or whatever that uses it. Sure. It is non-free, but not a derivative of the kernel. Nvidia drivers also qualify here. This means that you are able to use these points (especially the last one) to respond to most of your question, and explain why the position of considering it ok to have non-free firmware in main is one that can be considered. I do not buy it. What shall we do with the cell, BTW? It has multiple processing units, and the central processing usint, if one may call it that, si the dispatcher, which does little work. Would the software that runs on the other processing units be considered to have different needs of freedom? Why? manoj -- e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap.- Karl Lehenbauer Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Wed, 12 Nov 2008, Peter Palfrader wrote: | Firmware is data that is uploaded to hardware components, not designed to be | run on the host CPU. A postscript file isn't firmware simply because you can upload it to a printer. So, maybe slightly better: | Firmware is data that is loaded into hardware components in order to | make the component function properly. It is not code that is run on | the host CPU. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
Hi Peter, As much as I respect the legitimacy of your proposal, I think it is overkill to use a GR for that. Let me explain... On Wed, Nov 12, 2008 at 12:14:10PM +0100, Peter Palfrader wrote: By excluding such firmware from Debian we exclude | users that require such devices from installing our operating system, or | make it unnecessarily hard for them. This is not necessarily so. I believe that not excluding those users is precisely the reason we have SC #4 and SC #5 (and it is hard to justify those sections without this reason). Though, it may be true incidentally that we're making it unnecessarily hard for them. But there's nothing in our Social Contract that requires it to be hard, and you don't need a GR to change that. For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
Hi, On Wed, Nov 12, 2008 at 03:29:30PM +0100, Robert Millan wrote: For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. well, as you say for yourself non-free is not Debian, which basically means that we provide infrastructure and such, but if in doubt the user is left alone with his problems. It also means that *we* need to distinguish between _official_ and _inofficial_ medias, while requiring users to get inofficial medias to install in the first place, which is quiet insane. I do think its good to handle those firmware data different from how we handle the non-free section. Possibly we also need to handle it different then main, because we have a source code requirement for main. Thats why I like his proposal. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
* Robert Millan [EMAIL PROTECTED] [2008-11-12 15:29]: For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. The problem with this is that we'll end up shipping official Debian CDs that won't work on many systems and eventually we'll end up telling people take the unofficial one, you know, the one that actually works. I've been doing that for NSLU2 and there it's not such a big deal because everyone uses netboot images, but it's more of a problem with CDs/DVDs. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Wed, Nov 12, 2008 at 04:20:33PM +0100, Martin Michlmayr wrote: * Robert Millan [EMAIL PROTECTED] [2008-11-12 15:29]: For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. The problem with this is that we'll end up shipping official Debian CDs that won't work on many systems and eventually we'll end up telling people take the unofficial one, you know, the one that actually works. I've been doing that for NSLU2 and there it's not such a big deal because everyone uses netboot images, but it's more of a problem with CDs/DVDs. Absolutely. I'm looking into creating such unofficial CDs already as part of the regular builds. As far as I can see, too many people are going to need them. If we make it too hard for people to install Debian on their hardware, we *will* lose a lot of users. I'm even in that group - a lot of the machines we have at work need firmware and if they don't install and work easily we'll probably end up being forced to install Fedora instead. I think I agree with the suggestion of creating a new archive section for firmware - packages that are acknowledged to not meet the same standards as main, but checked so that we know they're still legally shippable by default on official installation media. I'm not sure if we can make that kind of change before Lenny, so I'd be happy to go with another exemption for Lenny and make the change afterwards. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] When C++ is your hammer, everything looks like a thumb. -- Steven M. Haflich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
ke, 2008-11-12 kello 15:41 +, Steve McIntyre kirjoitti: I think I agree with the suggestion of creating a new archive section for firmware - packages that are acknowledged to not meet the same standards as main, but checked so that we know they're still legally shippable by default on official installation media. That's what Ubuntu does, for what it's worth. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve McIntyre wrote: Absolutely. I'm looking into creating such unofficial CDs already as part of the regular builds. I think I agree with the suggestion of creating a new archive section for firmware - packages that are acknowledged to not meet the same standards as main, but checked so that we know they're still legally shippable by default on official installation media. I would propose to create a new section of the archive, called 'sourceless' or such. Stuff within this archive doesn't have full sources. It is legally distributable and follows the DFSG with the only exception of missing sources. On top of the DFSG it is required that software in 'sourceless' _must not be executed_ on the host CPU. 'sourcless' therfore applies to firmware as well as eg. documentation pdfs or images without source. On each installation of such firmware or documentation a debconf question is asked and the user is warned that this is not part of 'main' and informed that the sources are missing. (Install this software, despite the fact that sources are not available. / Don't install this software.) This won't hide any problems to the user and give them an opportunity to install certain limited 'non-free' stuff without activating 'non-free' as a whole. Importantly, it also gives them an option to only install open source software. It will also simplify the job of the maintainers (or ftpmasters, RMs, etc.). They simply to move the relevant packages from 'main' to 'sourcless'. This won't break anything for the user, since 'sourceless' is activated by default (via the debconf questions). (Since the code is not executed on the host's CPU, dependencies should not be a problem.) Installation media might carry a label that firmware is included along with the free software from debian 'main', if it is believed that this is necessary (on top of the debconf questions). I hope that it will be possible to ship installation media prepared in this manner as official media without the need of having both 'official' and 'unofficial' images, reducing the amount of confusion... ;-) Cheers, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbBLwACgkQC1NzPRl9qEX5gACcDidAlEN9O0iKfjukJTK8DIFC 0b0Anin8Mfw4hPLQr61X+NtDru/F2iqy =9+xK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
* Steve McIntyre ([EMAIL PROTECTED]) [081112 16:31]: I think I agree with the suggestion of creating a new archive section for firmware - packages that are acknowledged to not meet the same standards as main, but checked so that we know they're still legally shippable by default on official installation media. I'm not sure if we can make that kind of change before Lenny, so I'd be happy to go with another exemption for Lenny and make the change afterwards. I think that are two different issues. We have educated our users that using stuff in non-free is bad, and we should continue so. Firmware however falls into another part IMHO. So let's be careful to not put really non-free crap into the same part of the archive as we put stuff we need on our installation medias. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
- Peter Palfrader [EMAIL PROTECTED] wrote: c) such firmware can and should be part of our official installation media. We've seen a trend towards organizations building on Debian as a foundation for various special purpose distributions. Debian adds a lot of value as a starting point precisely because of our commitment to a completely Free Software oriented process. I think its safe to say that our model forced Novell and Red Hat to both create parallel programs (OpenSUSE, Fedora) to match the influence of Debian. Extending on this trend towards distributors, maybe we should not be overly obsessed with the Debian reference platform running on every piece of equipment under the stars. If we accept that proprietary drivers, source and binaries are indispensable for a retail quality product then I think it would be better for us to promote value added distributions from other groups than to compromise our core policies. In the end, as we've seen with Ubuntu, second-tier distributors can *vastly increase* the market share of our packaging rather than diminishing it. I can't say whether this distribution process would take the form of an automated way to fetch proprietary apt-sources, a catalog of value-added ISO images or something completely different. I do think it would be more natural for us to rely on partners to fulfill this role because it would be more flexible going forward. Part of the process could be to establish a new set of policies for distributors to follow if they want to be recognized as Debian Compatible(tm). Major partners like Ubuntu, Mepis and Knoppix could help us work out some ground rules and maybe large commercial users like Hewlett Packard could give us some perspective on how their internal packages could fit into that sort of scheme. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
Hi, On Wed, Nov 12, 2008 at 12:14:10PM +0100, Peter Palfrader wrote: I so didn't want to get into this discussion, but here goes anyway. I'm considering formally proposing this GR (option): | Firmware is data that is uploaded to hardware components, not designed to be | run on the host CPU. Often this firmware is already required at install time | in order to use network or storage devices. | | Unfortunately such firmware often is distributed as BLOBs, with no source or | further documentation that lets us learn how it works or interacts with the | hardware in question. By excluding such firmware from Debian we exclude | users that require such devices from installing our operating system, or | make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. Point (c) could mean that for now such data may stay in the main section of our archive but that we should look into creating a new, seperate section for firmware that does not come with source. But that's an implementation detail that need not be part of the GR. I would second this proposal, as is, if it would be one. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
- Johannes Wiedersich [EMAIL PROTECTED] wrote: I would propose to create a new section of the archive, called 'sourceless' or such. Stuff within this archive doesn't have full sources. It is legally distributable and follows the DFSG with the only exception of missing sources. On top of the DFSG it is required that software in 'sourceless' _must not be executed_ on the host CPU. 'sourcless' therfore applies to firmware as well as eg. documentation pdfs or images without source. For the sake of argument, what if we created a distribution of Debian that only runs on architectures with more than one CPU. We will designate one of the CPUs to be the non-free CPU. This CPU will run all sourceless software. For this distribution we can move all of non-free into the sourceless designation since it does not run on the host CPU. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
