TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Learning about Bootc

63 点作者 nikodunk2 个月前

12 条评论

udev40962 个月前
&gt; Bazzite, was a better experience than SteamOS<p>Bazzite is so much worse than SteamOS in terms of usability. I installed it on my deck and it was full of bugs, the ISO image size is the biggest I have ever seen (~10G), KDE crashes way too often, invoking keyboard doesn&#x27;t work half the time, comes with so much bloat (waydroid being one of them). It&#x27;s a joke to even call it a better &quot;experience&quot;.<p>Also, immutability absolutely sucks for daily drive. I have to wait for 10mins for rpm-ostree to install a package while a normal distro can do it in seconds. Immutability makes sense in case of routers, VMs running core services (such as a reverse proxy, dns, etc)
评论 #43460301 未加载
评论 #43458894 未加载
评论 #43461470 未加载
MortyWaves2 个月前
&gt; Simple, right? This copies a file to run a Nginx container as a quadlet and a config into the &#x2F;etc folder. This brings GitOps to my OS. With this whenever my machine starts, whether for the first time or millionth time, its going to be configured to work exactly as expected with no extra work or additional configuration.<p>That isn&#x27;t GitOps. That&#x27;s immutable file systems. Make it as immutable as you want, that has nothing to do with GitOps. You need the other half of the story, the infrastructure-as-code and the deployment.
sevensor2 个月前
&gt; There is no denying that most applications are shipped today as a Docker container and most developers have some experience with them<p>Author and I move in quite different circles. This is not my experience of applications or of software developers.
评论 #43468207 未加载
account-52 个月前
After reading the article I don&#x27;t get why I need to know about bootc. It&#x27;s something to do with immutability like a couple of OSs I&#x27;ve never used, of which I&#x27;ve only heard of 1.
评论 #43458119 未加载
评论 #43459405 未加载
评论 #43458266 未加载
dailykoder2 个月前
Sounds interesting, but since I haven&#x27;t been in touch much with this topic I ask myself: Does this have any benefit for my personal home-computer usage?<p>For a long time I have the urge to try out Nix, because I clutter up my computer way too fast and therefore often get mad and just install a fresh system. This works fine with my files, but there are always applications which I forget about and forget to save configs. So having this all in a git repo to spin it up fast would be nice. Is bootc, fedora silverblue and so forth trying to achieve something similar?
评论 #43458434 未加载
hamandcheese2 个月前
Ahh, just what I need, shoddy Dockerfiles to define not only my applications but now my whole OS!
评论 #43458867 未加载
评论 #43460273 未加载
yjftsjthsd-h2 个月前
I <i>want</i> to know about - or rather, use - bootc. Unfortunately, the problem is this:<p><pre><code> FROM quay.io&#x2F;fedora&#x2F;fedora-bootc:41 </code></pre> If you&#x27;re using Fedora (or maybe RHEL) and happy to use premade base images then it&#x27;s apparently great. The moment you step off that happy path, good luck; nobody has written the code, and the docs are inadequate to do it yourself. Or at least, they were for me; I wanted to make an Alpine bootc image but everything was shades of &quot;now start from this Fedora image, install this magic package with the systemd integration, invoke the rpm wrapper, and it all works!&quot; which was kinda a problem trying to integrate with a system that had none of those things. It was annoying because I&#x27;m pretty sure the tech is actually distro agnostic, but it was too underdocumented to use.
评论 #43467549 未加载
MiiMe192 个月前
&gt;They can turn it on and know it will boot properly without having to worry about things users had to worry about in the past like drivers, kernel mods, or new packages breaking things – the ghosts of Linux Desktop Past.<p>I mean, you still need to setup your bootc image to contain those drivers and everything like that. Once you set up Debian, it will always just boot right too. This just seems like Yet Another Immutable Distro™. I guess stuff like this is a bit nicer for things like like game consoles, where you aren&#x27;t actually using it like a computer and installing &quot;normal&quot; software, but I don&#x27;t really see the how this will change the Linux desktop.
eriksjolund2 个月前
If you want to know why bootc is needed check this list of goals: <a href="https:&#x2F;&#x2F;containers.github.io&#x2F;bootable&#x2F;" rel="nofollow">https:&#x2F;&#x2F;containers.github.io&#x2F;bootable&#x2F;</a><p>I found that URL by following the link in &quot;bootc is the key component in a broader mission of bootable containers.&quot;<p>(<a href="https:&#x2F;&#x2F;bootc-dev.github.io&#x2F;bootc&#x2F;intro.html" rel="nofollow">https:&#x2F;&#x2F;bootc-dev.github.io&#x2F;bootc&#x2F;intro.html</a>)
linuxftw2 个月前
bootc is a great evolution for rpmostree IMO. Fedora Atomic had decent build tooling, but all of that was thrown away for Fedora CoreOS due to the ignition use. I was never a can of Fedora CoreOS but I really liked Atomic.<p>This seems to be a sensible pivot back the other direction. We don&#x27;t need the CoreOS parts that never really delivered any value. And now building an system image is a simple as writing the container file.<p>This way of doing things probably offers little to the average Linux user. However, it&#x27;s a great model for distributing &#x27;appliance&#x27; images, or having transactional updates on your servers. In the cloud, transactional updates aren&#x27;t that big of a deal, you can do a rolling replace of your instances. On bare metal machines, doing in-place transactional updates is a big win.<p>Rancher also has an interesting project called Elemental. It seems to be a little more portable for other distros, but I haven&#x27;t played around with it.
评论 #43460319 未加载
stakhanov2 个月前
I&#x27;ll offer a less charitable framing of the whole topic of immutable &#x2F; atomic distros: This is pretty much Linux distributors deciding they want to stop doing their job (or redefine what their job is to a much smaller scope). -- I&#x27;m not saying it&#x27;s not justifiable that the ecosystem may need to be reshaped in that way. I&#x27;m just cautioning people from drinking the “this is the future and the future looks bright” Kool-Aid all too easily.<p>The job of making a Linux distribution has always been what, in an old-fashioned term, used to be called “system integration” work. They would start with a bewilderingly huge array of open-source packages, each being developed without any centralized standard or centralized control over what the system actually looks like. Then they would curate a collection of build recipes and patches for those packages.<p>The value a distro delivers for the user is that, for any package “foo” that their heart desires, a user can just say “apt install foo” and it&#x27;ll “just work”. There will be default configuration and patches to make foo integrate perfectly with the rest of the system.<p>The value a distro delivers for package maintainers is: “Don&#x27;t worry about the packaging. Just put your code out as open source, and we&#x27;ll take care of the rest.”<p>The job of a distributor is extremely difficult, because of all the moving parts: People select their hardware, their packages, and they mess with the default configurations. It is no wonder at all that Linux distributions don&#x27;t always succeed in their mission to truly deliver on this. But it&#x27;s a huge engineering achievement that they work as well as they do, and I think we shouldn&#x27;t lightly give up on that achievement.<p>What we have now is basically distros going: Awwwww. Fuck it. This is too hard. I&#x27;m done with this. You know what? Instead of “any package your heart desires”, you get a fixed set of packages. The ones that everyone needs regardless of what they actually do with their computer. Instead of being allowed to mess with your configuration, we&#x27;ll make your rootfs read-only. (In the case of SteamOS): Instead of doing our best to make it work on your hardware, we&#x27;ll tell you precisely which piece of hardware you&#x27;ll need to buy if you want our software to run on it. User: Well, that&#x27;s additional money I need to spend. And, how do I install my favourite app “foo”? The one I need to actually get useful work out of my computer? Distro: Don&#x27;t worry, we&#x27;ve got you covered. We&#x27;ll provide a runtime for distrobox and flatpaks. Package maintainer of “foo”: How do I get my package out in a way that perfectly integrates with distros? Distro: Make a container. Congratulations: This is additional work you have to do now, that you didn&#x27;t have to do before. And about that idea of perfect integration: You can kiss that goodbye. User: I don&#x27;t know. I&#x27;m also in favour of integration. Distro: That&#x27;s alright. You can share and unshare stuff between containers and the host system. This, of course, is additional work you didn&#x27;t have to do before. Less work for me, more work for everyone else. The future looks so bright.
评论 #43458390 未加载
评论 #43458956 未加载
评论 #43458963 未加载
评论 #43459056 未加载
nimbius2 个月前
this is the absolute nadier of container&#x2F;cloud&#x2F;devsecops chinstrap hipster nonsense. we want to turn the entire system into a docker container because reasons? without ever addressing the sins of flatpak and the performance hit from containerization vs bare metal? what exactly is the win here?<p>&quot;Bootc allows you to make an OS the same way you make an application, using containers!&quot;<p>but <i>why.</i><p>&quot;There is no denying that most applications are shipped today as a Docker container&quot;<p>postfix, dovecot, nginx, veloren, gnome, hell roughly 16,000 packaged applications in the EPEL repository do not insist upon themselves as containers. Forgejo doesnt require a docker container either. the only people pushing docker are developers who are trapped toiling with some teetering monstrosity of rails&#x2F;gunicorn&#x2F;pypi dependencies that are so odious and brittle to deploy in a normal fashion that a containerized offering is the only way people would ever use them in the first place.<p>is this just another attempt to market capture my desktop with a proprietary backend store like snaps? or force me to sign up for a docker account just to log into my laptop? did a docker C level write this?