Sorry for continuing the OT, but it needs to be straightened out. There is an implicit suggestion that the code is slow because of Rust – but that’s not the case. These parts are slow simply because this implementation is still relatively new. Compare that to the years of testing behind GNU Coreutils. And the regressions mentioned are already fixed or will be fixed soon. I’m sure more will pop up, but hey, that’s normal for any software under active development, isn’t it?
Which kind of encapsulates why code which is still in active development, especially core functionality, probably shouldn’t be deployed yet (but still we’ve seen this with Wayland and other components becoming the default way before they were truly ready IMHO). The end result for me as a user is that I have a (more secure - I’m guessing that’s the primary motivation for rust coreutils?) but less usable system, and so (ironically) I’m forced to use an outdated (and potentially less secure, and also less likely to receive updates) version just so that I can work.
Just as (in the audio world) - most - people really don’t care what compressor was used, or what microphone or whatever, they just care if they like the tune. As a user, I don’t care about the clever inner workings of Wayland (but as a developer, I do get it) - that’s a given, its like having wheels on a car, you just expect that stuff to be there or its useless - but - I do care if my keyboard auto repeat is different (or not working, or broken) depending upon which application I use, if my mouse cursor is randomly scaled / themed differently between different applications (or sometimes application windows), if my window decoration / theme (if there at all) is different between different applications, I can’t copy paste reliably or a system which used to have uptimes measured in weeks or months - which was, and is, my main motivation for using Linux - now unpredictably logs me out of the session due to some (compositor / Wayland protocol violation) or forces a restart due to a memory leak after an hour or so. </rant>
just saying 
3 Likes
Yes, but Rust-Coreutils are slated to land in Ubuntu 25.10. That’s plenty of time before they make it into an LTS (hopefully ale the nasty bugs will gone by then). And I really think that for any serious work the LTS is a bare minimum. If one want to minimize the chance of running into un-battle-tested code even further, there are plenty of distros with have even more conservative policies – that’s why I’m on Debian stable. So I wouldn’t say users are being forced to run outdated, unsecure or unsupported OSes in this case.
Yeah, Wayland seems to be a different case. As a Linux audio user, I’m really keen on getting more audio software devs into it. While bugs in Wayland still don’t concern me that much (they will be eventually fixed, especially now that all major distros have embraced it), what worries me most are reports from you, the audio software developers, saying the Wayland architecture may be fundamentally broken or the transition will make your work much harder. For now, it looks like Wayland adoption by developers will lag considerably, and in the audio world it’ll probably be even slower. That won’t help reduce the chaos in the Linux audio ecosystem, which already isn’t exactly the sanest thing in the world (to put it mildly).
I wouldn’t go that far - fundamentally - it works, the key point being - fundamentally. We’ve had prototype Wayland native GUIs based on the PreSonus VST3 extension working, to the point that I can load a plug-in and do some stuff with it, so technically that’s cool, that’s like ‘well the engine works’ - but people just expect that - why wouldn’t they - but, we ran into some other design decisions that impact the user experience and which make no sense to me. (Its like - car analogy - having designed a great engine then they put the seats in backwards or something).
At the end of the day, its software, so it can all be fixed eventually but what pains me as a Linux user (since the early 2000’s) and a professional audio developer (in one guise or another) for around as long, and a strong advocate of using Linux for audio, is that opportunities for more mainstream appeal are being missed at the expense of deploying things which aren’t yet ready - I always use an LTS (for the reasons you suggest) but new users don’t always do that - or appreciate why that might be a better plan - than the ‘latest and greatest’. (if you buy a new Mac, you get the latest OS, they don’t suggest you run the previous one, because you know, the new one, well, its a bit… hmmm…). And especially in a niche area such as audio production, to attract more developers we need more users (and vice-versa). As developers, we’re used to a few problems, but the user experience has to be as pain-free as possible. In the meantime, I’ll still be shipping X11 based GUIs in my plug-ins for the foreseeable.
3 Likes
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.