Programming

In the movie industry, directors sometimes sign their as "Alan Smithee" to indicate they don't recognize the movie as their own work.
This can happen for various reasons, one well known example is David Lynch for Dune (1984) who didn't want his name associated with the movie since he didn't have the final cut.

Is there an equivalent for the software industry to indicate one wants to distance themself from a commit or a project they don't approve?

cross-posted from: https://feddit.org/post/22760294

The topic of the Rust experiment was just discussed at the annual Maintainers Summit. The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off. Congratulations are in order for all of the Rust for Linux team.

I got an email from Vercel urging to upgrade Next.js based project 3 days ago. POC was published 2 days ago. Today I've checked my logs and I could already see attack attempts.

I got an email from Vercel urging to upgrade Next.js based project 3 days ago. POC was published 2 days ago. Today I've checked my logs and I could already see attack attempts.

I’ve been working on a "Linux Inside Out" series and wrote a post that might interest folks here who like low(ish)-level / OS internals.

The idea is to dissect the components of a Linux OS, layer by layer, and build a mental model of how everything fits together through experiments.

The first part is about the kernel, in the post I:

• take the same kernel image my distro boots from /boot
• boot it directly with QEMU (no distro, no init system)
• watch it panic
• write a tiny Go program and use it as PID 1
• build a minimal initramfs around it so the kernel can actually start our process

The goal isn’t to build a real distro, just to give a concrete mental model of:

• that the Linux kernel is just a compressed file, you can boot it
• without anything else
• what the kernel actually does at boot
• how it hands control to userspace
• what PID 1 / init is in practice
• what is kernel space vs user space

Link: https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/

I’m the author, would be happy to hear from other devs whether this way of explaining things makes sense, and what you’d add or change for future posts in the series.

Hope you find it useful.

cross-posted from: https://feddit.uk/post/40593263

cross-posted from: https://feddit.uk/post/40593125

They state it's scheduled maintenance but the dashboard link leads to a 500 return. https://www.cloudflarestatus.com/

edit: I got it, see bottom of this message.

tldr: In a git post-receive hook, I'm doing npx @11ty/eleventy &, with an ampersand at the end. Yet, when I git push, I still have to wait for the output of npx @11ty/eleventy to finish before I regain control of the terminal. Why is that? And how can I just tell it to continue without waiting for the npx to finish?

Longer question:

I have a website that is being generated by a static HTML generator (I'm using 11ty). I want the site to regenerate every time I push to a specific git repo, which is hosted on my web server. I'm using the post-receive git hook to do this.

If you aren't familiar with git hooks, it's basically a bash script that goes in the .git/hooks directory that will run every time specific things happen in your repo. You can check out the sample ones that are included by default in every repo: you've got post-commit, post-receive (for the server side), etc.

So I'm using a post-receive script on the server side to call the 11ty command and regenerate the site whenver I push a new commit. It works, and it's very slick.

git will show you the output of the script whenever you push to the server. Which is also very cool, except that I'd rather not wait for that. This site will eventually get very large, so I'd rather just push something and assume that the site regenerated without actually watching the output.

The command to regenerate the site is npx @11ty/eleventy. I had assumed that putting an ampersand at the end of that would make it exit right away without waiting for the command to finish. However, it still waits for the command to finish, and git shows me the full output of that command before I can use the terminal again.

What can I do to just make that script exit right after it calls the npx command, and not actually wait for npx to finish?

The full script right now is:

#!/bin/bash  

cd ../eleventy-site  
npx @11ty/eleventy &  

edit: Thanks to the recommendations from @cecilkorik@lemmy.ca and @sin_free_for_00_days@sopuli.xyz, I tried a few more things and found something that worked. I don't understand why this works, but it does:

bash -c "npx @11ty/eleventy &" &> /dev/null  

You do have to do bash -c instead of just calling the command, and both the & inside of the quotes and after it are necessary, and the > /dev/null is necessary, too.

It started with a perfectly good and running kubernetes cluster hosting fediverse applications at keyboardvagabond with all the infrastructure and observability that comes with it. Then I made a simple networking fix.

TL;DR: I spent a solid month “pair programming” with Claude Code, trying to suspend disbelief and adopt a this-will-be-productive mindset. More specifically, I got Claude to write well over 99% of the code produced during the month. I found the experience infuriating, unpleasant, and stressful before even worrying about its energy impact. Ideally, I would prefer not to do it again for at least a year or two. The only problem with that is that it “worked”. It’s hard to know exactly how well, but I (“we”) definitely produced far more than I would have been able to do unassisted, probably at higher quality, and with a fair number of pretty good tests (about 1500). Against my expectation going in, I have changed my mind. I now believe chat-oriented programming (“CHOP”) can work today, if your tolerance for pain is high enough.

Ruby survives on affection, not utility. Let's move on.

Archived version: https://archive.is/20251204034843/https://www.wired.com/story/ruby-is-not-a-serious-programming-language/