Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze.

jj, an alternative to git, gets discussed a lot these days (1, 2, 3, 4) and is often pitched as a solution. While I’m very sold on the problems jj is trying to solve, the way it solves them hasn’t quite hit home with me. Every 3 months, for the last 1.5 years, I try it out for a few days, really trying to make it part of my workflow but eventually I give up and go back to git.

That’s where git history comes in.

Jujutsu, to capture it in one sentence, is a modern front-end to local git repositories, which is a radical, but powerful simplification.

Here are his reasons why jujutsu might be worth a try.

This text was all written by hand by Evan Martin, a human. I used no AI, and disclaim this in particular so that you can expect that the choices made in what to mention, what to leave out, and in what order were carefully considered.

Nice.

I pinged every IP address that wasn't reserved. The image is 8k by 8k and is re-encoded as an AVIF to be friendlier to mobile devices. Like every other survey done, it is using a Hilbert Curve to convert the linear address space to a contiguous 2d space. The hotter the colors (blue is coolest), the denser the ping responses were.

(If you are interested I can provide the full-resolution pyramidal-tiled TIFF (about 1 GB) that requires ~3 GB of RAM to view. I've also compressed the ping response data into its own format down to about 150 MB. PM me for a link)

Non-proxied image

Here is a 2006 survey to compare.

Some observations: Big Tech (USA) is in the top left. US government allocations, for the most part, did not respond to any pings. And maybe you didn't realize this before, but Multicast (Class D) & Class E consume a whopping 12% of the IPv4 range.

Source: https://js1024.fun/demos/2026/25/source

Over the past few days I've been building up this little file format hacking puzzle. It's a bit niche, but I hope the sort of people who're into this kind of thing might really enjoy it, so that's why I'm sharing it here!

(Yes, the Wii has no HTTPS yet, I've been busy building silly polyglot, quines, games and now a file format puzzle 😊)

The pattern is always the same:

1. Someone passionate creates a community
2. Early members are deeply invested — high-quality discussions, strong norms
3. Community grows, hits the front page / "all"
4. New users flood in, post memes, low-effort content, drive-by hot takes
5. Old-timers get drowned out
6. Mods either burn out and quit, or become dictators ruling their own fiefdom

Reddit's model accelerates this. Any subreddit that gets popular enough hits the All feed, and at that point the incentives shift from "quality contribution" to "what gets upvotes from the broadest audience." The people who built the community lose control of it.

I'm working on a social platform and I'm trying to design communities that don't go through this lifecycle. This is what I have in mind right now. A user's voting power within a community is proportional to their tenure in that specific community. So if someone's been there for 2 years, their vote counts more than someone who joined yesterday. No matter how many new users show up, they can't swing the community away from the people who built it.

The weighting wouldn't be dramatic, maybe a logarithmic curve where the first month gives you baseline power and it grows slowly over years. The goal isn't to create an aristocracy, just to make sure the signal from committed members isn't buried by a flash mob.

Implementation-wise I'm thinking:

• Each community membership has a joined_at timestamp
• When scoring a post within that community's feed, each boost/vote is multiplied by log2(days_since_join + 1) / log2(30) — so 1 day = 0.05x, 30 days = 1x, 1 year = ~1.7x, 5 years = ~2.1x
• The algorithm still surfaces new content to everyone, but the ranking is weighted toward longer-tenured members' tastes
• Also considering: a slow-boot period where new members' posts are held for review by existing members (like a probation phase)

But I'm second-guessing myself. Some concerns:

• Does this just create a gerontocracy where old members gatekeep forever?
• How do you handle the first 30 days when no one has much weight?
• Would this actually prevent the decay, or just slow it down?
• Is there a simpler/better mechanism I'm missing?

Curious what other approaches people have seen work (or fail). Has anyone implemented tenure-weighted voting before?

Edit: I appreciate the suggestions. A few of them actually align with features I’ve already built:

• Trust graph: The platform already uses directed trust edges, with vouching and inviter accountability (if an invitee misbehaves, the inviter is penalized). I can extend this model from the platform level down to individual communities.

• Invite-only mode: I already have trust-based monthly invite limits for the whole platform, so adding the same option for communities seems like a natural extension.

• Slow-boot / probation: This is already in place, new members’ posts are held for curator review before being published.

• Different interaction types: The system already supports multiple interaction types (like, comment, share, gift, emoji). I'm not sure how to expand these into Slashdot-style categories (e.g. agree/disagree, insightful/funny, quality/shitpost, high/low effort, etc.), but it's something I'd like to explore.

• Moderation limits: I like Slashdot's approach of limiting moderation to prevent burnout. I'm less certain whether meta-moderation would be a good fit here, but I'm open to considering it.

Bringing that back to tech debt: a simple kind of high-interest short-term debt would be committing code without tests or documentation. Yay, it works, ship it! And truthfully, maybe you should, because the revenue (and customer feedback) you get from shipping fast can outweigh how much more bug-prone you made the code in the short term.

But like all high-interest debt, you should plan to pay it back fast. Tech debt generally manifests as a slowdown in your development velocity (ie. overhead on everything else you do), which means fewer features launched in the medium-long term, which means less revenue and customer feedback.

[...]

Bankruptcy

The tech bankruptcy metaphor is an easy one: if refinancing doesn't work and your tech debt continues to spiral downward, sooner or later your finances will follow. When you run out of money you declare bankruptcy; what's interesting is your tech debt disappears at the same time your financial debt does.

This is a really important point. You can incur all the tech debt in the world, and while your company is still operating, you at least have some chance of someday paying it back. When your company finally dies, you will find yourself off the hook; the tech debt never needs to be repaid.

Okay, for those of us grinding away at code all day, perhaps that sounds perversely refreshing. But it explains lots of corporate behaviour. The more desperate a company gets, the less they care about tech debt.

I’m looking to follow more creators and developers on Mastodon who are passionate about open-source, privacy-first software, and system tinkering.

I spend most of my time working within the Android development stack, building local-first/offline-first applications, running Arch Linux, and messing around with low-level Android rooting and custom kernels.

Let's follow each other!

@jksalcedo@mastodon.social

#Hello eveyone!!

D.eSystem 6.0.8 beta is the final release of D.eSystem 6, ist way more stable than the old Beta versions and it introduces a gui for the D.eSystem version app

D.eSystem 6.0.8 on github: https://github.com/D-electronics-scratch/all_D.eSystem_versions/releases

Github main page: https://github.com/D-electronics-scratch/all_D.eSystem_versions

*The Rustification of Bun#

Rewriting 500,000 lines of Zig into another language would be a gargantuan undertaking if done by hand. “A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time,” Sumner wrote.

Instead, Sumner went with Claude. He spun up about 50 dynamic Claude Code workflows, reaching a peak of about 1,300 lines of code per minute and generating over a million lines of Rust code. The job took 11 days and cost about $165,000 at API pricing. Claude Fable did most of the heavy lifting.

I'm a beginner in programming, and I found out I cannot even reproduce a simple number guessing program I have earlier copied from a book.

Is it a beginner issue, or there is more than just continuing to learn to be able to code without hints?

Hey, not sure where to post this but I'll give it a try.

I've changed jobs many times due to the economics of the construction sector in Sweden going to shit. So now I'm all but ready to change my career.

Would it be wise to get a 2 yr degree and start over as an embedded dev? Other programming jobs have been scarce and I wonder if that applies even for embedded.

Thanks :)

Few weeks ago I wrote about a side project that I'm using to learn, this is my reviewing what I missed on the project, the main issues after a few dozen games in the platform with friends. And what I learned in the process.

All comments, feedback is appreciated.

Console? good, GUI? good, game dev? use Godot engine with its similar language Gdscript, but what else? Ive been seeing AI, Data Science stuff, but whats the point if ita slow?

Andrew Kelley quit his job in 2018 to build a programming language. Eight years later, Zig powers Ghostty, TigerBeetle and Uber's cross-compilation. It's top 5 most admired on Stack Overflow. There's just one thing missing: 1.0. Andrew Kelley explains why.

Vitaly talked to Andrew about:

• Why Zig has no 1.0 after a decade, and why that's deliberate
• Why Zig left GitHub
• Why Zig banned AI from Zig
• What makes Zig better than C (and why every other C replacement failed)
• Andrew’s take on Open Source

It's a long interview, but I found it very interesting and worth it.

Been working on a project where we need to keep an eye on competitor pricing pages and feature comparison tables. The data changes frequently enough that manual checking doesn't scale, but it's not structured data so scraping is painful.

What we ended up doing is taking scheduled screenshots of specific pages and diffing them visually. Sounds dumb, but it actually works better than trying to parse HTML that changes layout every other week.

The setup

We tried a few approaches before landing on something that stuck:

Attempt 1: DOM diffing. Wrote a script that grabbed the page HTML, stripped non-content tags, and compared. Broke constantly because class names changed, ads rotated, and layout shifts threw false positives everywhere. Lasted about a month.

Attempt 2: Text extraction + diff. Better, but lost all context. Knowing that some text changed doesn't help when you can't see where on the page it changed. Pricing buried in a table looks very different from pricing in a hero banner.

What worked: Visual monitoring. Take a full-page screenshot on a schedule, overlay it with the previous one, highlight the pixel differences. You immediately see what moved, what changed, what disappeared. We've been using SnapshotArchive for this — it handles the scheduling and keeps a visual history so you can scrub back through changes over time.

Where it's been most useful

Pricing pages, obviously. But also:

• Feature comparison tables (competitor added a feature we don't have? good to know early)

• Landing page A/B tests (you can literally watch competitors test different copy)

• Job postings (hiring for "AI engineer" tells you something about their roadmap)

• Changelog/release notes pages

The screenshot approach catches things that text-based monitoring misses entirely. A redesigned pricing page with the same prices but different emphasis? DOM diff says "no change." Visual diff says "they made the enterprise plan way more prominent."

Curious what others do

Is anyone doing this kind of competitive monitoring? What's your approach — manual, scripted, or some tool? We've been happy with the visual route but I'm sure there are workflows I haven't considered.