LeFantome @ LeFantome @programming.dev

Posts

0

Comments

1,654

Joined

2 yr. ago

Interesting to see the Clang attributes on there

Interesting to see the Clang attributes on there

Started with Soft Landing Systems (SLS). Pre-Slackware. Many hours downloading floppy disk images at school.

Moved to Red Hat (pre-Fedora and pre-RHEL) until I think 7.3 or so and then Mandrake. I did trial runs with many distros over time but none of them really stuck. Fedora for a release or two. Spent a few years on Manjaro for desktop and CentOS for server. Have been on Arch for many years now (or EndeavourOS). Never used Ubuntu really.

Moved to Proxmox for server. Although I never used Debian historically, quite a few of the containers I have on Proxmox now are Debian based as is Proxmox itself.

Lately, I have been using Chimera Linux for desktop though I have an Arch Distrobox on it so I guess I am a bit of a hybrid at this point.

Glad you are enjoying Arch. I agree, it is no longer hard to install.

Do you have an example of something in the Arch wiki that does not apply to EOS?

I mean, I guess most people self-installing Arch are not choosing Dracut (though you could and the Arch wiki covers it). I cannot really think of anything else though.

I use KDE with Chimera Linux which is only in beta. Rock solid.

Arch users do not consider EOS as Arch but it absolutely is.

EndeavourOS uses the vanilla Arch kernels, the vanilla Arch repos, and the AUR. There are only a handful of packages in the EOS repos and the majority of them are theming or utils that are what you would use on Arch as well (like yay and paru). There are a few quality of life utils that are totally optional and most EOS users are probably not even aware of. Plus, I suppose, the EOS keyring and a couple of packages so that the distro identifies as EOS instead of Arch. Distro identification is the only thing that “overrrides” anything in the Arch repos.

I describe EOS as an opinionated Arch installer with sensible defaults. Once installed, it is just Arch.

It is trivial to revert EOS to vanilla Arch if you want to. I don’t think it even requires a reboot.

I have never had anything in Arch take months to fix. One tip I would have is to use both the latest kernel and an LTS. If something “breaks” with a kernel module, just boot into LTS and it is probably fine there. I also had an issue with WiFi for about a week but a quick reboot into LTS and I was good to go immediately. When I tried the latest kernel two weeks later, it had been fixed there. Something similar happened with my FaceTimeHD camera. Same solution.

Just recently repartitioned my MacBook:

1 GB for EFI (vfat)

2 GB for /boot (ext4)

11 GB for swap

224 GB for / (bcachefs)

Grub cannot load a kernel off bcachefs so I need ext4 to bridge the gap. Once the kernel is loaded, it has no problem using bcachefs as root.

This is a laptop. On a desktop that can handle more drives, I would split /home onto a drive of its own.

I agree with you. But there is Distrobox if you want to “bring your distro”

Probably best he stops answering questions now. Stating positions will only limit his flexibility next election.

This one is already lost.

People recommend Mint mostly as a better Ubuntu I think. Ubuntu is still the most popular and, increasingly, not the best distro to start with.

Fedora currently fills the space that Ubuntu used to fill. Probably the biggest caveat with Fedora now is the lack of codecs by default.

Arch benefits not just from documentation but from its repo. Whatever you get told you need, it is always a relief to find it waiting there for you already tuned for your distro.

My current distro uses APK 3 as a package manager and that is already atomic. So I guess my current setup works fine, without any of the other hassles and limitations.

ffmpeg will do CPU detection and use features like AVX2 if available even on vanilla distros.

Makes very little difference

What did maximum even mean when you have a “virtual desktop” that was 4x times the size of your actual display. Because that is the kind of nonsense we used to do on Linux (because you you could and the other guys could not).

Linux was exciting but time consuming and not all that useful.

I used to bike into University, spend half the night downloading disk images of SLS, spend hours more installing, and spend hours more getting the X config timings working for my monitor. But when I was finally able to use the same window manager config as the Sun workstations at school I felt like King of the World! But what was I actually doing with it? Xterm and an ancient version of GCC.

That said, I created my own basic Shell in the early days and a few little utilities. So I learned a lot. I do not think I would even have attempted many things without the technical confidence that just being a Linux user brought. There was the feeling that you could do anything even though you were hardly doing anything. And new capabilities were constantly arriving so that feeling lasted years.

To understand how to interpret these complaints, we need to understand that Flatpak works by essentially installing a second set of libraries for your apps to run on. The apps run in a container (much like Docker) on top of these libraries. Flatpak uses the kernel and display server from your main distro but otherwise Flatpak is like a second distro unto itself.

So, if you only install a Flatpak app or two, it is very true that they will require quite a large number of support libraries to run (just like running one app on your distro is more distro than app space wise). However, as you add more apps, they they resuse the libraries that the first apps installed.

Because Flatpak installs all its own support libraries, the apps run the same on all distros (which is the point).

So, Flatapak does duplicate the libraries on your system out of necessity. Because your Flatpak apps does not use any of the libraries from your host system. However, they are only installed once inside the Flatpak environment.

The comments about vulnerabilities are neither here nor there. You have to trust your distro. You have to trust Flatpak (as a second distro). Both are subject to vulnerabilities and supply chain attacks but neither more than the other. Flatpaks are technically after as the container environment they run in “sandboxes” your Flatpak apps. In practice though, they require enough permissions that the sandbox is trivial to escape. So not much difference.

Flatpak is literally installing a second Linux distribution on your machine, just without a kernel. All the dependencies right down to the C library are installed in the Flatpak environment. This why you can run a Glibc Flatpak on a musl distro.

Microsoft could support Flatpak “natively” on Windows. It could use the same kernel and GUI glue that WSL uses but you have no need of specifying a distro or getting to the command-line. The experience could just be that you go into Flathub, install and remove apps, and everything would just work.

Apple could do the same with macOS.

If they did that, Flatpak could be a universal app distribution method on all three systems. Devs would only have to create and maintain a single version if they wanted.

Microsoft will not do that of course. If it really was a brainlessly simple alternative application store, they could OS/2 themselves and loose control of the platform.

Too bad though. It would be cool. No reason it could not be done independent of Microsoft of course but it would never be as popular if it was not built in.

Don’t confuse intelligence with knowledge. He blindly believed everything they taught him in engineering as well.