LWN: Comments on "Fedora 40 firms up for release"

Fedora 40 firms up for release

mathstuf — Sun, 28 Apr 2024 15:00:01 +0000

Agreed. I had used `wpa_supplicant` for the longest time with `ifup`/`ifdown`, but `iwd` and `systemd-network` do work better for me.

Fedora 40 firms up for release

farnz — Thu, 25 Apr 2024 14:34:17 +0000

The big problem with network scripts at the moment is that they're unmaintained, and depend on dhclient, which is being removed from the distro. I don't get the impression that there's huge opposition to keeping them around for now, just to putting work in to maintain them; if you want them to stay around, it might be worth volunteering to update them to not depend on dhclient.

Or consider systemd-networkd if you want something less dynamic than NetworkManager.

Fedora 40 firms up for release

Wol — Thu, 25 Apr 2024 14:16:10 +0000

Or is it just appallingly documented (like so many things) because it's "intuitive" and it "just works"?

Having finally managed to get my laptop to connect over wi-fi, the grief ... and in the end - having thought I'd uninstalled NM because it steadfastly refused to play ball - it was NM that got me online!

However, having had it refuse to use the wifi link because it thought the RJ45 was working, now it claims the RJ45 isn't working because the wifi is ...

Cheers,
Wol

Fedora 40 firms up for release

Tet — Thu, 25 Apr 2024 12:15:06 +0000

