I remember those from a 2016 paper, so it’s cool that there are open source implementations of it.
Although my pet peeve is that I think there shouldn’t be such things as container registries. We should just have general purpose storage with differential compression, which can store containers or other data.
For example pulling containers on sourcehut 10x slower because I guess there are no container caches on the local network, like there are in most clouds. But I think that is the “fault” of the whole tightly coupled container architecture.
Does anyone store containers in a place other than a registry? It looks like there is an optional IPFS backend, and I’m interested if anyone uses it, although my suspicion is that it probably works very poorly and slowly (since I mostly hear bad things about how well IPFS works)
I would like to experiment with storing container metadata in git and then the layers on a plain HTTP server (e.g. served by Nginx). I don’t see any reason that’s not possible? What does the container registry really add?
Tools to construct a read-only container ‘registry’ served by plain Nginx
Oh nice that’s basically what I’m looking for ! It doesn’t seem widely used, which makes me think there must be some downside like performance … but it’s worth checking out and understanding why, thanks.
edit: I guess the obvious downside is being read-only, which makes sense since plain HTTP has no way to persist data. So you can’t do docker push. But yeah I still think there is some potential to get rid of docker registries.
One bummer here is that it doesn’t seem to be fully static; it relies on a bit of custom nginx config to do URL rewriting and to munge error pages;. It doesn’t result in something you could just dump into an S3 bucket or moral equivalent - I’m not sure if such a thing is even possible, or the endpoints required by the clients are such that at least a little logic is required.
The registries add the distribution API. Most registries implement anything beyond the API calls that aren’t static (e.g. /v2/<name>/tags/, various forms of auth, the push flow) by redirecting to static storage.
Container registries are general purpose storage if you squint (and there are people working on making it “official”), with the added benefit of being able to programmatically understand how the pieces are related.
I thought most of the point of CentOS was “RHEL, but basically free”. If it’s going to be “what RHEL will be in the future”, then a lot of the value proposition goes away. Why not Fedora at that point?
My interpretation is that this will be a new stepping stone for changes coming from Fedora before making their way into RHEL. Nevertheless that too doesn’t sound differentiated enough to be sustainable.
While the Stream lifecycle is shorter than CentOS Linux, it is still 5 years. Stream will still keep the same kernel + rh patches for the full lifecycle, so very different from Fedora model. Stream will be a rolling release for the next minor release of RHEL.
According to the Stream page it’s intended to be “positioned as a midstream between Fedora Linux and RHEL”.
CentOS started out as an independent community project, but since 2014 it’s effectively been part of Red Hat, which owns the trademark and employs most of its developers. From Red Hat’s point of view all of this makes a lot of sense (Red Hat’s acquisition by IBM probably pays a part in this shift). But for people like you and me who want a “free RHEL” … yeah, it’s not a great change.
Free doesn’t pay IBM nothing. They get with this a rolling beta release where they iron out bugs. The CentOS users get…well they get nothing. Maybe Scientific Linux or FreeBSD like other commenters suggested.
That’s not quite true. FreeBSD is at either extreme, depending on what you’re looking at:
The base system, which includes the kernel, libc, and a bunch of core libraries and tools, is ABI-stable across an entire major release (supported for 4-5 years, I think). Anything written targeting these is guaranteed to keep working and get security updates for new versions. You can write a kernel module for FreeBSD X.0 and it will keep working for all FreeBSD X.y. Any device ioctl from the base system will keep working in the same way. Anything written using control interface (e.g. the the network configuration interfaces used by ifconfig and friends) has the same guarantees. Between major releases:
All syscalls will keep working via COMPAT interfaces in the kernel (which may optionally be compiled out for small / legacy-free systems).
Control interfaces and device ioctls may change in any way.
Core base system libraries will usually have symbol versioning and so will support old versions. Where there’s a complete ABI break, there’s a userspace compat package that installs the old version, though this may not get security updates.
The ports system, which contains all third-party software, is rolling release. If you depend on something like ffmpeg or Qt and want to avoid new versions then you need to either maintain a separate install of the version that you depend on (which is quite easy to do with a fork of the ports tree and configuring poudriere with a different LOCALBASE for all of your fixed-version things), bundle it with your program, or persuade the port maintainer to support multiple versions (a few things do this anyway. I think there are typically 3-4 versions of LLVM in the tree because a bunch of things depend on older ones).
In my experience, it’s pretty rare for software to break across even FreeBSD major version upgrades, unless it uses some third-party shiny buzzwordy dependency from ports that doesn’t provide any backwards compatibility guarantees.
The base system, which includes the kernel, libc, and a bunch of core libraries and tools, is ABI-stable across an entire major release (supported for 4-5 years, I think).
CentOS is supported for ~10 years, if I’ve understood everything correctly. You also get SELinux and a bunch of other features that are nice for different reasons.
FreeBSD is nice in many, many ways, but it is not a replacement for CentOS.
Yes, but ports/pkg is always a rolling (or semi-rolling if you go with quarterly updates) which differs greatly from the CentOS way of doing it. I’m not saying it’s good or bad, it’s just different.
With CentOS/Red Hat approach you end up with very outdated packages very quickly.
Yes, agreed. But you get security updates for them as well.
With FreeBSD approach you always have up-to-date packages.
Yes, and that can be a problem in itself. Imagine that you can’t upgrade to a newer version due to breaking changes, but a new security vulnerability pops up. What do you do?
I work in jurassic operations, it’s terrible and everything we run on is far too old. But we are not a developing organisation, we barely know anything about anything right now. Organisations like mine will always chose CentOS/similar if we get support for it, and we are willing to pay stupid amounts of money.
I used to work in software development as a tester. But not even in a team with virtually no technical backlog (like really!) would we ever chose to use a rolling distribution. That is just wasted work, effort, and money. Imagine trying to reasonably test supported versions for your app if using a rolling distribution.
You can write a kernel module for FreeBSD X.0 and it will keep working for all FreeBSD X.y
Only if you recompile. There is NO stable kernel ABI. Currently on 12.2 people must compile the GPU drivers locally, because the binary package is produced on 12.0 or 1 or whatever and it does not work.
I believe the GPU drivers are something of a special case here: They depend on the LinuxKPI module, which does not have the same stability guarantees as the rest of the kernel because it tracks Linux kernel interfaces that can change every minor release of the Linux kernel. For the rest of the kernel, they are much stronger binary-compat guarantees. There’s a process before branching each major release of adding padding fields to a bunch of kernel structures so that anticipated functionality can be added without breaking the KBI. This is the reason that a lot of Adrian’s work on WiFi didn’t get MFC’d: it depended on adding extra fields to structures at various places in the WiFi stack, which would have been KBI-breaking changes and so were not allowed into -STABLE without rewriting.
I know, I’m just saying that people who habe been using CentOS because “it’s redhat but free” might want to move to sometging else. People who needed CentOS for ABI compatibility will have to work with IBM/Redhat on this. Because RedHat doesn’t want to work for free, obviously.
We have our own open days this week-end at CERN. I’ll be volunteering on board games workshop to teach young kids basic programming concepts. If anyone around pass by the datacentre area to say hi.
When enabling 2FA, you are asked for your current password.
However on the main setting screen, you can change your password without providing the current one.
Finished The Ethical Slut, which left a mixed taste in my mouth (shush). Perhaps it’s just the times and communities that I’m aware of, but a lot of the book seemed to be defensive and oddly patronizing about what it covered (the practice of polyamory). During its initial publication, it kinda makes sense that they’d pick language and constantly reaffirm their readers, but at this point it just reads as kinda bubbly, overly sentimental, and a bit out of touch with the times.
That said, I’d still reccommend it to others for the same reason it was reccommended to me: exposure to a very different way of thinking about people and relationships.
Other than that, continuing my grind through the Programming Phoenix book. Sad thing is that anything I learn from it will probably be out-of-date in like six months, but hey, might as well try. :)
Anybody have good recs for military fantasy or science fiction? I need some popcorn reading (and yes I’ve read everything related to the Slammerverse). Maybe I should pick up one of the translations of the Legend of Galactic Heroes novels…?
I love Egan’s work. Have you had a chance to read Permutation City? Absolutely fantastic work about cellular automata and the hard problem of consciousness.
Great article!
FWIW I’m using docker and podman with the same images and it works well. Our CI runs on two configurations the same way:
There were some minor permissions issues on the mounts, but it wasn’t hard to work around.
So I’m glad that there are two implementations, so I don’t get locked into Docker.
Some of the links led me to these lazy pulling projects with associated file formats.
https://github.com/containerd/stargz-snapshotter
https://github.com/containerd/nerdctl
I remember those from a 2016 paper, so it’s cool that there are open source implementations of it.
Although my pet peeve is that I think there shouldn’t be such things as container registries. We should just have general purpose storage with differential compression, which can store containers or other data.
For example pulling containers on sourcehut 10x slower because I guess there are no container caches on the local network, like there are in most clouds. But I think that is the “fault” of the whole tightly coupled container architecture.
Does anyone store containers in a place other than a registry? It looks like there is an optional IPFS backend, and I’m interested if anyone uses it, although my suspicion is that it probably works very poorly and slowly (since I mostly hear bad things about how well IPFS works)
I would like to experiment with storing container metadata in git and then the layers on a plain HTTP server (e.g. served by Nginx). I don’t see any reason that’s not possible? What does the container registry really add?
https://github.com/NicolasT/static-container-registry is a thing but I haven’t gotten around to trying it so no idea if it’s any good
Oh nice that’s basically what I’m looking for ! It doesn’t seem widely used, which makes me think there must be some downside like performance … but it’s worth checking out and understanding why, thanks.
edit: I guess the obvious downside is being read-only, which makes sense since plain HTTP has no way to persist data. So you can’t do docker push. But yeah I still think there is some potential to get rid of docker registries.
One bummer here is that it doesn’t seem to be fully static; it relies on a bit of custom nginx config to do URL rewriting and to munge error pages;. It doesn’t result in something you could just dump into an S3 bucket or moral equivalent - I’m not sure if such a thing is even possible, or the endpoints required by the clients are such that at least a little logic is required.
There are some tools in https://github.com/ostreedev/ostree-rs-ext/ for importing and exporting container images from an ostree repo; it’s on my list of things to try out.
The registries add the distribution API. Most registries implement anything beyond the API calls that aren’t static (e.g.
/v2/<name>/tags/, various forms of auth, the push flow) by redirecting to static storage.Container registries are general purpose storage if you squint (and there are people working on making it “official”), with the added benefit of being able to programmatically understand how the pieces are related.
Check also cvmfs https://cvmfs.readthedocs.io/en/latest/cpt-containers.html
I thought most of the point of CentOS was “RHEL, but basically free”. If it’s going to be “what RHEL will be in the future”, then a lot of the value proposition goes away. Why not Fedora at that point?
My interpretation is that this will be a new stepping stone for changes coming from Fedora before making their way into RHEL. Nevertheless that too doesn’t sound differentiated enough to be sustainable.
While the Stream lifecycle is shorter than CentOS Linux, it is still 5 years. Stream will still keep the same kernel + rh patches for the full lifecycle, so very different from Fedora model. Stream will be a rolling release for the next minor release of RHEL.
Actually CentOS patches will go to rhel
According to the Stream page it’s intended to be “positioned as a midstream between Fedora Linux and RHEL”.
CentOS started out as an independent community project, but since 2014 it’s effectively been part of Red Hat, which owns the trademark and employs most of its developers. From Red Hat’s point of view all of this makes a lot of sense (Red Hat’s acquisition by IBM probably pays a part in this shift). But for people like you and me who want a “free RHEL” … yeah, it’s not a great change.
Free doesn’t pay IBM nothing. They get with this a rolling beta release where they iron out bugs. The CentOS users get…well they get nothing. Maybe Scientific Linux or FreeBSD like other commenters suggested.
FreeBSD is essentially a “rolling release” distro; it’s a fine system but not really a replacement for CentOS’ use case.
That’s not quite true. FreeBSD is at either extreme, depending on what you’re looking at:
The base system, which includes the kernel, libc, and a bunch of core libraries and tools, is ABI-stable across an entire major release (supported for 4-5 years, I think). Anything written targeting these is guaranteed to keep working and get security updates for new versions. You can write a kernel module for FreeBSD X.0 and it will keep working for all FreeBSD X.y. Any device
ioctlfrom the base system will keep working in the same way. Anything written using control interface (e.g. the the network configuration interfaces used byifconfigand friends) has the same guarantees. Between major releases:ioctls may change in any way.The ports system, which contains all third-party software, is rolling release. If you depend on something like ffmpeg or Qt and want to avoid new versions then you need to either maintain a separate install of the version that you depend on (which is quite easy to do with a fork of the ports tree and configuring poudriere with a different
LOCALBASEfor all of your fixed-version things), bundle it with your program, or persuade the port maintainer to support multiple versions (a few things do this anyway. I think there are typically 3-4 versions of LLVM in the tree because a bunch of things depend on older ones).In my experience, it’s pretty rare for software to break across even FreeBSD major version upgrades, unless it uses some third-party shiny buzzwordy dependency from ports that doesn’t provide any backwards compatibility guarantees.
CentOS is supported for ~10 years, if I’ve understood everything correctly. You also get SELinux and a bunch of other features that are nice for different reasons.
FreeBSD is nice in many, many ways, but it is not a replacement for CentOS.
If you need SELinux on FreeBSD then you have MAC (Mandatory Access Control) and also a SEBSD module:
You also have other security mechanisms on FreeBSD like Capsicum.
Didn’t know about MAC, cool! Not sure how I’ve missed it :-)
One nice thing with SELinux is that it’s included and enabled by default, not kernel patches et c to apply.
Is that still the case?
FreeBSD can be rolling release when you track STABLE or CURRENT and can also NOT be rolling release if you just use RELEASE version.
Yes, but ports/pkg is always a rolling (or semi-rolling if you go with quarterly updates) which differs greatly from the CentOS way of doing it. I’m not saying it’s good or bad, it’s just different.
With CentOS/Red Hat approach you end up with very outdated packages very quickly.
With FreeBSD approach you always have up-to-date packages.
You can also use Poudriere to create and maintain your own packages versions: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-poudriere-build-system-to-create-packages-for-your-freebsd-servers
Yes, agreed. But you get security updates for them as well.
Yes, and that can be a problem in itself. Imagine that you can’t upgrade to a newer version due to breaking changes, but a new security vulnerability pops up. What do you do?
I work in jurassic operations, it’s terrible and everything we run on is far too old. But we are not a developing organisation, we barely know anything about anything right now. Organisations like mine will always chose CentOS/similar if we get support for it, and we are willing to pay stupid amounts of money.
I used to work in software development as a tester. But not even in a team with virtually no technical backlog (like really!) would we ever chose to use a rolling distribution. That is just wasted work, effort, and money. Imagine trying to reasonably test supported versions for your app if using a rolling distribution.
Only if you recompile. There is NO stable kernel ABI. Currently on 12.2 people must compile the GPU drivers locally, because the binary package is produced on 12.0 or 1 or whatever and it does not work.
I believe the GPU drivers are something of a special case here: They depend on the LinuxKPI module, which does not have the same stability guarantees as the rest of the kernel because it tracks Linux kernel interfaces that can change every minor release of the Linux kernel. For the rest of the kernel, they are much stronger binary-compat guarantees. There’s a process before branching each major release of adding padding fields to a bunch of kernel structures so that anticipated functionality can be added without breaking the KBI. This is the reason that a lot of Adrian’s work on WiFi didn’t get MFC’d: it depended on adding extra fields to structures at various places in the WiFi stack, which would have been KBI-breaking changes and so were not allowed into -STABLE without rewriting.
I know, I’m just saying that people who habe been using CentOS because “it’s redhat but free” might want to move to sometging else. People who needed CentOS for ABI compatibility will have to work with IBM/Redhat on this. Because RedHat doesn’t want to work for free, obviously.
I am late to the party, but anybody have opinion/experience on https://github.com/pinterest/knox ?
We have our own open days this week-end at CERN. I’ll be volunteering on board games workshop to teach young kids basic programming concepts. If anyone around pass by the datacentre area to say hi.
For Java / Python we have one. You need to have a passport from one of the member states. 5 years contract. (https://careers.cern/content/member-states) https://jobs.smartrecruiters.com/CERN/743999674157079-software-engineer-be-co-aps-2018-84-ld-
I think this is the correct link for member states: https://home.cern/about/member-states
Thanks it is now corrected in the job advert.
Nobody mentionned https://lesspass.com/, I was thinking of giving it a go to replace pass for non critical web password.
Unix pass (https://www.passwordstore.org/)
I also use pass with keybase git.
Great news ! One small note:
When enabling 2FA, you are asked for your current password. However on the main setting screen, you can change your password without providing the current one.
Good catch, I’ll file a bug to make password changes require the current password as well.
Finished The Ethical Slut, which left a mixed taste in my mouth (shush). Perhaps it’s just the times and communities that I’m aware of, but a lot of the book seemed to be defensive and oddly patronizing about what it covered (the practice of polyamory). During its initial publication, it kinda makes sense that they’d pick language and constantly reaffirm their readers, but at this point it just reads as kinda bubbly, overly sentimental, and a bit out of touch with the times.
That said, I’d still reccommend it to others for the same reason it was reccommended to me: exposure to a very different way of thinking about people and relationships.
Other than that, continuing my grind through the Programming Phoenix book. Sad thing is that anything I learn from it will probably be out-of-date in like six months, but hey, might as well try. :)
Anybody have good recs for military fantasy or science fiction? I need some popcorn reading (and yes I’ve read everything related to the Slammerverse). Maybe I should pick up one of the translations of the Legend of Galactic Heroes novels…?
My favorite science fiction book is Diaspora by Greg Egan, and I recommend it whenever I can. It’s hard sci-fi, though.
For popcorn sci-fi, I like everything by Brian Daley. He’s written many Star Wars novels, but he writes other stuff too.
I just started Distress by Greg Egan and enjoyed it so far, even if for a non native english speaker the first chapter is challenging to keep up with.
I love Egan’s work. Have you had a chance to read Permutation City? Absolutely fantastic work about cellular automata and the hard problem of consciousness.
Not yet! So far I’ve only read Diaspora and Teranesia, but I plan to read his other work. Books pile up so quickly…
If you liked diaspora, you will also enjoy permutation city and schild’s ladder.
If you haven’t read the Imperial Radch trilogy by Anne Leckie, you should check it out.
A colleague found this, I though I would share : http://savvastjortjoglou.com/nba-shot-sharts.html https://github.com/savvastj/nbashots