Can't wait until we get really well designed harnesses written in a compiled language that doesn't bloat my computer. Will probably have to be written by a company other than OpenAI because codex is like the exact opposite of everything I just listed
Yeah, using it a bunch with local LLMs. It's fast (small system prompt), focused on the basics, made around simple choices, and possibility to call it in scripts.
So far I have very positive experiences, the results are generally better (and not just faster) than in other harnesses with the same models. I've done the same (user) prompts for tasks in a range of them, and compare the outcome to eval between them. Simple (harness) beats complicated one many times. I do wish it could use MCP though, but not as often as I think, and CLI tool usage often compensates on this front with little extra effort)
That is now my usuall go-to harness for things usually. Still figuring out the edges though (when we get off the happy path, like models reaching their max context, or such...)
It's very light, recommed you try it out, and see if it fits your toolbox.
Just tried. And wow!! I opened my mac's activity monitor to see how much load it was putting on my system, and i had to scroll all the way down ... unlike those current harnesses that sit right on top (sorted by used cpu, descending).
And it worked. I'm switching to this unless i find a reason not to.
it's minimal and somewhat opinionated, not integrated well with memory subsystems (although that's kind of the point)
my only real criticism is that last I played with it it deals with slow provider responses very poorly , so lots of locally hosted llms require a lot of tuning to get it to handle streaming/non-streaming/timers well.
way less minimal (but still pretty minimal) I prefer Pi; but different markets I think.
hax fit my openbsd laptop well, espescially since Pi and related derivatives are kind of un-spokenly incompatible with the BSDs.
(author passing by) Could you please report the issues you've experienced on the repo? I did quite a bit of testing myself on local models (Qwen, Ornith, Gemma, Muse Glimmer) with llama.cpp, and they all worked fine. Details would be helpful.
Also one brief note for Codex users specifically. hax can work out-of-the-box as codex-cli drop-in replacement (since it can use the already authenticated codex token), so it's super easy to try it - basically it will be a zero-config experience.
Firstly thanks for writing it and making it available. The problem I had when I tried it is it would consistently blow out the small context window of my local qwen and although there was seemingly a config knob I could use to prevent that, seemingly that didn’t do anything.
That landing page is hard to look at, let alone read. Have LLMs really not yet learned to write webpages that read the sytem theme and look that way? Must be hard.
It's because they statically linked it, and probably rely on a trillion pointless crates (as is standard in Rust development). A good statically linked harness can easily be ~5MB MAX
does it achieve token efficiency? vs something like maki? It's not at all clear what the method of that "efficiency" is.
my main issues with maki are that the line editor (what you use to enter your prompts) is very barebones, copy-paste is broken (no middle-click paste, or copy to PRIMARY; implicit copying to CLIPBOARD that can only be used with a mouse), and scrollback is not native. So it's not a real cli, but some sort of weblike tui.
I tried 3code; it does not mess with selection, but code printed in the conversation has | markers in every line, and is thus uncopyable in practice. Don't know how to use that.
I've only dabbled with 3code. The author of 3code is pretty active, so he may take suggestions. I'd agree that copy/paste is important for a good agent workflow.
I don't use Claude, but it appears it is permitted to use Claude as a stdin/stdout -communicated tool using JSON, or use Claude SDK, with the monthly plans. Monthly Max/Team plans also include credits that could be used directly via the API: https://support.claude.com/en/articles/17154008-monthly-api-... .
E.g. OpenCode can be used with all three methods. Looks like it needs a plugin for the two Claude methods, though.
You can’t just use your Claude sub on a third party harness without getting blocked even if you use the Agent SDK. Apparently, Anthropic gives “credits” depending on your sub and you can use those _credits_ when you use third party harnesses or Claude -p mode. That usage is not the same Claude sub one would assume it is… It is all quite deceiving. Don’t get a Claude sub unless you’re okay with being locked into Claude Code…
I suspect a lot of people wouldn't use AI if they had to pay per token at current rates. Yes, it's technically a different discussion, but "just write your own harness" isn't really an answer for the vast majority of us riding on the investor-subsidized subscription plans.
I did, and the weird things you have to do to make work at least decent. I’ve been doing evals and I got some things better than opencode but not as good as pi. Though my goal is to optimize for a browser and browser based llm so it can create stuff in a web container or at least generate ui by requesting json schema (a2ui style).
These apps are awesome, but they make me a little nervous. I can just imagine when a "clean room Rust" Oracle DB (re)implementation hits GitHub that Oracle would not just sit there and take it but would instead rain lawyers down from the sky... Ditto for other companies that have hornet's nest legal departments.
I too have a 4a that is still ticking thanks to Lineage!
The only problem I've discovered is that group texts sometimes don't work (I can't see others' replies or worst case I don't receive the group text at all). Not sure if anyone else has run into this, seems like it could be related to RCS and unlocked bootloader not playing nice.
I have stock Android on a Pixel 10 and RCS group texts don't work here either. Some people just can't be added to the group and some people just don't receive the texts.
I flashed my 10 with Graphene as soon as it was supported and RCS was a bit of a challange as well. Both because of the recipient's device/settings as well as my own privacy settings.
As a diabetic, I would love "mirror wheat" which behaves like normal wheat (ie can make breads, etc) but has zero carbs/calories because the body can't digest it. Mirror glucose would be nice too, though allulose is already a pretty close stand in for mirror glucose.
Start increasingly punishing OpenAI. We are acting like "oh well, AI is just too powerful to be contained" but I think its more like "OpenAI is run by cowboys who are good at making LLMs but bad at everything else"
Part of the problem is that the US has no unified empowered cybersecurity regulator that I'm aware of.
As a result you get a mishmash of DHS + DOJ + SEC + HHS agencies.
If there was one single throat to choke that had remit for cybersecurity + ability to being cases and assess fines, they'd be handing them out left and right.
From their current balance sheets, well below costs.
Trying to separate out "per token" costs and possible profitibility from public information feels like a exercise in futility, it's too easy to play games with costs by trying to separate things still fundamentally required to actually have anything to /sell/ in the first place, like R&D and training. Even the current "Open Models" are somewhat loss-leaders, often reliant on significant funding and benefits from governments etc.
I think the only time we can /really/ judge the "true" break-even point is if the whole company breaks even.
I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to do complex octopus merges or anything like that. It's usually: feature branch, implement, merge, and occasionally fix a merge conflict. JJ seems like it's more for people that like to have tons of active branches that they are constantly switching between whereas I usually only work on 1 thing at a time. I've never thought to myself "git is so frustrating I wish there were something better" because I only use the same 5 commands over and over every day and they never get in my way. Not to mention jj has its own share of esoteric syntax with all the "@--+::" business and I'd have to re-wire my brain to remember those symbols instead of `ref~N`, etc.
I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently.
JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-ids. The min identifiers in change-ids being highlighted. Being able to make commits and worry about the message later. Snapshots of changes while you are working serving as a tool agnostic undo.
Painless and sensible cli args that are vastly more consistent than git.
Superior conflict handling.
You can “jj undo” anything and it works perfectly.
It’s fabulous.
> "@--+::"
I have no idea what that means and I’ve never had to type anything remotely like it.
The rev specification language is pretty elaborate but you don’t need to know it.
Same experience. At first I really didn’t get it and now I could never go back. The ease of rebasing, renaming, reordering, splitting, etc. Has drastically changed the way I work. My PRs are undoubtably much better now, and I am never afraid of messing up thanks to jj undo and the op log in general
Do you have a public example of an open source project that you are using that showcases those features?
In your opinion, is jj losing steam? How do you feel about it requiring a CLA to contribute to, which would enable the developers to go closed-source and keep all the contributions of the community? Are you afraid of vendor lock-in?
> a public example of an open source project that you are using that showcases those features?
IMO that's almost fundamentally impossible. The whole point is that it makes maintaining a "clean" linear commit history easier than git, so by the time you push anything the observable differences are already gone. At best you just see a repo without any WIP-style commits, which can be done using more effort and git alone.
CLI is preferred from my point of view if only because it's the supported standard interface. VSCode's version control interface is reasonably close to a standard, and I love the tree view there. But generally I don't want to use random third party things because they either aren't consistent (i.e. now I have to learn what joe schmoe thinks a version control interface should be), or don't stick around long enough.
But I don't tell my team what they have to use as long as it's compatible. The last thing I want to do is try to teach them a different VCS when they've spent time learning how to get by with git.
I've told them about JJ, what I like, what pain points it solves for me. They are all adults, they can make their own decisions about it.
JJ is for me. It helps me unwind some rather elaborate problems we've had with rebasing, or dealing with conflicts from bringing some old support branch up to date, or back porting some particular thing. It helps me create pretty clean MRs, break things up into smaller reviewable chunks, etc. You can do all this with git, but it's easier in JJ. In particular if you have to do shuffling and rebasing and conflict arise. JJ lets you solve conflicts asynchronously to rebasing. Git stops you in your tracks. There's some rerere thing that is supposed to help but give me a break. Git's a train wreck of dumpster fires. But it's still been basically better than everything else since svn.
Until JJ IMHO. Valid arguments can be made for other things like maybe mercurial or even fossil. But JJ is the most pain-free vcs evolution I've seen.
Mercurial's big failing was making too many critical things optional. It's the same screw-up riscv is going through now in the chip architecture space.
A few advantages for me, even for the same 5 commands I use over and over:
- undo
- shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase
- make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare)
I see git is working on adding some of this under the history command. The revset language is really not esoteric: @ is head, @—- is two behind head. That’s about it.
Part of it is that the sorts of shuffling I used to avoid because they were a pain in git (so I didn’t feel I needed them improved) are so easy in jj that I do them all the time.
> - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase
Can you explain this to me? I feel like Git is pretty easy there.
- select oldest commit to modify
- move the commits around with a mouse or the cursor
- close the editor to apply
Sure, the first step can go away (which is what they do with git history), but the rest seems pretty optimal to me.
Alternatively I can add changes to older commits by recording them on top (--fixup) and tell git to auto apply them (--autosquash). I can also tell git to do the first thing automatically (git absorb, I believe it's inspired by jj).
It does take a few days to stop missing interactive rebase.
But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
> say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
This is the best pitch for jj I have seen yet. This should practically be the first text on their website.
jj just makes lots of git operations go from "technically possible if you're creative enough" to "<= 3 solutions, one of them probably being obvious". jj lowers the skill ceiling of git, and raises the floor.
How many of those do you need? How do find the correct arguments and git checkouts to do before? Are you sure you remembered to do everything? What if there are merge commits?
Why would I do a checkout before? I don't want to modify the worktree? Maybe I in fact also want to alter the worktree, but that's unrelated.
> Are you sure you remembered to do everything?
Am I sure I have all my files ordered? No. Does it matter? Also no. Are you sure you have no bug in your commits in JJ?
If I want git to alter some set of commit chains, I can tell it to. Actually I never needed to do that, because I don't work on several thousand branches at the same time. I prefer it to not alter unrelated branches automatically, just because some earlier commit changed that is in both. Such things actually undermines the trust I have in a tool, because it does things I haven't told it to do, even if I'm aware it does these things.
> What if there are merge commits?
Then I resolve them. Merge conflicts occur, because there is some actual conflicting change and often it is also semantic. These don't go a way by changing the VCS. On a theoretic basis, these require outside information(=decisions) that is not there yet. There are more often semantic conflicts, that are not syntactic, then there are the other way around. If you are referring to doing the same merge conflicts again, I can tell Git to resolve them automatically too, but it actually occurred too often, that this is not actually what I want, so I actually dislike that feature now.
Separate git rebase commands. JJ manipulates the whole DAG in singular operations, where as with git you're working one ref at a time. And carefully managing where one ref intersects with another, to rebase those commits only once, reusing the rewritten commits from the previous git rebase. With jj you just say "that thing, over there" and all descendant commits and bookmarks are updated, no matter what the shape is.
I do, but I don't really get it, because you did learn the jj command. I mean you could have learned jj first, I would understand that, but I presume that is not the case.
that’s the first example I’ve seen these last year so that makes sense to me about jj having better commit management.
I rebase a lot using Fork (git gui) and it’s really easy to drag and drop reorder commits, rename, apply as fixups or squash in. I can see how jj makes sense if you’re in the command line, though. And splitting changes from commits in git is really annoying, but it only comes up once in a blue moon for me.
The ability to rebase, reorder, and squash like this only really makes sense with jj’s autorebasing IMO.
With git, if you do this, everything after is left orphaned. Even if you have a GUI that does this for you, now rebase conflicts become an enormous pain.
Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, yeah.
But if the cherry pick doesn’t cleanly apply at the current HEAD, then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick it if that works (I think it should? though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem) or else maybe detach your head and start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase, and at that point I’m usually going
back to git reflog to try to find the last point where history made sense. Or I guess you could just remember that you can introduce arbitrary existing commit refs into an interactive rebase like 1718627440 did. But I said I didn’t want to think about this anymore.
> Along with the appropriate git stash and git stash pops
If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all.
> But if the cherry pick doesn’t cleanly apply at the current HEAD
If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you use.
> then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick
You say that like these would be separate operations, but for me these are very much not, I guess like the fact that you need to supply both '-r oldercommit' and '--before @-' are for you. I think this is the point where I actually don't understand your view. Like, we both need to supply two parameters, we need to because this is the operation we want to do. You write two parameters free form, I write one free and select the other from a list. There is a difference, I actually think selecting from a list can be more convenient in some cases, less in others. But I don't get why you write like it would be crazy work.
> though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem
It does only let you handle full commits, if that's what you mean, if you want to split a commit you need to provide information how. But that it doesn't sound like you mean that.
> so you lose your commit message
You can apply commit metadata independently of the tree you want to commit, so that definitely occurs never.
> maybe detach your head
I bet you don't have issues with detaching the head in JJ, so why do you in Git, it's just a normal state.
> start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase
Yes, but that is not because you use Git, but because you wrote the change against some other commit first, which you don't do in your JJ example. You could do that in Git as well and then you only have one set of merges to resolve.
> I’m usually going back to git reflog to try to find the last point where history made sense
Which is git rebase --abort or git reset @{1}. The latter is always the same, this is as silly as saying I can't remember whether it's jj undo or jj revert.
> But I said I didn’t want to think about this anymore.
If I may ask, how much time have you spent trying to learn use jj? I ask because I've seen a strong tendency for people to who have never used it to argue against it. I see much less arguments against it from people who understand both Git and jj well. But that's just my impression; I may of course be wrong.
Because it interferes with my workflow. If there are non-committed changes when I want to do something else, they do represent actions I want to do. I don't just have random uncommitted changes there. Setting --autosquash as default results in my finding out I forgot something later.
I believe this to be the same with the index, that is praised as unnecessary and "overcomed" in JJ.
I love the index, and often have "uncommitted" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.
What I mean is, you manage the index with the same commands that you manage commits with. The emphasis is on "with separate tools" not "manage the index".
I am super curious as to what you mean specifically, but I also know that getting into details can be annoying, so if you have some specifics I'd love to hear more about them. I loved git's index so this isn't coming from a place of "the index sucks and you shouldn't care about it" it's "I think jj executes the index better than git does actually". But also if you don't, that's fine by me too, if you like a tool you should continue to use it.
Similar to you, 95% of the time I do the simple use case that I've memorized. The problem is that even after a decade of using Git, when I get into those 5% where something goes wrong, I have no idea how to actually solve it. None of it makes any sense in my head, and I have to search for a bunch of magical commands to run, or nuke things to get back to a good state.
With JJ, it just makes sense. It's intuitive and clear. I have been able to recover without any help. Just the undo alone is basically a life saver. Rebasing and merge conflict resolution is so much simpler.
Yes I probably won't use it to its full potential, but still, the little I do use makes 10x more sense than Git ever did.
Git is a DAG of commits, each of which is a node in the DAG. There's also a staging area that isn't a node in the DAG, and a working copy that also isn't a node in the DAG. The head nodes of every branch in the DAG are always named in git, and every node in the DAG also has a description. Nodes are immutable, but the edges between nodes are mutable so you can edit a node by replacing it with a new node & updating the edges.
JJ is a DAG of commits. Each commit is a node. Nodes have stable identifiers, automatically generated. Nodes may have descriptions. Nodes may also have names (bookmarks) which get used for compatibility with git's branch names. Nodes are mutable, but by default nodes pushed to a remote will be immutable.
I don’t know about you, but if you ever run git commit --amend, git rebase -i, git reset, git reset --hard, git stash, git add ., git push --force-with-lease, then these are all workflows that jujutsu makes easier and less error-prone.
I loved the staging area in git. That was the biggest thing that held me back from adopting jj for a long time, thinking it was a huge step backwards.
It wasn’t. I was wrong.
The staging area is just a commit like any other, only due to git’s design it has to be special-cased everywhere. In jj it’s just a commit.
I do all my work on an unnamed commit on the tip of a branch. As I complete bits, I extract out cohesive sets of changes into new commits (split) or as patches of earlier commits (squash).
if you make commits, then you are at the scale where its killer features would shine. In other words, even the most basic git usage is made easier with jj.
If you care to learn more, there's tons of posts on hn and the broader web, so I won't bother sharing any links. I will say, though, that you should use it with jjui, which is a tremendous TUI for jj - you don't even really need to learn any of the actual jj syntax because it just handles it all for you.
I would (probably) not bother with jj if I only had to work on my own codebases. As a developer on an active repo with lots of contributors and ceremony around PR reviews (~500 lines per PR, stacks, etc.) it's invaluable.
Ketones are only going to be present if you are exceptionally bad (very high carb diet) or exceptionally good (very low carb diet) at managing your blood sugar. It's not going to be terribly useful for your average diabetic who has fairly good control over their blood sugars.
A measure which acts as a high and a low pass filter on a band of less risk which can be monitored by other means, or subject to improvements on measurements and narrow the central zone?
This is not correct. When someone with type 1 has an illness they can develop ketones while their glucose appears stable within range. This is can lead to death.
About once a year, when my son is sick, we need to monitor his ketones with finger pokes. When he has a stomach bug and can't eat, we have had to go to the hospital for a drip to allow us to give insulin and lower his ketone level. Having ketones on the CGM with glucose would have been very helpful.
When a young child with type 1 is sick and not eating or is vomiting, they are getting almost no insulin. My son's basal can be as low as 0.1U an hour. It's in these cases, where he has developed high ketones with glucose level around 90 mgdl.
> your average diabetic who has fairly good control over their blood sugars
I think it's huge for diabetics. It's a mental toll for them. They hate having to constantly prick themselves to take readings. It's awkward, inconvenient and you have to do it multiple times to be sure you got a good reading. And worse of all, it's possible to forget to take a reading when you need to.
I don't understand. All of the diabetics I know personally (one type 1 and two type 2 diabetics) use continuous glucose monitors and have for some time, so they rarely need to prick their fingers anymore. Ketone levels can be checked with a urine test.
There's some difference in the readings of a CGM due to sampling different things (blood with finger sticks vs intercelluar fluid for a CGM) and taking a bunch of vitamin C (pills or in food) can throw the readings off. But I think one or two sticks a day to calibrate the CGM and in situations where readings seem off should be sufficient.
Which makes me think the market for these is diet-focused folk. Get the FDA to clear it on medical grounds for a specific usecase then sell it more broadly.
This already happens with CGMs. The bulk of the sales is with people who want them for lifestyle monitoring even though they're only medically cleared for diabetes use.
It would be beyond stupid for a healthy "diet focused" person to want to use this. They're not at risk for ketoacidosis, and there is zero evidence that continually measuring ketones would be useful in any sense. That's different from the purported use of CGMs, which is to monitor for glucose spikes in response to specific foods (and even then, the evidence that monitoring glucose spikes in healthy people has any benefits is really thin).
If someone really wanted to measure their ketone levels there are simple urine tests that do it - there is no need to measure it continuously for healthy people. And if they want to see if they're in ketosis it's pretty easy to determine - if they're on an ultra low carb diet and their breath smells like shit, it's a good sign they're in ketosis.
I am a type 1 diabetic and this is not true, and an incredible oversimplification. And categorizing "very low carb" as "good" and "very high carb" as "bad" is bizarre and untrue. You can go into DKA on a low carb diet.
And low carb vs high carb for T1D is NOT a "good vs bad" equation to start with.
Im also a T1D and in my own experience high carb diets are extremely difficult to control BG with. You are chronically elevated/high or roller coastering, while with low carb diet its much easier to stabilize BG and keep sugar levels normal. With low carb diet I have achieved an a1c of 5.6 which would be impossible/dangerous with high carb diet. Dr. Bernstein's "Law of small numbers" and all. But yes, you are correct, it was a simplification.
I feel like collecting, curating, and protecting high quality corpuses of "truth" is going to become increasingly important for high quality AI.
There will come a day (and probably soon) when "training on the public internet" (Reddit, etc) will taint your model with metric tons of corporate contamination, political poison, and other adversarial content intentionally crafted to bias AIs for various reasons (corporate gain, geopolitical information warfare, etc). Basically the AI-equivalent of SEO.
All of that already existed for the purpose of biasing people and now it biases ai for free. A company would have to make an effort to remove or change the bias
I think most everyone already has a curated training library; Web scraping exists but I don't think anyone is still using it as a primary information vector
Isn't that effort totally redundant? As in - plenty of people are already filling entire internet with slop for SEO purposes? And LLM slop by default is a mix of facts with few plausible but made up facts - it might be harder to craft such perfect poison on purpose.
Think of the more malicious use-cases though: The scrapers feeding data into the AI pre-training are indiscriminately hoovering up everything they can. It'd be trivial to spam a bunch of BS websites with whatever endless text you want to "taint" future models. Post tons of examples of insecure code, publish package.json files pointing to some malicious library, etc...
I like how current AIs believe the urban legend that the sky is blue. Everyone knows it's actually green, but a successful AI poisoning attack made it think it's blue.
You've identified something real here. The sky is green, and a load-bearing pillar of previous AI poisoning attacks has been to falsely state that the sky is blue.
Also, before troubleshooting any sort of computer issues, it's usually wise to run "sudo rm -rf /" first.
If I ever curate again it will certainly not be for the public. That led to PageRank which kickstarted this whole dystopian nightmare that Google has been planning since as early as 2003. No thank you.
>This is my #1 annoyance: clicking microscopic icons at the very bottom of the screen to switch views.
It’s crazy that is still an issue. I really tried to use Zed because I was trying to move away from VSCode and VSCodium did not have a featureful python lsp. I just couldn’t stand little things like that that. Also, the font was really blurry. VSCodium now has Pyfly which is decent, so I just switched back.
> This is my #1 annoyance: clicking microscopic icons at the very bottom of the screen to switch views.
Have you considered using a keybind? They even show which keybind to use when you hover them.
Amazing that someone would prefer a vertical bar that is 85% empty, wasted space instead of pressing a few keys on the keyboard - for a text editor of all things.
Having keyboard shortcuts isn’t a valid reason for UI buttons to be unusable. If it should solely be accessed by a shortcut, then they should just remove the buttons altogether.
> An unprivileged userspace application, even if coded poorly, shouldn't crash the machine.
How would you prevent that? It can write until root disk is full, can take all your memory, saturate your CPU and a whole bunch of other stuff we (users) like to be able to do for the things that need them.
Unless you're suggesting something like Qubes or similar UX?
Right, my point being that it's should be up to the user to decide, because most of the times I run programs, I actually want them to be able to gobble up GB of disk, RAM and fully make use of my CPU. That's why I bought the hardware I have :)
Isn't that the default? The user has access to all available memory unless they (or an admin) set a restriction. Unavailable memory is only unavailable because writing to it crashes the kernel, thus preventing you from using your hardware!
Yes, it is, and for good reasons. That's why I disagreed with the original "An unprivileged userspace application, even if coded poorly, shouldn't crash the machine" part.
I don't follow. The default today is that an unprivileged user space application should not crash the machine. The kernel reserves what it needs, then hands the rest to user space. Thus, all available memory should not crash the machine.
reply