barrkel

Jujutsu has a mental model that aligns far more closely to Gerrit than GitHub etc.

It uses a persistent changeid to model a change mutating over time, like Gerrit uses Change-Id in the description footer, and unlike git.

Jujutsu can be colocated with git and use .git as its backing store; every jj change revision is a git commit.

When you use jujutsu, you tend not to use branches any more, and think in terms of changes and chains of changes (i.e. stacked PRs, what Gerrit calls Relation Chains).

Jujutsu makes it very easy to work with a chain of changes (stacked PRs), letting you update commits in the middle and automatically rebasing the rest of the chain, without forcing you to interrupt work and resolve conflicts if there happen to be any (so, unlike git rebase -i with 'edit' on the commit you want to update).

IMO if you like the Gerrit workflow and the way it handles chained commits, if you switch to jj for two days of work, you'll never want to use git again.

You'd expect a tool-enabled model to leverage crop and zoom tools to inspect and validate what it thinks it's seeing, though.

How do you do drop shadow layer mask effects with Pinta and KolourPaint?

I guess the idea is you can do edits via non-destructive layer effects and compositing a stack of layers, where somewhere amongst the stack is your original unmolested data. Though that has not been my experience with Gimp - it's far more likely to want to to commit to a rasterizing decision far earlier than Photoshop would.

I don't care. 99% of my uses of an image editor are for ad hoc edits. I never want to clutter my disk with project files on the off-chance I want to preserve layers or whatnot. I have zfs snapshots and cloud backups should I want to revert but the odds I want to revert an ad hoc image edit are approximately nil - I can never recall needing to do so.

I don't use Gimp as a 3D modeling software or a digital audio workstation. I use it to add text to a family photo. The primary storage medium is jpeg. I don't want or need anything else.

The real issues with Gimp start when you try to work with selections, transforms, cuts, crops and so on. Photoshop muscle memory doesn't transfer and it is so incredibly clunky.

If you run DNS at home (even just dnsmasq) and you bridge your home 192.whatever to tailscale, you can make the same domain name resolve both at home and via tailscale.

Export and Save As should be the same menu item with an option in the dialog.

There are many many more but start with the app having the overbearing assumption that it thinks you want save to its file format rather than make an ad hoc edit.

It is not the literal example because I told it to rename the function, but the function had the form thisNotThat for a boolean predicate that had a far more conventional name.

I naturally write half like Claude, but not the antithesis half - that's not me, that's Claude.

I have a chunky bit of functionality in my hobby app using babylon.js to render 3D worlds using things like portals and LoD rendering to manage the visual load. I built it out with a combo of Fable and Opus 5.

I too got fed up with the prose of Opus in particular, and tried going back. Unfortunately, the previous models were less able to hack it. The prose was better but progress was worse.

It wasn't just conversation and comments. Some of the function names were wild. Like it instead of something like "isSolidWall(x)" it would write something like "weightyNotEphemeral(x)" or something - that's not quite it, but it really did embed overwrought antithesis into the identifier instead of a straightforward positive predicate.

Go is particularly hilarious because it will just go and create a thread for every hardware thread in your system (my home system has 192 hardware threads), just in case it needs to scale up. So tiny utilities, little network proxies and the like add up to thousands of threads + stacks etc. for very little load.

The single biggest annoyance with Opus 5 is that it writes too elliptically.

Sentences that orbit a point, then jump to it like it's a revealed insight.

Unnecessarily abstract phraseology. Constantly using inanimate nouns as the subjects in sentences in order to unlock variety in verb choice, especially when it helps construct a sentence where the real action can 'land' like a surprise at the end.

It is definitely more capable, and yes, I've found it can make unwarranted decisions, but actually I've found Fable worse for that, particularly if it's off in a subagent somewhere out of sight.

And comments are out of control. I have a subsystem in my hobby app that I wrote over a couple of weekends with Opus + Fable. After ~30 or so commits it apparently started instructing subagents to copy the "existing verbose comment style of the codebase" - a verbose style it initiated. A review of the code showed it was approaching 3:1 comments to code ratio. I spent a day's worth of tokens (5x) rephrasing and eliminating comments.

journald is IMO the worst part of the systemd ecosystem. You're better off using it only as a router and not storing any logs in it. The indexing system it uses is slow and provides no control over chatty subsystems - you cannot truncate the logs for just a single identifier. For all the use indexing is doing you will get better performance out of a modern grep like ag or rg. Structure is worth something but it's better off somewhere other than journald.

Printing money without backing is not deficit spending!

We're all well aware of the money supply, M1 / M2 / M3, velocity of money, etc. It's important for money to not get tight when the economy slows down, and it's important to tighten up the amount of money when the velocity increases again. But this is neither deficit spending nor printing money without backing!

