Hacker News new | past | comments | ask | show | jobs | submit login

Amen.

Sadly it seems in a sense RH is funding both sides at the same time, as many of their employees are the very source of the "exciting" developments happening in the Linux ecosystem these days.

Thing is though that in a sense the Linux community has painted itself into a corner. Thanks to the likes of RHEL, Ubuntu LTS and Debian Stable, there is little reason for the upstream to be anything but "exciting".




Out of curiosity, what are the exciting developments happening in the Linux ecosystem these days?


Checkpoint-restore of processes (CRIU) is a fairly cool technology that is quite unique to Linux, and has gotten a lot of work in recent years. eBPF (both for seccomp and tracing) is also quite exciting in terms of its applications. User namespaces are also allowing for developments such as rootless containers. There's also some interesting stuff for trusted computing that are happening with IMA and TPM developments in general.

In user-space there's even more interesting developments, you just have to look a little closer. ;)


> Checkpoint-restore of processes (CRIU) is a fairly cool technology that is quite unique to Linux

DragonFlyBSD has had process checkpointing for more than 10 years.

https://www.dragonflybsd.org/cgi/web-man?command=checkpoint&...

While the functionality is admittedly & unfortunately quite limited, there are no technological reasons this couldn't have been furthered in the meantime given sufficient funding/dev time, etc.


CRIU has so many more features and is so much more powerful that I don't think it's a fair comparison at all to make. You might argue that you could have implemented all of the features on another system like DragonFlyBSD (and in fact I would argue it would've been easier than doing it on Linux) but I don't see why that statement matters. What makes CRIU "unique" is that it does have those features and it is used on production systems for live migrations. I remember there used to be very old Linux tools that did the same thing in the same timeframe as checkpt, but they weren't widely used either because they didn't support any of the things CRIU does.

For example, not being able to restore sockets of any form (such as TCP sockets) is a massive limitation that CRIU doesn't have. userfaultfd allows for CRIU to have a slave process that is used as a source of lazy page loading from another machine (allowing for viable cross-host checkpoint/restore with on paper no downtime). And you can use CRIU to checkpoint/restore entire containers (DragonFlyBSD doesn't have Jails, but it looks like you can't even checkpoint process trees).


CRIU looks amazing, live-migration of LXC containers :)


There are rough edges to be worked out before we arrive at solidly productionised systems, but I believe Red Hat and Docker are both heading in that direction.

Mind you, ask yourself: why do you need it?

If it's for apps, isn't the point of these platforms to not need to care about individual instances?

If it's for data, don't you have an existing way to manage HA or parallelism?


You’re making assumptions that I’m thinking of Docker, which couldn’t be further from the case. I’m looking at using LXC/LXD to replace full-fat VM’s for highly stateful, single-instance services - game servers. Being able to live-migrate a LXC container to drain a host for maintenance is indeed a useful feature to have.


I usually assume all sorts of things[0]; I've become accustomed to living in a world where strict division between state and logic is assumed, even for relatively intensive stuff like trading platforms and very large ticketing systems.

Kubernetes has been more open to absorbing sticky, less-factored workloads than more opinionated platforms are. Red Hat have definitely made that point to folk whenever we and they are competing for business.

I had occasion to look at CRIU relatively closely in recent times. It is, as I said, early days, with annoying corner cases that need someone to patiently fix and polish (we ran into problems with networking, environment variables and process IDs).

In your case it will probably become attractive in the next year or two, because both Red Hat and Docker Inc (which is why I mentioned Docker) are touting checkpoint migration as a feature and I expect both will devote engineering effort to productionise it.

As an aside, if you're using the JVM, there was a really clever paper on coordinating the JVM G1GC and CRIU to greatly improve migration time: http://www.gsd.inesc-id.pt/~rbruno/publications/rbruno-middl...

edit: [0] Which is why as usual I am a dimwit for starting with answers instead of questions.


Yep, every time I hear people get excited about live migration of containers I have to give them a sideways look. If you are running only one instance, than availability must not have mattered that much to you.


Flatpak is pretty damn awesome - a layered container-like attempt at tackling application distribution and Dependency Hell.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: