[–] 1 point 3 weeks ago (2 children)

There's a couple big reasons, sometimes you only have to deal with one or two, other times you're hit with all of them.

The data source for the algorithms often comes from arbitrary memory addresses that live outside the context of the C, C++, or Rust runtime. If I want to read CPU core temp I send magic numbers to one address to configure ADC channel conversion, another magic number somewhere else to do the conversion, wait a few dozen microseconds, then read a third new address that I squint one eye, spin around 10 times, and do a handstand and I'll get a number that looks like temperature.

If I'm running on the microcontroller, I'm essentially in production environment and I can't control what the data is. If I recompile for a different system (say x86 Linux) then I'm almost certainly going to segfault. I could abstract out the reading of the data, but then on my tiny 8MHz microcontroller that has to run it's main loop at 1000Hz, I only have a few thousand clock cycles to get everything done, calling functions, pushing/popping the stack takes a lot of time.

Adding to the pile-on most microcontrollers have <1MB of RAM, many in the tens of kilobytes range so I don't have much of a stack to work with and I need to keep even the number of instructions down.

Even if you do all the abstractions, you then have extra logic you have to write to simulate what is happening and subtle behaviors that are timing dependant. It frequently is extremely difficult to do that as the documentation rarely fully describes everything, so you can lull yourself into a false sense of security that you've tested the code and it's correct, but then you get stuck on a register value that never changes and a watchdog timer comes along and resets the hardware on you.

And that's not the getting into the runtime or build environments, flashing procedures, limited flash cycles, and a million other business constraints that technically you can do it, but at that point your dev team has all taken the month off to go play Half Life 3

  • source
  • parent
  • context
  • [–] 1 point 3 weeks ago (1 child)

    that is the argument linus is making... he is comparing a deterministic tool (a compiler that outputs the same assembly every time) to a non-deterministic tool and saying that they are the same type of tool. that require the same level of review, when they do not.

  • source
  • parent
  • context
  • [–] 1 point 3 weeks ago*

    IMHO supporting several init tools does more harm than good to any distribution. Its a lot of extra effort that few users will even notice.

    Traditionally we used a script to boot. Those of course looked different in each distribution, but the "init tool" was the same. Then we switched over to sysv init (and man did people complain about this overcomplicated mess of symlinks!), yet pretty much all distributions switched to that. Of course they shipped widely different init scripts, but the tool was pretty much the same everywhere. The Linux Standard Base even prescribed the sysv init and any compliant distribution had to use that. We never had a time where distributions offered options wrt. init tooling.

    I doubt the portability issue reporting from gentoo makes any difference whatsoever for the BSDs. They come up with all kinds of Linux compatibility stuff and that gets them the software they want.

  • source
  • parent
  • context
  • [–] 1 point 3 weeks ago (2 children)

    Frankly, compilers come pretty close to reaching the necessary complexity to be practically non-deterministic; anyone who had never spent days banging their head against code that works perfectly with debug enabled but fails utterly when compiled with release optimisations, but only when two logically entirely unrelated pieces of code happen to be written in a particular order, and then only if interrupts are enabled on the target… Well, anyone who hasn’t been through that has no business calling themselves a software engineer - and certainly no business telling other software engineers what tools they are allowed to use.

    that is still deterministic.... you don't understand what deterministic means.

    go ahead and show us an llm that is deterministic with a parameter passed to the inference engine. I'll wait.

  • source
  • parent
  • context
  • [–] 8 points 3 weeks ago (7 children)

    Modern, clean codebases that can attract rather than deter contributors. Sure, a lot of the coreutils are "feature complete" but they still need maintenance+security patches and someone will need to work on and release those.

    Are you someone who's also against the deprecation of X11 for Wayland?

  • source
  • parent
  • context
  • [–] 2 points 3 weeks ago

    Ai is bad is such an intellectually lazy take. Anyone who understands Data Science and Calculus well enough to understand how LLM's work are going to be able to get better results than everyone else. Everyone else, well, they are grasping at straws and inventing fictions....Seriously go study data science and experience statistics before you make claims that don't hold up to scrutiny.

  • source
  • [–] 5 points 3 weeks ago

    Interesting take on things.

    My take is that cachy is no better or worse than steamos. Bazzite is no better or worse than steamos. Since I do most of my gaming on my deck these days, having two options for a desktop/laptop experience that have a similar level of performance, and have never seen a major problem with is a good thing.

    Now, ngl, cachy and bazzite aren't my daily drivers on anything. Like I said, I game on my deck mostly, and my laptop is set up for way more casual use with mint. But I've tried them both multiple times, and had zero trouble with them. Wellll, not entirely true. On an ancient (damn near twenty year old) pc I screw around with for funsies, bazzite noped the fuck out. But mint runs like shit on it, so does debian, ubuntu, popos, and everything else I've put on it. Haven't tried cachy on it yet. If it takes something that old to flummox a distro, I ain't mad.

  • source
  • [–] 5 points 3 weeks ago (9 children)

    They're very open about not being 1:1 on feature matching.
    sudo-rs breaks Ansible privilege escalation. They blamed the Ansible team.
    The Rust coreutils package upgrade removes coreutils from your system and then fails to install the new ones because there aren't any coreutils installed. They blamed the dpkg team.

  • source
  • parent
  • context
  • [–] 14 points 3 weeks ago (3 children)

    CachyOS is the most stable distro I've ever used. It's been like 20 months or so, and I've had exactly a single issue, which resolved itself in like 3 days (kde bug that got fixed quickly and wasn't a big deal either). I have zero problems with only having outdated software in the repo, which is something I can't say about any other distro I've tried. It's the ONLY one where that's the case (obviously would apply to base arch as well).

    I have no idea what kind of problems people keep having that leads them to calling it "unstable". I certainly haven't experienced this at all.

  • source
  • view more: ‹ prev next ›