Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Pirate Praveen



2022, ഏപ്രിൽ 20 2:19:21 AM IST, Bastian Blank ൽ എഴുതി
>> 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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
On Tue, 2022-04-19 at 11:33 +0200, Christian Kastner wrote:

> 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.

Even before we get to being able to run Debian infra using free
firmware, lots of the x86 servers that make up the Debian infra require
proprietary software running on the CPU, mostly for managing the
hardware; sensors, RAID, BMCs, fault detection and other things.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:

> 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.

There is a list of libre firmware projects on this page:

https://wiki.debian.org/Firmware/Open

We are missing several notable libre firmware projects, it would be
great if Debian could package them. I wonder what other support Debian
could give to libre/open firmware projects.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Re: Bits from the DPL

2022-04-20 Thread Jonathan Carter

On 2022/04/20 08:25, j...@debian.org wrote:

2022-01-12  - Milestone 1 - Transition and toolchain freeze 2022-02-12  -
Milestone 2 - Soft Freeze 2022-03-12  - Milestone 3 - Hard Freeze - for key
packages and packages without autopkgtests To be announced - Milestone 4 
- Full

Freeze


Oops, that was a copy and paste from an initial incorrect mail, the 
dates are of course meant to be for 2023, not 2022.


-Jonathan


OpenPGP_signature
Description: OpenPGP digital signature


Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Andrey Rahmatullin
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.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Pirate Praveen



2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre ൽ എഴുതി
>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 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

Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Pirate Praveen



2022, ഏപ്രിൽ 20 1:14:14 PM IST, Andrey Rahmatullin ൽ എഴുതി
>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.
>

What is no here? This project don't exist or they don't want to provide a libre 
image?

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. 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Andrey Rahmatullin
On Wed, Apr 20, 2022 at 01:25:31PM +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.
> >
> 
> 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
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.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Ansgar
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.

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.

Ansgar



Bug#1009896: RM: ruby-ghi -- RoM; obsolete

2022-04-20 Thread Dmitry Smirnov
Package: ftp.debian.org
Severity: normal
Control: affects -1 src:ruby-ghi
X-Debbugs-CC: debian-devel@lists.debian.org

Please remove "ruby-ghi" from "unstable".

The package is obsolete and no longer maintained upstream.

Thanks.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The difference between technology and slavery is that slaves are fully
aware that they are not free.
 -- Nassim Nicholas Taleb

---

COVID-19: PCR-based testing produces enough false positive results to make
positive results highly unreliable over a broad range of real-world
scenarios.
https://www.medrxiv.org/content/10.1101/2020.04.26.20080911v3


signature.asc
Description: This is a digitally signed message part.


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Jonas Smedegaard
Quoting Russ Allbery (2022-04-19 23:57:21)
> 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 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.

Oh.

Re-reading again myself, and I agree.

Sorry for all the noise: I support option 5.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#1009898: O: dropwatch -- tool for detecting and diagnosing dropped network packets

2022-04-20 Thread Dmitry Smirnov
Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org

Package "dropwatch" needs new maintainer.

I have no understanding with upstream and unable to spare any time for this
package any more. Please adopt this package if you care for it.

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Freedom is the freedom to say that two plus two make four. If that is
granted, all else follows.
 -- George Orwell

---

Corman-Drosten review report: understanding PCR testing fraud.
 -- https://cormandrostenreview.com/


signature.asc
Description: This is a digitally signed message part.


Bug#1009899: ITP: genimage -- The Image Creation Tool

2022-04-20 Thread Sudip Mukherjee
Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-devel@lists.debian.org, sudipm.mukher...@gmail.com

* Package name: genimage
  Version : v15
  Upstream Author : many
* URL : https://github.com/pengutronix/genimage
* License : GPL-2.0
  Programming Lang: C
  Description : The Image Creation Tool

genimage is a tool to generate multiple filesystem and flash/disk
images from a given root filesystem tree. It also supports creating
flash/disk images out of different file-system images and files.

