TL;DR: firmware support in Debian sucks, and we need to change this.
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive [...]
What would I choose to do? My personal preference would be to go with
option 5: split the non-free firmware into a special new component
and include that on official media.
Does that make me a sellout? I don't think so.
TL;DR: firmware support in Debian sucks, and we need to change this. See
the
"My preference, and rationale" Section below.
In my opinion, the way we deal with (non-free) firmware in Debian is a
mess,
and this is hurting many of our users daily. For a long time we've been pretending that supporting and including (non-free) firmware on Debian systems
is not necessary. We don't want to have to provide (non-free) firmware to
our
users, and in an ideal world we wouldn't need to. However, it's very
clearly no
longer a sensible path when trying to support lots of common current hardware.
Background - why has (non-free) firmware become an issue? =========================================================
Firmware is the low-level software that's designed to make hardware devices work. Firmware is tightly coupled to the hardware, exposing its features, providing higher-level functionality and interfaces for other software to use.
For a variety of reasons, it's typically not Free Software.
For Debian's purposes, we typically separate firmware from software by considering where the code executes (does it run on a separate processor?
Is it
visible to the host OS?) but it can be difficult to define a single
reliable
dividing line here. Consider the Intel/AMD CPU microcode packages, or the U-Boot firmware packages as examples.
In times past, all necessary firmware would normally be included directly
in
devices / expansion cards by their vendors. Over time, however, it has
become
more and more attractive (and therefore more common) for device
manufacturers
to not include complete firmware on all devices. Instead, some devices just embed a very simple set of firmware that allows for upload of a more
complete
firmware "blob" into memory. Device drivers are then expected to provide
that
blob during device initialisation.
There are a couple of key drivers for this change:
• Cost: it's typically cheaper to fit smaller flash memory (or no flash at
all) onto a device. The cost difference may seem small in many cases,
but
reducing the bill of materials (BOM) even by a few cents can make a
substantial difference to the economics of a product. For most vendors,
they will have to implement device drivers anyway and it's not
difficult to
include firmware in that driver.
• Flexibility: it's much easier to change the behaviour of a device by simply
changing to a different blob. This can potentially cover lots of different
use cases:
□ separating deadlines for hardware and software in manufacturing
(drivers and firmware can be written and shipped later);
□ bug fixes and security updates (e.g. CPU microcode changes);
□ changing configuration of a device for different users or products
(e.g. potentially different firmware to enable different
frequencies on
a radio product);
□ changing fundamental device operation (e.g. switching between RAID and
JBOD functionality on a disk controller).
Due to these reasons, more and more devices in a typical computer now need firmware to be uploaded at runtime for them to function correctly. This has grown:
• Going back 10 years or so, most computers only needed firmware uploads to
make WiFi hardware work.
• A growing number of wired network adapters now demand firmware uploads.
Some will work in a limited way but depend on extra firmware to allow
advanced features like TCP segmentation offload (TSO). Others will
refuse
to work at all without a firmware upload.
• More and more graphics adapters now also want firmware uploads to provide
any non-basic functions. A simple basic (S)VGA-compatible framebuffer
is
not enough for most users these days; modern desktops expect 3D
acceleration, and a lot of current hardware will not provide that
without
extra firmware.
• Current generations of common Intel-based laptops also need firmware
uploads to make audio work (see the firmware-sof-signed package).
At the beginning of this timeline, a typical Debian user would be able to
use
almost all of their computer's hardware without needing any firmware
blobs. It
might have been inconvenient to not be able to use the WiFi, but most
laptops
had wired ethernet anyway. The WiFi could always be enabled and configured after installation.
Today, a user with a new laptop from most vendors will struggle to use it
at
all with our firmware-free Debian installation media. Modern laptops
normally
don't come with wired ethernet now. There won't be any usable graphics on
the
laptop's screen. A visually-impaired user won't get any audio prompts.
These
experiences are not acceptable, by any measure. There are new computers
still
available for purchase today which don't need firmware to be uploaded, but they
are growing less and less common.
Current state of firmware in Debian
===================================
For clarity: obviously not all devices need extra firmware uploading like this.
There are many devices that depend on firmware for operation, but we never have
to think about them in normal circumstances. The code is not likely to be Free
Software, but it's not something that we in Debian must spend our time on
as
we're not distributing that code ourselves. Our problems come when our user needs extra firmware to make their computer work, and they need/expect us
to
provide it.
We have a small set of Free firmware binaries included in Debian main, and these are included on our installation and live media. This is great - we
all
love Free Software and this works.
However, there are many more firmware binaries that are not Free. If we are legally able to redistribute those binaries, we package them up and include them in the non-free section of the archive. As Free Software developers,
we
don't like providing or supporting non-free software for our users, but we acknowledge that it's sometimes a necessary thing for them. This tension is acknowledged in the Debian Free Software Guidelines.
This tension extends to our installation and live media. As non-free is officially not considered part of Debian, our official media cannot include anything from non-free. This has been a deliberate policy for many years. Instead, we have for some time been building a limited parallel set of "unofficial non-free" images which include non-free firmware. These
non-free
images are produced by the same software that we use for the official
images,
and by the same team.
There are a number of issues here that make developers and users unhappy:
1. Building, testing and publishing two sets of images takes more effort.
2. We don't really want to be providing non-free images at all, from a
philosophy point of view. So we mainly promote and advertise the preferred
official free images. That can be a cause of confusion for users. We do
link to the non-free images in various places, but they're not so easy
to
find.
3. Using non-free installation media will cause more installations to use
non-free software by default. That's not a great story for us, and we
may
end up with more of our users using non-free software and believing
that
it's all part of Debian.
4. A number of users and developers complain that we're wasting their
time by
publishing official images that are just not useful for a lot (a majority?)
of users.
We should do better than this.
Options
=======
The status quo is a mess, and I believe we can and should do things differently.
I see several possible options that the images team can choose from here. However, several of these options could undermine the principles of
Debian. We
don't want to make fundamental changes like that without the clear backing
of
the wider project. That's why I'm writing this...
1. Keep the existing setup. It's horrible, but maybe it's the best we can do?
(I hope not!)
2. We could just stop providing the non-free unofficial images altogether.
That's not really a promising route to follow - we'd be making it even
harder for users to install our software. While ideologically pure,
it's
not going to advance the cause of Free Software.
3. We could stop pretending that the non-free images are unofficial, and maybe
move them alongside the normal free images so they're published
together.
This would make them easier to find for people that need them, but is
likely to cause users to question why we still make any images without
firmware if they're otherwise identical.
4. The images team technically could simply include non-free into the official
images, and add firmware packages to the input lists for those images.
However, that would still leave us with problem 3 from above (non-free
generally enabled on most installations).
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media. We
would
then generate only one set of official media, including those non-free
firmware packages.
(We've already seen various suggestions in recent years to split up the
non-free component of the archive like this, for example into
non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
(bike-shedding?) about the split caused us to not make any progress on
this. I believe this project should be picked up and completed. We
don't
have to make a perfect solution here immediately, just something that works
well enough for our needs today. We can always tweak and improve the setup
incrementally if that's needed.)
These are the most likely possible options, in my opinion. If you have a better
suggestion, please let us know!
I'd like to take this set of options to a GR, and do it soon. I want to
get a
clear decision from the wider Debian project as to how to organise
firmware and
installation images. If we do end up changing how we do things, I want a clear
mandate from the project to do that.
My preference, and rationale
============================
Mainly, I want to see how the project as a whole feels here - this is a big issue that we're overdue solving.
What would I choose to do? My personal preference would be to go with
option 5:
split the non-free firmware into a special new component and include that
on
official media.
Does that make me a sellout? I don't think so. I've been passionately supporting and developing Free Software for more than half my life. My philosophy here has not changed. However, this is a complex and nuanced situation. I firmly believe that sharing software freedom with our users comes
with a responsibility to also make our software useful. If users can't
easily
install and use Debian, that helps nobody.
By splitting things out here, we would enable users to install and use
Debian
on their hardware, without promoting/pushing higher-level non-free
software in
general. I think that's a reasonable compromise. This is simply a change to recognise that hardware requirements have moved on over the years.
Further work
============
If we do go with the changes in option 5, there are other things we could
do
here for better control of and information about non-free firmware:
1. Along with adding non-free firmware onto media, when the installer (or live
image) runs, we should make it clear exactly which firmware packages
have
been used/installed to support detected hardware. We could link to docs
about each, and maybe also to projects working on Free re-implementations.
2. Add an option at boot to explicitly disable the use of the non-free
firmware packages, so that users can choose to avoid them.
Acknowledgements
================
Thanks to people who reviewed earlier versions of this document and/or made suggestions for improvement, in particular:
• Cyril Brulebois
• Matthew Garrett
• David Leggett
• Martin Michlmayr
• Andy Simpkins
• Neil Williams
--
Steve McIntyre, Cambridge, UK.
steve@einval.com
Who needs computer imagery when you've got Brian Blessed?
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media. We would
then generate only one set of official media, including those non-free > firmware packages.
What would I choose to do? My personal preference would be to go with option 5:I agree, and actually I have been supporting this position for 20
split the non-free firmware into a special new component and include that on official media.
Sections and tags don't mean anything useful in the context of the5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media. We would
then generate only one set of official media, including those non-free > firmware packages.
Aren't drivers already part of the non-free/kernel section? Maybe also query for the use::driver tag.
1. Keep the existing setup. It's horrible, but maybe it's the best we can do?
(I hope not!)>
2. We could just stop providing the non-free unofficial images altogether.
That's not really a promising route to follow - we'd be making it even
harder for users to install our software. While ideologically pure, it's
not going to advance the cause of Free Software.
3. We could stop pretending that the non-free images are unofficial, and maybe
move them alongside the normal free images so they're published together.
This would make them easier to find for people that need them, but is
likely to cause users to question why we still make any images without
firmware if they're otherwise identical.
4. The images team technically could simply include non-free into the official
images, and add firmware packages to the input lists for those images.
However, that would still leave us with problem 3 from above (non-free
generally enabled on most installations).
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media. We would
then generate only one set of official media, including those non-free
firmware packages.
What would I choose to do? My personal preference would be to go with option 5:
split the non-free firmware into a special new component and include that on official media.
Also, drivers and firmware are different things.
Hi Steve,But people promoting these two options only care about loadable firmware,
thank you for bringing this up.
On 2022-04-19 02:27, Steve McIntyre wrote:
1. Keep the existing setup. It's horrible, but maybe it's the best we can do?
(I hope not!)>
2. We could just stop providing the non-free unofficial images altogether.
That's not really a promising route to follow - we'd be making it even
harder for users to install our software. While ideologically pure, it's
not going to advance the cause of Free Software.
Here's a somewhat radical idea: I propose that we make option (1) and
(2) conditional on all Debian infra switching to hardware entirely free
of binary firmware/microcode blobs.
TL;DR: firmware support in Debian sucks, and we need to change this. See the >"My preference, and rationale" Section below.
[...]
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media. We would
then generate only one set of official media, including those non-free
firmware packages.
[...]
Thanks to people who reviewed earlier versions of this document and/or made >suggestions for improvement, in particular:
• Cyril Brulebois
• Matthew Garrett
• David Leggett
• Martin Michlmayr
• Andy Simpkins
• Neil Williams
On 2022-04-19 02:27, Steve McIntyre wrote:
1. Keep the existing setup. It's horrible, but maybe it's the best
we can do? (I hope not!)>
2. We could just stop providing the non-free unofficial images
altogether. That's not really a promising route to follow - we'd
be making it even harder for users to install our software.
While ideologically pure, it's not going to advance the cause of
Free Software.
Here's a somewhat radical idea: I propose that we make option (1) and
(2) conditional on all Debian infra switching to hardware entirely
free of binary firmware/microcode blobs.
Because if *we* can't do it, then imposing this stringency on our
users is outright idealist hypocrisy.
[Spoiler: we can't, unless some open x86_64 silicon has popped up
somewhere (doubtful, because of the required patents).]
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific
exception only to allow inclusion of those packages on our
official media. We would then generate only one set of official
media, including those non-free firmware packages.
Quoting Christian Kastner (2022-04-19 11:33:30)
Here's a somewhat radical idea: I propose that we make option (1) and
(2) conditional on all Debian infra switching to hardware entirely
free of binary firmware/microcode blobs.
Because if *we* can't do it, then imposing this stringency on our
users is outright idealist hypocrisy.
[Spoiler: we can't, unless some open x86_64 silicon has popped up
somewhere (doubtful, because of the required patents).]
I certainly like "eat our own dogfood", but our infrastructure currently
runs on _top_ of Debian systems, using non-Debian applications.
I don't think we should put the bar higher for firmware than we do for applications, regarding "eat our own dogfood". What would be the point
of that (other than artificially creating an argument for option 5)?
In other words: Please let's take this is multiple steps, first being to distinguish non-free firmware from other non-free code, without deciding
yet exactly how strongly we then allow that new section to be integrated
with our "pure" parts.
Jonas Smedegaard (2022-04-19):
In other words: Please let's take this is multiple steps, first
being to distinguish non-free firmware from other non-free code,
without deciding yet exactly how strongly we then allow that new
section to be integrated with our "pure" parts.
I tend to favor incremental approaches. In the case at hand though,
I'm worried it'll be difficult to find people motivated to accomplish
that first step (which I guess is the biggest part of the work, but
arguably yields little benefit), without some commitment from the
project to actually use that work in order to solve the problems this
thread is about.
So I'd like to understand: why do you prefer to postpone the decision?
Along with adding non-free firmware onto media, when the installer[...]
(or live image) runs, we should make it clear exactly which
firmware packages have been used/installed to support detected
hardware. We could link to docs about each, and maybe also to
projects working on Free re-implementations.
When I install systems, I consider non-free blobs more risky than other code.Do you consider loadable non-free blobs more risky than their older
When I (sometimes, but not always¹) choose to "infect" my systems with non-free packages, I therefore consider each non-free package to try minimize the amount of risky blobs on my systems. As an example, I may choose to not apply realtek firmware updates when I can verify that my ethernet device works adequately without it.Do you see some inherent value in not applying a firmware update then?
On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
When I install systems, I consider non-free blobs more risky thanDo you consider loadable non-free blobs more risky than their older
other code.
versions soldered onto the hardware?
When I (sometimes, but not always¹) choose to "infect" my systemsDo you see some inherent value in not applying a firmware update then?
with non-free packages, I therefore consider each non-free package
to try minimize the amount of risky blobs on my systems. As an
example, I may choose to not apply realtek firmware updates when I
can verify that my ethernet device works adequately without it.
[...]On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
When I install systems, I consider non-free blobs more risky than other code.Do you consider loadable non-free blobs more risky than their older versions soldered onto the hardware?
Definitely "more risky" possibly not "less secure"
One of my biggest frustrations is that it's impossible to selectively
apply "security patches" and companies are wont to "smuggle" in feature changes along with security fixes.
No, but I do see a benefit in them not being applied automatically asThen what about hardware that doesn't have soldered firmware, only
part of a standard update. And for something like a firmware upgrade for
a network card, I might only want to install it if there was a security
issue that might actually impact me or I was having a problem. Otherwise
it's hard to imagine a scenario where a firmware upgrade can make things better but it's easy to imagine it making things much worse.
apt-get upgrade will tell you that linux-image-amd64 has a newer version(this is not really relevant, not exactly true and not really a feature)
but it then takes apt-get dist-upgrade to commit to that update.
(kernels are a bit of a funny case because some kernel updates happen(most package updates happen under apt-get upgrade)
under apt-get upgrade)
I'd like to see something similar for (non-free) firmeware where usersConsidering what I wrote above, this isn't really something we usually do.
can choose to default upgrade with their regular updates or can hold
back updates.
On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
When I install systems, I consider non-free blobs more risky than otherDo you consider loadable non-free blobs more risky than their older
code.
versions soldered onto the hardware?
When I (sometimes, but not always?) choose to "infect" my systems withDo you see some inherent value in not applying a firmware update then?
non-free packages, I therefore consider each non-free package to try
minimize the amount of risky blobs on my systems. As an example, I may
choose to not apply realtek firmware updates when I can verify that my
ethernet device works adequately without it.
My laptop requires the non-free binary blobs for WiFi, AMD GPU and HDMI Sound. I think making the non-free images easier to find is a good idea. I didn't know they even existed until I got this new laptop and nothing was working with the regular installer. Placing the non-free and non-free live images along side with the free installer images would be very nice.
On Tue, Apr 19, 2022 at 04:30:44PM +0100, Tim Woodall wrote:
On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
When I install systems, I consider non-free blobs more riskyDo you consider loadable non-free blobs more risky than their
than other code.
older versions soldered onto the hardware?
Definitely "more risky" possibly not "less secure"
One of my biggest frustrations is that it's impossible to[...]
selectively apply "security patches" and companies are wont to
"smuggle" in feature changes along with security fixes.
No, but I do see a benefit in them not being applied automaticallyThen what about hardware that doesn't have soldered firmware, only
as part of a standard update. And for something like a firmware
upgrade for a network card, I might only want to install it if there
was a security issue that might actually impact me or I was having a problem. Otherwise it's hard to imagine a scenario where a firmware upgrade can make things better but it's easy to imagine it making
things much worse.
loadable one? Would you not use it at all?
One valuable suggestion was to make sure users could easily select
freedom if that's what they wanted.
So I think a free installation image is important.
On Tue, Apr 19, 2022 at 04:30:44PM +0100, Tim Woodall wrote:
[...]On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:Definitely "more risky" possibly not "less secure"
When I install systems, I consider non-free blobs more risky than other >>>> code.Do you consider loadable non-free blobs more risky than their older
versions soldered onto the hardware?
One of my biggest frustrations is that it's impossible to selectively
apply "security patches" and companies are wont to "smuggle" in feature
changes along with security fixes.
No, but I do see a benefit in them not being applied automatically asThen what about hardware that doesn't have soldered firmware, only
part of a standard update. And for something like a firmware upgrade for
a network card, I might only want to install it if there was a security
issue that might actually impact me or I was having a problem. Otherwise
it's hard to imagine a scenario where a firmware upgrade can make things
better but it's easy to imagine it making things much worse.
loadable one? Would you not use it at all?
I notice that you shift the conversation topic from *upgrading*
firmware to *introducing* firmware.
I already mentioned that I would sometimes upgrade to newer firmware,
which I mean to imply that yes I would sometimes dare to permit my
devices to execute firmware. Sorry if that was unclear.
My concern is about hardware changing behavior. I.e. hardware not
being stable.
You partially narrowed the topic to upgrading firmware in <165037188392.1708.14819384411900940205@auryn.jones.dk>, so yes, I'mWhen I install systems, I consider non-free blobs more riskyDo you consider loadable non-free blobs more risky than their
than other code.
older versions soldered onto the hardware?
Definitely "more risky" possibly not "less secure"
One of my biggest frustrations is that it's impossible to[...]
selectively apply "security patches" and companies are wont to
"smuggle" in feature changes along with security fixes.
No, but I do see a benefit in them not being applied automaticallyThen what about hardware that doesn't have soldered firmware, only loadable one? Would you not use it at all?
as part of a standard update. And for something like a firmware
upgrade for a network card, I might only want to install it if there
was a security issue that might actually impact me or I was having a problem. Otherwise it's hard to imagine a scenario where a firmware upgrade can make things better but it's easy to imagine it making
things much worse.
I notice that you shift the conversation topic from *upgrading* firmware
to *introducing* firmware.
Now, some may argue that I am describing a case for package pinning
here, and that *might* be true but I don't know that yet - because the proposed change to the system does not exist yet so I cannot really know
that yet. Possibly the implementation will be so that I continuously
need to check if some new non-free blobs was introduced and block those, instead of the current situation of not needing to do anything actively
to keeping most possible risky "stuff" away from my systems.
3. We could stop pretending that the non-free images are unofficial, and
maybe move them alongside the normal free images so they're published
together.
This would make them easier to find for people that need them, but is
likely to cause users to question why we still make any images without
firmware if they're otherwise identical.
...
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific
exception only to allow inclusion of those packages on our official media.
We would then generate only one set of official media, including those
non-free firmware packages.
"Marc" == Marc Haber <mh+debian-devel@zugschlus.de> writes:
For example I would thinki it would be entirely reasonable for someoneWhile I do not expect that this is a significant use case I think that
to want to include a version of Debian installer for use with qemu in an environment that needed to be DFSG free.
Similarly, I think it would be reasonable for someone to want to provide entirely free Debian media along with a libre laptop.
It's probably what you meant, but just to be clear, as a user I'd
also want to know which of the firmware packages used/installed were
pulled from non-free and what devices prompted their addition.
Something like "The following packages do not meet Debian Free
Software Guidelines but were installed because they're necessary in
order to enable or secure some of your hardware: foo(CPUX21
processor microcode), bar(PM2743 power management controller),
baz(RF17G wireless interface), ..."
Marc> Would that not be possible by having an image WITH firmware
Marc> and an installer asking whether the user wants a free or a
Marc> usable system?
For example I would thinki it would be entirely reasonable for someone
to want to include a version of Debian installer for use with qemu in an environment that needed to be DFSG free.
Similarly, I think it would be reasonable for someone to want to provide entirely free Debian media along with a libre laptop.
If providing an image that includes but does not use non-free components
is acceptable for our users, we could save ourselves a lot of time and complexity by not repacking sources that include non-dfsg components.
We could just not use those components at least when targeting main for binaries.
On Tue, Apr 19, 2022 at 06:51:16PM +0200, Jonas Smedegaard wrote:
When I install systems, I consider non-free blobs more riskyDo you consider loadable non-free blobs more risky than their
than other code.
older versions soldered onto the hardware?
Definitely "more risky" possibly not "less secure"
One of my biggest frustrations is that it's impossible to[...]
selectively apply "security patches" and companies are wont to "smuggle" in feature changes along with security fixes.
No, but I do see a benefit in them not being appliedThen what about hardware that doesn't have soldered firmware, only loadable one? Would you not use it at all?
automatically as part of a standard update. And for something
like a firmware upgrade for a network card, I might only want to install it if there was a security issue that might actually
impact me or I was having a problem. Otherwise it's hard to
imagine a scenario where a firmware upgrade can make things
better but it's easy to imagine it making things much worse.
I notice that you shift the conversation topic from *upgrading*You partially narrowed the topic to upgrading firmware in <165037188392.1708.14819384411900940205@auryn.jones.dk>, so yes, I'm
firmware to *introducing* firmware.
asking about both sides of the question. I will even say that the
situation where some perfectly usable firmware is already available on
the device, and Debian just offers an update to it, is much less
important (but still very important for e.g. intel-microcode) than the situation where the device is not usable without firmware loaded by
Debian, which is the main usability problem with the status quo.
Firmware shipped as packages part of stable releases will probably
change the same way as software (i.e., security updates, other
important updates). So there should be not much reason for such
concern.
Such concerns would be more relevant for firmware updates using other
update channels such as `fwupd` uses.
Jonas Smedegaard <jonas@jones.dk> writes:
Now, some may argue that I am describing a case for package pinning
here, and that *might* be true but I don't know that yet - because
the proposed change to the system does not exist yet so I cannot
really know that yet. Possibly the implementation will be so that I continuously need to check if some new non-free blobs was introduced
and block those, instead of the current situation of not needing to
do anything actively to keeping most possible risky "stuff" away
from my systems.
I feel like Debian already offers multiple mechanisms to prevent installation or updates of packages, both specific packages and
packages by suite, archive, etc. I'm dubious that we need some
additional extra-special mechanism just for firmware, as opposed to documenting the many and varied mechanisms we already support for
pinning old packages, disabling automated upgrades, and so forth.
We need some way to clearly label non-free firmware packages so that
you can apply whatever installation or upgrade policy locally that you
want to apply, but solution #5 provides that by keeping the non-free firmware in a separate archive area (which apt calls "components") to
which you can apply different apt policy.
Quoting Russ Allbery (2022-04-19 19:29:09)
We need some way to clearly label non-free firmware packages so that
you can apply whatever installation or upgrade policy locally that you
want to apply, but solution #5 provides that by keeping the non-free
firmware in a separate archive area (which apt calls "components") to
which you can apply different apt policy.
The issue I have with option 5 is that non-free blobs are then enabled
by default.
I agree that we should make it easier for our users to choose to trust
black magic "stuff" that they need to enable their devices.
I do not think that we should impose on our users to trust black magic
by default, though.
I do not think that we should impose on our users to trust black magic
by default, though.
I think that all non-free code distributed by Debian (be that code
executed on the main CPU, and code uploaded to external devices, and
code served to other people's web browsers) should be easy to use but opt-in, not (some of it) opt-out. Because we cannot reasonably know
what it realy does and therefore not reasonably decide if sensible to
trust or not. We can only blindly assume that "newer is better".
On Tue, Apr 19, 2022 at 12:17:06PM +0000, Jeremy Stanley wrote:
It's probably what you meant, but just to be clear, as a user I'd
also want to know which of the firmware packages used/installed were
pulled from non-free and what devices prompted their addition.
Something like "The following packages do not meet Debian Free
Software Guidelines but were installed because they're necessary in
order to enable or secure some of your hardware: foo(CPUX21
processor microcode), bar(PM2743 power management controller),
baz(RF17G wireless interface), ..."
Why? Don't you want to use your devices? And will you also remove the
flash chips for the ones that contain a backed in firmware (aka all of
them)?
Quoting Ansgar (2022-04-19 19:04:36)
Firmware shipped as packages part of stable releases will probably
change the same way as software (i.e., security updates, other
important updates). So there should be not much reason for such
concern.
Such concerns would be more relevant for firmware updates using
other
update channels such as `fwupd` uses.
I wonder how you can confidently know that non-free blobs packages
for Debian are only likely to be improvements, when you cannot
verify their contents.
And how is it that fwupd distributed blobs are less likely to be
reliable. What am I missing here?
I thought I shifted the conversation topic from *upgrading* firmware to *introducing* firmware?When I install systems, I consider non-free blobs more risky than other code.Do you consider loadable non-free blobs more risky than their older versions soldered onto the hardware?
Definitely "more risky" possibly not "less secure"
One of my biggest frustrations is that it's impossible to selectively apply "security patches" and companies are wont to "smuggle" in feature changes along with security fixes.[...]
No, but I do see a benefit in them not being appliedThen what about hardware that doesn't have soldered firmware, only loadable one? Would you not use it at all?
automatically as part of a standard update. And for something
like a firmware upgrade for a network card, I might only want to install it if there was a security issue that might actually
impact me or I was having a problem. Otherwise it's hard to
imagine a scenario where a firmware upgrade can make things
better but it's easy to imagine it making things much worse.
I notice that you shift the conversation topic from *upgrading*You partially narrowed the topic to upgrading firmware in <165037188392.1708.14819384411900940205@auryn.jones.dk>, so yes, I'm asking about both sides of the question. I will even say that the situation where some perfectly usable firmware is already available on
firmware to *introducing* firmware.
the device, and Debian just offers an update to it, is much less
important (but still very important for e.g. intel-microcode) than the situation where the device is not usable without firmware loaded by Debian, which is the main usability problem with the status quo.
Ah, so your view is that newer blob might...
Similarly, I think it would be reasonable for someone to want to provide
entirely free Debian media along with a libre laptop.
Does this exist in the real world? Which hardware would such a system >contain?
Here's a somewhat radical idea: I propose that we make option (1) and
(2) conditional on all Debian infra switching to hardware entirely free
of binary firmware/microcode blobs.
Because if *we* can't do it, then imposing this stringency on our users
is outright idealist hypocrisy.
We have a small set of Free firmware binaries included in Debian main, and these are included on our installation and live media. This is great - we all love Free Software and this works.
Similarly, I think it would be reasonable for someone to want to provide >> entirely free Debian media along with a libre laptop.
Does this exist in the real world? Which hardware would such a system >contain?
liberated.computer it is refurbished and some components like wifi cards replaced so it works with 100% free software.
On Wed, Apr 20, 2022 at 12:55:44PM +0530, Pirate Praveen wrote:
Similarly, I think it would be reasonable for someone to want to provide >> >> entirely free Debian media along with a libre laptop.
Does this exist in the real world? Which hardware would such a system
contain?
liberated.computer it is refurbished and some components like wifi cards replaced so it works with 100% free software.
Intel Core i5-3320M CPU (dual-core, four threads, 3rd Gen)
So no.
This tension extends to our installation and live media. As non-free is >officially not considered part of Debian, our official media cannot include >anything from non-free. This has been a deliberate policy for many years. >Instead, we have for some time been building a limited parallel set of >"unofficial non-free" images which include non-free firmware. These non-free >images are produced by the same software that we use for the official images, >and by the same team.
There are a number of issues here that make developers and users unhappy:
1. Building, testing and publishing two sets of images takes more effort.
2. We don't really want to be providing non-free images at all, from a
philosophy point of view. So we mainly promote and advertise the preferred
official free images. That can be a cause of confusion for users. We do
link to the non-free images in various places, but they're not so easy to
find.
3. Using non-free installation media will cause more installations to use
non-free software by default. That's not a great story for us, and we may
end up with more of our users using non-free software and believing that
it's all part of Debian.
4. A number of users and developers complain that we're wasting their time by
publishing official images that are just not useful for a lot (a majority?)
of users.
We should do better than this.
Options
=======
The status quo is a mess, and I believe we can and should do things >differently.
I see several possible options that the images team can choose from here. >However, several of these options could undermine the principles of Debian. We >don't want to make fundamental changes like that without the clear backing of >the wider project. That's why I'm writing this...
1. Keep the existing setup. It's horrible, but maybe it's the best we can do?
(I hope not!)
2. We could just stop providing the non-free unofficial images altogether.
That's not really a promising route to follow - we'd be making it even
harder for users to install our software. While ideologically pure, it's
not going to advance the cause of Free Software.
3. We could stop pretending that the non-free images are unofficial, and maybe
move them alongside the normal free images so they're published together.
This would make them easier to find for people that need them, but is
likely to cause users to question why we still make any images without
firmware if they're otherwise identical.
4. The images team technically could simply include non-free into the official
images, and add firmware packages to the input lists for those images.
However, that would still leave us with problem 3 from above (non-free
generally enabled on most installations).
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media. We would
then generate only one set of official media, including those non-free
firmware packages.
(We've already seen various suggestions in recent years to split up the
non-free component of the archive like this, for example into
non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
(bike-shedding?) about the split caused us to not make any progress on
this. I believe this project should be picked up and completed. We don't
have to make a perfect solution here immediately, just something that works
well enough for our needs today. We can always tweak and improve the setup
incrementally if that's needed.)
These are the most likely possible options, in my opinion. If you have a better
suggestion, please let us know!
I'd like to take this set of options to a GR, and do it soon. I want to get a >clear decision from the wider Debian project as to how to organise firmware and
installation images. If we do end up changing how we do things, I want a clear >mandate from the project to do that.
My preference, and rationale
============================
Mainly, I want to see how the project as a whole feels here - this is a big >issue that we're overdue solving.
What would I choose to do? My personal preference would be to go with option 5:
split the non-free firmware into a special new component and include that on >official media.
Does that make me a sellout? I don't think so. I've been passionately >supporting and developing Free Software for more than half my life. My >philosophy here has not changed. However, this is a complex and nuanced >situation. I firmly believe that sharing software freedom with our users comes >with a responsibility to also make our software useful. If users can't easily >install and use Debian, that helps nobody.
By splitting things out here, we would enable users to install and use Debian >on their hardware, without promoting/pushing higher-level non-free software in >general. I think that's a reasonable compromise. This is simply a change to >recognise that hardware requirements have moved on over the years.
Further work
============
If we do go with the changes in option 5, there are other things we could do >here for better control of and information about non-free firmware:
1. Along with adding non-free firmware onto media, when the installer (or live
image) runs, we should make it clear exactly which firmware packages have
been used/installed to support detected hardware. We could link to docs
about each, and maybe also to projects working on Free re-implementations.
2. Add an option at boot to explicitly disable the use of the non-free
firmware packages, so that users can choose to avoid them.
Acknowledgements
================
Thanks to people who reviewed earlier versions of this document and/or made >suggestions for improvement, in particular:
• Cyril Brulebois
• Matthew Garrett
• David Leggett
• Martin Michlmayr
• Andy Simpkins
• Neil Williams
Similarly, I think it would be reasonable for someone to want to provide
entirely free Debian media along with a libre laptop.
Does this exist in the real world? Which hardware would such a system
contain?
liberated.computer it is refurbished and some components like wifi cards replaced so it works with 100% free software.
Intel Core i5-3320M CPU (dual-core, four threads, 3rd Gen)
So no.
What is no here? This project don't exist or they don't want to provide a libre image?Intel CPUs contain non-free microcode. Using them even implies enabling
Debian's free image works on these laptops and if we make only non-free images they won't be able to provide a fully free image.Eh, Debian's free image works on a lot of hardware, especially when you
liberated.computer it is refurbished and some components like wifi
cards replaced so it works with 100% free software.
Jonas Smedegaard <jonas@jones.dk> writes:
Quoting Russ Allbery (2022-04-19 19:29:09)
We need some way to clearly label non-free firmware packages so
that you can apply whatever installation or upgrade policy locally
that you want to apply, but solution #5 provides that by keeping
the non-free firmware in a separate archive area (which apt calls
"components") to which you can apply different apt policy.
The issue I have with option 5 is that non-free blobs are then
enabled by default.
I just re-read option 5 and I don't see where it says that. My understanding of the proposal is that the firmware would be on the
image and thus available to the installer. That doesn't imply that it
will be automatically enabled, either in the installer or on the
installed system. That could still be gated by a prompt.
2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre <steve@einval.com>ൽ എഴുതി
This tension extends to our installation and live media. As non-free is >officially not considered part of Debian, our official media cannotinclude
anything from non-free. This has been a deliberate policy for many years. >Instead, we have for some time been building a limited parallel set of >"unofficial non-free" images which include non-free firmware. Thesenon-free
images are produced by the same software that we use for the official images,
and by the same team.
There are a number of issues here that make developers and users unhappy:
1. Building, testing and publishing two sets of images takes more effort.
Can we reduce the tests? Do we really need to test both images for all
cases?
2. We don't really want to be providing non-free images at all, from apreferred
philosophy point of view. So we mainly promote and advertise the
official free images. That can be a cause of confusion for users. Wedo
link to the non-free images in various places, but they're not soeasy to
find.
I'm fine making it easier to find.
3. Using non-free installation media will cause more installations to usemay
non-free software by default. That's not a great story for us, and we
end up with more of our users using non-free software and believingthat
it's all part of Debian.
So a separate non-free firmware section as you proposed could work.
4. A number of users and developers complain that we're wasting theirtime by
publishing official images that are just not useful for a lot (amajority?)
of users.
Isn't voluntary work being able to work on things you care and not necessarily what majority wants?
I can understand if the current volunteers that produce and test fully
free images don't want to continue and no one else step up. Shouldn't this
be a call for volunteers ?
May be more people step in to maintain the free images if there is a call
for volunteers.
We should do better than this.
Options
=======
The status quo is a mess, and I believe we can and should do things >differently.
I see several possible options that the images team can choose from here. >However, several of these options could undermine the principles ofDebian. We
don't want to make fundamental changes like that without the clearbacking of
the wider project. That's why I'm writing this...
1. Keep the existing setup. It's horrible, but maybe it's the best wecan do?
(I hope not!)
As I said earlier, making non-free more prominent and more volunteers to maintain fully free images could work to reduce load on existing volunteers.
2. We could just stop providing the non-free unofficial imagesaltogether.
That's not really a promising route to follow - we'd be making it evenit's
harder for users to install our software. While ideologically pure,
not going to advance the cause of Free Software.
I think we should continue creating non-free images.
3. We could stop pretending that the non-free images are unofficial, andmaybe
move them alongside the normal free images so they're publishedtogether.
This would make them easier to find for people that need them, but is
likely to cause users to question why we still make any images without
firmware if they're otherwise identical.
This should be fine. This could be used as an opportunity to educate users and recommending to choose hardware which works with free images. We can highlight h-node.org here.
4. The images team technically could simply include non-free into theofficial
images, and add firmware packages to the input lists for those images.
However, that would still leave us with problem 3 from above (non-free
generally enabled on most installations).
I don't think we should do this.
5. We could split out the non-free firmware packages into a newexception
non-free-firmware component in the archive, and allow a specific
only to allow inclusion of those packages on our official media. Wewould
then generate only one set of official media, including those non-free
firmware packages.
I'm okay with it only if we don't get enough volunteers to maintain two images.
(We've already seen various suggestions in recent years to split upthe
non-free component of the archive like this, for example intodon't
non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
(bike-shedding?) about the split caused us to not make any progress on
this. I believe this project should be picked up and completed. We
have to make a perfect solution here immediately, just something thatworks
well enough for our needs today. We can always tweak and improve thesetup
incrementally if that's needed.)
These are the most likely possible options, in my opinion. If you have a better
suggestion, please let us know!
As mentioned earlier, call for volunteers to maintain two sets or reducing the number of test cases (some cases only tested with non-free and some tested only with free images)
I'd like to take this set of options to a GR, and do it soon. I want toget a
clear decision from the wider Debian project as to how to organisefirmware and
installation images. If we do end up changing how we do things, I want a clear
mandate from the project to do that.
My preference, and rationale
============================
Mainly, I want to see how the project as a whole feels here - this is abig
issue that we're overdue solving.
What would I choose to do? My personal preference would be to go withoption 5:
split the non-free firmware into a special new component and include thaton
official media.
Does that make me a sellout? I don't think so. I've been passionately >supporting and developing Free Software for more than half my life. My >philosophy here has not changed. However, this is a complex and nuanced >situation. I firmly believe that sharing software freedom with our users comes
with a responsibility to also make our software useful. If users can't easily
install and use Debian, that helps nobody.
By splitting things out here, we would enable users to install and use Debiansoftware in
on their hardware, without promoting/pushing higher-level non-free
general. I think that's a reasonable compromise. This is simply a changeto
recognise that hardware requirements have moved on over the years.
Further work
============
If we do go with the changes in option 5, there are other things we coulddo
here for better control of and information about non-free firmware:
1. Along with adding non-free firmware onto media, when the installer(or live
image) runs, we should make it clear exactly which firmware packageshave
been used/installed to support detected hardware. We could link todocs
about each, and maybe also to projects working on Freere-implementations.
Good idea.
2. Add an option at boot to explicitly disable the use of the non-free
firmware packages, so that users can choose to avoid them.
Acknowledgements
================
Thanks to people who reviewed earlier versions of this document and/ormade
suggestions for improvement, in particular:
• Cyril Brulebois
• Matthew Garrett
• David Leggett
• Martin Michlmayr
• Andy Simpkins
• Neil Williams
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
<br></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen <<a href="mailto:praveen@onenetbeyond.org">praveen@onenetbeyond.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
In case my own wasn't clear, what I meant was: (a) all of the x86_64
hosts in our infrastructure use CPUs that utilize non-free microcode,
and (b) unless we're crazy, those hosts also use the non-free
intel-microcode or amd64-microcode packages to get security fixes.
Here's an even more radical thought: shipping any x86_64 installer CD
without amd64-microcode and intel-microcode installed by default is a >disservice to our users. There's no ideological "Win" when you're paying
for it with the user's security, especially when they might be unaware
of the problem.
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific
exception only to allow inclusion of those packages on our official
media. We would then generate only one set of official media,
including those non-free firmware packages.
I recently tried to install Debian onto my new laptop. It's an HP Pavilian (can't remember the exact model sorry) with an AMD Rizon 5500 processor with integrated Radion graphic. All seemed to work well, until
I came to the detecting Internet stage of the install. It couldn't
detect my Wi-fi card. So then, I found the Non-free section and got the
CD version? I guess that's what I should have gotten? The DVD one is the
live environment right? See how confusion this can be? Anyway, I booted
that up, pressed s then Enter cause I'm blind, then began the install
again. The same thing happened. So apparently even the non-free images
don't contain all of the drivers. I know a driver for my card exists,
since Fedora has it. So, since Debian "won't work" on my system (that's
what a user *will* think), I went back to Windows, where I have all the
few games blind people can play, the MUD clients with sound packs, Twitter/Mastodon/Telegram clients that were made by the blind, for the
blind, a screen reader with wide community support, and a DE with
developers focusingon accessibility. Of course, that's just my use case
as a blind person. Others may focus on the graphics card, Wi-fi, sound
card, power management (My battery will never run out of power according
to acpi), or CPU management.
Ah well. Maybe Ubuntu will have the Wi-fi card. I mean they are a
company but when a group of regular people don't give something that I
can even install without plugging in my phone, finishing install,
somehow finding the right driver for my Wi-fi card, and then finally
being able to use it, then the first thing people will do is go find something else. They'll say "Okay well Debian is just for servers and 'FossBros'," shake their head, and move on.
This is from a user's perspective. It's hard enough to get them to want
to use Linux. A lot of people don't even know you can change the
operating system on your computer! So then for them to try Debian, which
is probably one of, if not the most, accessible of all distros thanks to
our few Debian Accessibility team, and then find that their network card isn't going to work, they'll run back to Windows. And to be clear, for a blind person, the only thing Linux has over Windows at this point is
that you can print text *and* images to a Braille printer. You can't do
that in Windows without expensive software. All the games, software for
the blind, Twitter/Mastodon/Telegram clients, all that is on Windows. So
for a blind person, switching from all that is gonna be even harder. So
the first sign of resistance will send them back.
Also, should we have to work for Debian? Shouldn't it make our computing
life easier by at least including the stuff we need to use all parts of
our computer? Besides that, with computers becoming even more "secure"
with Microsoft working on a chip, AMD and Intel having their stuff,
we'll *have* to include nonfree stuff in Debian eventually. Might as
well do it now to make users' lives a little easier for practice.
Another thing I just thought of, I wonder if, when we find hardware in
the installer that we don't have drivers for, if we can search for
drivers on apt, including the nonfree section, and ask if the user wants
to install them? The user would probably have to connect their phone for
the Wi-fi bit, but then all the stuff could easily be installed.
Devin Prater
r.d.t.prater@gmail.com <mailto:r.d.t.prater@gmail.com>
On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen <praveen@onenetbeyond.org <mailto:praveen@onenetbeyond.org>> wrote:
2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre <steve@einval.com
<mailto:steve@einval.com>>ൽ എഴുതി
>This tension extends to our installation and live media. As non-free is
>officially not considered part of Debian, our official media cannot
include
>anything from non-free. This has been a deliberate policy for many
years.
>Instead, we have for some time been building a limited parallel set of
>"unofficial non-free" images which include non-free firmware. These
non-free
>images are produced by the same software that we use for the
official images,
>and by the same team.
>
>There are a number of issues here that make developers and users
unhappy:
>
> 1. Building, testing and publishing two sets of images takes more
effort.
Can we reduce the tests? Do we really need to test both images for
all cases?
> 2. We don't really want to be providing non-free images at all, from a
> philosophy point of view. So we mainly promote and advertise
the preferred
> official free images. That can be a cause of confusion for
users. We do
> link to the non-free images in various places, but they're not
so easy to
> find.
I'm fine making it easier to find.
> 3. Using non-free installation media will cause more installations
to use
> non-free software by default. That's not a great story for us,
and we may
> end up with more of our users using non-free software and
believing that
> it's all part of Debian.
So a separate non-free firmware section as you proposed could work.
> 4. A number of users and developers complain that we're wasting
their time by
> publishing official images that are just not useful for a lot
(a majority?)
> of users.
Isn't voluntary work being able to work on things you care and not
necessarily what majority wants?
I can understand if the current volunteers that produce and test
fully free images don't want to continue and no one else step up.
Shouldn't this be a call for volunteers ?
May be more people step in to maintain the free images if there is a
call for volunteers.
>We should do better than this.
>
>Options
>=======
>
>The status quo is a mess, and I believe we can and should do things
>differently.
>
>I see several possible options that the images team can choose from
here.
>However, several of these options could undermine the principles of
Debian. We
>don't want to make fundamental changes like that without the clear
backing of
>the wider project. That's why I'm writing this...
>
> 1. Keep the existing setup. It's horrible, but maybe it's the best
we can do?
> (I hope not!)
>
As I said earlier, making non-free more prominent and more
volunteers to maintain fully free images could work to reduce load
on existing volunteers.
> 2. We could just stop providing the non-free unofficial images
altogether.
> That's not really a promising route to follow - we'd be making
it even
> harder for users to install our software. While ideologically
pure, it's
> not going to advance the cause of Free Software.
I think we should continue creating non-free images.
> 3. We could stop pretending that the non-free images are
unofficial, and maybe
> move them alongside the normal free images so they're published
together.
> This would make them easier to find for people that need them,
but is
> likely to cause users to question why we still make any images
without
> firmware if they're otherwise identical.
This should be fine. This could be used as an opportunity to educate
users and recommending to choose hardware which works with free
images. We can highlight h-node.org <http://h-node.org> here.
> 4. The images team technically could simply include non-free into
the official
> images, and add firmware packages to the input lists for those
images.
> However, that would still leave us with problem 3 from above
(non-free
> generally enabled on most installations).
I don't think we should do this.
> 5. We could split out the non-free firmware packages into a new
> non-free-firmware component in the archive, and allow a
specific exception
> only to allow inclusion of those packages on our official
media. We would
> then generate only one set of official media, including those
non-free
> firmware packages.
I'm okay with it only if we don't get enough volunteers to maintain
two images.
> (We've already seen various suggestions in recent years to
split up the
> non-free component of the archive like this, for example into
> non-free-firmware, non-free-doc, non-free-drivers, etc.
Disagreement
> (bike-shedding?) about the split caused us to not make any
progress on
> this. I believe this project should be picked up and completed.
We don't
> have to make a perfect solution here immediately, just
something that works
> well enough for our needs today. We can always tweak and
improve the setup
> incrementally if that's needed.)
>
>These are the most likely possible options, in my opinion. If you
have a better
>suggestion, please let us know!
As mentioned earlier, call for volunteers to maintain two sets or
reducing the number of test cases (some cases only tested with
non-free and some tested only with free images)
>I'd like to take this set of options to a GR, and do it soon. I
want to get a
>clear decision from the wider Debian project as to how to organise
firmware and
>installation images. If we do end up changing how we do things, I
want a clear
>mandate from the project to do that.
>
>My preference, and rationale
>============================
>
>Mainly, I want to see how the project as a whole feels here - this
is a big
>issue that we're overdue solving.
>
>What would I choose to do? My personal preference would be to go
with option 5:
>split the non-free firmware into a special new component and
include that on
>official media.
>
>Does that make me a sellout? I don't think so. I've been passionately
>supporting and developing Free Software for more than half my life. My
>philosophy here has not changed. However, this is a complex and nuanced
>situation. I firmly believe that sharing software freedom with our
users comes
>with a responsibility to also make our software useful. If users
can't easily
>install and use Debian, that helps nobody.
>
>By splitting things out here, we would enable users to install and
use Debian
>on their hardware, without promoting/pushing higher-level non-free
software in
>general. I think that's a reasonable compromise. This is simply a
change to
>recognise that hardware requirements have moved on over the years.
>
>Further work
>============
>
>If we do go with the changes in option 5, there are other things we
could do
>here for better control of and information about non-free firmware:
>
> 1. Along with adding non-free firmware onto media, when the
installer (or live
> image) runs, we should make it clear exactly which firmware
packages have
> been used/installed to support detected hardware. We could link
to docs
> about each, and maybe also to projects working on Free
re-implementations.
Good idea.
> 2. Add an option at boot to explicitly disable the use of the non-free
> firmware packages, so that users can choose to avoid them.
>
>Acknowledgements
>================
>
>Thanks to people who reviewed earlier versions of this document
and/or made
>suggestions for improvement, in particular:
>
> • Cyril Brulebois
> • Matthew Garrett
> • David Leggett
> • Martin Michlmayr
> • Andy Simpkins
> • Neil Williams
>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Wed, Apr 20, 2022 at 01:25:31PM +0530, Pirate Praveen wrote:
Intel CPUs contain non-free microcode. Using them even implies enablingSimilarly, I think it would be reasonable for someone to want to provide >>>>>> entirely free Debian media along with a libre laptop.
Does this exist in the real world? Which hardware would such a system >>>>> contain?
liberated.computer it is refurbished and some components like wifi cards replaced so it works with 100% free software.
Intel Core i5-3320M CPU (dual-core, four threads, 3rd Gen)
So no.
What is no here? This project don't exist or they don't want to provide a libre image?
the Debian non-free repo to get security fixes for it.
Intel GPUs reportedly don't work good enough, or at all, without non-free firmware, according to the surveys done during the bullseye freeze.
Debian's free image works on these laptops and if we make only non-free images they won't be able to provide a fully free image.Eh, Debian's free image works on a lot of hardware, especially when you
don't need to download anything during the install (e.g. because you use a DVD image or don't install a GUI), the installed system, on the other
hand...
But I agree that technically it's fine "to provide entirely free Debian
media along with a libre laptop" in this case.
There are a number of issues here that make developers and users unhappy:
Answer bellow this awful piece of text from someone who doesn't know how
to make a space between line.
On 2022-04-20 06:04, Devin Prater wrote:
I recently tried to install Debian onto my new laptop. It's an HP
Pavilian (can't remember the exact model sorry) with an AMD Rizon 5500
processor with integrated Radion graphic. All seemed to work well, until
I came to the detecting Internet stage of the install. It couldn't
detect my Wi-fi card. So then, I found the Non-free section and got the
CD version? I guess that's what I should have gotten? The DVD one is the
live environment right? See how confusion this can be? Anyway, I booted
that up, pressed s then Enter cause I'm blind, then began the install
again. The same thing happened. So apparently even the non-free images
don't contain all of the drivers. I know a driver for my card exists,
since Fedora has it. So, since Debian "won't work" on my system (that's
what a user *will* think), I went back to Windows, where I have all the
few games blind people can play, the MUD clients with sound packs,
Twitter/Mastodon/Telegram clients that were made by the blind, for the
blind, a screen reader with wide community support, and a DE with
developers focusingon accessibility. Of course, that's just my use case
as a blind person. Others may focus on the graphics card, Wi-fi, sound
card, power management (My battery will never run out of power according
to acpi), or CPU management.
Ah well. Maybe Ubuntu will have the Wi-fi card. I mean they are a
company but when a group of regular people don't give something that I
can even install without plugging in my phone, finishing install,
somehow finding the right driver for my Wi-fi card, and then finally
being able to use it, then the first thing people will do is go find
something else. They'll say "Okay well Debian is just for servers and
'FossBros'," shake their head, and move on.
This is from a user's perspective. It's hard enough to get them to want
to use Linux. A lot of people don't even know you can change the
operating system on your computer! So then for them to try Debian, which
is probably one of, if not the most, accessible of all distros thanks to
our few Debian Accessibility team, and then find that their network card
isn't going to work, they'll run back to Windows. And to be clear, for a
blind person, the only thing Linux has over Windows at this point is
that you can print text *and* images to a Braille printer. You can't do
that in Windows without expensive software. All the games, software for
the blind, Twitter/Mastodon/Telegram clients, all that is on Windows. So
for a blind person, switching from all that is gonna be even harder. So
the first sign of resistance will send them back.
Also, should we have to work for Debian? Shouldn't it make our computing
life easier by at least including the stuff we need to use all parts of
our computer? Besides that, with computers becoming even more "secure"
with Microsoft working on a chip, AMD and Intel having their stuff,
we'll *have* to include nonfree stuff in Debian eventually. Might as
well do it now to make users' lives a little easier for practice.
Another thing I just thought of, I wonder if, when we find hardware in
the installer that we don't have drivers for, if we can search for
drivers on apt, including the nonfree section, and ask if the user wants
to install them? The user would probably have to connect their phone for
the Wi-fi bit, but then all the stuff could easily be installed.
Devin Prater
r.d.t.prater@gmail.com <mailto:r.d.t.prater@gmail.com>
On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen <praveen@onenetbeyond.org
<mailto:praveen@onenetbeyond.org>> wrote:
2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre <steve@einval.com
<mailto:steve@einval.com>>ൽ എഴുതി
>This tension extends to our installation and live media. As non-free is >> >officially not considered part of Debian, our official media cannot
include
>anything from non-free. This has been a deliberate policy for many
years.
>Instead, we have for some time been building a limited parallel set of >> >"unofficial non-free" images which include non-free firmware. These
non-free
>images are produced by the same software that we use for the
official images,
>and by the same team.
>
>There are a number of issues here that make developers and users
unhappy:
>
> 1. Building, testing and publishing two sets of images takes more
effort.
Can we reduce the tests? Do we really need to test both images for
all cases?
> 2. We don't really want to be providing non-free images at all, from a >> > philosophy point of view. So we mainly promote and advertise
the preferred
> official free images. That can be a cause of confusion for
users. We do
> link to the non-free images in various places, but they're not
so easy to
> find.
I'm fine making it easier to find.
> 3. Using non-free installation media will cause more installations
to use
> non-free software by default. That's not a great story for us,
and we may
> end up with more of our users using non-free software and
believing that
> it's all part of Debian.
So a separate non-free firmware section as you proposed could work.
> 4. A number of users and developers complain that we're wasting
their time by
> publishing official images that are just not useful for a lot
(a majority?)
> of users.
Isn't voluntary work being able to work on things you care and not
necessarily what majority wants?
I can understand if the current volunteers that produce and test
fully free images don't want to continue and no one else step up.
Shouldn't this be a call for volunteers ?
May be more people step in to maintain the free images if there is a
call for volunteers.
>We should do better than this.
>
>Options
>=======
>
>The status quo is a mess, and I believe we can and should do things
>differently.
>
>I see several possible options that the images team can choose from
here.
>However, several of these options could undermine the principles of
Debian. We
>don't want to make fundamental changes like that without the clear
backing of
>the wider project. That's why I'm writing this...
>
> 1. Keep the existing setup. It's horrible, but maybe it's the best
we can do?
> (I hope not!)
>
As I said earlier, making non-free more prominent and more
volunteers to maintain fully free images could work to reduce load
on existing volunteers.
> 2. We could just stop providing the non-free unofficial images
altogether.
> That's not really a promising route to follow - we'd be making
it even
> harder for users to install our software. While ideologically
pure, it's
> not going to advance the cause of Free Software.
I think we should continue creating non-free images.
> 3. We could stop pretending that the non-free images are
unofficial, and maybe
> move them alongside the normal free images so they're published >> together.
> This would make them easier to find for people that need them,
but is
> likely to cause users to question why we still make any images
without
> firmware if they're otherwise identical.
This should be fine. This could be used as an opportunity to educate
users and recommending to choose hardware which works with free
images. We can highlight h-node.org <http://h-node.org> here.
> 4. The images team technically could simply include non-free into
the official
> images, and add firmware packages to the input lists for those
images.
> However, that would still leave us with problem 3 from above
(non-free
> generally enabled on most installations).
I don't think we should do this.
> 5. We could split out the non-free firmware packages into a new
> non-free-firmware component in the archive, and allow a
specific exception
> only to allow inclusion of those packages on our official
media. We would
> then generate only one set of official media, including those
non-free
> firmware packages.
I'm okay with it only if we don't get enough volunteers to maintain
two images.
> (We've already seen various suggestions in recent years to
split up the
> non-free component of the archive like this, for example into
> non-free-firmware, non-free-doc, non-free-drivers, etc.
Disagreement
> (bike-shedding?) about the split caused us to not make any
progress on
> this. I believe this project should be picked up and completed. >> We don't
> have to make a perfect solution here immediately, just
something that works
> well enough for our needs today. We can always tweak and
improve the setup
> incrementally if that's needed.)
>
>These are the most likely possible options, in my opinion. If you
have a better
>suggestion, please let us know!
As mentioned earlier, call for volunteers to maintain two sets or
reducing the number of test cases (some cases only tested with
non-free and some tested only with free images)
>I'd like to take this set of options to a GR, and do it soon. I
want to get a
>clear decision from the wider Debian project as to how to organise
firmware and
>installation images. If we do end up changing how we do things, I
want a clear
>mandate from the project to do that.
>
>My preference, and rationale
>============================
>
>Mainly, I want to see how the project as a whole feels here - this
is a big
>issue that we're overdue solving.
>
>What would I choose to do? My personal preference would be to go
with option 5:
>split the non-free firmware into a special new component and
include that on
>official media.
>
>Does that make me a sellout? I don't think so. I've been passionately >> >supporting and developing Free Software for more than half my life. My >> >philosophy here has not changed. However, this is a complex and nuanced >> >situation. I firmly believe that sharing software freedom with our
users comes
>with a responsibility to also make our software useful. If users
can't easily
>install and use Debian, that helps nobody.
>
>By splitting things out here, we would enable users to install and
use Debian
>on their hardware, without promoting/pushing higher-level non-free
software in
>general. I think that's a reasonable compromise. This is simply a
change to
>recognise that hardware requirements have moved on over the years.
>
>Further work
>============
>
>If we do go with the changes in option 5, there are other things we
could do
>here for better control of and information about non-free firmware:
>
> 1. Along with adding non-free firmware onto media, when the
installer (or live
> image) runs, we should make it clear exactly which firmware
packages have
> been used/installed to support detected hardware. We could link >> to docs
> about each, and maybe also to projects working on Free
re-implementations.
Good idea.
> 2. Add an option at boot to explicitly disable the use of the non-free >> > firmware packages, so that users can choose to avoid them.
>
>Acknowledgements
>================
>
>Thanks to people who reviewed earlier versions of this document
and/or made
>suggestions for improvement, in particular:
>
> • Cyril Brulebois
> • Matthew Garrett
> • David Leggett
> • Martin Michlmayr
> • Andy Simpkins
> • Neil Williams
>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
No such confusion...
https://wiki.debian.org/Firmware
Here's a nice guide on how to install the firmware on ANY damn DVD/CD/USB/Pogo stick
No there's both install DVD, install CD, live CD, live DVD, net install, etc...
Even explanation on how to make your own boot disk.
What did we do 30 years ago before crying for help on a mailing list ?
We'd read the manual BEFORE trying out something.
This still applies today.
Answer bellow this awful piece of text from someone who doesn't know how
to make a space between line.
I think you lack pretty much of seeing more than you own self and use case.No, everything I write in these threads I write for our potential users
I've used plenty of laptop without making a mess, sometime by using a external Wifi card or simply choosing wisely.So you've lost the context.
Now, regarding your complain on the microcode. I think it's useless to
have a conversation regarding this subject with you because having a
global view seems out of bound for your mind.
Yes microcode are copyrighted blob. So run your computer without using microcode update and do a change of CPU every time a potential bug is
found in a CPU.
You know what microcode does ? If so explain to me how it could be
possible to have a CPU with microcode in the open-source without having
more risk than benefits ? Now we'd see hacking done on the CPU
micro-code itself because anyone could sign it. Dumb bell.
You've now got your solution. What are you asking for ? We provide a OS,
we don't change the world to make it suit your need.
Hello,
Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a ecrit:
Answer bellow this awful piece of text from someone who doesn't know how
to make a space between line.
For information, reading mails with a speech synthesis doesn't
necessarily render spaces between lines.
So yes, people using them don't actually "see" the need for such
spacing.
Samuel
On 2022-04-20 08:39, Samuel Thibault wrote:
Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a ecrit:
Answer bellow this awful piece of text from someone who doesn't know how >> to make a space between line.
For information, reading mails with a speech synthesis doesn't
necessarily render spaces between lines.
So yes, people using them don't actually "see" the need for such
spacing.
When you talk or read a text out loud, you make pauses ?
Why wouldn't they apply then you write a text ?
When you talk or read a text out loud, you make pauses ?
Why wouldn't they apply then you write a text ?
Are we again in the world of "Everyone must adapt because I'm different" ?
We ain't gonna go back to this WOKE thinking and "positive
discrimination bullshit", please no !
2022, ഏപ്രിൽ 20 1:52:45 PM IST, Ansgar <ansgar@43-1.org>ൽ എഴുതി
On Wed, 2022-04-20 at 12:55 +0530, Pirate Praveen wrote:
liberated.computer it is refurbished and some components like
wifi
cards replaced so it works with 100% free software.
No, it doesn't. It just *hides* the fact that you use non-free
software. If you are happy with that, fine, but please don't claim
it
uses 100% free software.
So are our official images not 100% free? If so what are we even
proposing to change?
This question was about a desire to ship libre version of the image
with a laptop that can work with that image. Someone asked if such a
laptop exist in reality and I pointed out to someone doing that
actually.
And everything from keyboard, mice, storage (SD cards, SSD,
rotating
disks, controllers), ... has firmware. I don't expect them to have
done
much about that. Of course some devices come with preinstalled
firmware, so it's easy to ignore the firmware exists. However, that
does not "free" you from the restrictions of proprietary software
that
comes from using non-free firmware in any way compared to having
the OS
supply the firmware data.
There are many layers of issues regarding firmware. I did not oppose
creating a non free image. I was only asking to keep creating the
free image for those who want it.
https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484/6
This has a pretty in depth analysis. I tend to agree with the
criteria FSF set for RYF certification relating to firmware.
2022, ഏപ്രിൽ 20 1:52:45 PM IST, Ansgar <ansgar@43-1.org>ൽ എഴുതി
On Wed, 2022-04-20 at 12:55 +0530, Pirate Praveen wrote:
liberated.computer it is refurbished and some components like wifi
cards replaced so it works with 100% free software.
No, it doesn't. It just *hides* the fact that you use non-free
software. If you are happy with that, fine, but please don't claim it
uses 100% free software.
So are our official images not 100% free?
Hi,
On 2022-04-20 08:39, Samuel Thibault wrote:
Hello,
Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, aecrit:
Answer bellow this awful piece of text from someone who doesn't know how >> to make a space between line.
For information, reading mails with a speech synthesis doesn't
necessarily render spaces between lines.
So yes, people using them don't actually "see" the need for such
spacing.
When you talk or read a text out loud, you make pauses ?
Why wouldn't they apply then you write a text ?
Are we again in the world of "Everyone must adapt because I'm different" ?
We ain't gonna go back to this WOKE thinking and "positive
discrimination bullshit", please no !
Samuel
--
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development
On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:
There are a number of issues here that make developers and users unhappy:
There are a couple more issues related to unredistributable firmware:
Some firmware is only available in the operating system preinstalled on
the device and needs to be manually extracted before d-i is run,
potentially even only from processes running on the preinstalled
operating system in cases where the storage must be wiped (such as
Android devices) before an alternative OS like Debian can be installed.
IIRC there is some laptop WiFi firmware that is like this.
Some firmware is not redistributable and is only available in
proprietary drivers on websites and is hard to extract from those
drivers. IIRC some of the proprietary nvidia firmware for use by the
libre nouveau GPU driver is like this, both signed firmware for very
new nvidia hardware and unsigned firmware for very old nvidia hardware, >although the firmware for the old nvidia hardware has libre firmware in >nouveau, but the libre firmware is/was buggier than the proprietary
firmware. The tools for extracting the old firmware aren't in Debian.
bwt !
1st I've always saw Debian having brltty support from the start
2nd Just install the firmware instruction here and your problem will be >solved.
https://wiki.debian.org/Firmware
Stop blaiming other people when the problem is a lack of research on
your part and expectation all work "out of the box" in all situation.
Take destiny into your own hand.
On 2022-04-19 01:27:46 +0100 (+0100), Steve McIntyre wrote:
[...]
Along with adding non-free firmware onto media, when the installer[...]
(or live image) runs, we should make it clear exactly which
firmware packages have been used/installed to support detected
hardware. We could link to docs about each, and maybe also to
projects working on Free re-implementations.
It's probably what you meant, but just to be clear, as a user I'd
also want to know which of the firmware packages used/installed were
pulled from non-free and what devices prompted their addition.
Something like "The following packages do not meet Debian Free
Software Guidelines but were installed because they're necessary in
order to enable or secure some of your hardware: foo(CPUX21
processor microcode), bar(PM2743 power management controller),
baz(RF17G wireless interface), ..."
This would allow me to make better informed decisions, such as:
1. Disable some of these devices if I don't actually use them.
2. Seek out alternative open peripherals which do work without
proprietary firmware.
3. Reach out to the manufacturer of my device and extol the virtues
of open firmware.
4. Consider (as you mentioned) working on my own reimplementation.
Jonas Smedegaard <jonas@jones.dk> writes:
In other words, rather than having to do what one does now and choose
between the free installer and the non-free installer, my understanding of >option #5 is that there would be one install image, but there could then
be a prompt asking you whether you want to install non-free firmware. We >could even offer a few different options (with the caveat that options
tend to confuse users, so we may not want to add too many or gate them
behind an advanced mode):
1. Purely free installation.
2. Enable non-free firmware in the installer but don't put it on the
installed system. (Not sure how useful this is, but I could see
needing non-free firmware to bootstrap from wifi but the running system
may eventually not use the non-free firmware.)
3. Enable non-free firmware and install it on the system but pin it so
that it's never upgraded by default.
4. Enable non-free firmware and enable normal upgrades, similar to adding
the non-free archive area today but only adding the firmware archive
area.
I think 1 and 4 are the most useful options, and I'm not sure how many
people really want 2 or 3, but if there are enough people who want them, I >don't see any technical barriers to adding them.
I feel professionally obligated to argue that Debian should, *by default*, >upgrade anything that it installs, since from a security standpoint that
is the least risky default configuration (with, as always, the caveat that >there are special cases with different security models for which this
default isn't appropriate). But that doesn't rule out a prompt or
allowing a user to turn this off if they want to.
I agree that we should make it easier for our users to choose to trust
black magic "stuff" that they need to enable their devices.
I do not think that we should impose on our users to trust black magic
by default, though.
I think this is a somewhat different question than whether we put the >firmware on the default installation media so that it's *available* if
users want it.
[ Other options ]Russ Allbery wrote:
1. Purely free installation.
[...]4. Enable non-free firmware and enable normal upgrades, [...]
Now, the *default* is going to be the hard choice for us to make.
Anyways, if we want to gatekeep Debian, then fine.
On Wed, Apr 20, 2022 at 8:08 AM Polyna-Maude Racicot-Summerside < debian@polynamaude.com> wrote:
Hi,
On 2022-04-20 08:39, Samuel Thibault wrote:
Hello,
Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, aecrit:
Answer bellow this awful piece of text from someone who doesn't know how >> to make a space between line.
For information, reading mails with a speech synthesis doesn't necessarily render spaces between lines.
So yes, people using them don't actually "see" the need for such
spacing.
When you talk or read a text out loud, you make pauses ?
Why wouldn't they apply then you write a text ?
Are we again in the world of "Everyone must adapt because I'm different" ?
We ain't gonna go back to this WOKE thinking and "positive
discrimination bullshit", please no !
Samuel
--
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development
On Wed, 2022-04-20 at 17:11 +0100, Steve McIntyre wrote:
[ Other options ]Russ Allbery wrote:
1. Purely free installation.
[...]4. Enable non-free firmware and enable normal upgrades, [...]
Now, the *default* is going to be the hard choice for us to make.
Do you think the choice for the default should be part of a GR too, a >separate GR or decided some other way?
On Wed, Apr 20, 2022 at 09:51:01AM -0500, Devin Prater wrote:
Anyways, if we want to gatekeep Debian, then fine.
The person you're replying to is not a member of the Debian Project and
does
not speak for us.
We are not all accessibility experts, but Debian as a community has always supported the efforts of those who are, to make Debian as usable as
possible
with accessibility technologies.
Please don't assume the hostility of the previous messages is in any way representative of Debian. (And, that being the case, I would suggest it's unnecessary to engage with.)
On Wed, Apr 20, 2022 at 8:08 AM Polyna-Maude Racicot-Summerside < debian@polynamaude.com> wrote:
Hi,
On 2022-04-20 08:39, Samuel Thibault wrote:
Hello,
-0400, aPolyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13
know howecrit:
Answer bellow this awful piece of text from someone who doesn't
to make a space between line.
For information, reading mails with a speech synthesis doesn't necessarily render spaces between lines.
So yes, people using them don't actually "see" the need for such spacing.
different" ?When you talk or read a text out loud, you make pauses ?
Why wouldn't they apply then you write a text ?
Are we again in the world of "Everyone must adapt because I'm
We ain't gonna go back to this WOKE thinking and "positive
discrimination bullshit", please no !
Samuel
--
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development
--
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 Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
So then, I found the Non-free section and got the CD version? I guessYes, the variety of our ISOs and the poor way they are presented to the
that's what I should have gotten? The DVD one is the live environment
right? See how confusion this can be?
Thanks! That's a really good question, and one that we should also
include on the GR. I'd split my option 5 into two:
5. Include non-free firmware but do not enable it by default
6. Include non-free firmware and enable it by default
In either case, we'd make the opposite choice available via a d-i kernel command line option and a boot menu option. I think that makes sense?
3. We could stop pretending that the non-free images are unofficial, and
maybe move them alongside the normal free images so they're published
together. This would make them easier to find for people that need
them, but is likely to cause users to question why we still make any
images without firmware if they're otherwise identical.
4. The images team technically could simply include non-free into the official
images, and add firmware packages to the input lists for those images.
However, that would still leave us with problem 3 from above (non-free
generally enabled on most installations).
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media. We would
then generate only one set of official media, including those non-free
firmware packages.
(We've already seen various suggestions in recent years to split up the
non-free component of the archive like this, for example into
non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
(bike-shedding?) about the split caused us to not make any progress on
this. I believe this project should be picked up and completed. We don't
have to make a perfect solution here immediately, just something that works
well enough for our needs today. We can always tweak and improve the setup
incrementally if that's needed.)
But back on topic, would the nonfree DVD ISO's have more firmware on them than the CD version? Or is that just for offline installs?As far as I understand it there is just one set of non-free firmware for including in the ISOs and separate drives, which consists of all non-free firmware found in the archive.
"Russ" == Russ Allbery <rra@debian.org> writes:
TL;DR: firmware support in Debian sucks, and we need to change this.
what other support Debian could give to libre/open firmware projects.
TL;DR: firmware support in Debian sucks, and we need to change this. See the "My preference, and rationale" Section below.
On Thu, Apr 21, 2022 at 09:57:36AM +0300, Hakan Bayındır wrote:
As everybody knows, Debian is also releasing the said firmware as compressed >> archives and these are visible in the download page [0], however usage and >> documentation is neither clearly documented, nor easy for the beginners or >> casual users.(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
for a separate drive, there may be some documentation about putting the
files to the installation drive but at that point the user should just
burn the firmware ISO)
The whole process can be simplified with a simple GUI/CLI tool akin toOnly as long as it's usable on Windows.
GRML2USB which accepts the ISO file and burns (sic) it to a USB drive, and >> simplifying the whole process a lot. The tool can accept the ZIP file, or
can have checkbox saying "Integrate firmware" if one decides to make such
tool auto-downloading resources.
As everybody knows, Debian is also releasing the said firmware as compressed archives and these are visible in the download page [0], however usage and documentation is neither clearly documented, nor easy for the beginners or casual users.(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
The whole process can be simplified with a simple GUI/CLI tool akin to GRML2USB which accepts the ISO file and burns (sic) it to a USB drive, and simplifying the whole process a lot. The tool can accept the ZIP file, orOnly as long as it's usable on Windows.
can have checkbox saying "Integrate firmware" if one decides to make such tool auto-downloading resources.
It's linked in the same yellow block on the page you linked as the archive itself.As everybody knows, Debian is also releasing the said firmware as compressed(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04 for a separate drive, there may be some documentation about putting the files to the installation drive but at that point the user should just
archives and these are visible in the download page [0], however usage and
documentation is neither clearly documented, nor easy for the beginners or
casual users.
burn the firmware ISO)
I know it's documented, but it's buried deep down.
In my ideal world (for newcomers), the link should produce the fileThey should just get the firmware ISO and burn it instead of fiddling with
directly, not the directory, or they get the tool, insert a USB drive, and viola.
TL;DR: firmware support in Debian sucks, and we need to change this. See the "My preference, and rationale" Section below.
In times past, all necessary firmware would normally be included directly in devices / expansion cards by their vendors. Over time, however, it has become more and more attractive (and therefore more common) for device manufacturers to not include complete firmware on all devices. Instead, some devices just embed a very simple set of firmware that allows for upload of a more complete firmware "blob" into memory. Device drivers are then expected to provide that blob during device initialisation.
For free software reasons, I believe that Debian should encourage this method of distribution too, because it opens up the option for free
firmware to be developed as replacement for the non-free ones (or encouraging vendors to (eventually) release their firmware under a free licence). In the case of firwmare on the device, it is much harder to load
a free one.
On Thu, Apr 21, 2022 at 10:57:47AM +0300, Hakan Bayındır wrote:
It's linked in the same yellow block on the page you linked as the archive itself.As everybody knows, Debian is also releasing the said firmware as compressed(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04 >>> for a separate drive, there may be some documentation about putting the
archives and these are visible in the download page [0], however usage and >>>> documentation is neither clearly documented, nor easy for the beginners or >>>> casual users.
files to the installation drive but at that point the user should just
burn the firmware ISO)
I know it's documented, but it's buried deep down.
I mean, I agree it's not good but most of places on debian.org that are related to downloading are not good. At least https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ is now just two clicks away from the main page.
In my ideal world (for newcomers), the link should produce the fileThey should just get the firmware ISO and burn it instead of fiddling with all of that.
directly, not the directory, or they get the tool, insert a USB drive, and >> viola.
On Wed, Apr 20, 2022 at 12:53:46PM -0500, Devin Prater wrote:
But back on topic, would the nonfree DVD ISO's have more firmware on themAs far as I understand it there is just one set of non-free firmware for >including in the ISOs and separate drives, which consists of all non-free >firmware found in the archive.
than the CD version? Or is that just for offline installs?
Steve McIntyre <steve@einval.com> writes:
Thanks! That's a really good question, and one that we should also
include on the GR. I'd split my option 5 into two:
5. Include non-free firmware but do not enable it by default
6. Include non-free firmware and enable it by default
In either case, we'd make the opposite choice available via a d-i kernel
command line option and a boot menu option. I think that makes sense?
I agree with this option split, but that reminds me of a different
procedural note.
While I recognize and respect the desire to create a comprehensive ballot, >I'm still going to advocate for proposing a GR only with the options that
the person proposing the GR would vote above NOTA, and possibly only your >preferred options.
Yes, my position was always "the only ISO link on the main page should beAs everybody knows, Debian is also releasing the said firmware as compressed(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
archives and these are visible in the download page [0], however usage and
documentation is neither clearly documented, nor easy for the beginners or
casual users.
for a separate drive, there may be some documentation about putting the files to the installation drive but at that point the user should just burn the firmware ISO)
I know it's documented, but it's buried deep down.It's linked in the same yellow block on the page you linked as the archive itself.
I mean, I agree it's not good but most of places on debian.org that are related to downloading are not good. At least https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
is now just two clicks away from the main page.
Again, I think two clicks is too deep. A newcomer doesn't have to know the difference between all the files there. We're having this discussion because I see that the current amount of friction is seen as detrimental, and I agree.
Providing a free ISO and a set of stuff to make it usable is strictlyIn my ideal world (for newcomers), the link should produce the file directly, not the directory, or they get the tool, insert a USB drive, andThey should just get the firmware ISO and burn it instead of fiddling with all of that.
viola.
"The user shall do X" is not a very correct standpoint either. Even if we decide to add the firmware somehow into the "Official" ISOs, I still believe having a simple tool to do all of that is beneficial for new starters.
If we want to have more new users or entice people who're starting toI agree and I don't see why this should be done with a set of additional
use/try Linux, initial barrier should be lowered.
What would I choose to do? My personal preference would be to go with optiob 5:
split the non-free firmware into a special new component and include that on official media.
As everybody knows, Debian is also releasing the said firmware as
compressed archives and these are visible in the download page [0],
however usage and documentation is neither clearly documented, nor easy
for the beginners or casual users.
Considering most users are doing installs over USB, and official Debian
ISOs are hybrid by default, how the following plan feels?
1) Document the use of ZIP files for firmware introduction during install more clearly and prominently,
2) Make these ZIP archives much more accessible via links and prominent placement,
3) Document creation of a USB drive which is both bootable and has
writable space for extra files
4) Write another document detailing adding these ZIP files to the said
media in 3,
5) Profit by allowing people to assemble their own installation media with firmware blobs if they see the need.
On Tue, 19 Apr 2022 08:21:10 -0600, Sam Hartman <hartmans@debian.org>
wrote:
One valuable suggestion was to make sure users could easily select
freedom if that's what they wanted.
So I think a free installation image is important.
Would that not be possible by having an image WITH firmware and an
installer asking whether the user wants a free or a usable system?
On 21 Apr 2022, at 21:14, Gunnar Wolf <gwolf@debian.org> wrote:
Marc Haber dijo [Tue, Apr 19, 2022 at 06:56:54PM +0200]:
On Tue, 19 Apr 2022 08:21:10 -0600, Sam Hartman <hartmans@debian.org>
wrote:
One valuable suggestion was to make sure users could easily select
freedom if that's what they wanted.
So I think a free installation image is important.
Would that not be possible by having an image WITH firmware and an
installer asking whether the user wants a free or a usable system?
Up to a certain point, I guess. But users do get confused by Debian, a stubbornly-free distribution, having multiple images –some official,
some unblessed– on different places.
Maybe if the free image finds (important? i.e. the only connectivity
option, or required for enabling a video card beyond framebuffer?)
hardware for which firmware is required, it could display a prominent message, suggesting the user to download the
official-but-firmware-carrying images from a simple debian.org URL.
However I think we should continue to produce install media without
non-free components, at least for a period of time after making the
switch (as another reply said, perhaps 1-2 releases and review). It
feels like me too big a step to take to stop producing DFSG-compliant
media.
From simply a principle perspective, that's the "pure" aim
of the project. If we continue to provide it but not on the default
path then we might be able to gather some information on how popular
or useful it is (how many downloads it attracts; or what kind of
hardware configurations it can actually be used on; perhaps cross- referencing it with popcon or installation-report data)
A further evolution of this idea might be adding another question to
Debian Installer regarding to non-free software.
If the users choose “No” for enabling non-free repositories, another question might ask “Your system seems to need some firmware packages
to operate correctly, do you want to enable only the firmware
packages, but not the other non-free software?”
Normally, the installer asks for “firmware.zip” file if it can’t continue, but it’s already noted that making it work is very very
hard (I only succeeded once in my 15 years of Debian use). Maybe
making this process easier helps?
After some discussion on #debian-www with sney (author of the current >auto-download page)
TL;DR: firmware support in Debian sucks, and we need to change this. See the "My preference, and rationale" Section below.
In my opinion, the way we deal with (non-free) firmware in Debian is a mess, and this is hurting many of our users daily. For a long time we've been pretending that supporting and including (non-free) firmware on Debian systems
is not necessary. We don't want to have to provide (non-free) firmware to our users, and in an ideal world we wouldn't need to. However, it's very clearly no
longer a sensible path when trying to support lots of common current hardware.
Background - why has (non-free) firmware become an issue? =========================================================
Firmware is the low-level software that's designed to make hardware devices work. Firmware is tightly coupled to the hardware, exposing its features, providing higher-level functionality and interfaces for other software to use.
For a variety of reasons, it's typically not Free Software.
For Debian's purposes, we typically separate firmware from software by considering where the code executes (does it run on a separate processor? Is it
visible to the host OS?) but it can be difficult to define a single reliable dividing line here. Consider the Intel/AMD CPU microcode packages, or the U-Boot firmware packages as examples.
In times past, all necessary firmware would normally be included directly in devices / expansion cards by their vendors. Over time, however, it has become more and more attractive (and therefore more common) for device manufacturers to not include complete firmware on all devices. Instead, some devices just embed a very simple set of firmware that allows for upload of a more complete firmware "blob" into memory. Device drivers are then expected to provide that blob during device initialisation.
I've been a Debian Developer for quite some time and can usually manage to figure out most tasks like this, and providing separate firmware to the installer has completely defeated me every time I've tried it. I've spent frustrated hours trying to follow the documentation and doing things that look right only to have the installer say that there's no firmware visible without any clue as to how to debug the errors. Every time I have tried this, I have eventually given up and found the non-free images, which just worked.
If this is going to be the solution, it has to be WAY easier to do.
Am Thu, Apr 21, 2022 at 10:12:19AM -0700 schrieb Russ Allbery:
I've been a Debian Developer for quite some time and can usually manage to >> figure out most tasks like this, and providing separate firmware to the
installer has completely defeated me every time I've tried it. I've spent >> frustrated hours trying to follow the documentation and doing things that
look right only to have the installer say that there's no firmware visible >> without any clue as to how to debug the errors. Every time I have tried
this, I have eventually given up and found the non-free images, which just >> worked.
If this is going to be the solution, it has to be WAY easier to do.
I confirm that I never ever managed to provide the needed firmware to
the free official installer. Thus my consequence was to ignore it and
just use the non-free firmware enabled installer. I do not think that
it is sensible to let users make this experience themselves and I'm
really welcoming the effort Steve did. Out of the original post I
prefer option 5. Currently I don't habe time to read the whole thread
but I have spotted some sensible enhancements of option 5 that are
worth discussing.
Thanks a lot Steve
Andreas.
Am Thu, Apr 21, 2022 at 10:12:19AM -0700 schrieb Russ Allbery:
I've been a Debian Developer for quite some time and can usually manage to >> figure out most tasks like this, and providing separate firmware to the
installer has completely defeated me every time I've tried it.
I confirm that I never ever managed to provide the needed firmware to
the free official installer.
TL;DR: firmware support in Debian sucks, and we need to change this. See the "My preference, and rationale" Section below.[...]
Thanks to people who reviewed earlier versions of this document and/or made suggestions for improvement, in particular:
• Cyril Brulebois
• Matthew Garrett
• David Leggett
• Martin Michlmayr
• Andy Simpkins
• Neil Williams
Hi,
On Mon, Apr 18, 2022 at 9:28 PM Steve McIntyre <steve@einval.com> wrote:
TL;DR: firmware support in Debian sucks, and we need to change this. See the >> "My preference, and rationale" Section below.
In my opinion, the way we deal with (non-free) firmware in Debian is a mess, >> and this is hurting many of our users daily. For a long time we've been
pretending that supporting and including (non-free) firmware on Debian systems
is not necessary. We don't want to have to provide (non-free) firmware to our
users, and in an ideal world we wouldn't need to. However, it's very clearly no
longer a sensible path when trying to support lots of common current hardware.
Background - why has (non-free) firmware become an issue?
=========================================================
Firmware is the low-level software that's designed to make hardware devices >> work. Firmware is tightly coupled to the hardware, exposing its features,
providing higher-level functionality and interfaces for other software to use.
For a variety of reasons, it's typically not Free Software.
For Debian's purposes, we typically separate firmware from software by
considering where the code executes (does it run on a separate processor? Is it
visible to the host OS?) but it can be difficult to define a single reliable >> dividing line here. Consider the Intel/AMD CPU microcode packages, or the
U-Boot firmware packages as examples.
In times past, all necessary firmware would normally be included directly in >> devices / expansion cards by their vendors. Over time, however, it has become
more and more attractive (and therefore more common) for device manufacturers
to not include complete firmware on all devices. Instead, some devices just >> embed a very simple set of firmware that allows for upload of a more complete
firmware "blob" into memory. Device drivers are then expected to provide that
blob during device initialisation.
I'm from the group that defends Debian current position on this and I
like to install only what the machine needs to work and I use free
firmware on my machine for the wireless network card for example. I
don't see it as a mess, but it's organized by separating what's free
from what's not. The question of identifying what firmware my machine
needs, this for me is easy and it was just a question I had to learn
in the beginning many years ago. It is a problem for some and not for
all. There is the unofficial installer that solves this problem by
installing only what the user's machine needs without the user doing
it himself.
I agree with this option split, but that reminds me of a different
procedural note.
While I recognize and respect the desire to create a comprehensive ballot, I'm still going to advocate for proposing a GR only with the options that
the person proposing the GR would vote above NOTA, and possibly only your preferred options.
There are a couple of reasons for this. One is that the people who prefer your disfavored options may have their own way of wording them that's slightly different than what you might believe they would want to say, and it's awkward to update other people's ballot options. The other, somewhat more technical reason is that I expect this GR to require a 3:1 majority
for some options, and mixing 3:1 and 1:1 majority options on the same GR
can be rather confusing. We may end up needing to do that anyway for this vote, but I think it would be a good idea to avoid creating the problem unless someone steps forward and proposes a 1:1 option that they really
want to win.
(That said, I think there's a big exception, which is that if you've canvassed a bunch of people who may not want to try to craft their own
ballot options, and developed options to reflect their views, I think
that's a fine approach and a good reason to propose options that aren't
your personal preference.)
As a side note, I don't remember exactly how this worked before, but under the current constitutional rules the original GR proposer doesn't have a special ability to put a bunch of options on the original ballot. You
start with one option, and then you can add more options but they all need
to be sponsored independently. So that also pushes in this direction of ballot construction.
I've been a Debian Developer for quite some time and can usually manage to >figure out most tasks like this, and providing separate firmware to the >installer has completely defeated me every time I've tried it. I've spent >frustrated hours trying to follow the documentation and doing things that >look right only to have the installer say that there's no firmware visible >without any clue as to how to debug the errors. Every time I have tried >this, I have eventually given up and found the non-free images, which just >worked.
If this is going to be the solution, it has to be WAY easier to do.
I understand the urge to insist upon absolute DFSG purity in the media
we produce, but when it comes to wanting to avoid every last shred of
data that we could not regenerate ourselves, I think we crossed that
line some time ago.
I'm thinking of shim-signed, which is included in our official media.
Despite being free software in source form, it is signed by Microsoft,
and can only be expected to work with that signature ... which we cannot >create.
On most (all?) hardware one is able to avoid UEFI secure-boot, so won't
need to use shim-signed, but I'd imagine that some hardware insists on >secure-boot, or the opt-outs are somehow broken and so is not usable
without shim-signed.
Is the presence of shim-signed on the install media enough to make
people feel somehow contaminated?
If not, is the problem having other blobs of data on the media that we
also cannot generate, or is it the licensing of that data, or something
else?
If it ensures that fewer people abandon Debian out of frustration with
the install then I'd suggest that it will actually result in less
non-free software being used overall, as will having the option to
enable only non-free-firmware without also enabling non-free.
Is the presence of shim-signed on the install media enough to make
people feel somehow contaminated?
I think so, yes. Personally, I don't care too much but i can
understand why some people might.
We can compile shim-signed and compare the signed code with our own
object code, can't we? That we we would only have to worry about the validity and benignness of the signature and not worry about having undocumented functionality in the signed code.
I see several possible options that the images team can choose from here. However, several of these options could undermine the principles of Debian. We
don't want to make fundamental changes like that without the clear backing of the wider project. That's why I'm writing this...
That's the option 3 more or less.I see several possible options that the images team can choose from here. However, several of these options could undermine the principles of Debian. We
don't want to make fundamental changes like that without the clear backing of
the wider project. That's why I'm writing this...
I have an idea for an extra option:
6. Put the closed source firmware somewhere in the Debian images, but never install closed source firmware by default. "No" should be the default.
to put "non-free" into sources.list should also be an non-default choice, even when you install closed source firmware.No, that's a bad idea, which is one of the main reasons for the option 5.
On Fri, 22 Apr 2022 11:16:42 +0200, Philip Hands <phil@hands.com>
wrote:
I understand the urge to insist upon absolute DFSG purity in the media
we produce, but when it comes to wanting to avoid every last shred of
data that we could not regenerate ourselves, I think we crossed that
line some time ago.
I'm thinking of shim-signed, which is included in our official media.
Despite being free software in source form, it is signed by Microsoft,
and can only be expected to work with that signature ... which we cannot >>create.
On most (all?) hardware one is able to avoid UEFI secure-boot, so won't >>need to use shim-signed, but I'd imagine that some hardware insists on >>secure-boot, or the opt-outs are somehow broken and so is not usable >>without shim-signed.
Excuse me for asking a user question on -devel, but do we have any
docs where someone explains how much a security trade off is
shim-signed relativ to the optimum? I think that using shim-signed is
surely worse than a directly signed kernel, but I don't know whether I
can tell my system (or shim-signed?) to accept MY or Debian's signed
kernel without the Microsoft intermediate signature, and whether this
is any more secure than running an encrypted system without secure
boot at all.
If not, is the problem having other blobs of data on the media that we
also cannot generate, or is it the licensing of that data, or something >>else?
We can compile shim-signed and compare the signed code with our own
object code, can't we? That we we would only have to worry about the >validity and benignness of the signature and not worry about having >undocumented functionality in the signed code.
Personally, I'd even go for option 4, so that other drivers are covered
too (the general advice that can be found on the internet for users
with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
which is just a sad state of affairs). But option 5 is already a great improvement upon the status quo.
Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin:
On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote:
I see several possible options that the images team can choose from here.
However, several of these options could undermine the principles of Debian. We
don't want to make fundamental changes like that without the clear backing of
the wider project. That's why I'm writing this...
I have an idea for an extra option:
6. Put the closed source firmware somewhere in the Debian images, but neverThat's the option 3 more or less.
install closed source firmware by default. "No" should be the default.
Option 3 says to publish two sets of images.
And it says nothing about defaults.
----
3. We could stop pretending that the non-free images are unofficial, and maybe move them alongside the normal free images so they're published together. This would make them easier to find for people that need them, but is likely to cause users to question why we still make any images without firmware if they're otherwise identical.
----
to put "non-free" into sources.list should also be an non-default choice, even when you install closed source firmware.No, that's a bad idea, which is one of the main reasons for the option 5.
The idea is not to promote closed source firmware in any way. Have it available, but only for the people who really want it.
On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote:
That's the option 3 more or less.I see several possible options that the images team can choose from here. >>> However, several of these options could undermine the principles of Debian. We
don't want to make fundamental changes like that without the clear backing of
the wider project. That's why I'm writing this...
I have an idea for an extra option:
6. Put the closed source firmware somewhere in the Debian images, but never >> install closed source firmware by default. "No" should be the default.
to put "non-free" into sources.list should also be an non-default choice,No, that's a bad idea, which is one of the main reasons for the option 5.
even when you install closed source firmware.
If you want to drop the non-firmware image then it's the option 4 more orI have an idea for an extra option:
6. Put the closed source firmware somewhere in the Debian images, but neverThat's the option 3 more or less.
install closed source firmware by default. "No" should be the default.
Option 3 says to publish two sets of images.
----
3. We could stop pretending that the non-free images are unofficial, and maybe move them alongside the normal free images so they're published together. This would make them easier to find for people that need them, but is likely to cause users to question why we still make any images without firmware if they're otherwise identical.
----
And it says nothing about defaults.d-i defaults are mostly unrelated to the ISO set and the archive setup questions. You seem to want to add a yet another "free vs usable, with
*shrug* that's just "have it available for most people" with extrato put "non-free" into sources.list should also be an non-default choice, even when you install closed source firmware.No, that's a bad idea, which is one of the main reasons for the option 5.
The idea is not to promote closed source firmware in any way. Have it available, but only for the people who really want it.
Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin:
On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote:here.
I see several possible options that the images team can choose from
That's the option 3 more or less.However, several of these options could undermine the principles of Debian. We
don't want to make fundamental changes like that without the clear backing of
the wider project. That's why I'm writing this...
I have an idea for an extra option:
6. Put the closed source firmware somewhere in the Debian images, but never
install closed source firmware by default. "No" should be the default.
Option 3 says to publish two sets of images.
And it says nothing about defaults.
----
3. We could stop pretending that the non-free images are unofficial, and maybe move them alongside the normal free images so they're published together. This would make them easier to find for people that need them,
but is likely to cause users to question why we still make any images
without firmware if they're otherwise identical.
----
choice,to put "non-free" into sources.list should also be an non-default
even when you install closed source firmware.No, that's a bad idea, which is one of the main reasons for the option 5.
The idea is not to promote closed source firmware in any way. Have it available, but only for the people who really want it.
Maybe it's also an idea to put the firmware in a seperate partition.
With regards,
Paul
BTW: I sell Debian media like USB-sticks. I know about the problems
people have to choose a medium-type etc.
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl
Luca Boccassi wrote:
Personally, I'd even go for option 4, so that other drivers are covered
too (the general advice that can be found on the internet for users
with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
which is just a sad state of affairs). But option 5 is already a great
improvement upon the status quo.
Agree!
The original post did mention video cards, but I'm left unsure whether the >non-free stuff in the NVidia case, for example, would fall into "firmware" >(hence included) or "drivers". If the latter, my sense is that Option 5 was >intended to be narrowly focused and exclude such drivers. I'd rather support >a wider focus that would include drivers -- basically any "non-free hardware >support package". So if Option 5 is narrow and Option 4 is wide-open "non- >free" maybe there's room for an option in between?
Making Debian hard to use is a very short-sighted view of how to promote
free software - it works in the very short term only.
If you don't like the fact that Microsoft's keys are involved,
it's possible on a lot of machines to enrol your own keys
and remove Microsoft's entirely.
we could even offer our own different shim-signed package to match.
If we had a large enough number of users wanting a different root of trust
Excuse me for asking a user question on -devel, but do we have any
docs where someone explains how much a security trade off is
shim-signed relativ to the optimum? I think that using shim-signed is
surely worse than a directly signed kernel, but I don't know whether I
can tell my system (or shim-signed?) to accept MY or Debian's signed
kernel without the Microsoft intermediate signature, and whether this
is any more secure than running an encrypted system without secure
boot at all.
Do we have docs for that?
Does the status quo incentivize them?Making Debian hard to use is a very short-sighted view of how to promote free software - it works in the very short term only.
The same applies in the other direction -- making no real distinction
between free and non-free software is a short term solution to the usability problem, but does not incentivize hardware vendors to open up designs in the slightest.
With drivers, user awareness is there at least.(only for people who can actually differentiate drivers and firmware)
People know that the nV drivers are essentially unsupported and if itAs opposed to "nouveau usually doesn't work and if it indeed doesn't, just install the non-free driver".
breaks, they get to keep the pieces.
The same isn't true for firmware, users just expect that stuff will workThis, again, should be equally applied to loadable firmware and firmware
and if it doesn't, it's Debian's fault. We can either validate that expectation, or push back on it, saying "this hardware is supported on a best-effort basis, but we can't help you because it's closed source."
I don't think we have docs for running with a different root of trust
than MS'. To be honest, I'm not sure we even _should_ have a lot of docs around it, since the general brittleness of the boot process, UEFI and friends might very well lead to more systems being broken when people discover the docs and run with the instructions without understanding
the implications.
As for it being more secure, for that to be a good and meaningful
discussion, we have to agree on what the threat model is. What's the
threat you want to protect against by using your own or Debian's keys?
SoftwarebulemieFrank Klemm
Steven Robbins wrote:
Luca Boccassi wrote:
Personally, I'd even go for option 4, so that other drivers are covered too (the general advice that can be found on the internet for users
with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc", which is just a sad state of affairs). But option 5 is already a great improvement upon the status quo.
Agree!
The original post did mention video cards, but I'm left unsure whether the non-free stuff in the NVidia case, for example, would fall into "firmware" (hence included) or "drivers". If the latter, my sense is that Option 5 was
intended to be narrowly focused and exclude such drivers. I'd rather support
a wider focus that would include drivers -- basically any "non-free hardware
support package". So if Option 5 is narrow and Option 4 is wide-open "non- free" maybe there's room for an option in between?
I have no desire to add a wider set of packages from non-free onto our
media, I'm afraid. I'm entirely focused on firmware and **not**
drivers. As and when we start to draft a GR to formalise what the
project wants, feel free to add an option for that too but I
personally wouldn't expect it to gain much traction.
On Sat, Apr 23, 2022 at 10:48:03PM +0200, Paul van der Vlis wrote:
If you want to drop the non-firmware image then it's the option 4 more or less.I have an idea for an extra option:That's the option 3 more or less.
6. Put the closed source firmware somewhere in the Debian images, but never
install closed source firmware by default. "No" should be the default.
Option 3 says to publish two sets of images.
----
3. We could stop pretending that the non-free images are unofficial, and
maybe move them alongside the normal free images so they're published
together. This would make them easier to find for people that need them, but >> is likely to cause users to question why we still make any images without
firmware if they're otherwise identical.
----
In that case the hardware will work, like how it would be if you wouldAnd it says nothing about defaults.d-i defaults are mostly unrelated to the ISO set and the archive setup questions. You seem to want to add a yet another "free vs usable, with
free as the default" question, which is not too bad, just yet another
thing for most people to change.
*shrug* that's just "have it available for most people" with extra complexity. And you seem to miss the problem with installing firmware packages but not enabling updates for them.The idea is not to promote closed source firmware in any way. Have itto put "non-free" into sources.list should also be an non-default choice, >>>> even when you install closed source firmware.No, that's a bad idea, which is one of the main reasons for the option 5. >>
available, but only for the people who really want it.
As I said, this is about d-i questions and defaults more than it's aboutI have an idea for an extra option:
6. Put the closed source firmware somewhere in the Debian images, but neverThat's the option 3 more or less.
install closed source firmware by default. "No" should be the default.
Option 3 says to publish two sets of images.
----If you want to drop the non-firmware image then it's the option 4 more or less.
3. We could stop pretending that the non-free images are unofficial, and maybe move them alongside the normal free images so they're published together. This would make them easier to find for people that need them, but
is likely to cause users to question why we still make any images without firmware if they're otherwise identical.
----
I see it more like option 5, with the difference that no closed source firmware or repository will be installed by default. With the non-free ISO this is the case.
For people who don't like closed source firmware, it gives the option not to install some firmware. E.g.: do I need that bluetooth adapter?
And we stay a possibility for FSF-people.FSF people condemned Debian long ago: https://www.gnu.org/distros/common-distros.html#Debian
Most SSD devices also have firmware, do you update that firmware?Sure.
On 25 Apr 2022, at 19:40, Andrey Rahmatullin <wrar@debian.org> wrote:
On Mon, Apr 25, 2022 at 05:53:03PM +0200, Paul van der Vlis wrote:
As I said, this is about d-i questions and defaults more than it's aboutIf you want to drop the non-firmware image then it's the option 4 more or >>> less.I have an idea for an extra option:
6. Put the closed source firmware somewhere in the Debian images, but never
install closed source firmware by default. "No" should be the default. >>>>> That's the option 3 more or less.
Option 3 says to publish two sets of images.
----
3. We could stop pretending that the non-free images are unofficial, and >>>> maybe move them alongside the normal free images so they're published
together. This would make them easier to find for people that need them, but
is likely to cause users to question why we still make any images without >>>> firmware if they're otherwise identical.
----
I see it more like option 5, with the difference that no closed source
firmware or repository will be installed by default. With the non-free ISO >> this is the case.
For people who don't like closed source firmware, it gives the option not to >> install some firmware. E.g.: do I need that bluetooth adapter?
ISO choices and content.
And we stay a possibility for FSF-people.FSF people condemned Debian long ago: https://www.gnu.org/distros/common-distros.html#Debian
Most SSD devices also have firmware, do you update that firmware?Sure.
--
WBR, wRAR
While what you’re saying is technically true, the default selection[...]
means much more than a default. It’s defines the stance of Debian, as
a whole.
So, if Option 5 is adopted, the default state is as important as the
step itself IMHO. I also still believe that giving people the tools
for assembling their "firmware enabled” install media is a valid
option, but it’s not favored as far as I can see (no hard feelings, though).
And we stay a possibility for FSF-people.FSF people condemned Debian long ago: https://www.gnu.org/distros/common-distros.html#Debian
While I like and support what FSF is standing for, I don’t think
their “condemnation” is a valid reason for not pursuing the ideals
DFSG puts forward. In my opinion, DFSG is one of the things underpins
the essence of Debian, and is a force for creating a more free and
open world. We’re almost there on the driver side, and while it gonna
take some time, we can be there on the firmware side. We just have to
be persistent, sometimes stubborn even.
On Mon, 2022-04-25 at 23:48 +0300, Hakan Bayındır wrote:
While what you’re saying is technically true, the default selection[...]
means much more than a default. It’s defines the stance of Debian, as
a whole.
So, if Option 5 is adopted, the default state is as important as the
step itself IMHO. I also still believe that giving people the tools
for assembling their "firmware enabled” install media is a valid
option, but it’s not favored as far as I can see (no hard feelings,
though).
And we stay a possibility for FSF-people.FSF people condemned Debian long ago:
https://www.gnu.org/distros/common-distros.html#Debian
While I like and support what FSF is standing for, I don’t think
their “condemnation” is a valid reason for not pursuing the ideals
DFSG puts forward. In my opinion, DFSG is one of the things underpins
the essence of Debian, and is a force for creating a more free and
open world. We’re almost there on the driver side, and while it gonna
take some time, we can be there on the firmware side. We just have to
be persistent, sometimes stubborn even.
Maybe then the "DFSG-free" installer should also exclude drivers for
devices that require non-free firmware, including preinstalled non-free firmware? It could also show a message indicating that such devices are
not supported (if possible).
People could still assemble their "non-free firmware enabled" install
media including such drivers.
Ansgar
Note that this fact was mentioned many times in this thread.No, they do not. Most popular devices won't work at all without non-
free firmware, including boring things such as mass storage (SD cards,
SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...).
Yeah, you’re right. Since the firmware images always there and doesn’t need to be hot-loaded by the driver itself 99% of the time (for these
classes of devices), I tend to forget about them.
I wonder whether these “proper” firmware can be considered as part of the hardware,FSF and/or some FSF proponents certainly think like this. Others just conveniently ignore it completely.
since it’s bundled with the hardware, but not with the driver itself.In the Linux world loadable firmware is rarely "bundled with the driver".
This makes matters more complicated, of course, but starting somewhereSuch arguments seem to ignore that
may create the same wedging effect as in the drivers, over time.
While I understand where you're coming from, I don't think such thing
is necessary, because a) Most popular devices with non-free firmware
blobs already work without such firmware
, albeit with a lower performance
(e.g. Realtek NICs), and b) The drivers gracefully handle the lack of firmware already, with a couple of harmless "ERROR:" messages.
On 26 Apr 2022, at 11:30, Ansgar <ansgar@43-1.org> wrote:
On Tue, 2022-04-26 at 10:47 +0300, Hakan Bayındır wrote:
While I understand where you're coming from, I don't think such thing
is necessary, because a) Most popular devices with non-free firmware
blobs already work without such firmware
No, they do not. Most popular devices won't work at all without non-
free firmware, including boring things such as mass storage (SD cards,
SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...).
, albeit with a lower performance
(e.g. Realtek NICs), and b) The drivers gracefully handle the lack of
firmware already, with a couple of harmless "ERROR:" messages.
I would assume such NICs actually come with preinstalled non-free
firmware which just has less functionality...
I get the impression you pretend that preinstalled non-free firmware
just doesn't exist.
Ansgar
On Tue, Apr 26, 2022 at 11:59:20AM +0300, Hakan Bayındır wrote:
Note that this fact was mentioned many times in this thread.No, they do not. Most popular devices won't work at all without non-
free firmware, including boring things such as mass storage (SD cards,
SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...).
Yeah, you’re right. Since the firmware images always there and doesn’t >> need to be hot-loaded by the driver itself 99% of the time (for these
classes of devices), I tend to forget about them.
I wonder whether these “proper” firmware can be considered as part of the hardware,FSF and/or some FSF proponents certainly think like this. Others just conveniently ignore it completely.
since it’s bundled with the hardware, but not with the driver itself.In the Linux world loadable firmware is rarely "bundled with the driver". This includes the use case discussed in this thread.
This makes matters more complicated, of course, but starting somewhereSuch arguments seem to ignore that
may create the same wedging effect as in the drivers, over time.
1) it's not about "starting somewhere" because we aren't discussing
something we will need to decide before some point in the future: the situation exists for many years, we are discussing whether we should
change how to handle it, not how to start handling it;
2) the often mentioned expected effect on hardware manufacturers should be already felt in some form as the status quo of not providing any non-free firmware on the official image is many years old;
3) so far the usability of systems with the official image becomes worse,
not better, over time.
On Sat, 2022-04-23 at 12:21 +0200, Marc Haber wrote:
Is the presence of shim-signed on the install media enough to make
people feel somehow contaminated?
I think so, yes. Personally, I don't care too much but i can
understand why some people might.
Why?
Because it contains a third-party signature for which the private
key is not included in Debian? The same is true for signatures in >debian-archive-keyring, debian-keyring, ca-certificates, wireless-
regdb, and many other packages.
If we were to include more signatures in binary packages (e.g., a
signed manifest listing files (with hashes) shipped by the package,
signed executables, an embedded signature for the .deb itself), would
that be a problem?
We do include signatures for source packages (*.dsc and also for
upstream tarballs) as well.
We can compile shim-signed and compare the signed code with our own
object code, can't we? That we we would only have to worry about the
validity and benignness of the signature and not worry about having
undocumented functionality in the signed code.
Debian's buildds build shim (binary package: shim-unsigned); the binary >generated by Debian is then signed by Microsoft's key.
We don't have good docs around this in general (hey, it's security
software - it's against the law to write good and complete docs!), but
I've certainly discussed this with a few folks over the years.
Alternatively, people can build replacement shim-signed packages using
their own root of trust if desired. If we had a large enough number of
users wanting a different root of trust, we could even offer our own >different shim-signed package to match.
Better than that, our shim-signed source package always double-checks
things here. At build time it removes the Microsoft signature and
compares that shim binary to the binary that we submitted for
signing. We would spot immediately if there was any code added.
On Sat, 23 Apr 2022 13:54:59 +0200, Ansgar <ansgar@43-1.org> wrote:
Why?
If only I knew. I myself don't feel to comfortable to rely on
Microsoft being able to pull the plug on us any time. I don't know
whether they can, but I imagine some kind of revocation mechanism
being in place.
Because it contains a third-party signature for which the private
key is not included in Debian? The same is true for signatures in debian-archive-keyring, debian-keyring, ca-certificates, wireless-
regdb, and many other packages.
A running system doesn't rely on any of those.
Debian's buildds build shim (binary package: shim-unsigned); the
binary generated by Debian is then signed by Microsoft's key.
And we have a mechanism to check whether the code is actually the
same?
On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre <steve@einval.com>
Better than that, our shim-signed source package always double-checks >>things here. At build time it removes the Microsoft signature and
compares that shim binary to the binary that we submitted for
signing. We would spot immediately if there was any code added.
And if that check fails at build time, the Debian process refrains
from putting a Debian signature on the deb and from uploading? Can the
end user build the shim herself, remove the signature from the signed
shim and compare the binary, preferably in a documented way?
On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre <steve@einval.com>
wrote:
We don't have good docs around this in general (hey, it's securityIt would be great to have that written down somewhere to tell poeple
software - it's against the law to write good and complete docs!), but
I've certainly discussed this with a few folks over the years.
what they're actually doing.
Alternatively, people can build replacement shim-signed packages using >their own root of trust if desired. If we had a large enough number of >users wanting a different root of trust, we could even offer our own >different shim-signed package to match.I would probably prefer to have grub an/or the kernel signed, avoiding additional code, but maybe having some explanation would convince me
that the shim actually improves things additionally to adding
complexity.
secure boot signing process at Microsoft is a review-sign process
On Tue, 2022-04-26 at 20:41 +0200, Bastian Blank wrote:
secure boot signing process at Microsoft is a review-sign process
What kind of review are Microsoft doing of the Debian shim?
Are they reviewing the source and checking for a reproducible build?
On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre
<steve@einval.com> wrote:
Alternatively, people can build replacement shim-signed packages
using their own root of trust if desired. If we had a large enough
number of users wanting a different root of trust, we could even
offer our own different shim-signed package to match.
I would probably prefer to have grub an/or the kernel signed,
avoiding additional code, but maybe having some explanation would
convince me that the shim actually improves things additionally to
adding complexity.
I can't speak to how big of an advantage A is, but B seems to me to be
pretty important.
If that understanding is not correct, I'd be interested to learn what
the actual point of having the shim is.
]] Hanno 'Rince' Wagner
I am a very firm believer of giving people as much information as
possible while being responsible. Meaning, that I would love to have
that documentation - including a big warning sign which sais "if you
follow this path, you may brick your machine and this is your problem,
not ours". If someone is interested to learn _how_ the security is
done and implemented, why should this be unavailable?
Sadly, warnings generally don't work because people will ignore them and >break their systems and then blame the people writing the
documentation, causing load and grief on people were trying to be
helpful by writing the docs.
I don't think we should invest a lot into writing the docs required
because we can use that effort elsewhere. Documentation requires >maintenance, just like everything else and if it's rarely used, we get
little value out of that effort. If somebody is very eager to write and >maintain that documentation over time, by all means, but we haven't seen >anyone step up to do so.
On 2022-04-26 at 10:14, Marc Haber wrote:
On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre
<steve@einval.com> wrote:
Alternatively, people can build replacement shim-signed packages
using their own root of trust if desired. If we had a large enough
number of users wanting a different root of trust, we could even
offer our own different shim-signed package to match.
I would probably prefer to have grub an/or the kernel signed,
avoiding additional code, but maybe having some explanation would
convince me that the shim actually improves things additionally to
adding complexity.
My understanding has always been that the point of having a
Microsoft-signed shim, rather than having Microsoft sign GRUB or the
kernel, is to A: avoid the need for round-trip with Microsoft's signing >facilities every time the GRUB or kernel packages are updated, and B:
ensure that end-users can still build their own kernels (et cetera)
without having to go through the Microsoft signing process, even if
their systems are set up to take advantage of the signed shim.
(And the point of having Microsoft sign it, rather than using a signing
key under the control of e.g. Debian, is that Microsoft's key is already >considered valid by the relevant firmware environments - including the
ones that can't be told to add another key to the list of valid ones.
That avoids having another barrier to entry, in the form of a set of
steps at the start of the install process which is going to be different
per UEFI designer, and is also going to be complex and unintuitive from
the perspective of a non-technical potential new user.)
On 2022-04-26 at 18:05, Paul Wise wrote:
On Tue, 2022-04-26 at 20:41 +0200, Bastian Blank wrote:
secure boot signing process at Microsoft is a review-sign process
What kind of review are Microsoft doing of the Debian shim?
Are they reviewing the source and checking for a reproducible build?
I'd be curious to have a more in-depth answer to this, myself.
My understanding has always been that they check to make sure that what >they're signing is not visibly malicious, and in most cases also that it >can't chain to load something else (which isn't signed, and might be >malicious). Since the entire purpose of the shim - at least as I
understand it - is to chain to load something else, clearly either that >understanding is not correct, or they're making an exception for the
case of the shim.
5. We could split out the non-free firmware packages into a newWe would
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media.
then generate only one set of official media, including those non-freeup the
firmware packages.
(We've already seen various suggestions in recent years to split
non-free component of the archive like this, for example intoprogress on
non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement (bike-shedding?) about the split caused us to not make any
this. I believe this project should be picked up and completed.We don't
have to make a perfect solution here immediately, just somethingthat works
well enough for our needs today. We can always tweak and improvethe setup
incrementally if that's needed.)have a better
These are the most likely possible options, in my opinion. If you
suggestion, please let us know!to get a
I'd like to take this set of options to a GR, and do it soon. I want
clear decision from the wider Debian project as to how to organisefirmware and
installation images. If we do end up changing how we do things, Iwant a clear
mandate from the project to do that.
TL;DR: firmware support in Debian sucks, and we need to change this. See the "My preference, and rationale" Section below.
5. We could split out the non-free firmware packages into a new
non-free-firmware component in the archive, and allow a specific exception
only to allow inclusion of those packages on our official media. We would
then generate only one set of official media, including those non-free
firmware packages.
From a practical side, I'd likely put option 5 (without the extrachanges requested here) somewhere close to the top for all the good
FWIW, as a 10+ years user (first time caller :p) I strongly support
sticking with the status quo. There are plenty of systems that don't
require firmware to work, and often when people say it doesn't "work"
they really mean that its functionality is more limited.
Further, there are security concerns with blobs. Yes, we can get
microcode updates, but were those updates themselves actually audited?
As far as I know, they are just as opaque as the code they're
replacing. They could be making security worse, and we won't know
until someone finds the exploits. The rare event where a microcode
update is released and it increases security is far outweighed by the
vast majority of the situations where installing opaque code is
detrimental to security.
If people are unhappy with the status quo, my proposal would be to
encourage more people to work on free alternatives. There is an ocean
of possibilities here, from open hardware to reverse engineering. My
feeling is that a lot more could be done to better support hardware
that doesn't involve non-free code at all. There are many free
projects that have never made it to Debian.
There are definitely people who use forks because it's easier toThis would mean almost officially dropping support for user computers and,
install non-free firmware. What's the problem with that? Let them use
forks. A distro can't be all things to all people.
Debian is unique in this area, and it would be a shame to sacrifice thatI'm afraid that not providing hardware support is not the same as
and make it just like all the rest. And it's unclear what benefit there
is to attracting a larger and larger userbase as a bottom-line. It is
not a commercial project, so they will not be paying customers. The
best-case scenario is that people are attracted to making contributions
or becoming more interested in free software, which I thought was the
main goal. So if that isn't prioritized, what's the point?
On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote:
There are definitely people who use forks because it's easier toThis would mean almost officially dropping support for user computers and,
install non-free firmware. What's the problem with that? Let them use
forks. A distro can't be all things to all people.
as I've heard, many of the servers. It's certainly possible but I'm afraid this will lead to even fewer new contributors to Debian.
Debian is unique in this area, and it would be a shame to sacrifice thatI'm afraid that not providing hardware support is not the same as prioritizing free software, or even free hardware.
and make it just like all the rest. And it's unclear what benefit there
is to attracting a larger and larger userbase as a bottom-line. It is
not a commercial project, so they will not be paying customers. The
best-case scenario is that people are attracted to making contributions
or becoming more interested in free software, which I thought was the
main goal. So if that isn't prioritized, what's the point?
As a person who's handling a lot of servers, I can tell that most high >performance hardware is running either load-on-boot (generally ethernet
and other network cards) or persistent (generally storage and RAID >contollers) non-free firmware blobs.
First category can perform basic tasks without firmware, but servers
being servers, this low performance mode is undesirable barring
light-load servers which is both a minority and a contradiction to the
word server in my profession.
On Wed, 1 Jun 2022 09:41:35 +0300, Hakan Bay?nd?r <hakan@bayindir.org>
wrote:
As a person who's handling a lot of servers, I can tell that most high
performance hardware is running either load-on-boot (generally ethernet
and other network cards) or persistent (generally storage and RAID
contollers) non-free firmware blobs.
First category can perform basic tasks without firmware, but servers
being servers, this low performance mode is undesirable barring
light-load servers which is both a minority and a contradiction to the
word server in my profession.
A machine that can boot and install debian without needing the
firmware blob is already one step better than a machine that needs an
install medium with firmware.
Greetings
Marc
Basic tasks include networking - many IBM and Dell servers use(d) Broadcom >chipsets which wouldn't work without a non-free driver. Been caught out like >that installing in a data centre: can't get networking to work to get the >drivers I need for the network card.
On 30.05.2022 09:36, Andrey Rahmatullin wrote:
On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote:
There are definitely people who use forks because it's easier toThis would mean almost officially dropping support for user computers and, as I've heard, many of the servers. It's certainly possible but I'm afraid this will lead to even fewer new contributors to Debian.
install non-free firmware. What's the problem with that? Let them use forks. A distro can't be all things to all people.
As a person who's handling a lot of servers, I can tell that most high performance hardware is running either load-on-boot (generally ethernet and other network cards) or persistent (generally storage and RAID contollers) non-free firmware blobs.
First category can perform basic tasks without firmware, but servers being servers, this low performance mode is undesirable barring light-load servers which is both a minority and a contradiction to the word server in my profession.
Also, this persistent firmware is meant to be updated throughout the life of the hardware (5-10 years in normal cases). This is why there's fwupd which can manage this upgrade process very elegantly.
Debian is unique in this area, and it would be a shame to sacrifice that and make it just like all the rest. And it's unclear what benefit there is to attracting a larger and larger userbase as a bottom-line. It isI'm afraid that not providing hardware support is not the same as prioritizing free software, or even free hardware.
not a commercial project, so they will not be paying customers. The best-case scenario is that people are attracted to making contributions or becoming more interested in free software, which I thought was the main goal. So if that isn't prioritized, what's the point?
While I proposed a different way for supporting this binary blobs and defended it rather strongly in this mailing list, I'd love to see Debian support more hardware.
On the other hand, I still hold the view that inclusion of this firmware should be in line with the due-diligence Debian is famous for. i.e. Labeling non-free firmware correctly, and giving the user freedom to not install
them, even if this cripples the target hardware in question.
Cheers,
Hakan
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 339 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:14:57 |
| Calls: | 7,466 |
| Calls today: | 2 |
| Files: | 12,691 |
| Messages: | 5,627,862 |