Changelog News

Developer news worth weighting for

Jerod here! 👋

After our conversation with Alya Abbott last week, we decided to try Zulip in earnest for a bit. So far so good! If you’d like to kick the tires with us, join here.

Ok, let’s get into the news.

🎧 Your pods for the week

🤖 AI is more than GenAI (Daniel Whitenack)
💚 Starbucks DVD peddlers (Emily Freeman)
🎙️ Open source threaded team chat?! (Alya Abbott)
🚀 Learning & teaching networking & AI (Du’An Lightfoot)
🪩 Don’t ever use these TypeScript features (JS Party crew)

🏋️ Is Linux collapsing under its own weight?

A Rust for Linux developer, Wedson Almeida Filho, resigned from the project after an unfortunate interaction with another maintainer. Wedson’s parting words:

I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it’s best to leave it up to those who still have it in them.

After that, Asahi Lina (developer of the Apple GPU drivers for Linux) sounded off with her own frustrations with maintainers and Rust from the DRM perspective. Her conclusion:

But I get the feeling that some Linux kernel maintainers just don’t care about future code quality, or about stability or security any more. They just want to keep their C code and wish us Rust folks would go away. And that’s really sad… and isn’t helping make Linux better.

The post I’m linking to is in response to those two events. The author (“cb”) thinks they “signal deeper issues in Linux, both technical and cultural.” Some of the technical & cultural issues are explained in the post. What does this mean for the Rust for Linux project?

I think Rust for Linux as a project is in danger as a project, not because of technical reasons (though larger kernel ones don’t help matters), but because of social ones. It’s trivial for a maintainer who doesn’t want Rust to sandbag integration efforts for their subsystem, for whatever reason (not liking it, not wanting the workload, etc.) via refusing to help.

And what does this mean for the future of Linux? The author seems to believe an eventual fork is likely…

🗺️ Bret Victor introduces Dynamicland

Dynamicland is essentially making the real world computational then giving people what they need to compute it however they like. You really should watch the six minute introduction video, which is filled with amazing statements like:

You don’t have to simulate a virtual world when the real world simulates itself.

And this one, which is just bonkers (emphasis added):

Everything I’ve shown is taking place in our communal computing system, called Realtalk. And this is it. Realtalk is not a codebase. It’s a poster gallery.

To call this endeavor ambitious would be an understatement. Here’s the sum, which, if they pull it off (and maybe they already have?) would be a big technical achievement & an enormous cultural achievement:

Dynamicland is nonprofit, and Realtalk is not a product. You don’t buy communal computing. You don’t download communal computing.
Our goal is to invent a form of computation which local communities of non-specialists can make for themselves. From the ground up, for their own needs, which they fully understand and control.
A form of computation which is learned and taught, not downloaded and used. Like reading and writing, or mathematics, or the arts.
Not a product, but a practice.

🤷‍♀️ “SRE” doesn’t mean anything useful any more

Rachel (by the bay) laments her realization that “Site Reliability Engineer” has become useless as a way to categorize people with a very particular set of skills, much like every other title has before it:

Clearly, somewhere along the line, someone lost the thread, and it has completely destroyed any notion of what a SRE was supposed to be.
Just so we’re operating on a level playing ground here, I’ll lay down my own personal definition of the term, and what I expected from people in that role and what I expected from myself.
To me, a SRE is both a sysadmin AND a programmer, developer, whatever you want to call it. It’s a logical-and, not an XOR.

She goes on to detail what is meant by “sysadmin” and what is meant by “programmer”, but what she’s been seeing in attempts to hire are “SRE”s who are just ops people. I agree with Rachel, but not just about SREs… I’ve found most job titles in the software world to be relatively useless, and so much more so as each title ages.

💰 3.7 million fake GitHub stars

Thanks to Socket for sponsoring Changelog News

How much weight do you put in a project’s GitHub star count? Probably too much…

Socket researchers have uncovered 3.7 million fake GitHub stars, highlighting a growing threat linked to scams, fraud, and malware, with these campaigns rapidly increasing over the last six months.

Based on this research, Socket is launching a new “Suspicious Stars on GitHub” alert that utilizes the low activity and clustering heuristics to detect packages associated with repositories that have fake stars.

if you want to get proactive alerts and check your entire organization for suspicious star packages (and 70+ indicators of supply chain risk), install the free Socket for GitHub app in just 2 clicks. Whenever a new dependency is added or updated in a pull request, Socket analyzes the package’s behavior and security risk, alerting you before any malicious code has the chance to land in your project.

🐣 Your company needs Junior devs

