I see some similarity to Fira Sans, which IMO is the most underrated sans serif. It is legible yet quirky, but just enough so as to not be annoying or pretentious.
Erik Spiekermann was the designer for both fonts (well, the first-named of two designers for Fira Sans, but he seemed to be leading it). Not surprising if his personal style shows through.
I don't get the people complaining that they need it on their low-power microcontrollers yet instead of using an XSLT library they'd rather pull in Chromium.
With how bloated browsers are right now, good riddance IMO
They are not talking about pulling in Chromium on a microcontroller. Their web server is on a microcontroller, so they want to minimize server side CPU usage and force the browser to do their XSLT transformation.
Since it's a microcontroller, modifying that server and pushing the firmware update to users is probably also a pain.
Yeah, I don't think XML + XLST is any better than or allows anything that sending say JSON and transforming it with JS wouldn't. However that would require changing the firmware, which as you mention may be difficult or impossible.
I think they're talking about outputting XML+XSLT on those microcontrollers, i.e. just putting out text. Chromium would come in for the viewer who's loading whatever tiny status-webpage those microcontrollers are hosting on a separate device.
I think it's a very good article. Even if you disagree with some of the individual points in it, the advice given are very concrete, pragmatic, and IMO tunable to the specifics of each project.
On state, in my current project, it is not statefulness that causes trouble, but when you need to synchronize two stateful systems. Every time there's bidirectional information flow, it's gonna be a headache. The solution is of course to maintain a single source of truth, but with UI application this is sometimes quite tricky.
Yes it’s total madness to synchronize and replicate complex state that logically belongs together. This is why microservices are such hot garbage. Well, how people tend to use them anyway.
Monotonic state is also better than mutable state. If you must distribute state, think ownership. Who owns it? Eg Theres nothing necessarily wrong with having state owned by eg a mobile client that can be adjusted by the user. Then you can sync it to the backend if you want, but they are only a reader/listener, and should never try to control it directly.
I have recently posted some critical questions. I didn't do that because I "enjoy being contrarian" (rather me enjoying a discussion). I did that to flesh out, what the benefits of JJ are. I think VCSs are interesting, I think Git has some issues, but in my opinion most problems are caused by a misguided mental models, I haven't/can't tried JJ. Most things I heard were workflows that are claimed are not possible in Git, but are possible and most-times only a few commands. There are other design choices which I disagree with and which might bother me.
("haven't/can't tried JJ" meaning I enjoy running a stable distro, but wouldn't mind compiling it myself. But Rust and Rust software is a fast moving target, so it is a hassle to deal with if you aren't invested in it's ecosystem. Also it violates the GNU standard, which makes it unfriendly for endusers, but this seams to be the norm nowadays.)
And some people just happen to disagree - doesn't automatically mean they just like "being contrarian". I took the "Yup..." to mean "this is what I was expecting, because it agrees with what I have seen before on this topic".
> I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.
And some unknown quantity of readers don't see anything compelling enough to either try it and/or comment on it after they have (or have not) tried it.
To be fair, I more or less invited these responses by bringing it up. Organically, complaints are very rare.
Obviously not everyone who tries something is going to switch, even if you take as an axiom that the other thing is objectively better. But I still think it’s notable that—without explicitly prompting that type of response—so few people seem to have negative experiences with jj given how tribal and passionate engineers tend to be over tooling.
I dunno, I've tried it and I think I will stick with Git for a while longer at least. I really don't like the fact that it automatically commits changes in the working tree. Apparently you can turn it off but.. yeah I dunno.
I may change my mind. Especially if they provide a less shit alternative to submodules and LFS. (And I agree this guy is just being contrarian - jj definitely does fix some Git annoyances.)
This was the thing that stopped me from giving jj a shot for the longest time, but it turned out to be a complete non-issue. Definitely don't turn it off!
The "aha" moment you might be missing is that you should consider your latest revision to just be the staging area. `jj commit -i` (shorthand for `jj describe; jj split -i`) is effectively `git add -i; git commit`. If you're worried about accidentally pushing unfinished work, don't be! It won't let you push changes without a message by default, and you update bookmarks (e.g., branch pointers) at your discretion anyway. Both of these mean that `jj git push` isn't going to accidentally push a bunch of in-flight work.
Think of it less like jj commits everything by default, and more like your working copy gets the benefits of change tracking and being able to take part in repo operations even when you haven’t taken a moment to make a commit.
Say I check out a branch (or bookmark or whatever). I compile it. Some stuff doesn't work. I add some debug printfs. Compile it again. Ok I'm done now.
In git I can just revert all the changes and I haven't modified anything important. In `jj` won't I have actually added all of those debug printfs to the top commit of that branch? Now I have to manually revert the edit?
As I understand it, the answer is "aha, but you just have to remember to `jj new` before you do any edits. The problem is I'm very sure I will constantly forget to do that. I guess you could say Git is opt-in to modifying commits whereas jj is opt-out, and I think I prefer opt-in.
I have very little jj experience but does that sound accurate? (Genuine question; I would love something better than Git.)
The default command you should reach for with jj to checkout a branch is `jj new branch` which creates a new commit to store your debug prints. You shouldn't do a two step process where you can forget the second step in the first place.
That said, if you do for whatever reason run `jj edit branch` instead (which enables the case you are discussing), jj will have snapshotted the previous change so you can still automatically revert the debug prints using
Better still, you can keep your debug printfs around on top of your ‘pushable’ work, and they'll be automatically be rebased as the tree changes underneath. If there are conflicts, you don't have to deal with them unless and until you actually want to use the conflicted code again.
In order to "check out a branch" in jj, you would have had to run `jj new` already. So your edits won't be "added ... to the top commit of that branch", but in a new commit (revision) when you checked out the branch. Then you can use `jj split` to keep whatever changes are important and discard the debug print statements.
In git you can also revert all the changes and you haven't modified anything important! `jj restore` or `jj abandon` would let you undo your changes or abandon the entire revision.
As others have noted, checking out a branch and accidentally modifying one of the commits on it is actually kind of hard to do. `jj git fetch` pulls in remote changes to your repo, but you don't "check out a branch": you either `jj edit` an existing commit or create a new one entirely with `jj new`. So you're unlikely to accidentally overwrite a commit by accident. I even find myself using `jj edit` less and less these days; if I want to change an existing commit (even if it's in the middle of a chain of commits), it's easy to `jj new <commit-to-modify>` and then `jj squash` the modifications into it. This allows me to double-check the modifications I'm making before I decide to commit to them (pun intended).
That said, I absolutely have forgotten to `jj new` before. Mostly this happens when I plop down at the laptop and start making changes without remembering to make a new revision. Whatever revision I happened to be on gets all those edits. Sometimes I work for quite awhile before realizing this, and so having to pick out which changes belong where piecemeal would be a ton of work.
But this is precisely the power of having all these changes in the repo as a revision. I can use all my SCM tooling to solve the problem for me! For the sake of this example, let's assume that I've pushed all my changes to a remote branch and then stupidly continued editing them. Now my local copy of branchname and branchname@origin have diverged; they both have the same revision, but different git contents.
# Oh no! I've accidentally made edits to `master`. `omny` points to two
# separate git commits; one is my local copy of `master` and one is the
# remote.
> jj log
@ omny me@example.com 2025-08-14 13:22:15 master* ae25
│ Made some changes
│ ◆ omny hidden me@example.com 2022-03-26 14:49:58 master@origin 79d4
╭─╯ Made some changes
◆ notn me@example.com 2022-03-23 17:03:05 b192
│ Earlier changes
# First, rebase our local changes onto the remote commit. This neatly
# splits out the changes I just made from the changes that were there
# before I messed up.
> jj rebase --branch master --destination master@origin
Rebased 1 commits to destination
Working copy (@) now at: omny?? 67a9 master*
Parent commit (@-) : omny?? 79d4 master@origin
# You can see that now my local changes have been rebased on top of
# the remote copy. Unfortunately, they still have share the same
# revision id so jj is not happy with me! We'll have to put those
# changes into a new revision and make sure our local `master` points
# to the same id as the one at `origin`.
> jj log
@ omny?? me@example.com 2025-08-14 13:28:14 master* 67a9
│ Made some changes
◆ omny?? me@example.com 2022-03-26 14:49:58 master@origin 79d4
│ Made some changes
~
# Make a new revision for our changes to go into.
> jj new
Working copy (@) now at: plwu 70d8 (empty)
Parent commit (@-) : omny 79d4 master
# Abandon the local revision where we accidentally changed the
# `master` branch. Normally this would get rid of our changes,
# but `--restore-descendants` makes sure that the filesystem
# contents of the new revision we just made remain unchanged.
# Since we're getting rid of the revision that made those edits,
# those edits have to be moved up into that new revision in order
# for it to look the same as it did before!
#
# Abandon would also normally delete our local copy of the
# `master` bookmark. But `--retain-bookmarks` keeps it, and pushes
# it back one revision. This is exactly what we need!
> jj abandon master --restore-descendants --retain-bookmarks
Abandoned 1 commits:
omny?? 67a9 master*
Rebased 1 descendant commits (while preserving their content) onto parents of abandoned commits
Working copy (@) now at: plwu 69ce
Parent commit (@-) : omny 79d4 master
# Everything is happy again! My recent changes are now on their
# very own revision.
> jj log
@ plwu me@example.com 2025-08-14 13:33:45 69ce
│ (no description set)
◆ omny me@example.com 2022-03-26 14:49:58 master 79d4
│ Make some changes
~
I want to be clear about something here. I have never done this before. This isn't a pattern that's ingrained into me. I've certainly accidentally edited the wrong revision before, but it's always been relatively easy to split out the changes I made so I've never needed to really solve this in the general case before.
I read your comment, figured this would probably be the easiest way to do it using the primitives I'm familiar with, and I tried it. And it worked! I didn't need to go digging through manpages to figure out how to do it, it was a simple composition of commands I use every single day. I did this on a live, real repo I am actively working on where I had edits in flight, and just for giggles I squashed them into master. I had zero fear about doing this because a `jj op restore` would get me back to safety no matter what.
This will also work basically unmodified if you haven't pushed the changes. The only difference is you'd use the raw revision id instead of `master` and you'd use git commit ID of the earlier changes you wanted to keep (pulled from `jj evolog`), which you'd substitute everywhere I used `master@origin`. This works for every case where you have two sets of changes in one revision and you want to pull out the later changes from the earlier ones.
You're reading an extremely biased sample of experiences. It's probably the opposite: 90% haven't tried it, 9% tried and didn't see any reason to switch, and around 1% have switched and won't shut up about it. For an advanced git user, it doesn't offer all that much. I used it for a couple of weeks and can't say that it saved me any time or any amount of work; it was either zero, or so close to zero that I wasn't able to notice it.
When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.
> For an advanced git user, it doesn't offer all that much.
As a (former) advanced git user, nothing could be further from the truth. We are always the most passionate cohort of jj users in these threads. This is almost certainly because jj unlocks a bunch of additional abilities and workflows that we've been torturing out of git (or given up on, or didn't even conceive was possible) for years.
On the flip side if all you ever do it git pull, git commit, git push, jj is probably not going to offer you much.
>For an advanced git user, it doesn't offer all that much.
arrogant, and completely absurdly wrong. I've used Git for 20 years. `jj` the single best improvement to my development workflow in... well, since adopting Git.
> I used it for a couple of weeks and can't say that it saved me any time or any amount of work
I would bet 5 figures that's a lie.
> When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.
So despite all this chest puffing, an appeal to authority would tip the scales for you?
There’s no need to be antagonistic. We’re all friends here :)
I am an unabashed jj evangelist and I don’t think they’re lying when they say it didn’t save them any time. Adoption costs might be small but they’re not zero. Some workflows are easy with either tool. And some people just don’t “get” it and struggle to adapt to a different mental model. That’s okay!
> So despite all this chest puffing, an appeal to authority would tip the scales for you?
I think GP was simply saying this would be a clear sign to them that if it’s mature enough to handle kernel developers’ needs, that’s a good sign it’s worth the effort to switch. It definitely would be! I can’t wait to hear if and when kernel developers start switching; it will be a huge positive indicator.
There are at least six Android app stores in China that have more than 100 million MAUs each: Huawei AppGallery, Tencent MyApp, Xiaomi Mi Store (or GetApps), Oppo, Vivo, and Honor stores.
If you look at Garnet's source code it is very non-idiomatic C#. It goes to extraordinary lengths to avoid the garbage collector. Almost all memory management is done with unmanaged memory and pointers.
They also have a very clever internal design and do some other tricks like strategically avoiding async/await and moving I/O operations onto the network request thread.
I think the programming language is not relevant, especially since startup time plays no role. A different design can have much more impact, and IIRC Garnet is not fully compatible with Redis.
On latest Android, long-pressing home activates the Google Assistant overlay, which allows you to select any text on screen (and translate and search region).
correct and it looks like it tries to do some autocorrect, not great when you need to copy some random characters password (like it was the case in the share WiFi password in previous android version, where you couldn't copy displayed password natively)
