DistroWatch Weekly, Issue 1078
Posted: 2024-07-08 00:06:35 Source: https://distrowatch.com/12190
The DistroWatch news feed is brought to you by TUXEDO COMPUTERS. This week in DistroWatch Weekly:
Tips and tricks: Changing init software after a distribution has been installed
News: Peppermint OS unveils new Loaded edition, HardenedBSD updates ports, OpenSSH vulnerability patched
Questions and answers: Server machines running desktop environments
Released last week: Finnix 126
Torrent corner: Finnix, KDE neon, Raspberry Pi OS
Opinion poll:....
6.10-rc7: mainline
Posted: 2024-07-07 21:23:46 Source: http://www.kernel.org/
| Version: | 6.10-rc7 (mainline) |
|---|---|
| Released: | 2024-07-07 |
| Source: | linux-6.10-rc7.tar.gz |
| Patch: | full (incremental) |
Linus Torvalds Tactfully Discusses Value of getrandom() Upgrade for Linux vDSO
Posted: 2024-07-07 21:18:00 Source: https://linux.slashdot.org/story/24/07/07/2116225/linus-torvalds-tactfully-discusses-value-of-getrandom-upgrade-for-linux-vdso?utm_source=atom1.0mainlinkanon&utm_medium=feed
Linux's vDSO (or virtual dynamic shared object) is "a small shared library that the kernel automatically maps into the address space of all user-space applications," according to its man page. "There are some system calls the kernel provides that user-space code ends up using frequently, to the point that such calls can dominate overall performance... due both to the frequency of the call as well as the context-switch overhead that results from exiting user space and entering the kernel." But Linus Torvalds had a lot to say about a proposed getrandom() upgrade, reports Phoronix: This getrandom() work in the vDSO has been through 20+ rounds of review over the past 2+ years, but... Torvalds took some time out of his U.S. Independence Day to argue the merits of the patches on the Linux kernel mailing list. Torvalds kicked things off by writing: Nobody has explained to me what has changed since your last vdso getrandom, and I'm not planning on pulling it unless that fundamental flaw is fixed. Why is this _so_ critical that it needs a vdso? Why isn't user space just doing it itself? What's so magical about this all? This all seems entirely pointless to me still, because it's optimizing something that nobody seems to care about, adding new VM infrastructure, new magic system calls, yadda yadda. I was very sceptical last time, and absolutely _nothing_ has changed. Not a peep on why it's now suddenly so hugely important again. We don't add stuff "just because we can". We need to have a damn good reason for it. And I still don't see the reason, and I haven't seen anybody even trying to explain the reason. And then he responded to himself, adding: In other words, I want to see actual *users* piping up and saying "this is a problem, here's my real load that spends 10% of time on getrandom(), and this fixes it". I'm not AT ALL interested in microbenchmarks or theoretical "if users need high-performance random numbers". I need a real actual live user that says "I can't just use rdrand and my own chacha mixing on top" and explains why having a SSE2 chachacha in kernel code exposed as a vdso is so critical, and a magical buffer maintained by the kernel." Torvalds also added in a third message: One final note: the reason I'm so negative about this all is that the random number subsystem has such an absolutely _horrendous_ history of two main conflicting issues: people wanting reasonable usable random numbers on one side, and then the people that discuss what the word "entropy" means on the other side. And honestly, I don't want the kernel stuck even *more* in the middle of that morass.... Torvalds made additional comments. ("This smells. It's BS...") Advocating for the change was WiredGuard developer Jason Donenfeld, and more communication happened (and continues to happen... 40 messages and counting). At one point the discussion evolved to Torvalds saying "Bah. I guess I'll have to walk through the patch series once again. I'm still not thrilled about it. But I'll give it another go..."
Read more of this story at Slashdot.
Fedora 41 Finally Retires Python 2.7
Posted: 2024-07-07 14:34:00 Source: https://developers.slashdot.org/story/24/07/06/234249/fedora-41-finally-retires-python-27?utm_source=atom1.0mainlinkanon&utm_medium=feed
"After sixteen years since the introduction of Python 3, the Fedora project announces that Python 2.7, the last of the Python 2 series, will be retired," according to long-time Slashdot reader slack_justyb. From the announcement on the Fedora changes page: The python2.7 package will be retired without replacement from Fedora Linux 41. There will be no Python 2 in Fedora 41+ other than PyPy. Packages requiring python2.7 on runtime or buildtime will have to deal with the retirement or be retired as well. "This also comes with the announcement that GIMP 3 will be coming to Fedora 41 to remove any last Python 2 dependencies," adds slack_justyb. GIMP 2 was originally released on March 23, 2004. GIMP will be updated to GIMP 3 with Python 3 support. Python 2 dependencies of GIMP will be retired. Python 2's end of life was originally 2015, but was extended to 2020. The Python maintainers close with this: The Python maintainers will no longer regularly backport security fixes to Python 2.7 in RHEL, due to the the end of maintenance of RHEL 7 and the retirement of the Python 2.7 application stream in RHEL 8. We provided this obsolete package for 5 years beyond its retirement date and will continue to provide it until Fedora 40 goes end of life. Enough has been enough.
Read more of this story at Slashdot.