[–] 4 points 2 weeks ago

Not really some features are but other are really good to have them backed in for someone that just want to game.

Also SteamOS, ChimeraOS and other HTPC flavoured distro are usefull if you have a PC in the living room and don't bother Steam account.

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

    No the goal of Docker is not to make sure the results of compiling are identitcal. It is to make it work on your machine, there is some nuance to it.

    This is more the goal of something like nixpkgs (NixOS).

    This is not really in the same realm of the dramatically different output a LLM will give though.

    Yes this is not same realm but my point was that eve if LLM would give you different results each time the result is transparent and editable. Also developers tools evolve and Linus have more technical knowledge to use this tool in a way that will gave him satisfying result than me or a junior dev with 1.5 years of experience. He was against LLM generated code a few years ago, not because he hated on AI but because this tool was giving him unsatisfiying results. If compilers were not working 50% of the time he would probably write everything in assembly. LLM models and their coding harness cannot be compared to what they were 2 years ago. And most of the devs are using them. Will that transform bad devs into good ones? Probably not. Does that mean that LLM generated or assisted code is the way to go? Not necessarly. But it means that it's a tool that find its use in the majority of development teams and thus that they find it quite useful.

    There is some issues with it and I'm not here to deny them. Whether they are social, environmental, capitalist, monopolist, learning. Like every new disruptive tool we use them in ways we won't in the future and I think it's similar with AI.

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

    Yes you can get a different result. Compilers are designed to be deterministic, but a build is more than the compiler. Usually the bytes differ but the behavior is identical.

    Docker is far from being reproducible!

    It works on my machine ≠ reproducible. But reproducible will make it works on your machine.

    Using a compiler does not guarantee you to get byte-perfect output each time, especially not on different machines.

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

    Human slop code existed way before we had auto-complete in our IDEs, way before Copilot start writing small functions and thus bad code is not because of LLM. AI slop is no different than Human slop, it uses a shit ton of ressource to generate it and is faster at getting a working output but bad codebase is not new.

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

    You cannot, that's why reproducible builds are hard. Modern compiler are made with compilers (egg/chicken problem) not assembly nor machine code and you always loose some perfect prediction.

    Yes LLMs are less predictible than compiler but their output is readable to human, while machine code is very hard (yet not impossible).

    Is that a bad things that 99% of devs have forgot how to write code cutting holes in paper? Tools are changing and while a direct comparison between the move from paper to COBOL or assembly to C is not the same as python to LLM generated it's hard to deny that LLM will change how human write code.

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

    There is a difference with vibe coder that have no code background and software engineer that use LLM to generate code.

    This situation is very similar to auto-completion IDE back in the days or more recently the first public version of Copilot.

    AI don't vomit blackbox. It infere completely auditable transparent code (often with overdetailled comments). Maintainers do review the code that they will have to maintain before merging it in the main codebase. In FOSS they often don't care who you are, they are looking at the quality of your code, not your LinkedIn profile.

  • source
  • parent
  • context
  •  

    So I was digging around AlternativeTo.net and Meshtastic-related Android apps called Bitmesh came across. And buried in the doc in the GitLab repo is a protocol spec the author seems to have wroten called MAM: Micro Apps over Meshtastic. It's not really talked about anywhere I could find, which seems like a shame as I think it deserves way more attention than it's getting.

    The core idea is simple but kind of elegant: right now if you want to build a third-party app on top of Meshtastic, you're basically stuck fighting over the radio with everyone else, with no clean way to share the channel between multiple independent apps. MAM is a small framing layer that sits on top of Meshtastic's PRIVATE_APP portnum and lets completely different apps coexist on the same channel without stepping on each other.

    Concretely, here's what it does:

    • A 4-byte header + MessagePack payload per packet
    • App multiplexing via a 16-bit message ID (so multiple apps share one channel cleanly)
    • Reassembly for messages that span multiple packets (up to 16 chunks × 236 bytes = ~3.7 KB)
    • A defined handshake with the local node over BLE (ToRadio / FromRadio)
    • Honest, explicit security posture: the PSK is public, it's a namespace token, not actual security, that's each app's problem to solve

    What struck me reading it is how general-purpose it feels. The spec is very deliberate about what it does and doesn't cover things like reliability, encryption, and app-level schemas are explicitly left to each app to figure out. It's just the transport plumbing, nothing more. There's even a registered vs experimental app ID split built in, which reads like the author was thinking about other people building on top of it, not just their own use case.

    I'll be honest, some of the finer technical details go a bit over my head. But the overall design feels solid and the spec is short enough to read in one sitting. I'd be curious what people who've actually built things on Meshtastic think. Does this solve a real problem? Is there something else already doing this that I missed? Does the spec have obvious holes? Is anyone aware of other apps implementing it?

     

    I'm currently using an AMD Radeon RX 7800 XT 16GB and I don't planned to change it any time soon. However I have a couple of friends that are entering PC gaming or upgrading their existing rigs and asks a couple of things to me their nerdy friendly PC gamer friends.

    Of course they are pretty much all tired of the current Windows bloat, spy and flakyness so we're looking if their gaming habits and libraries would be a good match for Linux and Proton.

    Considering that AMD are the best supported GPU for Linux Gaming and that NVidia is moving away from accessible pricing I was wondering if including Intel Arc would be a good or a bad idea for my proposals. I know it won't offer the PC MASTER RACE experience but honestly who cares. My friend just wants a cheap but reliable gaming PC to play casually at 1440p or maybe even staying at 1080p. If intel won't suit I will probably recommend second hand AMD Radeon to fit their budget.

    Anyone here have tried some Intel Arc gaming on Linux? What was your experience? Any issues I should be aware? Recommendation? What distro have the best out-of-the-box experience?

    Thanks

    Edit: LinusTechTips recently released a video on the different GPU brands for linux gaming including Intel Arc B580 12GB

     

    I don't use Google account on most of my devices. I have an older phone on LineageOS 22.1 that I use mainly to test apps. It has GApps installed but I never sign in. I have faced a couple apps that on startup are launching the PlayStore app and ask me to sign in, I guess for "security". Is there a way to bypass that ? I don't want to link my Google profile and would love to use this app offline like I should.

    Is this something that could be done with LuckyPatcher ? Is there easier methods ?

    view more: next ›