I am using it as part of my current project in $dayjob. Its a
necessary tool to create images with u-boot.
I can maintain it.


--
Regards
Sudip



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Devin Prater
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.pra...@gmail.com




On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen 
wrote:

>
>
> 2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre ൽ എഴുതി
> >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 num

Bug#1009902: ITP: pyqt6-webengine -- Python bindings for the Qt WebEngine framework

2022-04-20 Thread Dmitry Shachnev
Package: wnpp
Severity: wishlist
Owner: Dmitry Shachnev 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: pyqt6-webengine
  Version : 6.3.0
  Upstream Author : Riverbank Computing Limited 
* URL : https://riverbankcomputing.com/software/pyqtwebengine/intro
* License : GPL
  Programming Lang: SIP
  Description : Python bindings for the Qt WebEngine framework

PyQt6-WebEngine is a set of Python bindings for The Qt Company’s Qt WebEngine
framework. The framework provides the ability to embed web content in
applications and is based on the Chrome browser. The bindings sit on top of
PyQt6 and are implemented as three separate modules corresponding to the
different libraries that make up the framework.

I am going to maintain it in the Debian Python Team, like pyqt5webengine.
Packaging will be here:

https://salsa.debian.org/python-team/packages/pyqt6-webengine/

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Jonathan Dowland

On Tue, Apr 19, 2022 at 01:43:39PM +0200, Christian Kastner wrote:

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.


I hadn't even noticed that there was an amd64-microcode package.
Although I see that it is older than my CPU (3945WX), so I'm not sure
that it is (yet) a problem (for me). That said…


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.


I can agree with that, but I think that's a bridge to cross *after* the
change proposed by Steve.


--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Jonathan Dowland

Hi Steve,

Thank you for raising this issue and writing about it so clearly.

On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre 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 would then generate only one set of official media,
   including those non-free firmware packages.


My preference is a variation on Option 5: Effectively, a two-phase
version of it. I think we should produce installer media including
the non-free firmware and for that to be the media that people are
directed to, in the most part, via the normal routes (default path
on website, etc.¹)

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)

I'd also like to see us put a bit more effort into tools like vrms²
so we can make it easier for folks to gauge how much non-free stuff
they are relying upon and maybe even work towards offering tailored
alternatives. (For example I've currently got an Nvidia GPU and the
binary blob drivers installed, for the first time in over a decade,
and I could do with some hand-holding to identify an alternative
which would not require non-free drivers and/or firmware.)


¹ I agree with another person in this thread that the current behaviour
  of auto-downloading an ISO after visiting /download is wrong and
  should be changed, but, that is orthogonal to what you have raised
  and should be addressed separately.

² perhaps starting with renaming it…


--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Russell Stuart

On 19/4/22 10:27, Steve McIntyre 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 would
 then generate only one set of official media, including those non-free
 firmware packages.


The motivation here for splitting non-free firmware into a separate 
component is so we can install Debian on modern hardware.  That's a good 
reason, but I've always thought there was at least one other good reason.


It doesn't belong in Debian.

Unlike everything else, we usually don't have the source, which neuters 
many of the nice security properties inherent with open source.  We 
don't compile it, because even if we did have the source it's probably 
for a CPU & silicon we don't support.  Ergo reproducible builds are out 
of the question: it could literally contain, copy or do anything the 
hardware allows and none of us would be the wiser.  Peculiarly, we don't 
care about the licence, beyond being allowed to distribute it in the 
first place.


One of Debian's foundations is the DFSG but when it comes to this stuff, 
freedoms?  We don't even have the freedom to avoid it.  I'm genuinely 
surprised the project has managed to be in denial and pretend it had a 
choice for this long.


In short non-free packages we have the source for is one thing.  These 
binary opaque blobs are quite another.  They should be in a different 
component.  Non-free-firmware sounds far too innocent to me.  How about 
"not-debian", or "under-sufference".


