amouat

No, not really, and I don't think you need to be snarky.

It may be an industry body, but it runs multiple community conferences and projects which support Open Source. A notable example in this case being the OpenSSF https://openssf.org/

The LF is not perfect, but I would expect them to come from an OSS and community angle on this.

My best understanding from reading this is a) where possible and b) where necessary. This is the Linux Foundation, so it must put OSS and community first, surely.

People talk about contributing financially, but how and to what end? Most projects aren't set up to accept or utilise donations. That said, I would say we should be providing all OSS projects with significant access to AI in order to review their codebases and PRs and hopefully relieve some of the maintenance burden. I know there are some initiatives in this area already.

I stopped reading in anger at "That’s not an accident; it was the point."

It's pretty disrespectful imo -- it feels like the reader's time is worth less than the author's.

That's what I thought, but in the 2nd para:

No Roman numerals. No Arabic numerals. No left-to-right reading direction. No assumed orientation. Something that works in a mirror, in zero gravity, in any language spoken on Earth or beyond it.

As other comments have pointed out, base 10 is a pretty big assumption though.

I noted "warfighter" as well. Never heard that before.

I played with some of these tools 12 years ago and created "dim", but it was really just Vim with limelight and goyo in a Docker container.

https://github.com/amouat/dim

There is something nice about having the editor as a separate command especially for writing.

I assume they just pretend to be the Googlebot so the site just gives the text.

Personal blog: adrianmouat.com

Seems to be England only. No results for Edinburgh.

It's all the same people. If you really don't know, a few of the incidents are here: https://www.bbc.co.uk/news/videos/c6299nrj76yo

The ladder is still there! See that pile of wood there? That's where we put the rungs. And if dig in that hole over there you might even find the extension we removed last week...

I'm pretty sure that's in development, it's just more difficult.

Also traksy e.g: https://traksy.uk/live/T+EDB+KGX+d+@2024-07-10T13:00/M+1+EDI...

Just wanted to say that I appreciate how well written this is. It does make a difference when an author can clearly and succinctly state their case.

I wrote a similar program once. To get it to be efficient I had to use a bunch of heuristics including scrabble scoring words, so it would prefer words with low scrabble scores which were more likely to fit in with other words.

The declining share price and profits is exactly what made it possible for IBM to buy Hashicorp. The license change didn't juice things -- it watered down the price. $6 billion is a snip compared to the $14 billion IPO valuation.

Fintan Ryan has a nice write-up here: https://medium.com/@fintanr/on-ibm-acquiring-hashicorp-c9c73...

From @stefantalpalaru (comment dead)

The software being used to illustrate an unrelated song: https://www.youtube.com/watch?v=L7UsnI_HQYM

Support him? Start by talking to him and seeing what he thinks is fair.

I'm using this quote:

"I love it but sometimes it feels like being a Morty on Rick’s adventure to the compilerland."

Sort of.

A few things though:

- we don't use scratch. Our base image is chainguard/static which includes certs and a few other things typically needed by apps.

- we have our own Linux distribution called Wolfi

- we don't "defeat scanners". We work with scanners and publish security advisories. They recognise Wolfi. You can definitely find some images of ours that have CVEs (especially if you have an old image lying around).

I did a short YouTube version of the announcement: https://www.youtube.com/watch?v=QuyBWDx21d0

I work at Chainguard.

In a nutshell we produce minimal container images with a low CVE count. In many cases they should be drop in replacements for the containers you are currently using.

This is particularly useful if your team uses a scanner like trivy/snyk/grype/Docker Scout and spends time investigating CVEs. Less CVES == less time investigating. It can also be critical in regulated environments.

Wolfi packages are served from https://packages.wolfi.dev/os which can be used with apk tools or apko.

The built Chainguard images are all on the cgr.dev registry.

Wolfi is completely OSS.

The policies regarding Chainguard Images have changed over time, so if there are docs that don't properly reflect this, please let me know and I'll get them updated.

I'm very sorry that we broke things for you.

To be clear, nothing has changed with Wolfi. Wolfi is an open source community project and everything is still available there: https://github.com/wolfi-dev/.

We have made changes to Chainguard Images - our commercial product built on top of Wolfi - which mean you can no longer pull images by tag (other than latest). Chainguard images are rebuilt everyday and have a not inconsiderable maintenance cost (and the money we make here directly helps us support Wolfi).

The easiest way to avoid this is to build the images yourself. You can rebuild identical images to ours using apko and the source files in the images repo e.g: https://github.com/chainguard-images/images/blob/main/images... (note you can replace package names with versioned versions). You can also just use a Dockerfile with the wolfi-base image to "apk add" packages. Full details are here: https://www.chainguard.dev/unchained/a-guide-on-how-to-use-c...

I agree that pinning is a best practice. The above blog explains that you can still do it using a digest, but I accept this isn't the simplest solution.

If I can help any more, please feel free to get in touch - you can find me most places including twitter https://twitter.com/adrianmouat

You might want to check out Wolfi and Chainguard Images. Wolfi is a Linux distro that we use to build minimal images that are roughly comparable to Alpine in size but, everything is compiled from source against glibc.

Our images come without a shell or pacakge manager by default, but there are -dev variants that include these.

https://github.com/wolfi-dev/ https://github.com/chainguard-images/images

I loved this book! It's about much simpler, generally turn based games though

We needed Wolfi to be able to create minimal (distroless if you like) container images based on glibc with 0 vulnerabilities. Turns out a lot of other people are interested in Wolfi for various reasons, and we're more than happy to work with them.

You definitely don't need to use Wolfi! But I would say, if you run containers you might want to check out Chainguard Images: https://github.com/chainguard-images/images

I think it's more subpackages such as -dev, -lib and -doc variants. These are defined as part of the parent package but count as distinct packages.

Yeah, it's definitely not a platform for running containers. Apologies for any confusion there.

But regarding being a full linux distro, we're really just missing the kernel and I could see that happening at some point in the future.

99% of Wolfi is the package repository. We've compiled all the software to run an OS from source against glibc and made it available as APKs (apart from the kernel). The major use case for this is composing container images using tools like apko.

When you run Linux containers, you're using the kernel from the host, but everything else is provided in the container i.e. file system, utilities etc. So you can effectively run Debian or Alpine on top of a Arch kernel by just doing "docker run debian" etc. And now you can also do "docker run cgr.dev/chainguard/wolfi-base".