Kinda surprising that this doesn't support Linux.
Podman can transparently start microVMs instead of local containers via libkrun as well, which does support Linux: https://josecastillolema.github.io/podman-wasm-libkrun/
714 karma · joined December 4, 2025
Podman can transparently start microVMs instead of local containers via libkrun as well, which does support Linux: https://josecastillolema.github.io/podman-wasm-libkrun/
Anonymous, third-party outlets for complaints like Blind can also likely be useful. Even at companies that never punish anyone for criticizing the company, participation rates in internal surveys are typically atrociously low, and people stop speaking up even informally if it's clear to them that nobody actually acts on employee feedback. Most companies probably perceive such channels of communication as threats, though.
Idk about audits. I worry that it's easy for them to become their own circus and overhead without materially improving things. But you may be right.
Linus' purpose in adopting the GPLv2 was something like "to avoid free-riders on his kernel code; if you make improvements upon the Linux kernel for some product, you have to share them with the users of your product".
The GPLv3 addressed a gap in the protections GPLv2 guarantees to end-users, namely that if a vendor locks down other parts of the stack (in the case of the Linux kernel and TiVo-ization, at least the bootloader), inspecting the and modifying the software can be useless for them in terms of the real freedom it grants those users— the device can just refuse to run the modified software.
For Linus, moving to GPLv3 would extend the domain of the GPL beyond the code of his project to the broader context in which it is used, namely the situation of the user. He sees this as inappropriate, in a way. He doesn't care about the broader context in which Linux is deployed or if some devices only allow you to run vendor-approved kernels. He sees the GPLv3 as changing what "GPL" means in a way that offends him.
For the FSF, the point has always been to use licensing as a mechanism to protect and promote the freedom of people using computers. The FSF's primary concern has never been the rights or conveniences of maintainers at all. It's not about "no freeriders with downstream forks who hide their patches", though that was an incidental effect of the GPLv2. The purpose is to use copyright licensing as a mechanism to inch towards a world where users who do computing— on their laptop, on their mobile phone, or on their TV's set-top box— can transparently inspect and modify all of the devices they compute on. For them, the GPLv2 had a vulnerability that made its function of protecting user freedom easily bypassable, and they patched it in the GPLv3.
But the question of whether linking against the kernel's public interfaces constitutes a derivative work is outside the scope of GPLv2 vs GPLv3 and not yet fully tested/settled by the courts.
Hopefully this context does make clearer, at least, the spirit of the license of the software Bambu inherited when they forked it from others. It's very much about letting users actually modify/replace the software running on their devices without restriction.
> Someone reverse engineered the plug-in and put it into orca slicer and then claimed that the plugin should have been GPLed to begin with which I find dubious. I don't really see it being much different than downloading closed drivers on Ubuntu but I'm also not a open source lawyer.
The GPLv3 specifically was written to address a problem called "TiVo-ization", which is when a hardware vendor uses some trick (DRM, proprietary blobs, whatever) to prevent users from actually running modified versions of the software.
The AGPL, the license of this particular software, extends the GPLv3 with protections for users of network services:
> Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program. In both licenses, sections four through six provide the terms that give users the right to receive the source code of a program.
https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t...
And on TiVo-ization: https://en.wikipedia.org/wiki/Tivoization
The Linux and proprietary drivers situation is more complicated, but proprietary drivers on Linux are generally restricted to interfaces that Linux chooses to expose to them for that purpose. But the Linux kernel seems to take a narrower view of what constitutes a derivative work than was likely intended by the FSF in writing the GPL. Under a "traditional" reading of the GPL, those proprietary drivers are meant to be illegal. Whether some or all of the linking done by proprietary drivers in the Linux kernel is really allowed by the GPL or not is somewhat untested, I think.
Someone I'm close to is going through this right now. They work at a place that officially highly values "inclusion", and their employer's website is dripping with virtue-signaling language related to it. But that someone is disabled, and in fact there's nobody at the organization who owns accessibility issues. Disability accommodations are haphazard, and often not timely. Why? Because no one owns them. They just get punted to an internal employee affinity group of disabled people who don't have a real chain of command, a real budget, or even a real prerogative to do accessibility work, let alone meaningful power— many of its members are routinely chastised by their bosses whenever they dedicate any time to solving access problems within the company. "That's not what we pay your for", "that's not your job", "I need you on this other thing", etc.
Meanwhile the organization receives public accolades from meaningless business press organization as a "great place to work" or even "great place to work for people with disabilities".
I think it's fine for companies to value diversity, and to value it publicly. A little virtue signaling is fine, as a treat; it may actually repel nasty people, encourage good behavior, or make employees feel more welcome sometimes. That stuff is good.
But there's also a real possibility that a company making diversity an explicit value results in lots of energy going into activities that let that company's executives pat themselves on the back about how good they are without actually doing much for inclusion. I wouldn't take any sizeable company's stated values too seriously, including that one.
> GitLab’s six core values are Collaboration, Results for Customers, Efficiency, Diversity, Inclusion & Belonging, Iteration, and Transparency, and together they spell the CREDIT we give each other by assuming good intent. We react to them with values emoji and they are made actionable below.
Since those terms don't speak for themselves individually, it's worth seeing what they're supposed to mean to get a sense of what GitLab is forsaking now. Each section is actually pretty lengthy, so you should go look and skim for yourself.
Here's the page: https://handbook.gitlab.com/handbook/values/
And here's an archive from yesterday, for when that changes: https://web.archive.org/web/20260510150031/https://handbook....
Friends don't let friends do Platonism.
For real, if you're a formalist you can ask these foundational questions without fear of this kind of dread; they become methodological rather than some kind of metaphysical mess.
I spent some time dealing with this today. The real issue for me, though, was that the refactors the agent did were bad. I only wanted it to stop making those changes so I could give it more explicit changes on what to fix and how.
It could also be because their manager is less technical. It's not unusual in my life for a PM to try to "rephrase" or restate things I've written in order to make them "easier to understand" in a way that in fact falsifies them or makes them more difficult to understand for the people who will actually have to work on/with it.
This particular example is a useful one for me to think about, because it's a version of hiding complexity in order to present a simple interface that I actually hate. (WYSIWYG editors is another one, for similar reasons: it always ends up being buggy and unpredictable.)
Me, too. The AI hype machine involves some really bad ideas, the amount of money being poured into "AI" right now distorts everything, public understanding of how these tools work is low, and a lot of contemporary uses both by corporations and governments are irresponsible, dangerous, and likely to produce or reproduce harmful biases and reduce the accountability of humans for crucial decisions and outcomes.
At the same time, it's useful for me at work, and I'm curious about it. I sometimes enjoy using it. It lets me do things I didn't have time for before. It eliminates some procrastination problems for me. I think its use in computing is also likely to be increasingly mandatory for the near-to-moderate term, so it's probably good for me to get used to using it and thinking about it and looking for new useful things it can do for me.
And my own experiences in using AI are part of what drive my anti-AI sentiment as well! I see it do completely insane and utterly stupid things pretty much every day, both in my personal life and in my professional life. I have a visceral awareness of its unreliability because I use it frequently.
I should hope that as hackers we can muster some understanding and respect both for LLM users and for people with hard "anti-AI" stances. Even if you're "pro-AI" to the core (whatever that means), it's worth understanding the most serious and well-considered arguments of critics of LLMs and the contemporary "AI" race. You might even find, as someone who uses and enjoys using LLMs, that you agree with many of them.
It's worth remembering that the way that ended was extremely bloody, particularly for the Luddites themselves. There were a handful of extreme participants, there was a murder, and there was a hell of a lot of violence directed at anyone perceived as a Luddite— even though most actual Luddites themselves mostly avoided violence against other humans.
It would be good if we can somehow avoid such outcomes this time.
So I need them to not only not devolve into gibberish, but remain smart enough to be useful at contexts several times longer than that.
> Simple as.
Neither Apple nor app developers control either what font sizes a user needs or how many apps they're running which produce menu bar icons. In that context, "not so long that it [...] pokes into the menu icons" isn't even well-defined. It's literally meaningless unless you parameterize it according to factors like those, which is not "simple as" anything.
It's a computer screen, not a page in some particular print magazine.
> it seems more like a "don't make your list of menu entries so long it spans the notch and pokes into the menu icons"
Only counting menu bar items that either (a) come with the operating system or (b) are imposed on me by applications that my employer forces me to run for compliance or other purposes, there are eleven mandatory icons in my menu bar at all times. So it doesn't matter whether the app in focus has few menu items or many; I run into this issue regardless.
> I prefer to blame Rider
There are a few ways to make sense of the situation, but none of them look great for Apple tbh.
If the menu bar is well designed but it doesn't work well with increased display scaling, accessibility is a second-class (or worse) concern in Apple's design.
If the menu bar is well designed but it doesn't work well when there are dozen menu bar icons, then it isn't suitable for environments where users don't control the number of menu bar icons they have to deal with— this, of course, is many professional environments.
So either: macOS isn't genuinely intended to be accessible, macOS isn't a general-purpose operating system for professionals, the menu bar has a bad design, or some combination of all three.
Of the three, "the menu bar's design is bad" seems the simplest and least absurd.
The other thing that kills me about Gemini is that the voice recognition is god-awful. All of the chat interfaces I use have transcriptions that include errors (which the bot usually treats unthinkingly as what I actually said, instead of acting as if we may be using a fallible voice transcription), but Gemini's is the worst by far. I often have to start conversations over because of such badly mangled transcriptions.
The accuracy problems are the biggest and most important frustrations, but I also find Gemini insufferably chummy and condescending. It often resorts to ELI5 metaphors when describing things to me where the whole metaphor is based on some tenuous link to some small factoid it thinks it remembers about my life.
The experiences it seems people get out of Gemini today seem like a waste of a frontier lab's resources tbf. If I wanted fast but lower quality I'd go to one of the many smaller providers that aren't frontier labs because lots of them are great at speed and/or efficiency. (If I wanted an AI companion, Google doesn't seem like the right choice either.)
Maybe the model is good but the product is so shitty that I can't perceive its virtues while using it. I would characterize it as pretty much unusable (including as the "Google Assistant" on my phone).
It's extremely frustrating every way that I've used it but it seems like Gemini and Gemma get nothing but praise here.
It indeed is. It's a way of coping with systems that are fundamentally illegible and unpredictable. If you have full rights over your machine and you're not running extremely shoddy software, you should never have to reboot your computer to make an issue go away. And rebooting your computer often guarantees that you'll never actually understand whatever issue is plaguing you.
Encouraging people to reboot their computers is promoting a fundamentally superstitious mode of engagement with machines that are generally reliable and predictable, instead of approaching them in terms of cause and effect. At best, it's the tired point-and-click sysadmin's workaround for not knowing what their system is doing.
Maybe for overwhelmed IT departments running half-baked operating systems loaded to the gills with invasive and meddlesome corporate spyware suites so inherently complex and complicated in their interactions with each other that the system itself is rendered more or less incomprehensible (even to the people administering it), just asking users to reboot is the right play to write in the tech support playbook. Maybe it's got the right ROI for a geek reluctantly roped into giving free tech support for a relative. But it's absolutely mumbo-jumbo and a sign that the "troubleshooter" is probably either ill-equipped to understand what's going on or just not interested.
I've never ended up with undesired software on my system except for under two circumstances: either (a) it's installed by the OS vendor, or (b) some proprietary indie software I used got bought by a shady company who now wants to spy on me and sell my data. Systems like Gatekeeper don't protect against either.
> Also, it’s just such a bad security precedent. This page describes the error you get as “the typical macOS Gatekeeper warning”, as though it were just another piece of corporate silliness, like clicking through a EULA.
It mostly is another piece of corporate silliness. For most people it rarely does something useful. But I agree; if you're courting normie users you should just pony up and get your code signed and notarized. Otherwise just tell people that if they don't already know what Gatekeeper is and understand the risks of bypassing it as well as how to do so, your software isn't for them.
I also felt that it was probably good for me for her to break my flow and demand my attention every now and then. It helped remind me to get up and stretch and be human better than I otherwise would have done.