OpenPGP_0xF5231C62E7843A8C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Polyna-Maude Racicot-Summerside



On 2022-04-20 04:06, Andrey Rahmatullin wrote:
> On Wed, Apr 20, 2022 at 01:25:31PM +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.
>>>
>>
>> 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
> 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.
> 
I think you lack pretty much of seeing more than you own self and use case.
I've used plenty of laptop without making a mess, sometime by using a
external Wifi card or simply choosing wisely.

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.

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Polyna-Maude Racicot-Summerside
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.pra...@gmail.com 
> 
> 
> 
> 
> On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen  > wrote:
> 
> 
> 
> 2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre  >ൽ എഴുതി
> >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

Re: Firmware - what are we going to do about it?

2022-04-20 Thread Polyna-Maude Racicot-Summerside
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-20 08:32, Polyna-Maude Racicot-Summerside wrote:
> 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.pra...@gmail.com 
>>
>>
>>
>>
>> On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen > > wrote:
>>
>>
>>
>> 2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre > >ൽ എഴുതി
>> >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
>>  

Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
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. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Samuel Thibault
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



Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Andrey Rahmatullin
On Wed, Apr 20, 2022 at 08:28:25AM -0400, Polyna-Maude Racicot-Summerside wrote:
> 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
who don't have enough knowledge to find things they need or to dismiss
propaganda. It's much easier for me to handle my own use cases.

> I've used plenty of laptop without making a mess, sometime by using a
> external Wifi card or simply choosing wisely.
> 
> 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.
So you've lost the context.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Polyna-Maude Racicot-Summerside
Hi,

On 2022-04-20 08:39, Samuel Thibault wrote:
> 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.
> 
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



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Samuel Thibault
Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 09:07:47 -0400, a ecrit:
> 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 ?

Because it's difficult for software to divine whether line breaks are
really meant to be flow break or not.

Help on this really welcome.  Bullshit words are not welcome.

Samuel



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Jonathan Dowland

On Wed, Apr 20, 2022 at 09:07:47AM -0400, Polyna-Maude Racicot-Summerside wrote:

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 !


Even IF it was your job to police other people's communication style on
Debian lists, you are really throwing stones in glass houses. Please,
refrain from complaining about someone's posting style ON LIST at least.

--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net



Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Pirate Praveen



2022, ഏപ്രിൽ 20 1:52:45 PM IST, Ansgar ൽ എഴുതി
>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.

"The rational is that the particular bit pattern which constitutes the firmware 
is relatively fixed, and so is essentially hardware. Of course, just like the 
company need not glue the case shut to prevent the end user from using a 
shunt-mod to overclock the GPU, they similarly don’t have to clip off the JTAG 
pins to prevent the user from rearranging those bits however they like. They 
just must not expect the user to do so (or have software on the machine to do 
it for the user automatically) in order to have a correctly functioning 
machine."

Specifically this,
They just must not expect the user to do so (or have software on the machine to 
do it for the user automatically) in order to have a correctly functioning 
machine.

So a person with RYF certified hardware should be a able to use an image 
without the proprietary firmware. As I already clarified, I just want to keep 
the free image option and not opposed to the separate non-free image.

>Ansgar
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Samuel Thibault
Pirate Praveen, le mer. 20 avril 2022 19:47:31 +0530, a ecrit:
> 2022, ഏപ്രിൽ 20 1:52:45 PM IST, Ansgar ൽ എഴുതി
> >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?

They are.

What is not is your computer, that already embeds non-free firmware when
you buy it. Loading newer versions of them or not doesn't change that.

Samuel



Re: Keep both images but stop pretending no-free is unofficial

2022-04-20 Thread Ansgar
On Wed, 2022-04-20 at 19:47 +0530, Pirate Praveen wrote:
> 2022, ഏപ്രിൽ 20 1:52:45 PM IST, Ansgar ൽ എഴുതി
> > 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.

