There's no limitation on concurrent filesystem operations in "the computer" or the operating system, such "queue" functionality is clearly part of whatever file manager you're using or the VFS backend it's using for SMB.

There are zillions of tools available for copying files, I suggest you find a better one (*cough* rsync at the CLI) or file a bug report against whatever file manager that is in that cropped screenshot.

Sweet sod all. The only way rust "excludes" anything is where there is no compiler for a particular arch... Which is to say architectures that aren't supported by current kernels or current Debian anyway.
If you want to run a current GNU/Linux distro on 25 year old 32bit hardware you're SOL, rust or no rust. Did we all moan so loudly about Linux not supporting 16bit? Or drivers for OAK VLB video cards being dropped? Or when we needed more than 4MB RAM and our 386 wasn't fast enough to run GNOME 1.1?

Does anyone here actually run GNU/Linux on a DEC Alpha or an Amiga? That covers most of the "old shit" that won't be able to compile rust code (at least not with LLVM)... Or are we just complaining for the sake of complaining?

Beyond the inevitable deprecation of ancient hardware, what language a program is written in means nothing to the end user of a binary distro at all. It's all machine code by the time you get it.

Compiler licences (i.e. clang/LLVM/rustc not being GPL) have nothing to do with the language itself. Language spec licences don't transfer to programs written in that language either.

If you never work on or even compile the code in question (neatly covering most of the chronic "new == bad" "young == stupid" "we're all doomed" whiners and conspiracy theorists around here), the language or compiler used is irrelevant... So long as the implementation isn't a mess.

IOW, Ubuntu's coreutils replacement didn't go sideways because it's a rewrite in rust, it went sideways because it's a rewrite that didn't get tested properly.
If APT with rust is maintained to the same code-quality standards as APT without rust has been, the only thing that changes for users is maybe some different libraries being installed. Any issues pertaining to language or compiler toolchains is for the developers and packagers to deal with, and they're mostly the same people wanting this to begin with.

LOL, I knew TDE was keeping a few dinosaurs around, but I didn't realise they were hanging on to that particular fossil. IIRC upstream stopped doing any serious work on it somewhere around 2003. Still, if it works it works.

No, I'm refusing to be drawn into an obvious trap, and a discussion which has nothing to do with the topic at hand. If you must start this nonsense again, for the umpteenth boring time, find some other gullible sap.

My statements stand on their own merit, as they are based on readily verifiable fact. I have neither the need nor the desire to resort to metaphysical rambling to defend them.

Because they're completely different technologies, operating on different layers. You don't choose ALSA or pulseaudio/pipewire, you choose ALSA with or without a sound server on top of it for additional functionality.
That added functionality is primarily dynamic gapless source/sink switching, intelligent sample-rate selection, and JACK-style live patching and routing. ALSA can do most of those things by itself statically if you're willing to write a convoluted .asoundrc, but pulseaudio/pipewire does it on-the-fly without interrupting playback.

Technology evolves and expectations change. Nobody had 4 bluetooth devices they want to seamlessly switch between in 2002. Very few people had complex livestreaming setups with multiple mixed sources in 2002.
Just as OSS was extended with sound servers to deal with the rise of fancy graphical desktops and UI sound effects, ALSA was extended with sound servers to fit the needs of mobile computing, wireless audio peripherals, and an increasing number of people wanting to do complex dynamic mixing without the need for a dedicated mixing deck.

ALSA also can't do video streaming of any kind, which is one of the primary reasons to use pipewire in a wayland environment. I don't use wayland (currently), but if you do, you'll need pipewire for screenshots, video capture, and remote-desktop.

Whether you need any of that is up to you, but the software exists and is widely deployed - with many satisfied users. That speaks to more than a few people finding it useful enough to justify the added complexity.

Can you go a single post without trying to derail technical discussion with irrelevant pseudo-philosophical bullshit?

Damn, this is so stereotypical "old coot too busy living in the past and basking in ancient glories to notice the house burning down around them" it'd be outright hilarious, if it weren't so tragic.

Go on then, ban the uppity kids from "your" lawn. If you're so keen to drive user count to zero, might as well make it quick. For the love of dog, at least quit with the endless "In my day..." sanctimonious preaching.

Phew, so this is the go and ralph pessimisim club after all. Had me going for a bit there.

Ahh, even better... Vintage test equipment.
Beware, that disease is catching and never entirely curable. Voltmeters are particularly pernicious, being simultaneously easy to obtain and easy to justify. Scopes and signal generators are safer - since they take up more space, it's slightly easier to notice when you have enough only need one more.

Simpson did make nice gear, and I have just realised I don't have any. I'll be right ba...

Ahem, my current "old faithful" bench meter is one of these... And yes, I have used the 5Kv range, and I am still alive.

Project #379 (currently occupying said bench) is to fix the '90s Hameg (yeah, I know, kinda "meh") 40MHz storage scope I got for a song. Digital overlay and analog side don't agree on what range channel B is on, and that's some in-house shift-register data-bus malarkey that looks deliciously entertaining to figure out. Also I'm pretty sure it's the last "hybrid" storage scope with a real tube...
But I digress. I wouldn't want to annoy the locals (more), with off-topic not-conspiracy non-whinging now would I.

Oh, too late. Here they come for amateur philosophy hour.

Righty ho then, seems I'm rolling rocks up Mt. Kruger again. Guess I'll stop now before this gets out of hand.

Shame, audio engineering is a bit of a hobby of mine. Mostly old-school analog stuff mind, but here I was hoping for a real debate and maybe an excuse to unpack some of my pets test equipment. Nevermind.

I see... When rational arguments don't go your way, appeal to, what, garden-shed psychology? philosophy? No thanks.

If you think your ears are a reliable instrument, you might be happy reading tea leaves.

I'm not going to argue this, you'll just keep trotting out the old "if you can't hear the difference" line until we both die of old age.
I've been there before, with many an audiophool convinced that the special crystal power lead stands or $8000 speaker cables they got conned into buying make a real difference. All that happens is abandonment of any kind of scientific method for a bunch of feely-woo about "warmness" "depth" "clarity" and other intangible unquantifiable nonsense. Sound reproduction is not magic, and any parameter thereof that matters can be measured and quantified.

Further, it can be measured and quantified with the kind of equipment that costs very little these days - so you are either intentionally omitting measurements because you know they won't prove your point, or you lack the expertise to conduct them. Either way, I call shenanigans. The burden of proof is on the one making the bold claims, and right now that is you.

It's not so difficult to hook up a scope and show us the difference either. If the ALSA defaults really sound that bad, it should be quite obvious on even rummage-sale grade 10MHz gear.

"If you don''t hear the difference it doesn't mean my gizmo isn't working, you must just not have golden ears" is the standard line of audiophool snake-oil salesmen everywhere, always has been.

Yeah, I know. I've got an old Pi with a DAC hat in my lounge that's set up that way. It only runs MPD, so who cares about stream mixing. vOv

That's... Interesting. I've talked to people having strange issues with the system bell before, and never really figured out what was going on. That might be a useful clue the next time it comes up.

As they say in the industry, 'scope shots (showing resampling artefacts) or it didn't happen. You're writing guides on "bit-perfect" "audiophile" sound, so I assume you have a decent 'scope handy to test your findings, right?
Alternatively, feel free to point out the lines in the kernel sources that do this. I've looked (a long time ago, to be fair), have you?