I'd vote for option 5. Thanks so much for bringing this up.
Devin Prater
r.d.t.pra...@gmail.com
On Mon, Apr 18, 2022 at 7:28 PM Steve McIntyre wrote:
> TL;DR: firmware support in Debian sucks, and we need to change this. See
> the
> "My preference, and rationale" Section below.
>
> In my opin
On Apr 19, Steve McIntyre wrote:
> 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.
I agree, and actually I have been supporting this position for 20
years (time fli
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-fr
On Tue, Apr 19, 2022 at 10:22:15AM +0200, parodper wrote:
> > 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
> >
On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:
> 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.
This is a great write-up and proposal, thank you very much
Hi Steve,
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 promis
w...@debian.org wrote:
>
>Also, drivers and firmware are different things.
*Totally*. This is one of my pet peeves - many *many* people confuse
the two and talk about "non-free drivers" in Debian when they actually
mean firmware... ARGH.
--
Steve McIntyre, Cambridge, UK.
Hi Steve,
* Steve McIntyre [2022-04-19 01:27]:
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 al
On Tue, Apr 19, 2022 at 11:33:30AM +0200, Christian Kastner wrote:
> Hi Steve,
>
> 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 st
Quoting Christian Kastner (2022-04-19 11:33:30)
> 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
> Do you have a publication of that analysis? I was thinking the same
> about the organization of Debian for some time but never did analysis
> or compared it to other distros.
i found it here http://lkcl.net/reports/wot/ it's dated 2017 (not a bad
guess, 4 years). please bear in mind, the primary
Hi,
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
On 2022-04-19 12:41, Jonas Smedegaard wrote:
> 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 i
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 abo
Quoting intrigeri (2022-04-19 13:20:19)
> 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
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?
> When I (sometimes, but not always¹) choos
Quoting Andrey Rahmatullin (2022-04-19 14:47:27)
> 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
Steve> 3. We could stop pretending that the non-free images are
Steve> unofficial, and maybe move them alongside the normal free
Steve> images so they're published together. This would make them
Steve> easier to find for people that need them, but is likely to
Steve> cause use
Package: wnpp
Severity: wishlist
Owner: Michael Ikwuegbu
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-openurl
Version : 1.1.1
Upstream Author : Axel Rauschmayer
* URL : https://github.com/rauschma/openurl#readme
* License
On Tue, 19 Apr 2022, Andrey Rahmatullin wrote:
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
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 risky than other
> > > code.
> > Do you consider loadable non-free blobs more risky than their older
> > ve
>
> 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-fre
Quoting Andrey Rahmatullin (2022-04-19 18:01:10)
> 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 risky
> > > > than other code.
> > > Do you conside
On Tue, 19 Apr 2022, Andrey Rahmatullin wrote:
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 risky than other
code.
Do you consider loadable non-free blobs m
On Tue, 19 Apr 2022 08:21:10 -0600, Sam Hartman
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 w
On Tue, 2022-04-19 at 18:51 +0200, Jonas Smedegaard wrote:
> 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 pe
Jonas Smedegaard 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 th
On Tue, Apr 19, 2022 at 06:51:16PM +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?
> > > >
> >
> 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
> "Marc" == Marc Haber writes:
Marc> On Tue, 19 Apr 2022 08:21:10 -0600, Sam Hartman
Marc>
Marc> 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.
Quoting Andrey Rahmatullin (2022-04-19 19:49:59)
> On Tue, Apr 19, 2022 at 06:51:16PM +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
> > >
On Apr 19, Sam Hartman wrote:
> 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
>
Hi Sam
On Tue, Apr 19, 2022 at 02:05:20PM -0600, Sam Hartman wrote:
> 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
On Tue, Apr 19, 2022 at 12:17:06PM +, 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
Quoting Russ Allbery (2022-04-19 19:29:09)
> Jonas Smedegaard 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
Jonas Smedegaard 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
>> firmwa
Package: wnpp
Severity: wishlist
Owner: Hilmar Preusse
X-Debbugs-Cc: debian-devel@lists.debian.org, ProFTPD Maintainance Team
* Package name: proftpd-mod-kafka
Version : 0.1-1
Upstream Author : TJ Saunders
* URL : https://github.com/Castaglia/proftpd-mod_kafka
* Lic
On Tue, 2022-04-19 at 23:33 +0200, Jonas Smedegaard wrote:
> 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
On 2022-04-19 22:51:59 +0200 (+0200), Bastian Blank wrote:
> On Tue, Apr 19, 2022 at 12:17:06PM +, 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 wh
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: mkdocstrings
Version : 0.17.0
Upstream Author : Timothée Mazzucotelli
* URL : https://github.com/mkdocstrings/mkdocstrings
* License : ISC
P
On Tue, 2022-04-19 at 23:00 +0200, Jonas Smedegaard wrote:
> 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 fo
On Tue, Apr 19, 2022 at 11:00:23PM +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 hardwa
42 matches
Mail list logo