No, the question was about a free OS "along with a libre(!) laptop". If
"libre" means "can use non-free firmware as much as it wants (as long
as this is hidden from the user)", you can just leave out the "libre"
part.

And even for this 10-year-old computer, some non-free firmware is still
present in user-accessible parts (Intel ME). So it's not much of a
change if Debian's install would ship a second one.

> > 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.

Yes, that is the "Of course some devices come with preinstalled
firmware, so it's easy to ignore the firmware exists" approach I
mentioned.  That looks just like lying to oneself to me, so I don't
feel it useful to consider. Other people might be fine with it.

Ansgar



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Devin Prater
Oh, so that's the kind of person you are. Good. I can dismiss your cranky
attitude then. Okay, so the common way of doing this *is* to put a blank
space between paragraphis then? I was told otherwise, but I'm so used to
working with Markdown that I still do it. I just thought I'd make things
look less Markdown-ish on a group full of sighted people that might see a
big blank space instead of a new paragraph.

Anyways, if we want to gatekeep Debian, then fine. Only advanced users will
read up on what firmware is supported, *buy* a laptop with those specs
(which will probably be online (not at Walmart and such)), and if they
don't have the money, figure out how to see or hear their computer long
enough to install needed packages. Great.

Devin Prater
r.d.t.pra...@gmail.com




On Wed, Apr 20, 2022 at 8:08 AM Polyna-Maude Racicot-Summerside <
deb...@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, 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 ?
> 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
>
>


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve McIntyre


Jeremy Stanley wrote:
>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.

Nod, that's exactly what I was suggesting. More information for users
here helps them to make decisions like this, absolutely.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve McIntyre
Hi Polyna-Maude,

Polyna-Maude R.-Summerside wrote:
>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.

Please tone your argument down here.

As developers we're having a discussion about how to make things work
better and more easily for our users. Devin's description of the
troubles they had are entirely on-topic and useful in the context of
that discussion. Castigating them here is *not* helpful.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve McIntyre
Paul Wise wrote:
>
>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:

Oh, I'm quite sure there are more than that even! :-)

>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.

Yup.

>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. 

Yup.

I don't see us fixing *all* of these issues any time soon. But in
those cases where we *can* redistribute firmware we can make things
easier for users who need it.

And *then* we can explain to them why the non-free firmware is bad for
their freedom, with examples of what they can do to improve things.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve McIntyre
Russ Allbery wrote:
>Jonas Smedegaard  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.

Nod, exactly. We can add those options via boot flags and menu
options, with later d-i screens too to allow the choice (maybe in
advanced mode). That's probably the easiest way to manage it.

Now, the *default* is going to be the hard choice for us to make. With
the example of blind people using d-i, we'll want to make an easy
option for those people to boot the installer with all firmware
enabled and installed - see the firmware-sof-signed package that
they'll need to get audio prompts during installation.

>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.

Yup.

>> 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.

Nod.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Ansgar
Hi Steve,

On Wed, 2022-04-20 at 17:11 +0100, Steve McIntyre wrote:
> > Russ Allbery wrote:
> > 1. Purely free installation.
[ Other options ]
> > 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?

Ansgar



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve Langasek
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 <
> deb...@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, 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 ?
> > 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
> >
> >

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve McIntyre
Hey Ansgar!

Ansgar wrote:
>On Wed, 2022-04-20 at 17:11 +0100, Steve McIntyre wrote:
>> > Russ Allbery wrote:
>> > 1. Purely free installation.
>[ Other options ]
>> > 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?

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?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Andrey Rahmatullin
On Wed, Apr 20, 2022 at 05:04:13AM -0500, Devin Prater wrote:
> 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? 
Yes, the variety of our ISOs and the poor way they are presented to the
user is already a significant problem even before considering official and
non-free ones.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Russ Allbery
Steve McIntyre  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.

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.

