Re: Firmware - what are we going to do about it?
On 30.05.2022 09:36, Andrey Rahmatullin wrote: On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote: There are definitely people who use forks because it's easier to install non-free firmware. What's the problem with that? Let them use forks. A distro can't be all things to all people. This would mean almost officially dropping support for user computers and, as I've heard, many of the servers. It's certainly possible but I'm afraid this will lead to even fewer new contributors to Debian. As a person who's handling a lot of servers, I can tell that most high performance hardware is running either load-on-boot (generally ethernet and other network cards) or persistent (generally storage and RAID contollers) non-free firmware blobs. First category can perform basic tasks without firmware, but servers being servers, this low performance mode is undesirable barring light-load servers which is both a minority and a contradiction to the word server in my profession. Also, this persistent firmware is meant to be updated throughout the life of the hardware (5-10 years in normal cases). This is why there's fwupd which can manage this upgrade process very elegantly. Debian is unique in this area, and it would be a shame to sacrifice that and make it just like all the rest. And it's unclear what benefit there is to attracting a larger and larger userbase as a bottom-line. It is not a commercial project, so they will not be paying customers. The best-case scenario is that people are attracted to making contributions or becoming more interested in free software, which I thought was the main goal. So if that isn't prioritized, what's the point? I'm afraid that not providing hardware support is not the same as prioritizing free software, or even free hardware. While I proposed a different way for supporting this binary blobs and defended it rather strongly in this mailing list, I'd love to see Debian support more hardware. On the other hand, I still hold the view that inclusion of this firmware should be in line with the due-diligence Debian is famous for. i.e. Labeling non-free firmware correctly, and giving the user freedom to not install them, even if this cripples the target hardware in question. Cheers, Hakan
Re: Firmware - what are we going to do about it?
On Wed, 1 Jun 2022 09:41:35 +0300, Hakan Bay?nd?r wrote: >As a person who's handling a lot of servers, I can tell that most high >performance hardware is running either load-on-boot (generally ethernet >and other network cards) or persistent (generally storage and RAID >contollers) non-free firmware blobs. > >First category can perform basic tasks without firmware, but servers >being servers, this low performance mode is undesirable barring >light-load servers which is both a minority and a contradiction to the >word server in my profession. A machine that can boot and install debian without needing the firmware blob is already one step better than a machine that needs an install medium with firmware. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Firmware - what are we going to do about it?
On 1.06.2022 14:33, Marc Haber wrote: On Wed, 1 Jun 2022 09:41:35 +0300, Hakan Bay?nd?r wrote: As a person who's handling a lot of servers, I can tell that most high performance hardware is running either load-on-boot (generally ethernet and other network cards) or persistent (generally storage and RAID contollers) non-free firmware blobs. First category can perform basic tasks without firmware, but servers being servers, this low performance mode is undesirable barring light-load servers which is both a minority and a contradiction to the word server in my profession. A machine that can boot and install debian without needing the firmware blob is already one step better than a machine that needs an install medium with firmware. You're indeed right. On the other hand, No server I touched ever refused to boot w/o any firmware blobs on the install medium. IOW, servers can boot current Debian as is, but linux-firmware-non-free contains some performance enhancing and useful blobs for them post installation. Persistent firmware comes loaded out of the box already (like the old days). Cheers, Hakan Greetings Marc
Re: Firmware - what are we going to do about it?
Hi Hakan, On Wed, Jun 01, 2022 at 09:41:35AM +0300, Hakan Bayındır wrote: > > > On 30.05.2022 09:36, Andrey Rahmatullin wrote: > > On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote: > > > There are definitely people who use forks because it's easier to > > > install non-free firmware. What's the problem with that? Let them use > > > forks. A distro can't be all things to all people. > > This would mean almost officially dropping support for user computers and, > > as I've heard, many of the servers. It's certainly possible but I'm afraid > > this will lead to even fewer new contributors to Debian. > > As a person who's handling a lot of servers, I can tell that most high > performance hardware is running either load-on-boot (generally ethernet and > other network cards) or persistent (generally storage and RAID contollers) > non-free firmware blobs. > > First category can perform basic tasks without firmware, but servers being > servers, this low performance mode is undesirable barring light-load servers > which is both a minority and a contradiction to the word server in my > profession. > Basic tasks include networking - many IBM and Dell servers use(d) Broadcom chipsets which wouldn't work without a non-free driver. Been caught out like that installing in a data centre: can't get networking to work to get the drivers I need for the network card. > Also, this persistent firmware is meant to be updated throughout the life of > the hardware (5-10 years in normal cases). This is why there's fwupd which > can manage this upgrade process very elegantly. > If you're unlucky, you may find that support just isn't there any more - some MegaRAID / LSI cards :( > > > Debian is unique in this area, and it would be a shame to sacrifice that > > > and make it just like all the rest. And it's unclear what benefit there > > > is to attracting a larger and larger userbase as a bottom-line. It is > > > not a commercial project, so they will not be paying customers. The > > > best-case scenario is that people are attracted to making contributions > > > or becoming more interested in free software, which I thought was the > > > main goal. So if that isn't prioritized, what's the point? > > I'm afraid that not providing hardware support is not the same as > > prioritizing free software, or even free hardware. > > While I proposed a different way for supporting this binary blobs and > defended it rather strongly in this mailing list, I'd love to see Debian > support more hardware. > > On the other hand, I still hold the view that inclusion of this firmware > should be in line with the due-diligence Debian is famous for. i.e. Labeling > non-free firmware correctly, and giving the user freedom to not install > them, even if this cripples the target hardware in question. > > Cheers, > > Hakan > All the very best, as ever, Andy Cater
Re: Firmware - what are we going to do about it?
On Wed, 1 Jun 2022 15:21:01 +, "Andrew M.A. Cater" wrote: >Basic tasks include networking - many IBM and Dell servers use(d) Broadcom >chipsets which wouldn't work without a non-free driver. Been caught out like >that installing in a data centre: can't get networking to work to get the >drivers I need for the network card. PXE boot will work and load a kernel and a doctored initrd that contains the non-free firmware. Been there, done that, for thousands of machines. It would be so nice if Debian would offer such an initrd out of the box. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#1012227: general: CPU usage is 50% or higher with WebKitWebProcess
Package: general Severity: important X-Debbugs-Cc: tmcconnell...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation?Unsure, I've been having this issue for a while now * What exactly did you do (or not do) that was effective (or ineffective)? Don't know other than keeping my system up to date * What was the outcome of this action? WebKitWebProcess will use 50% of CPU by itself and will often take the CPU usage to 100% * What outcome did you expect instead?Lower CPU usage *** End of the template - remove these template lines ***
Bug#1012227: general: CPU usage is 50% or higher with WebKitWebProcess
Control: reassign -1 libwebkit2gtk-4.0-37 Control: retitle -1 webkitgtk: CPU usage is 50% or higher with WebKitWebProcess On Wed, 2022-06-01 at 14:57 -0500, Tim McConnell wrote: > WebKitWebProcess will use 50% of CPU by itself and will often take > the CPU usage to 100% Bugs in WebKit should not be reported against 'general', but against the appropriate WebKit package, reassigning the bug. The webkit-help mailing list or the WebKit IRC/Matrix channel can probably help you figure out why this is occurring and what workarounds that you might be able to try. https://webkitgtk.org/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#1012227: general: CPU usage is 50% or higher with WebKitWebProcess
Processing control commands: > reassign -1 libwebkit2gtk-4.0-37 Bug #1012227 [general] general: CPU usage is 50% or higher with WebKitWebProcess Bug reassigned from package 'general' to 'libwebkit2gtk-4.0-37'. Ignoring request to alter found versions of bug #1012227 to the same values previously set Ignoring request to alter fixed versions of bug #1012227 to the same values previously set > retitle -1 webkitgtk: CPU usage is 50% or higher with WebKitWebProcess Bug #1012227 [libwebkit2gtk-4.0-37] general: CPU usage is 50% or higher with WebKitWebProcess Changed Bug title to 'webkitgtk: CPU usage is 50% or higher with WebKitWebProcess' from 'general: CPU usage is 50% or higher with WebKitWebProcess'. -- 1012227: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012227 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1012239: ITP: christianriesen-otp -- PHP library to check HOTP and TOTP one time passwords
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-devel@lists.debian.org, j...@nahmias.net, chris.rie...@gmail.com, pkg-php-p...@lists.alioth.debian.org * Package name: christianriesen-otp Version : 1.4.3 Upstream Author : Christian Riesen * URL : https://github.com/ChristianRiesen/otp * License : MIT Programming Lang: PHP Description : PHP library to check HOTP and TOTP one time passwords Implements hotp according to RFC4226 and totp according to RFC6238 (only sha1 algorithm). Once you have a secret, you can use it directly in this class to create the passwords themselves (mainly for debugging use) or use the check functions to safely check the validity of the keys. The checkTotp function also includes a helper to battle timedrift. . Also includes a static GoogleAuthenticator function class to generate a correct url for the QR code, so you can easy scan it with your device. Google Authenticator is available as application for iPhone and Android. This removes the burden to create such an app from the developers of websites by using this set of classes. Dependency of KanBoard. Will be maintained within PHP Team.
