I read it the other way:

        # Using 'no !=' instead of 'yes =' to make sure async nfs
        # mounting is the default even without a value in
        # /etc/default/rcS

/etc/default/rcS as shipped with initscripts has '#ASYNCMOUNTNFS=yes', so

87          if [ no != "$ASYNCMOUNTNFS" ] ; then

is true, and the do_wait_async_mount loop runs until timeout or all mounts appear.

i.e. async mount (AKA just loop while waiting for the network initscript / manager / whatever to call the mountnfs hook) is default behaviour as per the comment, and /etc/init.d/mountnfs.sh only calls /etc/network/if-up.d/mountnfs itself if the user has explicitly disabled async mount.

...which neatly explains the conspicuous lack of attempts to mount NFS in Andre's logs on a fresh install with networkmanager, and the "works same as it always did" for those using ifup and static definitions in /etc/network/interfaces (me, and I suspect you as well).

Seems to me that if Devuan is going to use networkmanager in the default desktop install (connman is going away and all that) and we want fstab NFS mounts to work, the obvious solution would be for Devuan to fork the networkmanager package and put /etc/NetworkManager/dispatcher.d/01-ifupdown back where it belongs.

Of course. The whole 3 ancient architectures that are a "problem" have been using old kernels and custom patches so far, but whichever way you slice it their days are numbered. Nobody really cares, because the only productive use for such machines is as museum exhibits.

@zapper I'm not about to legitimize that childish outburst with a meaningful reply, if the best you have is "but your face" we are done here. Go back to kindergarten.

This kind of unsubstantiated, over-generalised speculation is exactly why

Do you code in rust? How about java? What have you written in python?
Do you personally know these "newbies" you claim are "enabled" by rust? Do you have the expertise to critique their code, or are you just talking out your arse on subjects you have no experience with (again)?

I suspected as much.

The traditional ifupdown setup runs /etc/network/if-up.d/mountnfs to scan fstab once the network interface is up.
I don't have a Devuan install with NetworkMangler to check, but IIRC NM should call the same via /etc/NetworkManager/dispatcher.d/01-ifupdown...

Which is suspiciously absent in the Excalibur package.

Poking about...

I don't use the thing myself, perhaps someone who does might explain how mountnfs is intended to be called by NM now (sans systemd, which would otherwise handle all this)? I dont see a new dispatcher hook file in initscripts (which provides /etc/network/if-up.d/mountnfs), or the Excalibur network-manager package itself.

@ralph.ronnquist: Unless I'm missing some other mechanism, I don't see how the setup in Excalibur is going to work as packaged, at least without a bunch of (somewhat arcane) end-user shenanigans creating a new hook to call mountnfs.
NFS in fstab isn't unusual and should really work OOTB for the default desktop install, was this configuration tested prior to release?

Without logs, crystal ball says boot service ordering issue - i.e. netmount runs before network is up. Especially likely if using some newfangled network "manager" rather than ifupdown.

Any pastebin or fileshare service that isn't obnoxious... or just use pastebinit.

Hardware only supported by ports which do not have a working rust toolchain, obviously. That's right there in the quote from your OP, no "opinion" needed.
If you can't be bothered to check out which ports those are and which architectures they target, why would I bother to opine on the matter?

Crystal ball is out on loan.

Is your 15 year old laptop reliant on a Debian port that doesn't have a working rust toolchain?

Read harder. Rust is just a programming language. Rust has sweet bugger all to do with what Debian does or does not run on.

The "type of computer" Debian can run on is a function of the "type of computer" Debian can be built on. That means having a working compiler toolchain for every required component and language involved, which can produce code that will run on the target architecture.
Adding rust to APT simply moves the rust toolchain from "recommended" (i.e. needed for some optional software) to "required" (needed for core Debian utilities) - alongside C, C++, and a whole bunch of other stuff.

Yes yes, Big Bad Evil Tech, yada yada. What does Microsoft, AI, or IoT have to do with using rust for parts of APT?

"Stability" in the sense Debian practices it is about code maturity and testing. It has nothing whatsoever to do with what languages are used in that code.
If Debian releases untested unstabilised versions of APT to the stable channel, that's breaking with stability. If they rewrite it entirely in brainfuck, then put it through the full testing and stabilisation cycle before release... That's pretty annoying, but still "stable".