-- 
Russ Allbery (r...@debian.org)  



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Devin Prater
Sorry, that was rather strongly worded. Although, I think if we just keep
accessibility in mind, from the desktop environment to the boot process,
Debian is already far beyond other distros. Arch comes close, but one has
to know when the boot process begins in order to press Down arrow then
Enter to begin the accessible installer, and then one has to install stuff
like alsa-utils and espeakup to have an accessible console and such, as of
like six months ago.

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?
Devin Prater
r.d.t.pra...@gmail.com




On Wed, Apr 20, 2022 at 11:39 AM Steve Langasek  wrote:

> 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 <
> > deb...@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, 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 ?
> > > 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
> > >
> > >
>
> --
> 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/
> slanga...@ubuntu.com vor...@debian.org
>


RFC: pam: dropping support for NIS/NIS+?

2022-04-20 Thread Steve Langasek
Hi folks,

As of glibc 2.32, upstream has split out RPC support; if you want RPC
functionality, you now need to link against libtirpc instead, which is a
superior, more featureful implementation.

This is a good thing architecturally, but one of the side effects for us is
that, via PAM, we are now pulling a large number of crypto libraries into
the transitively-essential set, because pam_unix links against libtirpc for
NIS / NIS+ support.

Sam Hartman made a valiant attempt to make this an optional dynamic
dependency, but ultimately abandoned the effort.

So I'd like to take a step back and challenge an underlying assumption by
asking: do any of our users actually *need* this functionality?  The RPC
functionality is only used for NIS and NIS+.  NIS is historically quite
insecure, and I'm not aware of any efforts to improve its security (AFAIK
the linkage of the crypto libraries doesn't fix the fundamentally insecure
interfaces of NIS).  NIS+ is intended to be a more secure version of NIS,
but to my knowledge there has never been a free implementation in the
archive; this was a Sun-specific technology, which Sun deprecated two
decades ago[1].

If we dropped support for NIS and NIS+ in the next Debian release, would
anybody miss it?  Or has everyone moved on to LDAP / AD by now?

-- 
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/
slanga...@ubuntu.com vor...@debian.org

[1] "Prior to the release of Solaris 9 in 2002, Sun announced its intent to
remove NIS+ from Solaris in a future release and now recommends that
customers instead use an LDAP-based lookup scheme."
https://en.wikipedia.org/wiki/NIS+


signature.asc
Description: PGP signature


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Andrey Rahmatullin
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 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.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve Langasek
Thanks for starting this discussion, Steve, I appreciate the care you've put
into laying out the options.

On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote:

>  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.)

I am personally comfortable with your preferred option 5, for all the
described reasons (does not reduce user net freedom vs. status quo ante when
the firmware was both non-free and non-updatable, etc etc etc).

However, and I know that I'm suggesting work for other people here: one
thing that has surprised me over the years this question has been open is
that no one who has strong feelings about this issue has taken it upon
themselves to refactor the images so that the non-free firmware is
distributed as an add-on image that could be discovered by the installer at
runtime.  This would preserve the ability to have entirely-free media under
Debian's definition thereof, while also giving users a clearer path to
installing any necessary firmware without having to re-download a separate
image.

And sometimes having 2 separate USB sticks for an install is an
inconvenience, so perhaps someone wants to be particularly clever and give
the installer an appropriately-sized empty partition in the partition table
that the firmware bits could be blatted into.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature


Re: Firmware - what are we going to do about it?

2022-04-20 Thread nervuri
The Debian Social Contract begins with "Debian will remain 100% free".
Changing that is a pretty big deal.  Debian's principled stance on free
software has been one of the main reasons I've been using it for almost
a decade.  I really appreciate the peace of mind of knowing that the
system is 100% free by default.  However, I do use specific non-free
firmware packages for certain devices and it is a pain to find and
install them (which I do by hand, after installing Debian from the
official ISO).

