Well, Graphite solves the problem of how to keep your stack of GitHub pull requests in sync while you squash merge the lowest pull request in the stack; which as far as I know jujutsu does not help with.
Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow.
I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration.
Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over.
jj is actually perfectly fit for this and many other problems. In fact, this is actually the default behavior for jj -- if you squash a bunch of jj commits, the bookmarks on top automatically point to the updated rev tree. Then when syncing the dependent branches to git they all rebase automatically.
The problem however lies in who or what does this rebasing in a multi-tenant environment. You sort of need a system that can do it automatically, or one that gives you control over the process. For example, jj can often get tripped up with branch rules in git since you might accidentally move a bookmark that isn't yours to move, so to speak.
Correct (Graphite eng here for context) - we've thought about extending our CLI to allow it to sync jj with GH pull requests to do exactly this. Essentially - similar workflow but use `jj` as the frontend instead of `gt`
Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.
The problem I have had with this type of app is that, on Instagram at least any video that a friend posts is considered a reel. And I want to watch videos that my friends post. What I don't want is swiping mindlessly through random videos. So really I would like a swipe blocker not a short video blocker. (And bonus points if I could make it work on Firefox)
This is a good point, I will try to find a solution. Currently, it's able to whitelist Reels from the DM feed, and it will block the rest as soon as you start scrolling, I'll see how to do this for normal posted reels.
On the one hand, yes this has obviously high immediate value; on the other hand, I can't help but feel like you are giving access to multiple tools that can be used for arbitrary code execution anyway (i.e. running tests, installing dependencies, or running any linter that has a plugin system...), so blacklisting `git --exec-path=/bin/sh` for example is... Misguided? You would have a better time containing the agent in an environment without internet access?
It’s not misguided. The goal isn’t prefect security, the goal is mitigating risk and collaborating with cross functional security, compliance, platform, operations, etc… teams.
Use Jules, also by Google if you need what you describe.
I have an actual oven where I can select "programs".
As far as I can tell, they control three parameters:
* Where the heat comes from (top, bottom, or both)
* Whether or not ventilation is activated
* The temperature
There is also a dial for temperature, but not for the other two parameters. I am not sure whether every combination is covered by the "program" dial. I am not sure whether or not my understanding is even correct.
I would say it's an 7.5 out of 10 on the nightmare bicycle scale.
Settings like "Bake", "Roast", etc are quite frustrating. They do have meanings, but pretty much no user knows what they mean. A selector that lets the user choose which heating elements they want to use might be useful, but this seems like it might be a case where if the user doesn't know the difference between "Bake" and "Roast" they may also not be in a position to decide if they want heat from the bottom, top, or both anyway.
Most people have a hard time unplugging from social media, despite widespread distrust of big tech.
Can't unplug from banking, even when literally communists (literally literally, I've met some proud of being communists, they still got a mortgage).
Coal and petroleum-based fuels are slowly getting unplugged, but the issues were known over a century ago, and the transition only became relevant scale when the alternative was already much cheaper — and it's not yet clear how much damage has been done in the intervening years.
--
Any AI worth using is so because it's at least one of [cheaper, better] than a human on the same task: any AI which is both more expensive and worse just doesn't have any reason to be used in the first place.
This means that "unplugging" an AI comes with a cost of losing every advantage that made you start using it in the first place.
And? Look to fossil fuels and the greenhouse effect — even with ample evidence of both a causal mechanism and the results, we've still got people who want to drill and burn more oil; and also, there's also plenty of people who want to switch oil off despite all the positive things that oil brings.
An AI which is "only" as misaligned as one of the major industrial sectors of the world, that is made out of humans who are necessarily able to care about human interests, and which drove a huge amount of economic improvement and brought with it derivatives such as basically all polymers, is still capable of great harm. And because of those benefits, society as a whole still has not unplugged the oil drills.
The more power there is in a system, the harder it is to keep it aligned with our best interests, even when there are humans not just at the wheel but occupying every step.
And the more aligned it is, the harder it is to "just unplug it" when things — as is inevitable because nothing is perfect — do go wrong.
The README fails to address the elephant in the room, which is that usually shell scripts mainly call external commands; as far as I can tell there is no documentation of which built-ins are supported?
That said, in a similar vein, you could probably create a bundler that takes a shell script and bundles it with busybox to create a static program.
Busybox commands often don't support all features used to and differ even substantially if you depend on GNU additions. https://www.busybox.net/about.html
I have been keeping a running list of busybox/toybox deficiencies and differences. There are more than I would have expected.
An alternative is to use crunchgen from NetBSD (also included with some of the later BSDs) which crunches full-featured, source tree versions of multiple utilities in a single, static binary. What busybox refers to as a "multi-call" binary.
It will be larger than busybox of course. I get evertyhing I need in a binary less than 5M.
I haven't looked at the code, but I assume this is just taking care of things like pipes, loops, variables, conditionals, etc, and leaving the actual binaries like jq as stubs assumed to be there. Its abstracting the shell, not the programs you run in the shell.
Sure, but why is that an interesting goal? Historically, bash has had very good backwards compatibility, and it’s unlikely that you need new features anyway.
you can write bash but run the scripts on systems that may not have bash, is my first thought. packaging “shell” scripts into a scratch container or similar sounds pretty nice for certain use cases.
I assume this is what they are talking about here:
> Standard library: we aim to add first-class support for a variety of frequently used/needed commands as builtins. you no longer need external programs to use them.
That's not going to be an easy task, and would basically entail porting those commands to go.
In France, training cars have only one steering wheel, and the instructor is perfectly able to drive the vehicle by steering with his extended left arm.
reply