• 673 Posts
  • 1.95K Comments
Joined 1 年前
cake
Cake day: 2025年4月4日

help-circle




  • Und wenn man durch harte Arbeit ohnehin nichts erreichen kann, warum soll man sich also anstrengen? Meine Mitbewohnerin ist mit ihrer Abfindung auf Reisen gegangen. Irgendein anderer Job wird sich schon finden, wenn sie zurück ist, sagt sie. Die meisten meiner Freund:innen in Shanghai machen derzeit eine Auszeit und leben vom Ersparten, das sich über die Jahre angesammelt hat. Dafür in eine WG ziehen und mehr aufs Geld schauen zu müssen, macht ihnen nicht viel aus. Diesen Ausstieg aus der Leistungsgesellschaft nennt man tǎng píng, Flachliegen.

    Ah, so meinte Merz dass, als er sagte, wir sollten uns im internationalen Wettbewerb mehr an China orientieren, wegen der Wirtschaft und so.





  • What part of Rust is fun?

    C is fun to me because the syntax is easy to understand and straight to the point.

    You probably had never the pleasure to search for bugs caused by C Undefined Behaviour in multithreaded code.

    When I was writing my diploma thesis, I was writing multi-threaded code for an embedded DSP system. Results were wrong all the time. I tracked it down to atan2() giving wrong results. I searched for about six weeks how to fix that and it disappeared when I changed the position of the program’s data segment.

    (If the concept of Undefined Behaviour is new to you, I can recommend the web pages of Jens Regehr).

    The above debugging experience was 25 years ago. We have better languages now. Rust has no Undefined Behaviour. That means you can track any bug (except compiler bugs) deterministically down to where the actual logic of the code, and the model of it which was in your head depart. This is great.

    Rust is fun because you can compile a complex program and it runs.

    But industry is still working with a fifty year old language written for systems where 32 kilobytes were a lot of memory. At work, I am still searching for bugs in multi-threaded C code with manual memory management (the previous developer didn’t think this needs locks), and I have to explain to the CTO that no, wo won’t have a release this fall, while the company literally drowns in technical debt.











  • e> Linux users: switch from Windows to Linux to avoid ai slop

    Linus, an out of touch idiot: Actually vibe coded slop in the OS is good!

    I don’t like LLMs for a number of reasons - the theft, the environmental impact, the deceptive marketing - and also because I am really pissed about the abysmal quality which my AI-pilled coworker produces.

    But in difference to Windows and most commercial software, the Linux kernel project has high quality standards, and I have some faith they’ll keep them.

    Also, the cited mail discussion is not about AI generating unreviewed code - which I still see as very questionable - but about checking code for bugs and deficiencies. Given the amount of CVEs found by LLMs, I see no way around that for important infrastrcture projects like the kernel.

    Many people are not amused by the hype - me neither. But AI could unexpectedly help open source in a few ways:

    • it will become clearer that quality matters. We alrrady see that with Windows - Linux is getting many new users.
    • We might see a trend to source code rewriting and re-use instead of using libraries. Libraries are pervasively used now, and that has drawbacks like bloat and dependency hell.
    • Copyright is rapidly losing importance. This is really bad for artists and book authors. But for most (not all) programmers not, since copyright in software was mostly a tool to protect profits of corporations. Software development at its core is a service.
    • Issues of autonomy and control are becoming more important than ever. The kernel is a pragmatic project, but it being free to use and modify is absolutely central - that’s why it uses the GPL - and we are also seeing every day that Stallman was and is right more than anybody would desire.

  • Brilliant and nuanced description.

    It also makes me pause when thinking about AI. AI-generated code, as it is commercially used, undoubtly increases technical debt. Companies want to use it because they see it as an advantage. But it can also lead quickly to technical debt bankruptcy. Which will likely be the outcome given the bone-headed way how many companies actually use AI.

    But what drives them?

    A lot of AI adoption seems to be driven by two things: Fear and greed. Fear, of becoming obsolete among the competition. Greed to not miss out on a perceived bonanza. This is not necessarily rational. It might be the cause why all these purported gains in speed are rarely actually measured.

    But as Apenwarr (Avery Pennarun) points out, companies often behave more rational than it seems. Specifically, as he writes, they accept an unsustainable level of technical debt when it seems that they cannot compete any more. That makes actually sense: Why polishing a shiny, immacculate, well-designed code base, when you never have the chance to re-earn the money that you did spent for that? (People do the same: An aging person living in a run-down house with broken roof and heating might not want to invest in repairs or installing a heat pump, because that person will not see the gains from this investment - possibly their children, but will they keep the house?).

    But how does all this match up with technical debt and AI? Are tech companies simply giving up business? Are they completely unaware on the level of technical debt it creates? Why does this happen?



  • Kroah‑Hartman consistently framed language choices in terms of reviewer workload rather than developer convenience. Linux has “over 5,000 developers” but “about 150 core maintainers that review the majority of the code,” a skew that drives his priorities. “We optimize for reviewers. We don’t optimize for developers because we have a lot of developers,” he said, suggesting Rust’s ability to enforce locking and lifetime rules at build time means reviewers can spend their limited bandwidth on logic rather than bookkeeping: “If it builds as a reviewer, I know it’s OK. I can look at the logic.”

    That’s a great point. Living open source code must be readable and maintainable. Rust is an excellent match for that.


  • Kroah‑Hartman consistently framed language choices in terms of reviewer workload rather than developer convenience. Linux has “over 5,000 developers” but “about 150 core maintainers that review the majority of the code,” a skew that drives his priorities. “We optimize for reviewers. We don’t optimize for developers because we have a lot of developers,” he said, suggesting Rust’s ability to enforce locking and lifetime rules at build time means reviewers can spend their limited bandwidth on logic rather than bookkeeping: “If it builds as a reviewer, I know it’s OK. I can look at the logic.”

    That’s a great point. Living open source code must be readable and maintainable. Rust is an excellent match for that.