All in all, I'm on board with option 5.  By all means, create the
non-free-firmware archive and include it in the official media.  But
also make it clear to users why proprietary firmware ought to be
avoided.  Add a prompt during installation (similar to the software
selection prompt) and make the best of the educational opportunity that
it provides.  It can begin with a statement on why the Debian Project is
against non-free *ware and it can also mention the security benefits
(and potential pitfalls) of packages like intel-microcode.  Something
like:

```
The hardware devices listed below currently require non-free firmware to
function.  The Debian project advises against the installation of
non-free firmware [insert reasons here], while acknowledging that some
users may require such firmware to use certain devices or to receive
security updates from device vendors.

Select which devices you wish to install non-free firmware for:

  [ ] CPU (device name)
  [ ] Wi-Fi (device name)
  [ ] Bluetooth (device name)
  [ ] Fingerprint reader (device name)

You can change this selection at any time by running [command].  You can
also disable the use of all non-free firmware by selecting the [...]
boot option.
```

Something along these lines would be ideal, I think.



Re: RFC: pam: dropping support for NIS/NIS+?

2022-04-20 Thread Boyuan Yang
Hi,

在 2022-04-20星期三的 10:57 -0700,Steve Langasek写道:
> Hi folks,
> 
> As of glibc 2.32, upstream has split out RPC support; if you want RPC
> functionality, you now need to link against libtirpc instead, which is a
> superior, more featureful implementation.
> 
> This is a good thing architecturally, but one of the side effects for us is
> that, via PAM, we are now pulling a large number of crypto libraries into
> the transitively-essential set, because pam_unix links against libtirpc for
> NIS / NIS+ support.
> 
> Sam Hartman made a valiant attempt to make this an optional dynamic
> dependency, but ultimately abandoned the effort.
> 
> So I'd like to take a step back and challenge an underlying assumption by
> asking: do any of our users actually *need* this functionality?  The RPC
> functionality is only used for NIS and NIS+.  NIS is historically quite
> insecure, and I'm not aware of any efforts to improve its security (AFAIK
> the linkage of the crypto libraries doesn't fix the fundamentally insecure
> interfaces of NIS).  NIS+ is intended to be a more secure version of NIS,
> but to my knowledge there has never been a free implementation in the
> archive; this was a Sun-specific technology, which Sun deprecated two
> decades ago[1].
> 
> If we dropped support for NIS and NIS+ in the next Debian release, would
> anybody miss it?  Or has everyone moved on to LDAP / AD by now?

Before any discussion takes place, I would like to point out a previous
attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check out
the LWN article at https://lwn.net/Articles/874174/ , which would definitely
be helpful for the condition in Debian.

Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part


Re: RFC: pam: dropping support for NIS/NIS+?

2022-04-20 Thread Gabor Gombas
Hi,

On Wed, Apr 20, 2022 at 10:57:58AM -0700, Steve Langasek wrote:

> So I'd like to take a step back and challenge an underlying assumption by
> asking: do any of our users actually *need* this functionality?  The RPC
> functionality is only used for NIS and NIS+.  NIS is historically quite
> insecure, and I'm not aware of any efforts to improve its security (AFAIK
> the linkage of the crypto libraries doesn't fix the fundamentally insecure
> interfaces of NIS).  NIS+ is intended to be a more secure version of NIS,
> but to my knowledge there has never been a free implementation in the
> archive; this was a Sun-specific technology, which Sun deprecated two
> decades ago[1].
> 
> If we dropped support for NIS and NIS+ in the next Debian release, would
> anybody miss it?  Or has everyone moved on to LDAP / AD by now?

NIS still has uses in small, closed environments where setting up LDAP
would be overkill, or if you have to interface with some ancient
systems. NIS+ was a nice idea in its own time, and it allowed making NFS
more secure before RPCSEC_GSS took over. However, the strength of the
crypto used by NIS+ probably does not worth much today anymore, so I'd
be surprised if anyone still used it on Linux.

