It is a programming language. That thing you write between single quotation marks when you invoke jq is a program. (And like with other programming languages, it's often useful to write your jq programs to files instead of always writing them inline in the shell.)
I love jq, though. It provides an extremely good language for its task, even if I often have to take a look at the manual when writing an interesting jq program.
> At least before it would listen to instructions like this.
Would it actually follow them? IME LLMs are incapable of estimating the length of their own output, the total length of the current context, etc. They just make stuff up unless they have external tools that can inspect those things for them.
> The Phosh project aims to provide a daily-usable, robust and easy to use graphical user environment for mobile devices running mainline Linux. The name is a portmanteau of phone and shell as phosh was one of the first components developed by the project. It hence coined the whole project’s name and is still one of its core components. All of Phosh is entirely Free Software.
Hahahaha. I think for the limited purpose of iterating on elisp code, using gptel or efrit to let an agent run wild and iterate in a live environment could be useful. I'd want to run that in a VM though, and not as my user or with access to personal data beyond reusable parts of my config.
Once you get it set up, Emacs is a pretty damn good "agent" multiplexer as well. I use agent-shell with Projectile on Doom Emacs as my main workflow these days, and it works very well even if I have 6 projects open or whatever.
Claude and Codex are also both quite good at working with Emacs as well. Depending on your isolation/sandboxing strategy, they can either run commands against your session via emacsclient (a bit scary) or dump elisp in the REPL for you to evaluate. Both are really efficient in terms of giving you a fast feedback loop.
One of the great joys of NixOS is that configuration of existing features is continuous with development of new features. Both are just NixOS modules. In the same way, configuring your desktop is continuous with configuring a server is continuous with preparing a netboot image for an embedded device. If you know how to configure a NixOS desktop, you also know how to prepare your own custom NixOS install media. If you want it to, Nix can cure the stomach ache HCL gives you when you write Terraform.
Nixpkgs is also the largest collection of packages in existence.¹ Anything you could want to throw into an image is likely already there.
The author of the blog post is already a Nixpkgs/NixOS contributor, too, so they might also be thinking "some of the improvements I make in shrinking dependency closures or finding deeper ways to turn off certain features are potentially upstreamable".
And even if the experiment is a wash, in exploring this kind of (ab)use of NixOS for generating tiny images, a NixOS user is also learning more about the dependency relations and other structure of the NixOS systems they're already running, which might be interesting or rewarding.
I'm not saying that as a Nix enthusiast I'd never use Buildroot or Yocto, but I understand the appeal of exploring how far NixOS can be pushed for this and how easy or hard it is to do.
While we're here we should also note that NixOS isn't really the Nix tool for this job anyway. There's a cool project called not-os² where minimization is one of the goals that has already succeeded in getting the image size down to < 50 MB.
There's also a project targeting commodity wifi routers called Liminix, which likewise takes some NixOS ideas and uses them to produce teeny-tiny images, (presumably even smaller than not-os, given many of the target devices don't include so much as 50 MB of flash).
Nah this kind of thing is pretty common for servers or little embedded computers. If you're always building the image on some other machine, there's no compelling reason to include that binary or it's dependency closure on the system.
Typically someone who goes for this indeed likes and runs "full fat" NixOS on some systems. What they want is to get really small images for some special purpose, like containers or disk images for a puny old Raspberry Pi, and build them using their usual NixOS workstation or server or whatever.
Packaging for Linux distros is about review, following standards and conventions, authority, and responsibility. (And maybe also sometimes patching for compatibility.) LLMs can sometimes help with some of the mechanical parts, but the curation and trust stuff not so much.
The NUR was sort of convenient before flakes were a thing, but now that there's a really common convention for sharing Nix code few use it. I bet most people who came across Nix in the last 4 years have never even heard of it.
"One namespace" is also technically true but doesn't work the same way with dnf or zypper as it does with pacman. dnf and zypper both make it easy to be explicit about the priorities of your repos and also to track which packages come from which repos and prevent that from changing. Plus openSUSE has a generously free public instance of the Open Build Service that you can easily use to host your own repos, and which hosts many individual repos you can add for specific purposes. When I ran openSUSE I always just ran my own repo there with only the extra packages I actually wanted, often just "forking" packages from repos hosted by well-known openSUSE developers so that I didn't have to manage updating the source packages myself but still didn't pull in the whole world from those repos and also didn't implicitly trust anything as loose as the AUR.
OBS is more like Ubuntu's Launchpad or Fedora's CO0R than the AUR. Random strangers can't take over the packages of others just because they go idle, and it's a bunch of separate repos, not one. Totally different trust model.
Zypper at least has a notion of "vendor", so you can arrange things so that only the handful of packages you care about will actually come from Packman.
Ubuntu actually has first-party repositories with proprietary codecs.
Nixpkgs is a pretty comprehensive monorepo of packages with a more normal review process than the AUR, and it includes non-free software as well, plus the model with flakes for third-party stuff is that you trust individual publishers for their little repos rather than one giant grab bag repo of unreviewed content like the AUR.
RPMFusion for Fedora kinda has a similar profile, in that it's a shared repo for various things unsuitable for the main one, but it follows more or less normal Fedora packaging and review standards, doesn't it?
Supply chain attacks are possible everywhere and some distros have particular weaknesses, but the AUR really is pretty much uniquely bad here.
> The problem with pull request is that they make it hard to review individual commits since they are geared towards reviewing the result of an entire branch at once. But the answer is not to share all the noise, it should be to encourage small atomic commits so you can review the early work before the entire feature/fix is complete.
Isn't that just a GitHub problem, as opposed to Phabricator, Gerrit, etc.?
> Most of the cloud platforms are open source. Linux, container, k8s…
Linux isn't a cloud platform and neither is Docker.
Kubernetes was created specifically to create a way in against AWS' de facto public cloud monopoly. The Cloud Native Compute Foundation is a classic "alliance of smaller players uses open-source and interoperability as a wedge against an incumbent that threatens hegemony".
> it’s entirely possible for someone to build and deploy their private cloud if they have the resources.
What is there for that, really? Basically just OpenStack?
Automation generally goes along with a transition to more "self-service" approaches that require the user to model internal states and workflows of whatever they're dealing with.
This is even true for things as seemingly non-technological as getting to your flight once you arrive at the airport. People who are used to dealing with a service desk might just show up with their printed ticket without even having looked at it, take it to the counter, and expect instructions on what to do next without having read or considered all the fields present on the ticket.
It's not just about understanding the technology, but sometimes about understanding the business, policies, whatever. When a human agent or customer service worker is handling that stuff for you (typical in the pre-computer age), you barely have to think about that stuff and even if you're told, it can be "in one ear, out the other". Automation very often means pushing a requirement of more understanding onto customers/users.
It is a programming language. That thing you write between single quotation marks when you invoke jq is a program. (And like with other programming languages, it's often useful to write your jq programs to files instead of always writing them inline in the shell.)
I love jq, though. It provides an extremely good language for its task, even if I often have to take a look at the manual when writing an interesting jq program.