FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-10-2012, 10:43 PM
Jonathan Nieder
 
Default Microcode and the installer ( Towards d-i wheezy beta 3)

(replying to -devel and -boot only)
Henrique de Moraes Holschuh wrote:
> On Mon, 10 Sep 2012, Philipp Kern wrote:

>> If we do that the same should also happen for firmware-linux-nonfree. Loading
>> the radeon KMS module without firmware available results in an unusable
>> (text) console. (Yes, it might be considered a bug that radeon is loadable
>> without.)
>
> Sounds good to me.
>
> What should I clone and hack to try to implement this?

<git://git.debian.org/d-i/base-installer.git>, I think.

> Is there any
> preference over install-by-default or ask-if-the-user-wants-it ?

Very good question. Neither sounds great to me --- let me explain
why.

If d-i asks if the user wants microcode, the user will presumably get
a question along the following lines (yes, I am exaggerating):

Install binary gobbledegook from $hardware_vendor?

There is some software that can run on your hardware
and can be regularly be updated through the package
management system, but we don't really know what it
does in detail. If you don't install this, your
computer will probably explode. Install it?

[ Yes ] [ No ]

The answer is always "yes", right? The user is going to wonder why we
wasting their time to ask them.

On the other hand, if we make the decision for the user (taking the
choice to fetch from non-free sources as permission), then it is hard
to claim that Debian is totally free and that non-free is only a
collection of packages that are not from the OS that have been
packaged to work well with Debian. This would be a fundamental change
to what it means to enable non-free.

The benefit of not requiring or installing any non-free software by
default cannot be preserved by throwing up any number of nagging
prompts. If the operating system includes only free software by
default (even when non-free is enabled in sources.list), the user gets
a few moments of seeing what free software can provide before making
an informed decision about what is right for their needs.

If I ran the world, then:

- if the user has gone to the trouble of providing firmware or
microcode on a USB stick or similar, then the installer would
just use it.

- likewise, a separate menu item that the user can choose in
order to install firmware or microcode sounds useful

- however, by default the installer would provide an OS with
full functionality without having to install non-free
software

- documentation such as the release notes would emphasize important
non-free packages, especially when they provide functionality for
which there is no free alternative

- on those radeons where the firmware is necessary for the
radeondrmfb driver, the installer would fall back to vesafb, with
clear instructions for switching back to radeon after installing
the firmware

Of course I don't run the world. Have fun.

Hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120910224128.GA1226@mannheim-rule.local
 
Old 09-13-2012, 04:55 PM
Henrique de Moraes Holschuh
 
Default Microcode and the installer ( Towards d-i wheezy beta 3)

On Mon, 10 Sep 2012, Jonathan Nieder wrote:
> (replying to -devel and -boot only)
(I am not subscribed to -boot. Please keep -devel on replies, or CC me
directly).

> Henrique de Moraes Holschuh wrote:
> > On Mon, 10 Sep 2012, Philipp Kern wrote:
> >> If we do that the same should also happen for firmware-linux-nonfree. Loading
> >> the radeon KMS module without firmware available results in an unusable
> >> (text) console. (Yes, it might be considered a bug that radeon is loadable
> >> without.)
> >
> > Sounds good to me.
> >
> > What should I clone and hack to try to implement this?
>
> <git://git.debian.org/d-i/base-installer.git>, I think.

It is actually the hw-detect module, and adding support for the two system
processor microcodes is somewhat trivial... as long as I ignore VMs. I just
need to add a hook to pre-pkgsel.d.

If I want to skip installing the processor microcode on VM images, I need to
install and "in-target" run virt-what before the hook can decide whether
installing the microcode packages is warranted or not.

Should I attempt to install virt-what (which brings dmidecode as a
dependency) to avoid wasting space on VM images ?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120913165555.GD29340@khazad-dum.debian.net">http://lists.debian.org/20120913165555.GD29340@khazad-dum.debian.net
 
Old 09-17-2012, 03:06 PM
Henrique de Moraes Holschuh
 
Default Microcode and the installer ( Towards d-i wheezy beta 3)

On Thu, 13 Sep 2012, Henrique de Moraes Holschuh wrote:
> On Mon, 10 Sep 2012, Jonathan Nieder wrote:
> > (replying to -devel and -boot only)
> (I am not subscribed to -boot. Please keep -devel on replies, or CC me
> directly).
>
> > Henrique de Moraes Holschuh wrote:
> > > On Mon, 10 Sep 2012, Philipp Kern wrote:
> > >> If we do that the same should also happen for firmware-linux-nonfree. Loading
> > >> the radeon KMS module without firmware available results in an unusable
> > >> (text) console. (Yes, it might be considered a bug that radeon is loadable
> > >> without.)
> > >
> > > Sounds good to me.
> > >
> > > What should I clone and hack to try to implement this?
> >
> > <git://git.debian.org/d-i/base-installer.git>, I think.
>
> It is actually the hw-detect module, and adding support for the two system
> processor microcodes is somewhat trivial... as long as I ignore VMs. I just
> need to add a hook to pre-pkgsel.d.
>
> If I want to skip installing the processor microcode on VM images, I need to
> install and "in-target" run virt-what before the hook can decide whether
> installing the microcode packages is warranted or not.
>
> Should I attempt to install virt-what (which brings dmidecode as a
> dependency) to avoid wasting space on VM images ?

PING? I need some feedback from debian-boot or from VM users!

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120917150633.GA32392@khazad-dum.debian.net">http://lists.debian.org/20120917150633.GA32392@khazad-dum.debian.net
 

Thread Tools




All times are GMT. The time now is 04:03 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org