Doing a quick check, PAM only seems to rely on the RPC libraries for
changing NIS passwords. Personally, I think losing that would not be a
big deal. While I can still see NIS being useful in some corners of the
world, I cannot imagine such an environment wanting to enforce password
expiration. And if you don't expire passwords, then you don't need PAM
to be able to change passwords - running yppasswd should be fine for
voluntary password changes.

Regards,
Gabor



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Sam Hartman
> "Russ" == Russ Allbery  writes:

Russ> I agree with this option split, but that reminds me of a
Russ> different procedural note.

Russ> While I recognize and respect the desire to create a
Russ> comprehensive ballot, I'm still going to advocate for
Russ> proposing a GR only with the options that the person proposing
Russ> the GR would vote above NOTA, and possibly only your preferred
Russ> options.

I agree with Russ in this instance, which may b surprising to some given
how I approached the systemd GR.

I think that we will likely find people to sponsor something close to
all of Steve's options.
And I think that allowing those people to craft the wording of those
options will give them the best chance of winning.
Russ> (That said, I think there's a big exception, which is that if
Russ> you've canvassed a bunch of people who may not want to try to
Russ> craft their own ballot options, and developed options to
Russ> reflect their views, I think that's a fine approach and a good
Russ> reason to propose options that aren't your personal
Russ> preference.)

I also agree with this exception.



Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:

> TL;DR: firmware support in Debian sucks, and we need to change this.

After some discussion on #debian-www with sney (author of the
current auto-download page) and larjona (web team), my preferred
solution to this issue looks somewhat like what is written below.

I believe this solution does not require a GR, as it balances the needs
of different segments of the Debian community and Debian's priciples.

Keep providing images without proprietary firmware, disable the
automatic download on the website download page, create a new download
page containing separate side-by-side panels catering to different
segments of the audience for installing Debian, ordered by the
sophistication of the audience and the amount of people in the
audience. Each of the panels should contain appropriate iconography and
minimal text to avoid overwhelming people; longer explanations could be
hidden behind links/dropdowns. Where the images containing proprietary
firmware images are mentioned, include an item pointing out the
non-free firmware and the limitations of Debian support for that
firmware. Some examples of the panels that could be included:

 * VMs; linking to the free images
 * libre hardware like RaptorCS's POWER9 computers; linking to the free
   images and explaining that we need help packaging the free firmware
   for those devices, since most of it isn't in Debian yet
 * desktops/laptops; linking to the non-free images
 * smartphones/tablets; linking to Mobian images
 * clouds; linking to the cloud images
 * servers; linking to the non-free images
 * Windows; linking to the Debian WSL app and win32-loader
 * SBCs; linking to some relevant info on the wiki
 * Raspberry Pi; linking to the RPi non-free images

If the Debian CD/live teams don't want to test the free images, then
those teams should feel free to stop testing them, and call for other
people to do that work.

If the Debian CD/live teams don't want to build the free images, then
that would pose a problem for people who don't want to download or
redistribute non-free firmware. I think there are enough of these
people that the opportunity to hand over building the free images to a
separate team would be needed.

I feel that the above is a good balance of preventing the problems
pointed out in your mail (along with some other ones), while not
completely fixing all of them due to the conflict with the needs of the
segment of Debian users who want to not have non-free firmware and then
mitigating that through the creation of a separate team for that. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
On Wed, 2022-04-20 at 15:32 +0800, Paul Wise wrote:

> what other support Debian could give to libre/open firmware projects.

Some ideas for this:

We could package the libre/open firmware projects that are missing.

We could lobby hardware vendors to release their existing proprietary
firmware and hardware management software under libre licenses.

We could lobby hardware vendors to stop requiring signatures for the
existing libre/open firmware projects.

We could lobby hardware vendors to allow users to enrol their own keys
for verifying firmware.

We could use some of our money to fund new work on the existing
libre/open firmware projects.

We could initiate the creation of a new non-profit dedicated to the
reverse engineering and reimplementation of proprietary firmware.

Anything else?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part