isityettime
I can't personally support light modes in my own software because I can't use/test them, but I'd still add an untested one and fix bug reports about it.
I'm just curious about what people mean when they talk about astigmatism in this context, because the term is usually thrown around without qualifications (plain "astigmatism" as opposed to "irregular astigmatism" or "uncorrectable astigmatism"). So I'm curious about the astigmatism of people for whom dark mode on glowing devices is a problem. Is it typically extremely severe? Is it typically uncorrectable? Is it that people's glasses or contacts are often subtly wrong/outdated? Are many astigmatics not myopic or presbyopic enough to wear glasses all the time anyway? Astigmatism is a broad category and I'm curious about the specific impairments people who avoid dark mode have, in part because I have astigmatism and nonetheless prefer (require, really) dark mode because of other vision problems.
That's what the web has always been. People don't all have the same display types, the same subpixel layouts, the same display sizes, the same DPIs, the same fonts, the same zoom levels... People use reader modes, global restyling extensions, per-site custom style sheets, full screen magnifiers, bounded/partial magnifiers, screen readers, OS high-contrast modes... the web has never been a fixed canvas that you get to paint on and then hand to users.
There's also one available as a major mode for Emacs: https://melpa.org/#/restclient
If the command line is acceptable but you want more of a focus on usability than curl has, there's httpie (https://httpie.io/) and its clone xh (https://github.com/ducaale/xh).
When those signals become sufficiently polluted, employers will invariably turn to some other signal.
Lowering the standards is a move politicians often make because it "solves" the problem you outline in the short term, even though it's ultimately self-defeating because it directly undermines the virtue signaling function of academic credentials. It's a "solution" which requires no funding, no changes to teaching practices, and no changes to the ways schools are organized. So it's attractive and politically feasible even though it's harmful and profoundly stupid.
The solutions you've proposed are the right kind of solution because they preserve the signaling function of credentials. But so far they're approaches that public schools and the governments that run them seem politically incapable of taking.
There's also something else to confront here in that even when the competency signaling functions are intact, academic and professional credentials are also to some extent scarcity goods, valuable precisely because not everyone has them. So if you solve all of these problems and you still allow grades to at least attempt to fulfill their purpose, a functional and coherent grades system will, to some extent, always perform differentiation of the labor market or be obviated by its failure to differentiate. The inequality that you see manifest as students who fail to graduate falling behind in life is actually downstream of the schools, and it has to do with how many seats are available for what kinds of jobs in the economy. If you address the former without addressing the latter, the real social justice impact is going to be limited.
And you ultimately can't educate your way out of having a working class; at some point you have to look elsewhere for assuring the dignity, security, and comfort of people who academically underperform relative to others. The working class as a whole must be made livable, instead of pretending we can shove everyone into its most comfortable sections (the "middle class") through education.
The way math is taught in the US is essentially free-floating, foundation less, and understanding-free: https://profkeithdevlin.org/wp-content/uploads/2023/09/lockh...
For my visual impairments, macOS is currently fine, because I only really need magnification and I can get away without using much of it since everything I really deal with is free flowing text, like in a terminal or IDE. But as I need to rely more on screen readers, I anticipate I may have to consider switching. Switching to something other than Linux would break my heart, though.
Try cloning on WSL, in the VM's filesystem, and let us all know how that goes.
Then the things you need to learn in order to read and understand most Nix code is just the stdlib, which is most convenient to browse here: https://noogle.dev/
Beyond that, it's all just conventions that are covered well by reference material. So those two are all you need in order to find your footing when it comes to the Nix language.
(For a tutorial overview of the whole ecosystem, nix.dev is the best entrypoint. For the build system or an introduction to some of the basic "internals", you want The Nix Pills. And in general, the best thing of all to read when it comes to Nix is Nixpkgs itself. :)
It's almost tempting to reach for "elsewhen" or "elsewhy", since we have "elsewhere". But if saying "elsewise" feels like chatting with a very elderly relative, saying those ones feels more like a seance with distant ancestors. But apparently it used to be a thing!
https://en.wiktionary.org/wiki/elsewho#English
https://en.wiktionary.org/wiki/elsewhither#English
https://en.wiktionary.org/wiki/elsewhence#English
https://en.wiktionary.org/wiki/elsehow#English
https://en.wiktionary.org/wiki/elsewards#English
Who? Companies whose audiences are certain kinds of corporations?
But I would think that as hackers, when we praise a programming language, we often have in mind virtues that are freely transportable to other programming languages; intrinsic achievements that can be learned from and applied broadly.
I want my programming languages to be lovely, concise, clear, expressive, powerful, fun, insightful, mind-bending, illustrative, flexible, convenient, well-integrated, well-founded, efficient, safe, or helpful. I don't want them to have moats. I don't want to have to say "I'm using this because I (or my industry) started using it years ago and it's sticky"; I want to be so lucky as to get to say "I'm using this because it's good"!
Maybe a minor semantic dispute in the eyes of some, maybe a kind of excessive literalism on my part, maybe a futile resistance to to concept creep, old man yelling at cloud.
But ykwim?
LiteLLM isn't a sandboxing tool so it just can't perform as much risk reduction even when everything is working as intended.
And what nono adds over sandbox-exec is a uniform interface across platforms and some policy management tools. You can impose the same restrictions via the OS built-in mechanisms yourself via Seatbelt or a built-in interface like sandbox-exec. You can also combine an OS-level sandboxing tool like nono, zerobox, Anthropic's srt, Seatbelt, landrun, Bubblewrap, Fence, etc., with a VM-based one like Docker's sbx, smolvm, krunvm, microsandbox, or Shuru. So now you need two simultaneous supply chain attacks in unrelated projects to line up just right at the same time.
"Eventually you have to trust some part of your security stack" is neither particularly interesting nor evidence that there's no way to defend against supply chain attacks. Even if you only have one sandboxing tool and it's OS-level rather than VM-based, that becomes a single part of your stack that you can give special attention to in evaluating updates in a way that LiteLLM can't be.
There's also just the empirical fact that at this point, trusting LiteLLM's maintainers to lock down their release pipelines looks foolhardy. This is the second supply chain attack they've had in 7 months. It's absolutely wiser to choose a sandboxing tool you like, audit it to examine its release pipelines, code signing requirements, attestation strategy, and whatever else, then put LiteLLM inside that tool's sandbox than to just thow your hands up and say "I gotta trust something, so it might as well be LiteLLM!". Maybe nono ain't it either, idk. I'm still experimenting to figure out how I want my setup to work.
But I think neither the defeatism nor the relativism in this thread are very compelling.
No, you can block this with sandboxing tools. For my LLM agents, I use a tool called Nono, whose macOS implementation is built on the same foundation as sandbox-exec. One of the key features it supports (and it's not the only tool that does this) is proxying and the injection of credentials via the proxy. For example, when I run Codex at work, Codex does not have access to my Azure AI Foundry API credentials. It sends out requests via dummy credentials, and the proxy injects the real ones outside the sandbox.
The other thing that proxy does is let you restrict network access in various ways. So you can run something like LiteLLM so that it doesn't have access to the internet at large; it can only talk to Azure AI Foundry or AWS Bedrock or whoever your inference provider is. You sandbox LiteLLM separately from your agents, and you give it access to much less. The software firewall stuff isn't perfect but it is a significant defense against things like this.
There are also lots of other restrictions that are easy to do which mitigate this. Nono blocks access to the root of $HOME, then selectively allows access to paths within it, and also explicitly blocks access to common paths to secrets. So it's pretty easy to make sure that access to important things are blocked: SSH credentials, GnuPG socket (and local Unix sockets in general), local OS keyrings, etc.
The way I use tools like this is exclusively by writing policy, testing it, and revising where the policy is inadequate. I never get approval fatigue because I don't do approvals.
You're right that attacks like this are hard to defend against, and that we're used to tool sprawl, and also that LLMs can do things like install tools we don't expect them to themselves! But there are ways to anticipate and mitigate attacks like this. Sandboxing tools (including contained and VMs) that support credential injection are genuinely useful for this.
I also enlisted delivery drivers as confederates in working on his fear of large motor vehicles! I'd explain that he was scared of trucks and ask if they were willing to feed him some treats from the vehicle. If they agreed, then I'd hand them some treats, go inside to get the dog, and then my dog and I would "discover" that the truck had a nice person inside who wanted to give my dog good things.
My dog loves cats, and it's not an accident. Even though I've never had a cat, I made sure to introduce my dog to cats when he was a puppy. I even made sure to introduce him to cats who were unaccustomed to living with dogs, and unfriendly or indifferent cats who didn't feel particularly inclined to tolerate him in their personal space, because I wanted him to learn to recognize and respect the signs of a cat's discomfort. (Some of that was ultimately undermined by time he spent in the company of my dog sitter's excessively tolerant cats, lol. He has arrived at the mistaken belief that monotonously barking at a cat is a good way to entice it to chase him, which can make him insufferable around cats who aren't interested in him.)
My dog is very small. He's never bitten anyone. But when someone at the park tells me they're afraid of dogs, I still make sure we keep our distance.
I'm sorry for the bad interactions you've had with dogs and the careless owners you've met who have subjected you to frightening or even dangerous encounters with their dogs. That's legit terrible.
But anyway I made an effort, sometimes more successful and sometimes less successful, to try to make my dog well-behaved towards every group you mention. Where I've failed to do so I manage him to keep him away from those critters and people who would rather avoid him. And I think even when people don't do all that, it's more lazy selfishness than it is hate.
As for the "open source license" issue, you need the four fundamental software freedoms with whatever is distributed, just like with conventional open-source software. The OSAID enumerates a formulation of each of all four, but this is the one that this release fails to meet:
> An Open Source AI is an AI system made available under terms and in a way that grant the freedoms to¹ [...] [u]se the system for any purpose and without having to ask for permission.
> 1: These freedoms are derived from the Free Software Definition (https://www.gnu.org/philosophy/free-sw.en.html)
(The footnote is theirs, not mine.)
So the OSI agree with me that these weights cannot be considered, in their terms, "open-source weights". Our disagreement is that I think the training data itself should be considered a necessary part of a bona fide open-source ML model.
I think the answer to ethical concerns about releasing training data that involves data that carries privacy restrictions, like medical data, is that such models cannot be free/open-source. I think that's okay; it's okay to acknowledge that not every machine learning model in the world can be open-source. Eve the FSF, who are generally hardliners about using, let alone producing, non-free software, admit the ethical use of non-free models under just such circumstances. They just so so without blurring the distinction between free and non-free, which is the tack I wish the OSI had taken.
> I don't think we have a proper term for what you are reaching for, and proper open-source models (training, training-data, etc. being fully open) are scarce.
I think you're very much right that we don't have a "brand" with either the same kind of institutional backing as terms like "open-source" and "free software" or a wealth of examples to point to.
I would, contra the OSI, not consider the model to be open-source even if the weights were under an open-source license. But that is the minimum condition under which it could be considered open-weight.
I'm sick to death of these shameless dilutions (including the notion that open-weight is open-source; the OSI is totally captured at this point)
The nearest analogue would be "weights available", I guess.
In that case copying something that is merely mediocre in most respects but has one outstanding quality, and generally exceeding it, makes sense.
I'm not sure any of that applies here except maybe that Anthropic might be more poised to make anything they publish suddenly very famous.