Re: Second call for votes for the Lenny release GR
This one time, at band camp, Frans Pop said: > On Tuesday 23 December 2008, Bdale Garbee wrote: > > But note that even if the super-majority issue causes some choices to > > have a low priority of winning, we the project at large can still learn > > very interesting things by studying the Condorcet intermediate results. > > Agreed in general, but... > The issue is not only "winning". The issue is also "not being ranked > because they get dropped before ranking because of failing to reach > majority". This will skew the official final result further than would be > the case in the absence of the super-majority requirements. That's not the end of the world. Even if we continue to use the same algorithm we have now, we still have the raw data. If a super majority option was both dropped from the rankings because it didn't make super majority and the most popular, that will be both significant and noticeable. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Second call for votes for the Lenny release GR
* Debian Project Secretary [081222 23:39]: > However, after thinking long and hard about this, I can find no real > constitutional basis for terminating the current vote. Therefore, attached > you will find the second call for votes. The only substantive change is that > I corrected the date and time for ending this vote which were in error in the > first call for votes, and I've signed the key already in use for this vote. In the light of some mail error messages people got when voting (one was post on planet.debian.org, I also got one and a acknoledge, so I am unsure if my vote was recorded), it would be nice if the voters page would work. The website says: For this GR, as always statistics shall be gathered about ballots received and acknowledgements sent periodically during the voting period. Additionally, the list of voters would be made publicly available. Also, the tally sheet may also be viewed after to voting is done (Note that while the vote is in progress it is a dummy tally sheet). But none of the links in there seems to work. Thanks in advance and for your work, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
New section for firmware.
Hi, I've been thinking about this proposal for some time, and I probably should have send this some time ago. At least some people seem to have had simular ideas, so I wonder why nobody propsed anything like this. The idea is to create a new section that contains files like firmware images and FPGA data that gets written to the hardware to make it fully functional. It is not meant for drivers that run on the host CPU. The new section should also be available on our CD/DVD images, so that users can just take a CD/DVD and that it works without having to search for the needed firmware and provide it on an other medium to the installer. As draft I'd like to propose: 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We'll create a new area in our archive that contains files like firmware images and FPGA data that gets written to the hardware to make it fully functional. The files in this area should not comply with the DFSG #2, #3 and #4, but should comply with the rest of the the DFSG. 3. This new section will be available on our CD, DVD and other images. I'm open for suggestions on how to better word this proposal, or other changes. The social contract now lists non-free and contrib. I'm not sure if we need to change the SC or not with this proposal. This is meant as a long term solution. The proposal is not about the Lenny release, but I wonder which requirements we should have for files in the new section. And I think if we want it to be able to put it on the CD/DVD, the requirements from the DFSG other than #2, #3 and #4 seem to make most sense. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
Kurt Roeckx wrote: > The files in this area should not comply with the DFSG #2, #3 and > #4, but should comply with the rest of the the DFSG. So anything that complies with 1 or 2 of these points, but not all of them, may not be included in the firmware section? s/should not/must not necessarily/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
Le mardi 23 décembre 2008 à 13:07 +0100, Kurt Roeckx a écrit : > The idea is to create a new section that contains files like > firmware images and FPGA data that gets written to the hardware > to make it fully functional. It is not meant for drivers that run > on the host CPU. There is no reason to restrict this area to firmware images. How about “Software that is not executed on the host CPU” ? That can include e.g. non-free documentation, which clearly doesn’t belong in the same place than nVidia binary drivers. > The new section should also be available on our CD/DVD images, > so that users can just take a CD/DVD and that it works without > having to search for the needed firmware and provide it on an > other medium to the installer. I think we should clearly separate it on a different medium, except for netinst images, for which there could be two versions. BTW, do we really need yet another vote for that? If there is consensus on the usefulness, isn’t it enough to have the approval of the FTP masters and the d-i developers? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: New section for firmware.
On Tue, Dec 23, 2008 at 03:24:25PM +0100, Josselin Mouette wrote: > Le mardi 23 décembre 2008 à 13:07 +0100, Kurt Roeckx a écrit : > > The idea is to create a new section that contains files like > > firmware images and FPGA data that gets written to the hardware > > to make it fully functional. It is not meant for drivers that run > > on the host CPU. > > There is no reason to restrict this area to firmware images. > > How about ???Software that is not executed on the host CPU??? ? That can > include e.g. non-free documentation, which clearly doesn???t belong in the > same place than nVidia binary drivers. While I think that non-dfsg-free documentation also merits to be split off from non-free, I don't think we should generalize this too much; e.g. clearly non-free copyrighted artwork or data should probably stay in non-free. Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008, Kurt Roeckx wrote: > The idea is to create a new section that contains files like > firmware images and FPGA data that gets written to the hardware > to make it fully functional. It is not meant for drivers that run > on the host CPU. Do you propose to include data for which we only lack source or build tools or doc? Or would it also include firmware data which has a license preventing any modification to the contents of the data? If the intent is to include it in our CD-ROMs, I think some people will want a "really really free" CD-ROM which doesn't have this section. So that would mean two sets of images. What is the advantage of this section over pulling firmwares from non-free into a second set of images? -- Loïc Minier -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
Le mardi 23 décembre 2008 à 15:27 +0100, Michael Banck a écrit : > > How about ???Software that is not executed on the host CPU??? ? That can > > include e.g. non-free documentation, which clearly doesn???t belong in the > > same place than nVidia binary drivers. > > While I think that non-dfsg-free documentation also merits to be split > off from non-free, I don't think we should generalize this too much; > e.g. clearly non-free copyrighted artwork or data should probably stay > in non-free. Why? In essence, it is very similar to a firmware. It can also be necessary (e.g. for game data) to make free software work, in a similar way to the kernel with firmware. And I know that installing it is not going to blow away my system with untrusted code. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: New section for firmware.
Josselin Mouette wrote: > Le mardi 23 décembre 2008 à 13:07 +0100, Kurt Roeckx a écrit : >> The idea is to create a new section that contains files like >> firmware images and FPGA data that gets written to the hardware >> to make it fully functional. It is not meant for drivers that run >> on the host CPU. > > There is no reason to restrict this area to firmware images. SC 5: "We have created contrib and non-free areas in our archive for these works. The packages in these areas are not part of the Debian system,although they have been configured for use with Debian." Would the packages in this "firmware-sourceless-notmain" section be "part of the Debian system" or not ? Would it be a "sourceless main" or an "important non-free" ? And if this section is not considered "part of the Debian system", why including software from it on the Debian CD's ? (The inverse question is to be answered too…) > How about “Software that is not executed on the host CPU” ? That can > include e.g. non-free documentation, which clearly doesn’t belong in the > same place than nVidia binary drivers. If the section would be considered "part of the Debian system", some documentation from "outside" the Debian system (non-free) would migrate to the Debian system, without any change in licence. This is a big move. >> The new section should also be available on our CD/DVD images, >> so that users can just take a CD/DVD and that it works without >> having to search for the needed firmware and provide it on an >> other medium to the installer. > > I think we should clearly separate it on a different medium, except for > netinst images, for which there could be two versions. Why not. But then, would the netinst images be "images of the Debian system" ? > BTW, do we really need yet another vote for that? If there is consensus > on the usefulness, isn’t it enough to have the approval of the FTP > masters and the d-i developers? Regarding the questions above, I think that they have to be carefully handled and answered, because this would be a section where the DFSG-compliance requirement is clearly weakened[0]. A statement from the Debian project as whole by the way of a GR (yet another GR I agree) would be necessary for such a modification of "the Debian system". This would formalize the felt consensus in stone and be a clear message to the outside too. Best regards, OdyX [0] Quoting the original proposal: "The files in this area should not comply with the DFSG #2, #3 and #4, but should comply with the rest of the the DFSG." -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Loïc Minier wrote: > If the intent is to include it in our CD-ROMs, I think some people will > want a "really really free" CD-ROM which doesn't have this section. Or maybe an explicit debconf question about the non-free nature? This could make sure that no one will get non-free software installed without explicit consent and take the burden off the CD team to prepare another set of CDs etc. (Of course anything on the CDs must be distributable). > So that would mean two sets of images. What is the advantage of this > section over pulling firmwares from non-free into a second set of > images? Fine control of allowing certain non-free drivers (and/or documentation) without enabling the whole 'evil empire' of 'non-free'. Simpler installation from CD/usb/etc (network cards etc.). See also my other post. Cheers, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklQ+WwACgkQC1NzPRl9qEXMMACeLdrZw320Ae5UDY09mfpQQ5PN oVQAn17KgugjE01mfbXSaDVAWt+Ps4gC =2t/t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Didier Raboud wrote: > And if this section is not considered "part of the Debian system", why > including software from it on the Debian CD's ? (The inverse question is to > be answered too…) Because it might be required in order to install all that free software in the first place. How should one download the firmware for the network card? (Please don't tell me: from a second computer or after installing an other non-free OS on that computer, as this might not be possible or might be difficult for some users. ) > If the section would be considered "part of the Debian system", some > documentation from "outside" the Debian system (non-free) would migrate to > the Debian system, without any change in licence. This is a big move. No. 'sourceless' will be another section, technically just like 'non-free'. Once the free OS is installed, activating the whole evil empire of 'non-free' is achieved by just adding these words to a single line of a config file. I presume that 'main' and 'non-free' packages rest peacefully next to each other on the hard disk of some package server. (I might be wrong here, but at least that is how it appears to the user: just activate 'non-free' for the very same server you use for main. I don't see, why this has to be different for the installer: why would the Debian project insist that the firmware must not be included with the installer and should be put on a second, different installation medium, though there might be more than enough space on the first cd/dvd/usb-stick? (Of course no non-free software is to be installed without explicit action on of the user, just as with 'non-free'. ) Cheers, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklQ/HEACgkQC1NzPRl9qEW81gCfXEYJWC8NBo+a38hKpn+RvQzl mksAn0Qpo3lyuYtHK9qpJO+9+YdxXqg8 =L3CX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008 at 03:34:29PM +0100, Loïc Minier wrote: > On Tue, Dec 23, 2008, Kurt Roeckx wrote: > > The idea is to create a new section that contains files like > > firmware images and FPGA data that gets written to the hardware > > to make it fully functional. It is not meant for drivers that run > > on the host CPU. > > Do you propose to include data for which we only lack source or build > tools or doc? Or would it also include firmware data which has a > license preventing any modification to the contents of the data? It did say that it shouldn't comply with DFSG #3, so that would mean it can prevent modification. > If the intent is to include it in our CD-ROMs, I think some people will > want a "really really free" CD-ROM which doesn't have this section. > So that would mean two sets of images. What is the advantage of this > section over pulling firmwares from non-free into a second set of > images? CDs with firmware from non-free on it would be unofficial CDs, since non-free isn't part of Debian. So I assume non of our pages would have a link to that. I want official CD images with the firmware on it. I'm open for other suggestions on how to reach that goal. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Roeckx wrote: > The idea is to create a new section that contains files like > firmware images and FPGA data that gets written to the hardware > to make it fully functional. It is not meant for drivers that run > on the host CPU. [FWIW, I've been having a similar idea and just didn't want to post it into the present controversal discussions.] I have one additional suggestion and a further question to the project. The suggestion is to add a debconf question to each installation from that 'firmware section'. This will honestly point out to users that they are about to install non-free stuff which is not part of debian proper [1]. Now the question: Would this section not be better called 'sourceless'? IMHO this would better point out, where exactly the problem with it is (compared to 'firmware' or similar). It might be useful to allow sourceless documentation into that section as well. Documentation is not part of the OS in a strict sense (and also not software in a strict sense). While I agree that documentation should conform to the DFSG just like software, I have to admit that I believe that the 'entry barrier' for non-free documentation on my computer system should be lower than that for non-free code. At present both reside in 'non-free', ie. if users activate 'non-free' aptitude will install non-free software just as readily as a documentation pdf (even if the license of the pdf allows modification and only the source of the pdf is missing for some reason or other -- sometimes just neglect of upstream). The important point is that users will get more balanced control of the software installed on their systems: It's no longer 'main' vs the whole evil empire of 'non-free'. While 'sourceless' firmware and pdfs will get better Debian support (like presence on distributed media) NO non-free software or documentation will be installed without an explicit warning and an explicit case-by-case decision of the user. By allowing users who presently have 'non-free' activated for things like wireless to remove 'non-free' from their sources.list, this might even contribute towards less non-free software on Debian systems. On the whole, I think that these section (with or without documentation) will be of great benefit to our users. It will allow them to run Debian on hardware that presently cannot be supported by DFSG-free software without having to activate the whole bunch of 'non-free' software or to use third-party software. Another advantage of having that additional section is that it takes some of the burden of the RT and/or the FTP assistants. Instead of having to decide whether to suspend the whole release process by removing an important package, they could just move the package in question to the new section. (Of course it wouldn't be nice to release with the whole kernel being outside main, but as a last resort it might be possible and it would neither be the fault nor the responsibility of the RT). Disclaimer: I am not a DD, so please take this as the very humble opinion of a (serious) debian user. Cheers, Johannes [1] "Unfortunately, your hardware (xy) currently is not supported by free software in Debian. You can now continue without installing non-free software. This might lead to part of your hardware not working properly. We offer the possibility to install some binary firmware. This is non-free software with no source code available. This software is not part of Debian and cannot be fully supported by Debian (we don't have the sources ourselves). As long as you don't activate the 'non-free' section of our archives, you can rest assured that Debian won't install further non-free software without your explicit consent in a question like this one. "Install non-free software foo? yes / NO" No being the default option. Feel free to improve or discard what I suggest. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklQ9PAACgkQC1NzPRl9qEVU/ACcDOoYH2reEbztYi5UwX0Z3RKo TF0Anif+tO/i5mk/tUOk9Di26KAgxOa3 =kcjd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
Johannes Wiedersich wrote: > Didier Raboud wrote: >> And if this section is not considered "part of the Debian system", why >> including software from it on the Debian CD's ? (The inverse question is >> to be answered too...) > > Because it might be required in order to install all that free software > in the first place. > > How should one download the firmware for the network card? (Please don't > tell me: from a second computer or after installing an other non-free OS > on that computer, as this might not be possible or might be difficult > for some users. ) In any case you have to download something and transfer it somehow to the target machine - this being a CD to burn or a USB key to write on, an OS giving hand to the installer kernel,... Downloading and burning a second "thing" should not be that hard (but could be in real corner-cases). But this is a "technical" issue. I think that the question is philosophical and related to "free and libre software" and Debian's concept of it. SC#1"We promise that the Debian system and all its components will be free according to these guidelines. (...) We will never make the system require the use of a non-free component." I think that according to this (and this is my interpretation, could be false), Debian has to provide CD images made of 100% of free and libre software (to the state of its common knowledge). Then, if some hardware (and it seems to be the case) needs special installation CDs, Debian 'can' provide some "tainted" CDs, as it know provides access to contrib and non-free - being CD's "not part of the Debian system". I know that having "unusable free Debian CD's" AND "useable non-free non-Debian CD's" could eventually lead to the only usage of the latters, but I am convinced that Social Contract made with the Free Software Community asks for a 100% Debian system (this includes CD's IMHO). I don't object having a third non-Debian system archive section, but this section should not taint the Debian system or its installer. Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Request for ruling re. use of lenny-ignore tags by release team
* Frans Pop (elen...@planet.nl) [081223 01:44]: > Given that the current status of the current "lenny firmware" vote is that > it will go forward, I would appreciate if the DPL and/or the Project > Secretary could rule on the following issue. On which constitutional rules? The secretary can interpret the constitution as necessary, and around 87iqqn2q1m@windlord.stanford.edu we agreed that according to the constitution the DPL or the delegates are the ones to make the decisions. The DPL has delegated an ongoing tasks to the Release Team. Of course the DPL could withdraw the ongoing delegation for the future, but according to constitution 5.1.1 the DPL may not revoke any decision done by the Release Team. Cheers, Andi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
Kurt Roeckx wrote: > Hi, > > I've been thinking about this proposal for some time, and I probably > should have send this some time ago. At least some people seem to > have had simular ideas, so I wonder why nobody propsed anything like > this. > > The idea is to create a new section that contains files like > firmware images and FPGA data that gets written to the hardware > to make it fully functional. It is not meant for drivers that run > on the host CPU. > > The new section should also be available on our CD/DVD images, > so that users can just take a CD/DVD and that it works without > having to search for the needed firmware and provide it on an > other medium to the installer. > > As draft I'd like to propose: > >1. We affirm that our Priorities are our users and the free > software community (Social Contract #4); >2. We'll create a new area in our archive that contains files > like firmware images and FPGA data that gets written to the > hardware to make it fully functional. The files in this > area should not comply with the DFSG #2, #3 and #4, but should ^ .. need not to comply ..; as already mentioned by others. > comply with the rest of the the DFSG. >3. This new section will be available on our CD, DVD and other > images. .. available to all supported installation methods. (This avoids a list which might be non-exhaustive.) Thiemo -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008 at 03:44:25PM +0100, Josselin Mouette wrote: > Le mardi 23 décembre 2008 à 15:27 +0100, Michael Banck a écrit : > > > How about ???Software that is not executed on the host CPU??? ? That can > > > include e.g. non-free documentation, which clearly doesn???t belong in the > > > same place than nVidia binary drivers. > > > > While I think that non-dfsg-free documentation also merits to be split > > off from non-free, I don't think we should generalize this too much; > > e.g. clearly non-free copyrighted artwork or data should probably stay > > in non-free. > > Why? In essence, it is very similar to a firmware. It can also be > necessary (e.g. for game data) to make free software work, in a similar > way to the kernel with firmware. While that might be true technically, I don't think you can compare it from a social POV. Firmware is (when it applies) (mostly) essential to make your hardware run; documentation is important to understand and learn code and/or important system programs. Game data is not essential at all in the wider scope of a Free Operating System. > And I know that installing it is not going to blow away my system with > untrusted code. That's certainly a requirement, but not the only one I would like to have. In the end, I guess that most games depend on their game data, so the question boils down to whether this new section is "part of Debian" and thus whether a depends-on relationship on this new section is allowed or not. Michael -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
Le mardi 23 décembre 2008 à 21:23 +0100, Michael Banck a écrit : > > Why? In essence, it is very similar to a firmware. It can also be > > necessary (e.g. for game data) to make free software work, in a similar > > way to the kernel with firmware. > > While that might be true technically, I don't think you can compare it > from a social POV. Firmware is (when it applies) (mostly) essential to > make your hardware run; documentation is important to understand and > learn code and/or important system programs. > > Game data is not essential at all in the wider scope of a Free Operating > System. I don’t think we ever made a distinction on the usefulness of software to select the section they belong to; this should only affect priority. > In the end, I guess that most games depend on their game data, so the > question boils down to whether this new section is "part of Debian" and > thus whether a depends-on relationship on this new section is allowed or > not. I certainly don’t wish the games in question to be moved from contrib to main; after all, they *do* depend on non-free data. But I’d like to be able to install this kind of data without adding non-free (which cannot be trusted) to my APT sources. And the same holds here for firmwares and game data. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
no blanket firmware exception, please (was: Re: Proposed wording for the SC modification)
Hello, On Mon, 17.11.2008 at 09:38:19 -0600, Manoj Srivastava wrote: > On Mon, Nov 17 2008, Charles Plessy wrote: > > Can the Secretary clarify again what will hapen if Peter's option is voted ? > > That GR clearly refines the DFSG statement that all programs > need source code. This supersedes the current DFSG, which allows for no > such exception. So the we need to amend the FSG wiht the changes after > the 3:1 vote. (Aside, on a personal note, anything else, to me, smells > of deceptive and underhanded handling of our social contract). without repeating the suggested new wording for the DFSG, I'd like to note that the concept is imho technically flawed, and serves to corrupt our freedom and the integrity of our systems in most likely unintended ways as a side effect. This is because it's becoming increasingly difficult to draw the line between "firmware", and a whole operating system for a co-processor. Think of devices that increasingly take control of our computers, like GPUs. nVidia's number-crunching graphics cards, or (intel) network cards that autonomously write stuff into the CPU's cache, even, spring to mind as examples of what's happening already today. If this tend were to continue, and I have very little doubt about that, we will end up with a "small" CPU that will run on free software because of some legacy decisions by the chipmakers, but all interesting stuff will happen on powerful co-processors, formerly "peripherals", which are exempted from running code that we have source for, and which will therefore be quite opaque to us. My fear is that handing out a blanket waiver for source code for such devices will get us into deep trouble before long, and therefore reject this move. I think that this issue most likely needs further discussion, and maybe even decisions on a case-by-case basis. [ OBS: Yes, I know that the vote is already over, but I missed these points in the discussion so far (but without having waded through all of it) and thought that these problems need to be considered. ] Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
[Kurt Roeckx] > The idea is to create a new section that contains files like firmware > images and FPGA data that gets written to the hardware to make it > fully functional. It is not meant for drivers that run on the host > CPU. Without weighing in on whether there _is_ a class of software for which users shouldn't have the right to look at and modify source code, this whole phrase "run on the host CPU" needs to die and be replaced by something more precise. The definition is only useful if you have a very simplified and outdated view of computer technology. There are lots of pieces of silicon that are not "host CPUs" but which still run software every bit as interesting and sophisticated as what we already give people source code for. (Many of you have heard me rant about this before. Nothing much new here, just hit 'd' now if you already know where I'm going with this.) Take a modern supercomputer: there'll be a handful of amd64 chips that run Linux, but what you actually paid for is the several thousand PowerPC "Cell" cores. Is it really reasonable to waive the source code requirement for number-crunching libraries designed to run on the Cells? They certainly aren't the "host CPU". As a variation on the modern supercomputer, take any code intended to run on an Nvidia GPU. People are apparently using those things for real computations now, s...@home type stuff. Take almost any embedded platform - PDA, phone, media player, or these days, all-of-the-above. Most people wouldn't think of them as having a "host CPU" at all, merely a controller that you upload data to via USB or Bluetooth. But of course they run OSes, sometimes Linux, maybe sometimes Debian. Would we want to ship PalmOS apps in Debian as blobs, without source code, merely because they don't execute on i386? Take qemu or MAME. Well, maybe not MAME, that's Ean's baby, but take qemu. Could we ship, without source code, full bootable OS images in Debian that are intended to run on an exotic architecture in qemu rather than on physical hardware? Surely qemu does not provide a "host CPU". And of course there are those wireless routers where people talk about using such-and-such "firmware", by which they really mean a blob containing a boot loader, Linux kernel, and root filesystem. Of course we know there is a MIPS chip in there, but the device is not sold as a computer or "host", but as a mere device that you plug into your network along with your computers. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Re: Second call for votes for the Lenny release GR
Some of the links have changed because of our change to using user 'secretary' for the vote processing. You can see the list of currently tallied votes, for example, at: http://master.debian.org/~secretary/gr_lenny/voters.txt Bdale -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Tue, Dec 23, 2008 at 01:07:43PM +0100, Kurt Roeckx wrote: > I've been thinking about this proposal for some time, and I probably > should have send this some time ago. At least some people seem to > have had simular ideas, so I wonder why nobody propsed anything like > this. > The idea is to create a new section that contains files like > firmware images and FPGA data that gets written to the hardware > to make it fully functional. It is not meant for drivers that run > on the host CPU. > The new section should also be available on our CD/DVD images, > so that users can just take a CD/DVD and that it works without > having to search for the needed firmware and provide it on an > other medium to the installer. While I think it would be reasonable to include sourceless firmware on our CDs and DVDs, I don't think this is actually a very good solution to the problem we face: - if they're included on the official "Debian" images, they need to meet Debian's definition of "free". - if the firmware are considered "free", then they can live in main. - if the images the firmware is included on aren't Debian images, then there will (presumably) still be demand for pure Debian images, and we don't need to add a new archive section in order to include non-Debian stuff on the images Having two sets of images doesn't make sense to me; the CD team have already posted publically this cycle about the infrastructure challenges involved with publishing those images that they already have to accomodate, doubling the image count doesn't sound feasible, IMHO. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New section for firmware.
On Wed, Dec 24, 2008 at 3:15 PM, Steve Langasek wrote: > Having two sets of images doesn't make sense to me; the CD team have already > posted publically this cycle about the infrastructure challenges involved > with publishing those images that they already have to accomodate, doubling > the image count doesn't sound feasible, IMHO. In addition, it should be fairly easy to add firmware D-I images; hd-media: mount & cp ISOs: xorriso (command-line) or isomaster (GUI), or just mount and genisoimage. netboot: cp win32-loader: cp & notepad So perhaps some extra info about remastering installation media in the d-i manual would be good for those like DSA who cannot just add the non-free firmware to removable media like a USB stick or floppy. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