Inflation is can come from a social psychological phenomenon around expectations. If the cost of living goes up in a surprising way, you feel the pinch. You want more money. Maybe your employer gives you a raise, and raises prices to compensate, reasoning that other things are also going up in price. The risk is this creates a self-propagating loop (which in turn does to a degree depend on accommodating institutions that don't restrict monetary supply).

You can trigger inflation through loose monetary policy, sure, and you can dampen the cycle by restricting the supply of money, and that's been the main function of independent central banks for most of the latter 20th and 21st century.

But inflation is literally just increase in the cost of living. It's a symptom, not a disease. It admits multiple explanations.

Inflation is an increase in the cost of living.

It can be caused by deficit spending. It can also be caused by supply shocks. For example, if you restrict building new housing, the price of housing will increase, both rents and house prices. If you tariff imports, a basket including those goods will rise in price to the degree those imports are not substituable. If you start a war in the Middle East, oil prices will rise, and increased energy costs can feed into lots of different things, raising prices.

Very similar to Windows Structured Exception Handling, which the Win32 implementation used, and also looks similar to Java, but without checked exceptions. try/except/end and try/finally/end blocks.

The major differences with C++:

    * objects are references not values, cutting out all the copy constructor,
      assignment operator, destruction on out of scope etc.
    * objects are zero-initialized after allocation and before constructors run
    * constructors are run from most derived to least derived
    * calling Free method checks if Self is nil
    * this + zero init means that you can call '.Free' on all the objects you 
      reference in the destructor without checking if they're nil first, 
      handling partial construction

It's not a memory safe language, but it does give you a bunch of idioms that, if you stick to them, you don't feel nearly as much pain as C++.

The combination of exceptions and non-trivial {copy constructor, assignment operator, destructor} are what combine to make C++ a somewhat broken language when you try to use all the features. And also responsible for poisoning the well for exceptions as an error handling mechanism for native code.

Delphi did native exceptions much better IMO.

As is well known, security is not a binary, it's a spectrum. It's why you add security in layers, and why it's generally a trade-off between risk and usability.

Your mileage may vary, but I sleep better with my own projects not having any node_modules in their build tree.

Load penalty is part of the Otis RSR algorithm, it's in the article.

If you run it in a sandbox with no internet access and a read-only role login for the database, and you supervise it, how big is the risk do you reckon?

Of course there's an issue if the data in the database is contractually restricted and you don't have a zero retention endpoint for inference, but the former usually comes with the budget to fund the latter.

JJ stacked changes are just a chain of git commits. To jj, a branch is just a pointer to a commit, like git. Code review is no different to whatever you normally do for git. Push to your review system and review commit by commit Gerrit style, or as a single unit, or as stacked PR (I have not done this however as I don't use GitHub any more).

A decent idea, however it seems to me a good chunk of it is because of git limitations. Have you looked jj?

I'm having a much better time with jj and a workspace per subagent than I was with git and worktrees.

It's still useful to have the CI gating on updating the master branch pointer, but you largely stop working with branches once you switch to jj.

Eggplant is called aubergine in UK and Ireland. Full true synonym.

The facts don't support a real eco panic. IMO it's a proxy for middle class job security fears, displacing into known middle class shibboleths. It can be sincere, but it's motivated reasoning.

No, but you would find jj solves this problem far more elegantly.

There comes a point in a startup's life where more controls are needed. Red tape. The stuff that slows down the big boys. Problem is, the red tape is scar tissue from previous informal process failures.

I think these control rooms were superior in some respects to modern software system observability.

- modelling the system rather than implementation (system status rather than many individual service statuses)

- supporting causal reasoning: the control flow on top means you can trace failure modes back, visually; software systems typically only model their own ontology, and you need to look somewhere else for the next abstraction down

- surface state first rather than time series; a pretty graph is nice to look at, but for actionability sometimes what you need is the flashing red light

- prioritize first-out indicator. In a complex system with lots of alerts, the most important diagnostic alert is often the first one - the rest are downstream and contribute to alert fatigue, despite them probably being more important business metrics

Is it being used in production anywhere, even if only a toy app?

I know you say it's not production ready and not optimized yet, but in the same breath - in your comment here - you say it's already faster.

My experience has been escalating fragmentation past 90%, along with lower performance owing to the fragmentation.

It's not actually. Think about it for a moment and you'll see life is full of tensions between preventing crimes and freedom / utility.

It's most obvious on the roads. Few non-commercial vehicles will limit your speed to the national maximum. Wouldn't a strict interpretation of your opinion imply speed governors?