𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

       🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆. 
 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍 
  • 0 Posts
  • 21 Comments
Joined 2 years ago
cake
Cake day: August 26th, 2022

help-circle

  • No, but just for you I spent time today extracting a list of ~250 packages installed from source on my computer, and tomorrow, I’m going to clean re-install all of them, timed, and post the results.

    There’s a mix of languages in there, and many packages have multiple language dependencies, but I’m going by the “Make Deps” package requirements and will post them.

    There will probably be too many variables for a clean comparison, but I know I have things like multiple CSV and json CLI toolkits in different languages installed, so some extrapolations should be possible.

    C is hard, because a lot of packages that must depend on gcc don’t include it in the make dependencies; they must assume everyone has at least one C compiler installed. A couple of packages explicitly depend on clang, so I’ll have that at least.





  • Granted, everyone is different. The cognitive load of Rust has been widely written about, though, so I don’t think I’m am outlier.

    Regardless, it’s not like either of us have any pull in the kernel (and probably never will). I fear for the day we let AI start writing kernel code…

    Absolutely never, in my case. This isn’t what concerns me, though. If Rust is harder than C, then fewer people are going to attempt it. If it takes several hours to compile the kernel on an average desktop computer, even fewer are going to be willing to contribute, and almost nobody who isn’t creating a distribution is ever going to even try to compile their own kernel. It may even dissuade people from trying to start new distributions.

    If, if, if. Maybe it seems as if I’m fear-mongering, but as I’ve commented elsewhere, I noticed that when looking for tools in AUR, I’ve started filtering out anything written in Rust unless it’s a -bin. It’s because at some point I noticed that the majority of the time spent upgrading software on my computer was spent compiling Rust packages. Like, I’d start an update, and every time I checked, it’d be in the middle of compiling Rust. And it isn’t because I’m using a lot of Rust software. It has had a noticeable negative impact on the amount of time my computer spends with the CPU pegged upgrading. God forgive me, I’ve actually chosen Node-based solutions over Rust ones just because there was no -bin for the Rust package.

    I don’t know if this is the same type of “cancer” in the vitriolic Kernel ML email that led to the second-to-last firestorm, but this is how I’ve started to feel about Rust - if there’s a bin, great! But no source-based packages, because then updating my desktop starts to become a half-day journey. I’m almost to the point of actively going in and replacing the source-based Rust tools with anything else, because it’s turning updating my system into a day-long project.

    Haskell is already in this corner. Between the disk space and glacial ghc compile times, I will not install anything Haskell unless it’s pre-compiled. And that’s me having once spent a year in a job writing Haskell - I like the language, but it’s like programming in the 70’s: you write out your code, submit it as a job, and then go do something else for a day. Rust is quickly joining it there, along with Electron apps, which are in the corner for an entirely different reason.


  • You’re throwing the baby out with the bath water with the reductio ad absurdum argument. Rust may very well be less secure than Ada - if so, then does that make it not good enough?

    I say it’s not worth trading some improvement in safety for vastly longer compile times and a more cognitively complex - harder - language, which increases the barrier of entry for contributors. If the trade were more safety than C, even if not as good as Rust, but improved compile times and a reasonable comprehensibility for non-experts in the language, that’s a reasonable trade.

    I have never written a line of code in Zig, but I can read it and derive a pretty good idea of what the syntax means without a lot of effort. The same cannot be said for Rust.

    I guess it doesn’t matter, because apparently software developers will all be replaced by AI pretty soon.


  • Progress?

    Just curious - when’s the last time you compiled the kernel yourself? Do you remember how long it took? And that was all just C, which - while not exactly fast - is at least an order of magnitude faster to compile than Rust.

    I’m seriously concerned that if Linux rally slowly does become predominantly Rust, development will stop, because nobody without access to a server farm will be able compile it in any reasonable amount of time.

    Rust would be better suited to a micro kernel, where the core is small and subsystems can be isolated and replaced at run time.

    Edit: adding a more modern language isn’t a bad idea, IMHO, I just think it should be something like Zig, which has reasonable compile times and no runtime. Zig’s too young, but by the time it’s considered mature, Rust will either be entrenched, or such a disaster that it’ll be decades before kernel developers consider letting a new language in.





  • Btw, why are you actually even surprised by it?

    Well, because Redhat was the first linux distribution I used, and I did so four about 6 years personally and then another decade professionally (various versions, from CentOS to RHEL) and IME it’s by far the worst distribution I’ve used, and RPM is, and always had been, a clusterfuck of a package management system. The excuse for use in Enterprise was that companies could pay for 24/7 service support, and that is often a deciding factor, especially if OPs has a strong voice in the decision process; but by god is it a horrible system.

    I’m actually pretty oblivious to any Redhat controversy; I don’t bother reading anything Redhat-related anymore.

    I’m not surprised that it’s widely used, for the same reason I’m not surprised Microsoft is widely used: because of the enterprise decision process. But the popularity surprises me.

    Did they provide raw scores?

    Yup! Here:

    Thanks!

    Ah, would this comment help?

    I saw that; absolute values would be preferable, but I can work with percentages - two decimal places of accuracy should be fine. It’s not like we’re trying to do science here.

    I’m more interested in a ranked-choice version of this poll.

    Me too. I suppose you could retro-actively use the raw scores for this. I’m curious of your findings!

    I think you can’t, because it requires each voter to rank their preferences, which requires a specific form of voting mechanism. I didn’t participate in the poll, but if it was run as ranked choice, and if we had access to the raw, per-voter results, and if the sample size was sufficiently large; then yeah - we could run a full Condorcet count and get some interesting answers!

    The hard part about doing an “should these two distros go into the same bucket” evaluation is determining how closely related distros are. For example, I wouldn’t consider Mint to be Debian because there are no number of packages you can remove from Mint to make it pure Debian without breaking it. Believe me, I’ve tried. At some point, there’s are very Mint-specific packages which, if you remove them, the system won’t boot. A dedicated and knowledgeable enough person might be able to swap packages out and keep a running system, but the Mint-ness is woven in pretty deeply into some core package dependencies. I suspect the same is true for Ubuntu->Debian, but maybe not for Kubuntu->Ubuntu. I know you can go from Arch->Artix and back again, although it’s a bit of work. I don’t know if you could remove enough of EndeavourOS to get pure Arch and still have a bootable system (I haven’t tried).

    So, you could just bucket everything by package manager - does it use apt? Then it’s Debian! Although, now with Snap, how much is Ubuntu based on Debian anymore, anyway? Anyway, this is the last, uninteresting way.

    More interesting is bucketing by whether it’s reasonably possible to convert one distribution to another. I suspect you could turn Arch into Endeavor by changing some source package lists, running an upgrade and maybe installing a package or a dozen. Figuring this out for every distribution would be hard.




  • I’m surprised to see Fedora ranked so highly.

    Did they provide raw scores? I’m curious about two things, one is which could be determined from vote counts, and the other which would require a different voting system:

    • I kinda want to roll up the values into the base distribution, and rank that. Distros obviously add value, but Endeavor and Cachy are a couple of extra (removable) packages descended from Arch. There’s a hard, subjective version: “Is Ubuntu really just Debian with extra packages?” ; an easier version of this: “can Y be turned into base X without dramatic system modification?”; and a really easy, but probably uninteresting version: “is Y descended from X?”.
    • I’m more interested in a ranked-choice version of this poll. While I suspect the results would be similar to the second evaluation version above - users are likely to rank ancestor or siblings above other base distros - it still might be interesting. E.G., I like EndeavorOS but might rank Alpine over base Arch.





  • I’m a little conflicted about Telon Cusk. I don’t think the EV auto industry would be as far advanced today if not for his efforts; I think we’d have gotten here eventually, but maybe a decade or two later.

    Same with the space industry. I wish that, instead, NASA would have been well-funded and space would have remained a science-first (with hidden military objectives; that was unavoidable) effort, but Tusk stepping in and pushing created a new space race where governments had failed.

    He created neither Tesla nor SpaceX, nor was he the technical mind behind them; but his pumping money into them and his grandstanding did a lot to motivate other players in those industries.

    Does that good outweigh his fundamental evil nature? Probably not. But he has been instrumental in some good advancements.