Re: Linking coreutils against OpenSSL
On Thu, Nov 09, 2023 at 05:38:05PM -0500, Benjamin Barenblat wrote: > Dear Debian folks, > > coreutils can link against OpenSSL, yielding a substantial speed boost > in sha256sum etc. For many years, this was inadvisable due to license > conflicts. However, as of bookworm, coreutils requires GPL-3+ and > OpenSSL is Apache-2.0, so I believe all license compatibility questions > have been resolved. > > What would you think about having coreutils Depend on libssl3? This > would make the libssl3 package essential, which is potentially > undesirable, but it also has the potential for serious user time savings > (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than > coreutils’ internal implementation). I plan to switch APT to OpenSSL for trixie too, so this is not a huge concern to me. It was rightfully pointed out that systemd already uses it, so it's already on bootable systems, with APT using it, it will also be around in chroots. > > Alternatively, what would you think about making sha256sum etc. > divertible and providing implementations both with and without the > OpenSSL dependency? Oh please no. There should be a single build of coreutils. There is no point in doing multiple ones. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: Linking coreutils against OpenSSL
On Fri, Nov 10, 2023 at 11:25:34AM +0900, Simon Richter wrote: > Hi, > > > What would you think about having coreutils Depend on libssl3? This > > would make the libssl3 package essential, which is potentially > > undesirable, but it also has the potential for serious user time savings > > (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than > > coreutils’ internal implementation). > > That is only on amd64 though. > > On ARM and riscv64, OpenSSL is slightly slower than coreutils' sha256sum, so > this would introduce an additional dependency and degrade performance. The > best choice there is the kernel crypto API, which knows about offload > hardware and special CPU instructions, both of which are common. OpenSSL should have the same hardware acceleration features as the kernel crypto API, without the socket overhead. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: Linking coreutils against OpenSSL
On Thu, Nov 09, 2023 at 11:13:51PM +, Luca Boccassi wrote: > On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote: > > > > Dear Debian folks, > > > > coreutils can link against OpenSSL, yielding a substantial speed boost > > in sha256sum etc. For many years, this was inadvisable due to license > > conflicts. However, as of bookworm, coreutils requires GPL-3+ and > > OpenSSL is Apache-2.0, so I believe all license compatibility questions > > have been resolved. > > > > What would you think about having coreutils Depend on libssl3? This > > would make the libssl3 package essential, which is potentially > > undesirable, but it also has the potential for serious user time savings > > (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than > > coreutils’ internal implementation). > > This sounds great. systemd also uses OpenSSL for various things, so > libssl3 is pretty much a given on any bootable installation anyway > already. Strongly agree. In addition to possible performance gains I think there are other benefits. Fewer better reviewed crypto implementations and a single upgrade path would be two, especially since like you say libcrypto is pretty much always there anyway. > > > Alternatively, what would you think about making sha256sum etc. > > divertible and providing implementations both with and without the > > OpenSSL dependency? > > Please, no, no more diversion/alternatives/shenanigans, it's just huge > and convoluted complications for no real gain. > +1
Bug#1055677: ITP: monaspace -- An innovative superfamily of fonts for code
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: monaspace * URL : https://github.com/githubnext/monaspace/tree/main * License : OFL-1.1 Programming Lang: N/A Description : An innovative superfamily of fonts for code I'll maintain this under the fonts team. It is not easy to find a good coding font. This one looks great. The Monaspace type system: a monospaced type superfamily with some modern tricks up its sleeves. It is comprised of five variable axis typefaces. Each one has a distinct voice, but they are all metrics- compatible with one another, allowing you to mix and match them for a more expressive typographical palette. Thank you for using reportbug
Re: Linking coreutils against OpenSSL
Hi, What would you think about having coreutils Depend on libssl3? This would make the libssl3 package essential, which is potentially undesirable, but it also has the potential for serious user time savings (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than coreutils’ internal implementation). That is only on amd64 though. On ARM and riscv64, OpenSSL is slightly slower than coreutils' sha256sum, so this would introduce an additional dependency and degrade performance. The best choice there is the kernel crypto API, which knows about offload hardware and special CPU instructions, both of which are common. Alternatively, what would you think about making sha256sum etc. divertible and providing implementations both with and without the OpenSSL dependency? Makes sense to me, especially if it is a diversion only, not full alternatives (which could not have sensible priorities, because what is fastest is system dependent. Simon
Re: Linking coreutils against OpenSSL
On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote: > > Dear Debian folks, > > coreutils can link against OpenSSL, yielding a substantial speed boost > in sha256sum etc. For many years, this was inadvisable due to license > conflicts. However, as of bookworm, coreutils requires GPL-3+ and > OpenSSL is Apache-2.0, so I believe all license compatibility questions > have been resolved. > > What would you think about having coreutils Depend on libssl3? This > would make the libssl3 package essential, which is potentially > undesirable, but it also has the potential for serious user time savings > (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than > coreutils’ internal implementation). This sounds great. systemd also uses OpenSSL for various things, so libssl3 is pretty much a given on any bootable installation anyway already. > Alternatively, what would you think about making sha256sum etc. > divertible and providing implementations both with and without the > OpenSSL dependency? Please, no, no more diversion/alternatives/shenanigans, it's just huge and convoluted complications for no real gain.
Linking coreutils against OpenSSL
Dear Debian folks, coreutils can link against OpenSSL, yielding a substantial speed boost in sha256sum etc. For many years, this was inadvisable due to license conflicts. However, as of bookworm, coreutils requires GPL-3+ and OpenSSL is Apache-2.0, so I believe all license compatibility questions have been resolved. What would you think about having coreutils Depend on libssl3? This would make the libssl3 package essential, which is potentially undesirable, but it also has the potential for serious user time savings (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than coreutils’ internal implementation). Alternatively, what would you think about making sha256sum etc. divertible and providing implementations both with and without the OpenSSL dependency? Best, Benjamin
Bug#1055634: ITP: asahi-nvram -- NVRAM utilities for Apple Silicon (arm) machines
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: asahi-nvram Version : 0.2.0-1 Upstream Contact: https://github.com/WhatAmISupposedToPutHere/asahi-nvram/issues * URL : https://github.com/WhatAmISupposedToPutHere/asahi-nvram/ * License : MIT Programming Lang: Rust Description : NVRAM utilities for Apple Silicon (arm) machines I intend to package the asahi-nvram utilities that are useful for Apple Silicon (arm) machines, eg. m1 and m2 (probably also m3, etc). The asahi-nvram includes the following tools (which are separate crates and will thus likely be uploaded as separate source packages): * asahi-nvram - generic utility * asahi-btsync - sync MacOS bluetooth settings to bluez * asahi-wifisync - sync MacOS wifi settings to iwd * asahi-bless - select active boot partition (These all use a common apple-nvram crate/library for parsing the nvram content.) The intention is that the packages will be maintained within the rust-team (with support from the bananas-team) and a MR is available for review at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/555 Regards, Andreas Henriksson