Doug Turnbull does a good job laying out the case for hiring junior devs, a drum that I’ve been beating off & on for years.

Lately, BigTech only wants elite squads of Staff devs that can “hit the ground running” on the big (often AI) initiative. It’s been remarked (over and over) that AI will completely replace junior developers. Juniors, after all, exist to do “code monkey” work, easily replaced with an LLM.
However, that misses the mark on why we have junior employees. Coaching junior employees becomes its own force multiplier for innovating at scale. It’s not about the added labor, it’s about a psychologically safe culture that values teaching and learning, and the innovation that this unlocks.

Doug makes a lot of great points in this article. I’ll add one: junior developers are plenteous! That means you can take your time and find the ones that will really gel with your organizational culture. Also you don’t have to pay them as much while you train them up & make them more valuable so you can pay them more.

Q: “But what if we train them up and they leave?”
A: “What if you don’t train them and they stay?”

💒 The LLM honeymoon phase is about to end

Baldur Bjarnason has been consistently bearish on the current crop of AI tools/products since I’ve been following him. I don’t agree with him in all aspects, but he does a good job of arguing his position, so I appreciate his writing on the subject.

In this latest post, Baldur explains how weaknesses in how LLMs work are making them great targets for manipulation.

We’ve also known for a while that prompts are effectively impossible to secure.
It should not come as a surprise that some researchers decided to see if prompt “security” could be bypassed with a malicious token stream that completely bypasses the whole “comprehensible language” part.
The process for discovering these malicious token streams – sorry, “Strategic Text Sequence” – is quite similar to what Profound, the company mentioned earlier, seems to be doing. You automate a process of shoving customised prompts into one end of the LLM black box and you map the output to discover token streams that have an unusually big impact on the output.

Given the opportunity for businesses to gain an unfair advantage… we all know what they’ll do with it. Baldur thinks this is going to go from bad to much, much worse as these techniques are uncovered:

This is going to get automated, weaponised, and industrialised. Tech companies have placed chatbots at the centre of our information ecosystems and butchered their products to push them front and centre. The incentives for bad actors to try to game them are enormous and they are capable of making incredibly sophisticated tools for their purposes.

🎞️ Clip of the week: You can’t trust the network

This is why my favorite Go Proverb is “a little copying is better than a little dependency.”

🍳 Creating a Git commit the hard way

This is a rad deep-dive by Aryan Ebrahimpour on Git internals viewed through the lens of trying to create a commit without using git commitor a GUI tool:

Git has two sets of commands: Porcelain (high-level commands) such as git add, git commit, git remote, etc., and low-level Plumbing commands, which are used by higher-level commands to manipulate Git objects and references. We used these low-level commands to craft a commit by creating its underlying tree and blob objects.

💰 Supabase + Vercel (official first-party integration)

Thanks to Supabase for sponsoring Changelog News

Vercel just added official First-Party Integrations. Supabase is one of them.

This makes it a lot easier to launch Postgres databases from Vercel with full support for Vercel Templates and integrated billing. This integration means that you can manage all your Supabase services directly from the Vercel dashboard. You can create, manage, and delete databases and all the credentials are automatically injected into your Vercel environment. All the billing is unified in your Vercel bill.

I don’t think we would have grown so quickly without Supabase and Vercel. We have used many different products since we started the company, but Supabase and Vercel are the few services that we still use today. Now, there are 180,000 Resend users sending millions of emails every single day, and even though we outgrew many other products, Supabase and Vercel continue to help scale our company despite our challenges evolving all the time. —Zeno Rocha, CEO @ Resend

🔎 Greppability is an underrated code metric

Moriz Büsing:

When I’m working on maintaining an unfamiliar codebase, I will spend a lot of time grepping the code base for strings. Even in projects exclusively written by myself, I have to search a lot: function names, error messages, class names, that kind of thing. If I can’t find what I’m looking for, it’ll be frustrating in the best case, or in the worst case lead to dangerous situations where I’ll assume a thing is not needed anymore, since I can’t find any references to it in the code base. From these situations, I’ve derived some rules you can apply to keep your code base greppable

Don’t split up identifiers
Use the same names for things across the stack
Flat is better than nested

Click through for explainers on these and code samples for each.

📐 A bit more on your way out the door

That’s the news for now, but we have some great episodes coming up this week:

On Wednesday: Erez Zukerman talking ergonomic keyboards
On Friday: Natalie Pistunovich talking AI coding tools

Have a great week, forward this to a friend who might dig it & I’ll talk to you again real soon. 💚

–Jerod