I think you’re missing the point of distroless by trying to make a distro out of an image based on distroless with a package manager.
The entire context of that image would be immediately lost and make absolutely no sense by introducing a package manager into it.
If you’re unfamiliar with combining portions of images as multi-stage builds, you may want to look into that to grasp the concepts better.
Another thing: not all containers are built with dockerfiles. You might want to get more familiar with how distroless images are built into the OCI-compliant sense, and the tools used therein.
What you’re describing not only already exists, it exists in the toolchain you mean to rewrite. It’s a hat on a hat, on another hat because it’s in containers.
Maybe if you described the problem you’re having, it might help others understand what you’re trying to solve for.
The package manager would not be part of the container image. The package manager is only used to build it. The container image will only include the packages the user specifies.
combining portions of images as multi-stage builds
That’s something I am making use of for this, actually :)
What you’re describing not only already exists…
Can you please give an example of a tool that can build a container image by being given only a list of packages it needs to have?
My tool would be as simple as doing something like this:
Yes. In your example, the base image is nodejs, which includes yarn. Then you copy your app into it with a COPY command and set the entrypoint to execute. Dead simple.
Which has its own dockerfile. My proposed tool would allow using other images as base too, but that is not the problem it is solving.
copy your app
Well you’d have to have it compiled or built if that is required in your case. With my system, the build recipe would be a gentoo ebuild (shell-script-like) that you would just reference.
The example I gave is pretty simple, you’re right. Say in another case, you list the following packages:
You could start with a nodejs base or an nginx base, and then write the steps to install the other. You’d also have to make sure to get all the deps if they have them.
You’re unlikely to find a ready image that has all what you want. But with my method, you can compose different ones however you like, rather than having to find an image that matches your exact use case.
Again, all you’re describing is just scripting tools that already exist together.
My question is “WHY?”. You’ve not been able to describe a problem that needs a solution. I’m seeing in these other comments that you’re just deflecting that question, so do you know what you’re trying to solve here?
Please demonstrate how the example I gave above can be done with common scripting tools, such it would mimic the declarative experience I described. I don’t think it is possible as you claim.
Can you please point to where I deflected any questions? I looked and could not find any instances of such.
I actually answered the question “why”, please refer to previous comments. It is also answered in the main post. But I will rephrase and summarize again here:
when creating a container image that requires certain applications installed, most dockerfiles explicitly install the dependencies of said applications as well. With my tool, you only declare the package you need, and it will resolve dependencies automatically and install them for you.
the above would work with distroless containers too, as the package manager used is outside of the produced container.
You'll have to forgive me, as I haven't tested this personally on Linux yet, but this webcam is a USB 3 device and doesn't have any special drivers. It should work plug-n-play.
The reason I bring it to your attention is that it has a nice physical lens for focusing, aperture, and zoom; all separate. It's 4k 30 fps and I can confirm that the picture is really nice.
So you want to build something like apko (alpine packages/repos, used in chainguard’s images) or rules_oci (used in google’s Debian-based distroless images) but for portage?
I think it’d be cool. Just keep in mind:
Container scanning tools (like trivy), afaik, tend to look for a package db. Going distroless breaks them. I believe this is why chainguard generates a SBOM (software bill of materials).
Container images are already de-duplicated, and often, the gains in pull times aren’t worth the additional debugging effort (for example, you won’t be able to have dig/curl installed without rebuilding and deploying the whole image, or even a bash prompt in most cases). They’re even more not worth it because lazily pulling OCI images is now a thing, though it’s in its infancy. See: eStargz and I believe dragonfly which uses nydus. More generally though, zstd:chunked will probably eventually become mainstream and default, which will all but eliminate the need for “minimal” starting images.
If you wanted to go really small, there’s stuff like slim which makes tailor made images.
Gentoo, afaik, doesn’t really do LTS releases, making it undesirable for server use, which is the main place containers are.
Distroless containers don’t share common base images because they are normally scratch-built. This breaks image deduplication, leading to increased disk usage instead of decreased disk usage, and why I personally swapped off chainguard’s images.
Did not know about apko. I am not attached to distroless, just thought it was a nice to have. So apko might be a reason I don’t pursue this project anymore. Thanks for showing me!
Your comment is very insightful for other reasons too. Thanks a lot :)
Yes, DisplayPort supports multi-channel audio and many advanced audio features. DisplayPort to HDMI adapters also include the ability to support HDMI audio.
This is cool, but half the software I need to use still doesn’t work on Wayland for some inexplicable reason.
I know this is the responsibility of the software maintainer to fix their compatibility, but as a business user I don’t have time to go around filing detailed bug reports and waiting for the next release when it’s fixed.
The solution for me is to switch back to X11 and move along, then in another year I try Wayland again after installing a new distro. After a few hours I find something that isn’t working on Wayland, rinse and repeat.
The thing is, volunteers work on what they want/specialize. Unless you are their boss and are paying them to work on something, you can’t force their hand.
I truly do think this is a cool feature, but after seeing all the comments saying stuff like “now there’s ZERO excuse not to use Wayland!”, I felt like it was appropriate to share my perspective as a professional user who uses their computer a little differently than a FOSS enthusiast or hobbyist/casual user. I’m not getting paid to go around submitting bug reports and making PRs, so when things don’t “just work” it can be a big issue.
Felt. VR took priority over color management with ICC profiles & HDR which is more important for commercial & general entertainment applications. I’ve had to switch back to X11 too.
That something being probably Microsoft Teams piece of crap app or similar bullshit like Discord, all of which FOSS devs can’t do anything about even if they could. Or simply your system incompatibility like NVIDIA proprietary drivers.
If you expect everything to just work as if it was consumer OS that is fully supported by 3rd parties, Linux might not be the best choice for you in general.
I’m talking about FOSS software incompatibilities, I don’t have any expectation for mega corporate apps like Discord and Teams to adopt it. Those are a lost cause, I just use the browser versions and pray.
I truly do think this is a cool feature, but after seeing all the comments saying stuff like “now there’s ZERO excuse not to use Wayland!”, I felt like it was appropriate to share my perspective as a professional user who uses their computer a little differently than a FOSS enthusiast or hobbyist/casual user. I’m not getting paid to go around submitting bug reports and making PRs, so when things don’t “just work” it can be a big issue.
“Zero excuse” is a bit of a stretch, I aggree, but most things work really well now in my, and a lot others experience, at least recently. I also do my work full time on Linux, it’s mostly devops/sysadm work so a lot of what I use is terminal, web browser and well… Teams and Slack (the first one work well with an unofficial client, the latter got fixed recently), so it’s really not that hard to switch to Wayland. On my private machine I do mostly gaming, consuming content, some basic audio production and editing and there I rely a lot on X11 programs some running through Wine. They all work fine on Xwayland, recently even including HiDPI support (at least with simple one screen scenario). It’s really hard to find completely broken use case unless it’s something like automation scripts that move windows around, emit click or capture keyboard input globally and were designed strictly for X11. Oh, and apps that have multiple windows and request certain positioning - that is currently still missing and WIP.
On the other hand, the topic was originally about VR. While still kinda early, gimmicky and niche, it’s pretty cool modern tech. Good luck with that on X. Even more common cases like high refresh rates with multi screen setups, VRR, all suck on X11 while working nicely on Wayland for some time now, at least with good drivers.
They’ve been doing quite a bit of work in the past year, on Newton, the future a11y stack, Spiel, for a better pipeline for speech synthesis (basically as an easy way to get more natural-sounding voice models) and on implementing AccessKit (the most recent stable a11y stack that is the same one the folks working on COSMIC are using).
I had a feeling nixos would have something, but I avoided it because it seemed more than a day’s worth of learning (and also its a bit opinionated). But I will revisit it one day!
i’ve had a lot of luck with the logitech brio which is a 4K WebCam, the only issue that I’ve run into is the fact that you have to make sure that it is plugged in to a USB 3.0 and not 3.1 port.
Am I wrong in assuming that both OS’s should be sharing the EFI and /boot partitions?
Shared ESP is fine as long as you don’t run out of space. Nothing in /boot should conflict but that’s not guaranteed, although having 2 potential boot partitions means having 2 potential grub configs. I’d make sda3 a ~2GB ext4 boot partition just for Fedora (mounted at /boot), and an sda5 with btrfs with a home subvolume mounted at /home, and a root subvolume mounted at /, then mount sda1 at /boot/efi (this is the default layout iirc, albeit with different partitions, ofc). This might be easier to do in the advanced blivet gui.
And yes, Linux’s boot process is a convoluted, fragile mess and there are currently multiple ongoing discussions on how to improve it.
The bug is the lack of documentation and that a simple unguarded command can erase all user’s data on the system.
Also, the principle of least surprise would like a word.
If I look at the command line arguments of a program called “systemd-tmpfiles” and one of them is called “purge” I will generally assume that option will purge temporary files.
Now it turns out that someone decided that this program would be a simple way to do something with /home directories(*) so they included /home in the config file for the program, the file that the program reads by default when it is invoked.
Who decided it would be a good idea for it to deal with /home?
(*)I have no idea what this program is doing with /home in its config file. I will presume that there is a useful and mostly logical reason for it, and that this command line option was just an unfortunate footgun for those users who were not intimately familiar with systemd.
There were talks a few years ago about changing sd-tmpfiles name but it was decide not worth it due to the churn and bikeshedding it would cause.
sd-tmpfiles is generally used to create, modify (e.g. permissions) and remove directories on the system. The home.conf is intended for systems that only ship /usr/ (e.g. containers) to create /home/ and /srv/ as a separate subvolume on btrfs
“Breaking userspace” is often considered a bug even if the code doing so is working as intended. Deleting user data because they bundle a config file deep in the directory tree for a completely different use case was not intended behavior even if one of them is defensive about the logic.
Is edid/sony.bin your new EDID? Does it revert back if you remove drm.edid_firmware all together?
Also, do you mind sharing your EDID? I had to edit mine to get VRR to work, so maybe there’s something invalid in yours. It does contain serial numbers though if that’s a problem.
Probably by editing your GRUB config or whatever bootloader you’re using.
Here is the EDID
Thanks, that should be enough I’ll have a look when I’m free. Also something like get-edid > monitor.bin would probably be easier for me though.
Edit: I’ve had a look, I can’t see any issues. Both checksums validate correctly and it advertises audio support. As you’ve probably seen in edid-decode, I’d expect it to show as ‘SONY TV’ (or at least for KDE ‘Sony SONY TV’ I believe).
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.