I'll be disappointed when network scripts are removed. One of the first things I do when I build a new box is to remove NetworkManager. It provides literally zero functionality that I didn't already have and brings with it increased complexity, lack of visilibity and unreliability. If you're on a laptop and your network connection is likely to change then it or something like it is needed. For me, with a fixed network with static IPs it's simply not and I'd rather live without it. But it looks like this is only a temporary reprive and that I'll be forced to use it in the next Fedora release :-(

Fedora 40 firms up for release

farnz — Wed, 24 Apr 2024 10:02:07 +0000

I just looked over my logs for Fedora 39; for various reasons, delta RPMs have cost me more network transfer than they've saved (usually because the kernel's delta RPMs did not reconstruct cleanly, so having downloaded a 20 MiB delta, it's followed up by downloading the 100 MiB full RPM).

So, the tradeoff with the current state of delta RPMs is you either use less CPU and less network transfer by not using delta RPMs, or you use more CPU and more network transfer to do delta RPMs then fall back to downloading the full RPM. And that's on the basis that you update daily, and thus the current generation strategy of only producing a delta against the previous RPM version actually creates deltas you can use; if you update less frequently (to reduce the amount of network transfer you use for metadata), you get access to fewer deltas, since you're more likely to have missed an intermediate update.

If people actually cared about delta RPMs, they'd be working on fixing those issues; but nobody cares, so they're getting disabled instead.

Fedora 40 firms up for release

motk — Wed, 24 Apr 2024 00:42:32 +0000

A cabal? Really? Touch grass.

Fedora 40 firms up for release

motk — Wed, 24 Apr 2024 00:40:20 +0000

I'm currently working in an area where ftp has been de facto for decades, but now you get very serious people from insurance companies looking at you if you're still using it, so we're unpicking twenty years of various scripts to do away with it. We're not even allowed to use scp anymore. Pleae let it die.

Fedora 40 firms up for release

motk — Wed, 24 Apr 2024 00:37:24 +0000

Uh, what does systemd have to do with this?

Fedora.next project

swilmet — Sat, 20 Apr 2024 16:05:46 +0000

The Fedora.next project is done!

Fedora.next is an umbrella phrase for the planning for the second decade of the Fedora Project.

"Done", i.e., the second decade has passed (Fedora 20 to 40) and so much has been achieved. A retrospective would be worthwhile. As well as plans or guesses of what will happen for the next 20 releases!

Fedora 40 firms up for release

mathstuf — Fri, 19 Apr 2024 20:38:07 +0000

If this were the case, I'd have a hard time communicating with the router when DHCP is misconfigured (usually my fault) and not doing its job properly. Today, I can claim a static IP, set up routes, and fix my problem over the network.

Fedora 40 firms up for release

vadim — Thu, 18 Apr 2024 15:39:46 +0000

Passive mode still leaves problems server-side.

For instance for a server behind NAT, you need a kernel module to rewrite packets. This is ugly, makes firewalling harder, doesn't work with SSL, and is a serious performance impact on fast networks because it can require very extensive packet inspection and rewriting.

Fedora 40 firms up for release

jond — Thu, 18 Apr 2024 15:04:38 +0000

I wanted to make the same comment but in respect of WARC support. At least there are many other options for FTP clients.

In WARCs case, it seems that it wasn’t removed so much as never implemented in wget2 in the first place: it seems wget2 is a different code lineage to wget1.

Fedora 40 firms up for release

mathstuf — Thu, 18 Apr 2024 14:49:10 +0000

I remember filing an issue to first check HEAD for the drpm manifest file's size before downloading it. If it was bigger than the proposed transaction's download…just don't as the manifest will eat up any and all savings the drpms might at that point. That did get fixed IIRC. When trying to save network, one needs to check *all* network downloads on the way to computing such savings.

Fedora 40 firms up for release

farnz — Thu, 18 Apr 2024 14:42:24 +0000

Most routers route completely separately to DHCP assignment, so there's no knowledge that an IP was manually assigned (or claimed in error) rather than DHCP-managed. Thus, no way to drop packets on the floor if they're from the "wrong" device.

And routers aren't involved at all if the packet is going on the same subnet; packets go direct if you're on the same subnet, and only go via the router if you're going upstream.

Fedora 40 firms up for release

Karellen — Thu, 18 Apr 2024 14:31:55 +0000

I'm kind of surprised that address conflicts are a problem on DHCP-managed address ranges.

Given that DHCP leases tend to be managed by routers, I'd have thought that if a device tries to send an IP packet with a source IP address that is in the DHCP-managed range but was not assigned to it, that the router would either return an error packet to the originator, or just drop the packet on the floor. I would not have expected it to forward the packet to any other devices on the subnet, or to pass it further upstream.

Fedora 40 firms up for release

rwmj — Thu, 18 Apr 2024 10:21:16 +0000

FTP is fine - I know because I wrote a whole FTP server from scratch. The original mode where the FTP server would connect back to the client (active mode) was a bad idea in hindsight, but every FTP client and server now defaults to passive mode.

Fedora 40 firms up for release

cyperpunks — Thu, 18 Apr 2024 10:04:03 +0000

Just switch to lftp

Fedora 40 firms up for release

seyman — Thu, 18 Apr 2024 08:51:42 +0000

> If you think the old relic is that valuable, convince your company to pay somebody to maintain this.

Or just use one of several ftp clients (ncftp, lftp, filezilla, ...) that the fictional cabal has somehow forgotten to remove from the distribution.

Fedora 40 firms up for release

zdzichu — Thu, 18 Apr 2024 07:59:32 +0000

The most glaring problem with delta-rpms is how to create the for all the combination of package versions which may be involved in the upgrade. No one found a viable solution for that.

Fedora 40 firms up for release

amacater — Thu, 18 Apr 2024 07:16:56 +0000

Agreed: Red Hat isn't behind every choice. Now that Fedora is effectively further upstream, even less so.
Fedora has a thriving set of developers of its own.

One thing, however: as a relative outsider, my viewpoint is that no-one should _rely_ on Fedora to be stable. It is a cutting edge release for things to be tried. If you want to rely on it long term - say as the basis for Amazon Linux 2023 which seems to be put together from three Fedora releases and CentOS stream - you're doing it wrong, given that the lifecycle is 13 months.

Fedora 40 firms up for release

vstinner — Wed, 17 Apr 2024 22:06:36 +0000

Red Hat is not behind every single choice in the open source community. I don't see the relationship between Wget2 and systemd.

Fedora 40 firms up for release

vstinner — Wed, 17 Apr 2024 22:04:17 +0000

FTP client also sends the password in clear text, which is not great in terms of security.

Fedora 40 firms up for release

vadim — Wed, 17 Apr 2024 21:40:50 +0000

FTP is a terrible protocol. I don't know why anybody uses it anymore.

* There's the NAT/firewall problems (okay, not a problem internally)
* There's the awful ASCII/binary mode that corrupts data.
* Awful support for SSL
* End of transfer is not signaled in any elegant manner. Socket is just closed.
* No protection against corruption.
* Opens a connection per file, leading to bad performance.
* Directory listings are non-standard, with a dozen possible varieties.
* Designed for interactive command-line usage and overall ill-fit for automation (some old school servers will want you to read the MOTD)

So yeah, FTP is dead and removed from web browsers for very good reasons.

Here's a good alternative: WebDAV. Runs on top of HTTP, doesn't have trouble with firewalls, doesn't have trouble with detecting ends of files, doesn't corrupt data, well supported out of the box everywhere, actually standard protocol, piggybacks on top of HTTP so saves you a second setup.

If you think the old relic is that valuable, convince your company to pay somebody to maintain this.

Fedora 40 firms up for release

jccleaver — Wed, 17 Apr 2024 21:10:57 +0000

>FTP can't die soon enough. It's terrible technology.
> And if organizations care about it, maybe they can pay the wget project to maintain the FTP functionality.

Thank you for clearly demonstrating the mentality in my above comment about Fedora Linux -- if the small cabal of leaders and/or systemd junkies doesn't rely on your feature, or finds something annoying even if it has no impact to them -- they'll have no compunctions about yoinking it, leaving a busy sysadmin to find out long after the fact that some expected behavior has changed and it's too late to fix it. Upon query or remark, they'll then be told to go pound sand for thinking that something like crontabs or *fricking FTP* might be something someone could be expected to rely on in a Linux distro.

Fedora 40 firms up for release

jccleaver — Wed, 17 Apr 2024 21:08:03 +0000

>The problem with delta RPMs for me is the extra CPU overhead.
>It's not uncommon at all for me to be running some weak silicon that can download all 1GB of updates in a minute or two, but takes forever to rebuild RPMs from .drpms.
>I get the noble intention, but if you're dealing with weak hardware, the savings is usually not worth seeing all your cores maxxed out for 10 minutes straight.

The answer, of course, is to do both. Have full RPMs for those who have lots of bandwidth and little CPU, and deltarpms for those on weak connections running normal box, or a VM on a normal box. The kvetching about the time/energy used to create deltarpms when high-compression and compute-intensive actions being done once for the benefit of many users always seemed symptomatic of larger problems with Fedora Linux as a whole -- near-complete obliviousness to the myriad use-cases out there.

Lesson learned: If someone on the systemd team or anywhere else isn't actively affected by an issue or use of a feature that you are, don't rely on it in Fedora Linux, because it'll be pulled whenever someone decides to toss out the babies to scratch a bathwater itch.

Fedora 40 firms up for release

vadim — Wed, 17 Apr 2024 08:53:31 +0000

FTP can't die soon enough. It's terrible technology.

And if organizations care about it, maybe they can pay the wget project to maintain the FTP functionality.

Fedora 40 firms up for release

eru — Wed, 17 Apr 2024 08:00:08 +0000

Wget2 has a number of user-facing changes in the form of changed CLI options and the removal of FTP and web archive (WARC) support

FTP removal in wget looks like a bad change. It is used much less than it used to, but FTP servers still exist, typically inside organisations.

Fedora 40 firms up for release

Subsentient — Wed, 17 Apr 2024 03:47:24 +0000

The problem with delta RPMs for me is the extra CPU overhead.
It's not uncommon at all for me to be running some weak silicon that can download all 1GB of updates in a minute or two, but takes forever to rebuild RPMs from .drpms.

I get the noble intention, but if you're dealing with weak hardware, the savings is usually not worth seeing all your cores maxxed out for 10 minutes straight.

Fedora 40 firms up for release

rahulsundaram — Wed, 17 Apr 2024 00:56:22 +0000

> I won't miss delta RPMs. When present, they typically save well less than half a percent, and the extra complexity isn't worth the tiny savings.

While I agree that delta RPMs are likely not worth the effort for many today, I have to note that when it originally introduced in Fedora the percentage of download savings was regularly well over 50% and sometimes over 90% as seen for instance in the test results from 2009.

https://fedoraproject.org/wiki/Test_Day:2009-04-16_Presto

This was a frequent source of delight for users at that time and I am glad Jonathan Dieter, a community volunteer stepped up to make this happen along with others in Fedora. In recent releases however, it appears that Fedora infrastructure stopped producing the delta RPM packages consistently resulting in the advantages largely being lost. Hopefully broadband internet access has caught up elsewhere in the world that this isn't a barrier to getting updates.

Fedora 40 firms up for release

JoeBuck — Wed, 17 Apr 2024 00:43:19 +0000

I won't miss delta RPMs. When present, they typically save well less than half a percent, and the extra complexity isn't worth the tiny savings.