darren0

I've been unhappy with the direction of Ubuntu for awhile, but having said that it's still the best collection of packages that install with fairly sane defaults for desktop/laptop. I've adopted a model of starting with ubuntu-minimal installation and just installing the debs I want (disable recommended packages by default). This gives me a fairly reliable base from Ubuntu but a system assembled how I want (except systemd, can't avoid systemd).

I honestly don't think most people care about this and have already forgotten about it.

I tried going this route and the desktop experience was rough. Debian doesn't seem to have reasonable defaults for fonts so I spent way too much time learning and configuring all the font systems. So literally just the font configuration was enough for me to switch back to Ubuntu and just only install the stuff I like (no snap, gnome).

Hmm... commoditization vs commodification?

Clearly this project isn't presented well as most comments don't seem to understand that the primary use case of this tool is to use P2P technology to make "docker pull" more efficient.

k3s author here. With user namespace and rootless support it is getting closer to k3s running in crostini, but nobody is really working on this. I was a big fan of crostini when it came out but the insistence on lxc and user namespaces makes it too limited and wouldn't recommend it if you work with containers.

"Firecracker provides a rate limiter built into every microVM. This enables optimized sharing of network and storage resources, even across thousands of microVMs."

Probably the most interesting feature.

2 of the 15 new cases in Japan are children. Seems like a reasonable precaution as children have a lot more physical contact than adults (example, lice spreads in children more easily).

No, I'm referring to the volume plugin framework. Volumes in general are just paths on a disk, that is simple enough. More info https://docs.docker.com/engine/extend/plugins_volume/

rkt is really a fundamentally different architecture and approach than Docker, but more importantly a large unmaintained code base. k3c is really a fairly light layer on top of CRI, containerd and buildkit. So the maintenance burden is very low and quality should be high given it's using the same technology as production Kubernetes clusters.

Depends on what your use case is, but if you are just focused on creating containers then swarm, libnetwork, volume drivers, plugin framework, "docker app", stacks, and buildx are some examples of features of Docker that aren't needed.

This tool is intended to be used outside of Kubernetes. Before you can deploy something on Kubernetes you first need to build a container. Docker is the primary tool used for building and developing containers. The intention of k3c is to replace Docker with a smaller tool that has the required parts of Docker that people use for development. And to make that tool more complimentary to the larger k8s ecosystem.

I bought a pixelbook last year as I was excited to play with the early native Linux integration. The technology that has been built is an amazing amount of work (crosvm, Wayland support, etc) but at the end of the day it's really only useful for simple use cases. This is a common theme for everything in ChromeOS.

I've given up on ChromeOS for the time being as been capable of any serious work I do. The more frustrating part is my kids have Chromebooks and as they've gotten older they've become a real detriment. They can't accomplish anything on them beyond school work. My kids are showing a lot of interest in graphic design and programming and both tasks are too hard or almost impossible on a Chromebook.

The basis of this article seems to be the statistic. "33% of U.S. carbon dioxide emissions from electricity generation". What does that have to do with gas burned in your home? The statistics is for gas burned to create electricity. That seems like significant different things.

It's somewhat ironic that you can't even trust this article. There's an obvious bias towards a "power struggle" view of the world's problems. The issue with the current state of affairs is essentially assumed to be because of billionaires and corporate consolidation. The solution presented is then to give more power to the people. Neither point is substantiated by fact.

One could just as easily argue that the state of the media is due to a failure to adapt to the internet in which blogs, Twitter, and social media become peoples primary source of information. So the "power of the people" could have in fact caused this issue. This also being a conjecture.

The only point in this article that is well substantiated is that trust in media is low and I feel this article is perfectly on trend.

k3s also shines in dev/test/CI. It's smaller and spins up faster and has specific features to preload applications on startup. It's a single ~50mb binary also so it's fast to download and run in CI. Many users have moved from kind to k3s in CI because of its speed, flexibility, and simplicity.

k3s has no direct relationship to systemd, I'm not sure what things not working you are referring too.

k3s has full flexibility to change any k8s option or component, it merely defaults to settings to meet it's goals of being a simple, lightweight, and secure distro.

Disclaimer: k3s creator

Kind is intended to be a development tool to run fully upstream clusters using kubeadm in Docker containers.

k3s is a custom distro that is oriented towards lightweight environments. The scope of k3s and kind are different (distro vs tool to run k8s in docker). There is another project called k3d (https://github.com/rancher/k3d) that more directly compares to kind. k3d will run k3s clusters in Docker. k3d creates clusters significantly faster and uses less mem/cpu resources than kind.

I really think most people want a traditional SQL database that has a stream query that gives real time updates. I honestly don't know enough about databases to understand why that isn't a simple enough feature to implement.

If you program C++ give it a shot. For all other languages stay far from it.

I have almost a violent reaction to gnome application UX. I find it terrible. It is so hard to figure out how to do anything.

Systemd has always been hyper focused on the desktop/laptop experience, and then justified for other use cases. Desktop is by a rediculously huge margin the least important use case. So something like systemd-homed does not make any sense in a server setup but I can basically guarantee it will be forced upon server setups, just like systemd-resolvd was.

Ironically the very small percentage of users that use Linux on the desktop tend to be of the more die-hard variety that don't welcome systemd's view of the world.

In the end systemd is an extremely bad steward of Linux.

I don't understand how a contractor unionizing gives them any more power over Google. Either which way they are a contractor and have to negotiate a contract. This article seems to imply the workers have an issue with Google, but unionizing just gives them power over HCL. So are they not happy with HCL?

You can keep your cluster after they are gone if you were already using eks, gke, or aks. Then just import that cluster into another multi cluster manager.

(Disclaimer: I work for Rancher)

This isn't true. For example containers use pivot_root instead of chroot or MS_MOVE because there are specific security issues with keeping a reference to the parents mount table.

If you care about security there is no reason to use chroot on Linux, there are better approaches.

To understand just how trivial it is to escape a chroot with root, just run "nsenter -m -t $$" and your out.

Yes but slirp isn't used in a production grade setup. It's more of a simple slow default that's guarantees to work, so it's used mostly in development setups.

There is also TinyEMU that has the added benefit that a JavaScript version is available that runs in the browser.

https://bellard.org/tinyemu/

We will update the docs over the next days, but in short yes. It's designed primarily so that people can build there own images.

The best fix is to upgrade to 18.09.2. For those that can't do that immediately, backported versions of runc for Docker releases going back to 1.12.6 are available from Rancher at https://github.com/rancher/runc-cve. But please only do that as a temporary workaround until you can properly upgrade to 18.09.2.

Please patch if you don't 100% trust all users on your host.