This whole place is a rage-against-the-machine echo-chamber for the terminally stubborn and wilfully uninformed... Which is why I rarely post here and usually get into a fight when I do.
This thread is a fine example: Ragebait OP, bunch of whinging about how bad "modern" software is and how stupid "modern" developers are, tangent rants about evil corporations and world domination... And zero technical analysis.

Now, again, million dollar question: Are any of you who are complaining actually running an affected port?

Well, if Devuan shipped netselect-apt with a usable mirror list, we could just use that as it's supposed to be used... But of course they don't, so instead it works brilliantly for finding the best Debian mirror.

I was referring to actual work (i.e. commits/active development), not final release. ARTS itself was close enough to "finished" (by KDE standards anyway) a whiles before KDE4 release.

On KDE4 in general... Personally I don't think it was particularly "bad", as much as it was subject to the same insane development model KDE has always used:
As soon as a major version is finally usable and all serious bugs are resolved, it's time for a complete rewrite and a horribly broken .0 showcasing the newest dumb trend-chasing idea.
With KDE4 that new thing was akonadi and "semantic desktop", which is still a complete mess to this day.
KDE3 was an outlier, because it's "new thing" was fixing the intolerable loading times of KDE2 (remember "prelinking?) and adding some graphical bling... both of which are kinda hard to catastrophically bungle.

Uhh, I don't think we're talking about the same ARTS here. The solution I was referring to hasn't been included in KDE for over 20 years now, and I doubt it even compiles on a modern distro.

If you're referring to

, then the operative word there is "video". Pipewire is more than just an audio server, it's a multimedia server... I.e. it also handles video, which ALSA, being a fairly low-level audio architecture, naturally does not.

Thank you for demonstrating how to say "I have no rational arguments left" without directly admitting such. I'll file it for next time I feel the urge to stage a debate in an asylum.

Aside, I'm pretty sure you've played that old card a few times already... Is it not getting a bit, ahh, trite?

No, it most certainly did not. Many sound cards in the late 90s - early 2000s were ISA plug-n-play, which required manual probing with isapnp and manual writing of settings (IRQ, DMA etc) to a text configuration file.
If you wanted to be able to play audio from more than one application simultaneously, you had to run a sound-server such as ESD (GNOME/Enlightenment) or ARTS (KDE)... Which only worked properly so long as everything you wanted sound from used that server.

Clearly, either you weren't there or you have industrial-strength rose-tinted glasses on. Linux audio in the early 2000s sucked, it was barely better than DOS when there was a driver for your card, and half the time there wasn't.

Yeah, you had to learn that you didn't really need to buy OSS4 to get working drivers after all, and you no longer needed to screw about with sound servers.
ALSA was created because OSS went proprietary with version 4 in 2002.  ALSA also brought DMIX, which solved the above problem and worked "out of the box" without constantly needing to find and kill whatever was tying up the sound device.

The "problems" (that ALSA was created to solve) are quite straightforward - There was no longer a viable free-software sound architecture for GNU/Linux, so one needed to be written.

Yes, it handles downloading packages for you and resolving dependencies automatically... Just like apt-get, for which it is simply a convenience frontend.
Would you prefer to do all that yourself, by hand, like Slackware?

There's nothing "hidden" about apt either for that matter, and there's no "AI" to be found in any of the Debian packaging tools beyond a garden-variety dependency resolver... Which has been there from the beginning. Frankly, your constant "everything new is a conspiracy" nonsense is as tiring as the pseudo-philosophical drivel that invariably follows it. Please stop hijacking threads and preying on new users with this trash.

I don't recall S3 being problematic (unless you wanted 16-bit color, and had more than 16MB RAM, and were still running a VLB card from the '90s... but I digress) but 3DFX sure was
As for Redhat... Yeah. likewise. I went from Slackware to Redhat, then straight to "screw this, I'll roll my own" with LFS.

Given prize exhibits a:

and b:

What, exactly, makes you think I have any desire to further engage with you? You are a site admin, and this is the example you set? How repulsive.

Are you aware that I care not one iota? Spinning up a forum isn't rocket science, nor is it particularly commendable if the intent is to run it like a tin-pot dictatorship for one's own aggrandizement, with a regular side of crotchety spite and patronising babble.

Or did you think "go and ralph's pessimistic arguing club" was just a silly joke?

I'm quite happy to help out here where there are technical questions, or chat where there is mildly amusing (and mostly sane) conversation to be had. But you? You I am done dealing with.

Ed. You want to know how this looks from the outside? From the point of view of the "never enough devs" who you will never do anything but drive away? Go read radiatedradio's comment on the previous page.