Brew applications are also unsandboxed unless the app developer chose to opt-into sandboxing.
Personally, I while I love sandboxing, I chose to use brew and other third-party installation methods because I didn’t want to use the App Store (and actually couldn’t unless I signed in using an Apple account, which I didn’t want to do).
If you use apps from the App Store, they will be sandboxed.
If you download apps elsewhere, they may or may not be sandboxed. It’s an opt-in thing.
Whether you choose to have guaranteed Sandboxing from the App Store but at the cost of Apple’s increased meddling is up to you.
They said GUI everything AND “just works”. I was more so referring to the latter.
My point is that nothing “just works”. With immutables, your system is less likely to break after updates, but introduce other headaches.
On a traditional distro, you can use pretty much any format. Traditional packages like deb/rpm, flatpak, snap, Nix, distrobox, etc.
That’s not the case for immutables. Bazzite primarily uses flatpak, but (1) not all apps are available as flatpaks, (2) not all apps work well as flatpaks, like IDEs, (3) apps may have permission issues that require some know-how and tweaking to fix. Bazzite also comes with Homebrew and Distrobox, but (1) Homebrew doesn’t have many GUI apps for Linux, (2) apps may not behave as expected in containers and don’t integrate as well. Finally, as a final resort, there’s layering but that (1) requires the terminal, (2) may not be allowed in the future as Universal Blue is going more bootc native without rpm-ostree support, (3) may not even run Fedora in the future if they like their “distroless” version more.
There is no right answer. While I love immutables, they bring their own set of problems to the table.
The problem with entire concept is the assertion that “after updates are run, the expected values are updated”. If the administrator can cause the expected values to be updated, you must assume that an attacker who can replace GRUB, in your example, can too, rendering the whole thing ineffective
This TPM stuff is focused on verifying the integrity of the the boot chain. It’s meant to protect against things like replacing GRUB or changing GRUB options in a malicious way. If that stuff is detected, the system won’t boot.
It’s goal is not to prevent malicious changes in userspace, after the system is booted. Protections against malicious userspace modifications must come elsewhere, like SELinux, AppArmor, sandboxed apps, Wayland, etc.
If the administrator can not cause the expected values to be updated, we’re into an Android like situation, where the vendor decides what you’re allowed to run on your machine. Neither outcome is better than what we have now
What do you mean by vendor here? Initially we were discussing applications doing some sort of system integrity check to decide whether or not the application would run. But now it seems like you are referring to the distro deciding whether or not you are allowed to do things.
But again, these checks are just for the OS and it would not make sense to try and turn this into a DRM-like system when Secure Boot is much better suited for that task.
And distros already control what you can and cannot do by how they choose to build the OS. Lets consider Aeon and Universal Blue.
Aeon is an OS that implements things that Poettering is discussing. Uses TPM to verify the integrity and unlock the disk if everything is fine. It also is immutable, which limits user customization in some ways as part of its philosophy. It discourage OS modifications and encourages use of Flathub and distrobox.
The Universal Blue family of distros does not implement Poettering’s stuff (though there is an option to do so). But it has similar restrictions as Aeon, discourages OS modifications, encourages use of Flathub/Homebrew/Distrobox.
My point is that verifying the boot chain integrity largely does not matter when it comes to user choice. While the two I mention do have restrictions, they are only philosophical, you could build a system that has these boot chain integrity checks and it not immutable. Measured Boot is great for this task because it puts the user is control, you don’t need to worry about the software being signed with some third party’s key to boot.
Lennart Pottering has an unfortunate habbit of deciding to fix problems that don’t actually need fixing, then coming up with a vastly overcomplicated solution
I agree in some respects. I like immutable distros, flatpaks, and sandboxed/containerized stuff, but sometimes you just need to install software on the host, unsandboxed. The big thing is that immutable distros want the OS and software on top to be cleanly separated.
Some say to use Hombrew, which will take up quite a bit of space and will not always work (like SELinux permission issues) and I don’t necessarily like it how puts all its dependencies on your PATH.
Notably, Systemd came up with system extensions. Seems complicated, have never gotten around to using them.
Then I look over at BSD land and their solution is stupidly simple. OS stuff goes into places like /usr/bin while user installed stuff goes into /usr/local/bin. I don’t really see why immutable distros can’t just have a normal package manager but have everything installed to a different place like /usr/local/bin and put that on the PATH.
The problem I see with that is that these values are far from regular. At the very least, the TPM will be checking the Linux kernel, bootloader, BIOS firmware. Any update to those will result in different measurements. And it’s not just the version that matters, but also the configuration. And there’s more things the TPM can measure, like connected hardware devices.
To reiterate, it’s not the case that the distro provides a hash of what the measurement should be. When you install, the actual software gets installed gets measured and recorded. That first measurement is automatically trusted, assumed to be good. It’s unique to your machine. Your machine will only boot so long as those measurements match. Those measurements only get updated when measurements are re-run, which is done after system upgrades.
Creating an allow list that works for most people would be next to impossible. The Secure Boot approach is much more suited for this task. I can only see this TPM allow-list approach working on corporate machines with controlled hardware and software updates. But at that point, using a custom secureboot key is easier and less liable to break.
It’s not vague at all if you know Poettering and have watched his talks.
This is about securing the boot chain to ensure the integrity of the OS. Ie, someone hasn’t replaced your GRUB with one that looks exactly the same but secretly records your disk password.
It does so in a decentralized way, so anything like Play Integrity would not make sense in the slightest. It’s the TPM chip measuring values and ensuring they match previous recorded values (and the values to change, such as after updates, so after updates are run, the expected values are updated). It’s not a Secureboot-like system that would make it more feasible to have a Play Integrity-like system.
That’s not at all what this about. Poettering has given quite a few talks about this subject, that being Linux boot chain verification and integrity.
One of the core concepts is measured boot. The TPM on your CPU measures the values of various pieces of software in the boot chain. If a measurement does not match, then the system will not boot because it could be compromised.
And unlike secure boot, this is a decentralized system. It’s not some corporation like Microsoft saying “this software is signed with this approved key, so it may boot”. It’s your own system checking the software and recording the expected value so that when you boot up, it checks again to make sure they match.
It’s not about apps asking doing things like DRM checks or anything like that. In fact, it can’t. GrapheneOS implements a system just like this to ensure the OS has not been tampered with.
7-zip does have a linux CLI, which works well.
The most basic command you need to use is 7zz x archive-name to extract an archive. Building a GUI around it doesn’t seem like it would be too much trouble honestly, wonder if anyone has done that.
You shouldn’t do sudo pacman -Sy banana. That results in a “partial upgrade”, which Arch doesn’t support. Instead, you want to do sudo pacman -S banana.
Even then, what do you consider AI?
Some people don’t even consider LLMs to be AI because they don’t consider them smart enough and or because they lack sentience.
Before LLMs, machine learning has been considered “AI”. DDG/Bing likely uses machine learning for their page rankings, are they going to stop that because this poll said no to AI?
The poll is just too vague with what AI means. When people say they hate AI nowadays, they typically don’t literally mean that. They really mean they hate how things like how LLMs are shoved into services that don’t need them, tech bros non-nonchalantly talking about replacing humans entirely, environmental impact of LLMs, people using LLMs for too many things, etc. Outside of stuff like that, there’s plenty of good uses of “AI”.
I wish they were more clear on this. Is this about existing AI features? Future AI features? AI images?
My only real complaint is that I would prefer it to never show the AI answer by default, I would just like to see the button to get the AI answer. And to be clear, I know I can set DDG to behave that way, but I do a lot of searches in private tabs too.
I actually do find the AI summary helpful. When it comes to basic programming questions, like to remind me of syntax or arguments, it gives a useful answer most of the time.
But I don’t want to see AI images. And I’m hesitant to agree to future AI features because of how aggressively some companies push them in your face.
They share a few small visual elements, like a top panel and “dock”, but using them are completely different experiences.
MacOS is in reality closer to KDE than Gnome. That being said, almost every Linux desktop environment and Windows are closer to each other than MacOS. MacOS is quirky in comparison to all of them.
I don’t really mind. 90hz is my sweet spot. It feels smooth enough and I’m not unnecessarily taxing my hardware for comparatively little improvements.
The only valid complaint I see is that 120hz is a little more versatile because it divisible by 24 and 30, while 90hz is only divisible by 30. So not as good for content that runs at 24fps. But even then, I still don’t mind, I don’t notice any presentation issues.