I think the question is, why ChromeOS instead of a Linux?
I love Linux and I would consider myself a power user (understanding HW arch, working with kernel sources).
Basic Chromebook apps (+ Play Store) are something that "just work" for 80% of time for my use-cases (which is, browser and ssh-ing into a power machine in ze cloud/DC). I also have rather good understanding of threat models here, and the quality of the sandboxes and HW roots-of-trust, hardening and software isolation on a typical Chromebook, so it gives me a relative piece of mind for specific use-cases (personal/family files etc.). Supporting an extended family, if they can get used to Chromebooks (it covers 99% of their needs, esp. that Android apps can be installed here) is a bliss.
Customizing Linux is mental fun, but on a road you probably something that just works, and typical Linux is rough at edges - GFX support, hibernation, esp. if you don't want to stick to some LTS distro, b/c you always need this newer package for dev purposes or tinkering.
The remaining 15% is covered by a VM, which seems really nicely integrated (X11 proxy etc). The remaining remaining 5% cannot be covered - custom kernels, custom USB drivers, occasional need to use Windows, but that's fine, I can do that on a desktop or on some random, cheap, low-power laptop.
In essence, it's just a thin client on steroids, which almost always works in its basic form. But if you want something more interesting, there's always a VM with some Linux distro, or Android apps via the Play Store. But these are optional and don't affect stability of the core system, if you don't use them.
An Android tablet is a muuuuuch better experience for running Android apps than the Pixel Slate. A Framework running Fedora is a muuuuuch better experience for doing dev work than a Chromebook.
ChromeOS is great when used for what it is, and it's cool that it can flex to handle edge casey things with VMs. But if the VM stuff is most of what you want to do, just go a different way.
This is something that jumps out to me - over how many years and why did you replace them?
None of them were replaced because I strictly speaking needed to replace them, and all got handed over to someone else who happily used them.
Biased but informed opinion: I own a Framework Laptop running Ubuntu 22.04.
Linux on a server or a desktop isn't so bad. Linux on a laptop is awful. Hibernation isn't supported. Battery life is mediocre, and battery drain in sleep is significant. If I close the lid on my Framework at 75% and come back the next day, it will be at 25%. If I come back in 3 days, it will be completely dead. Even on a device designed to support Linux (Framework, Thinkpad, whatever) the Bluetooth experience is....err......well, if you don't have anything nice to say don't say anything?
ChromeOS isn't perfect, but as a laptop I'd much rather run it (with Crostini to get a Linux development environment) any day.
There's apparently a world of difference. Nothing about the Framework suggests it was designed for Linux.
A proper Thinkpad does not have issues with hibernation, or losing battery, or graphics, or any of the other things you mentioned.
I just want something that works, and will receive updates as long as there are users. I don't want to muck about with VMs, or Crostini, or whatever it's called. Sounds like I must never let go of my Thinkpad.
The vast majority of people I know who tried running Linux on their laptop switched to Mac/Windows/ChromeOS. Containers and subsystems like WSLv2 or Crostini make it mostly painless to do Linux development while having a host operating system that has people paid to make the experience great rather than volunteers who generally want to work on shiny algorithms rather than fixing UX bugs.
More specifically: I've run Windows on the Framework and it was generally great (I wished it was a touchscreen, but that's about it). Maybe with the right magical device I could get a great Linux experience, but it's not worth having to search and compromise for me. I can install Windows on anything and it will work. I can buy any of the few Macbooks on sale and it will just work. I can buy any Chromebook and it will largely work out of the box. Linux is the only OS that makes me carefully check that my exact set of chipsets and components will probably not be a complete disaster. I buy laptops based on their hardware specs (screen, keyboard, trackpad, weight, ports) rather than their compatibility with an operating system.
But it's really not. Linux is mainly for users, by users. You're going to a very diverse set of users and experiences. For every tweaker out there you're going to find someone like me who just wants a unix-like operating system, with Perl and Python and everything else available with a minimum of fuss. They just don't speak up very often, because there's not much to something that works.
Of course it's important to mention the problematic bits too, and there's been many. I've mostly run Debian for over twenty years, and there has been several times where I had to fix issues from migrations such as rootless, utf8, python3 things, and file format migrations. For a long time things like hot plugging monitors, projectors and printers were a bit of a gamble.
But for the most part it's given me an environment where I can use a wide range of tools from emacs to nmap, from git to latex without giving a second thought how to configure paths, and how to fix some random missing dependency for a package to build, or why nginx doesn't pick up the changed file date. All those things have been ironed out by someone who went before me. That's worth a lot.
> I buy laptops based on their hardware specs (screen, keyboard, trackpad, weight, ports) rather than their compatibility with an operating system
Yes, that pretty much explains everything.
That's a luxury available to users only of a completely dominant software platform.
A Mac user could never say that. If you want OSX you must carefully buy supported hardware. You can buy a hackintosh, but don't fill up threads with complaints how bad the suspend works, and that the picture quality of the webcam is subpar.
Speaking for myself, I know what software I want to use. I do not care about hardware specifications in any other way than it runs my software reliably. Sometimes that means you can pick any color you want, as long as it's black. Black as my laptop.
Not necessarily. There's plenty of instances of devices working poorly in Windows before the issues get patched (if they are at all).
If you want something that 'just works', you are indeed better with the Apple ecosystem. They control the hardware and software.
The only way around these issues is to pressure vendors to provide better Linux support. The only reason Windows laptops tend to work better out of the box (or at least with all hardware working to some extent) is because of all the testing done by vendors.
Not sure if my E495 would qualify as a "proper thinkpad", although I've read about the same issues on T series laptops, I've almost never managed to make my laptop sleep in the 3 years I've owned this laptop starting from kernel version 5.4.x to the present 5.19.x. Whenever I try to 'systemctl suspend', one of the following things happens
- the laptop sleeps for a few seconds and wakes up
- the laptop sleeps for a few seconds and wakes up completely frozen and I have to perform a hard reboot
- the laptop doesn't sleep and freezes and I have to perform a hard reboot
- the laptop sleeps successfully but when I wake it up, the screen is messed up with green colors all over the place, hard reboot needed
My laptop also kept freezing randomly from 5.4.x to 5.14.x.
I don't know about the E-series specifically, sorry.
Not trying to contradict you. Just noting how even within one manufacturer's footprint (and "linux" however we define that for the purposes of this conversation) YMMV.
I am really waiting for a linux laptop, which is truly mobile. I also rather went with chromebooks so far.
I will say I agree, you can't use a Linux laptop and take a video call without being tethered to power.
I have never had a problem with suspend, hibernate, nor excessive battery drain (beyond what the hardware should do) on any of linux laptop setups.
Thats starting from a thinkpad in 1998 (yes), all the way to my current amd 4800 tongfeng (generic chinese oem laptop maker).
Along with quite a few chromebooks thrown in along the way (all of which were developer-mode enabled, WITH secure verified boot turned back on, so had full access to linux apps WITHOUT using crostini vm's).
But, seeing as how chromebooks are essentially machines running GENTOO LINUX with a custom google ebuild overlay, then perhaps their reliability should be another plus checkmark for "linux on laptops", and not somehow a ding against that.
Anyway, take that for what its worth ...
YMMV
Sounds like something that Framework should fix. There's nothing wrong with the Linux kernel per-se.
I have an older Dell Chromebook (turned into a Linux machine once Google stopped OS updates). Battery drain during sleep is pretty significant with either ChromeOS or Linux.
For web browser-based stuff, I have a constantly-updated state of the art browser with full vendor-backed hardware support for everything around graphics, sound, USB, Bluetooth, etc, anything else I might want, plus probably the best sandboxing you can get as far as protecting the core system from any malicious web exploits. It also works rather well in tablet mode with convertible devices. IME, getting all of this on bare-metal Linux and having it stay working for years is very hit-or-miss.
For linuxy CLI stuff, I have a built-in Linux container with a nice terminal. Everything I've wanted to do as far as CLI stuff works great, including Vim + Tmux, developing and compiling in any language, systemd services, docker and k8s CLI support. I've opened at least a dozen or so PRs on various open-source projects and maintained server clusters working entirely on a Chromebook. All the driver and display stuff is taken care of by ChromeOS so I never have to mess with config for it.
Can you expand on this? Perhaps a URL with more detail?
In the end though it is cultural and not technical. Debian will bend over backwards to make sure That One Guy can still install the latest version on his old Centaur CPU, from floppies. ChromeOS is laser-targeted for specific, allow-listed hardware platforms. If you are philosophically committed to the eternal comfort of That One Guy, the Debian way makes more sense. If you just want software that's faster and more secure, ChromeOS has the better way.
Which is a roundabout way of saying; it's critically important that we don't over-optimize for the central, happy path (just wanna browse securely on whatever hardware ya got). The most interesting things (and the most valuable) frequently come from the edge cases, which are absolutely supported by keeping an eye on the needs of "That One Guy". Unix interoperability has given us a bounty of awesome shit and I anticipate it will continue to do so.
Battery life of ThinkPad that supports Linux with TLP installed and properly configured will be very similar to Windows. And to address FUD from other reply to your question: AFAIK official Firefox builds for Linux use PGO as well, however PGO has quite less impact on battery life than what another commenter suggests.
I think the real challenge here is for distro vendors to figure out how to provide a better user experience around this. There's no reason that the ephemeral key can't be stored in a sealed state that can be recovered as the machine wakes. There are obviously some security implications to this, but I think it's fair to say that a lot of users would prefer making that trade-off.
What you want is that if someone steals your hibernated laptop, that absent a way to securely authenticate themselves as you, they can't restore the working memory of your laptop. If you think about it, if they could, much of the point of many security precautions would be lost.
My anecdotal experience with friends that tried Linux is that it left such a bad impression when they opened they're laptop the next morning and it's lost most of its battery life that some actually went back to Windows.
As a Fedora user, this is how my disks have been setup for many years, and I don't understand why Fedora have disabled hibernation. During wake from hibernation, the kernel and boot ramdisk would need user input to unlock the PV and to decode the LVs. Then, the hibernation state would be visible at the same time as the other filesystem state, and the kernel could decide whether to load the hibernation image or continue a normal boot sequence.
This seems to provide the protection of content needed for theft of a hibernated machine. I don't know whether there is some unhappy sequencing flaw in the dracut-generated ramdisk (between when the wake-versus-boot decision has to be made and the LVM decryption is done), or, whether someone at Fedora has decided that the threat model is different than we discuss above?
Again, the reason why it's different is the security model for memory is different from the filesystem. This is exactly what I was getting at: the fixed key. Encrypted swap volumes typically are set up to use ephemeral keys that are "forgotten" when you power down. The idea is that you only have access to that memory while the computer is running. When you boot up again, whatever data is in the swap partition is just noise. As mentioned in the link I provided (https://help.ubuntu.com/community/EnableHibernateWithEncrypt...), the current solution is to switch to using a fixed key, much as you described. That fundamentally changes the security model, and not in a subtle way.
I think there's a solution that more closely approximates the security model, with only a minor compromise: when you boot up, you generate an ephemeral key in the secure enclave, and use that to encrypt your swap. When you hibernate, the secure enclave encrypts all the metadata (including the ephemeral key) into a sealed state that is stored on disk with the swap information. When you restore, the sealed data is read back into the secure enclave (and erased) and it can then decrypt swap as needed. This still means the hibernated memory state is fully recoverable by whomever is able to authenticate with the enclave, but that's what everyone wants. On the upside, if you shut down the machine (rather than hibernate), the ephemeral key is lost, so there's no way anyone can recover what's on your swap, even if they have access to whatever fixed key(s) you have used for your LVM volumes.
If you're really paranoid, you could even generate a new ephemeral key on restore and reencrypt the entire swap volume with the new ephemeral key, though I'd question what realistic threat model that would really address.
I adopted the conveniently offered, software-based whole disk encryption mode when installing Fedora. A luks-encrypted LVM PV is the only luks mapping at runtime, and a naked /boot volume is the only volume not allocated as an LVM LV in that encrypted volume group. Thus, I have selected my storage security posture. I expect the cold or detached storage device to be resistant to inspection. Due to the unencrypted /boot, I have doubts that there is tamper-protection of the future running software, should I temporarily lose control of the physical device. I have no illusion that the running kernel lacks access to the plaintext content.
My swap is an LV in that encrypted volume group. Why is hibernation disabled on Fedora? This is where I feel like there is a poorly communicated threat model or some other unstated assumption that I do not appreciate. (But see my last paragraph below for a possible answer!)
Are people concerned about the written hibernation state using the same key as the filesystem volumes? I.e. that knowing how to unlock the whole-disk encryption means you can reconstruct the hibernated image too? I don't see why I, as a user, should care to protect the hibernation image even more than all my regular data. Similarly, if I have the key I can potentially attack the root volume (while offline) to inject all sorts of malware, such that I could exfiltrate RAM state from the running system in the future. Swap isn't required to open me to that attack.
Are people concerned about regular swap state being available on disk during system operation? I.e. the running Linux luks mappings can be abused to inspect swap state? I am not sure I can appreciate this angle, since I think it is farfetched that the swap mapping can somehow be more resistant to attack than the filesystem mappings in the same running kernel.
Are people concerned about regular swap state being left on disk during a non-hibernated shutdown? If so, I would suggest that the swap crypto should not be conflated with the hibernation crypto. Add an ephemeral cipher to swap if you must, but use framing/metadata to reliably distinguish the ephemeral swap "noise" image from a valid hibernation image. I'm OK saying that hibernate must write an entire image and not assuming that regular swapping can opportunistically prepare any hibernation state prior to a hibernation event actually commencing.
While writing all this, I have thought up another possible angle. Maybe this is the actual Fedora issue? I can see that control of an offline hibernation image means control of a future running system image, and this might violate some secure boot agenda? I.e. I can tinker with the hibernated state to introduce a "hacked kernel" and ask the system to restart with that. I can see why secure boot might prevent return from hibernation. This requires some integrity-protection chain to enable the trusted bootloader and kernel to verify a hibernation image before opting to load and restart it. I can see how a variation on your "sealed state" approach could address this. But note, it only requires integrity protection and does not actually need another layer of confidentiality protection.
Yes, we are talking about different scenarios. As I said, you can absolutely set up your swap to use a fixed password and then it will work fine as you describe.
> Are people concerned about the written hibernation state using the same key as the filesystem volumes?
That might be part of the concern, but it's more that it is possible to recover previous memory/swap state with a key that can reasonably be subsequently recovered.
Let's imagine a scenario where I have a secure password, that I enter into my browser, to say, access my bank's website. That's stored in memory by my browser & the GUI, but it is not normally allowed to be put on disk for security reasons. Then I hibernate my laptop and it gets written to the encrypted hibernate volume that uses a fixed password. I restore my laptop and go about my business. I might even reboot the laptop several time subsequently without thinking much about it. Then, someone finds a way to compromise the password used for swap encryption using any number of possible attacks (some you described). Now, not only do they have access to all the stuff on my computer, but they also have access to the contents of the encrypted swap volume, which unless I was lucky and the particular swap page was overwritten, the compromise goes back to the memory of the runtime from long before the machine was compromised. This would include this password that was very intentionally NOT stored on that computer, in order to avert precisely this kind of threat.
> If so, I would suggest that the swap crypto should not be conflated with the hibernation crypto.
That's another possible avenue, not that unlike what I was suggesting. It's worth noting though that these days there may not be much value in having separate passwords for swap vs. hibernate, since swap is rarely used on laptops.
They are all different security trade-offs, and it is debatable which is the right one. I don't think the current default is the right one for most users, but I do understand it.
[1]: https://gist.github.com/RobFisher/abd9b2b9fca4194ac8df112715...
1. Create a swap file. Our rule of thumb is ram + sqrt(ram) for hibernate
fallocate -l 72GiB swapfile
chmod 600 swapfile
mkswap swapfile
swapon swapfile
swapon --show
2. emerge suspend
3. Get the number to use with resume_offset later. In the current case, it was 125798400
swap-offset /swapfile
emerge sys-boot/grub
grub-install --target=x86_64-efi --efi-directory=/boot
vim /boot/grub/grub.cfg
timeout=5
menuentry 'Gentoo Linux 5.18.19' {
root=hd0,1
insmod all_video
linux /kernel-5.18.19 root=/dev/mapper/root resume=/dev/mapper/root resume_offset=125798400
}
4. Fix suspend.conf
vim /etc/suspend.conf
resume device = /dev/mapper/root
resume offset = 125798400
5. Setup an initramfs
cd /usr/src
mkdir initramfs
cd initramfs
mkdir -p bin dev etc proc sys new-root
cp -a /dev/{null,console,tty} /usr/src/initramfs/dev/
cp -a /bin/busybox ./bin
cd bin
for i in `./busybox --list`
do
ln -s ./busybox $i
done
cd ..
cp -a /sbin/cryptsetup ./bin
mkdir -p ./run/cryptsetup
lddtree -l /sbin/cryptsetup
Copy in all of those files until the local cryptsetup works appropriately
vim init
#!/bin/sh
# Define a rescue shell
rescue_shell() {
echo "Error in boot process, dropping to a shell"
exec /bin/sh
}·
# Mount our devices. We sleep prior to dev to hopefully finish loading.
mount -t proc none /proc
mount -t sysfs none /sys
sleep 2 && mount -t devtmpfs none /dev
# Decrypt the root partition
cryptsetup --allow-discards luksOpen /dev/nvme0n1p2 root || rescue_shell
# Attempt to resume
printf '%u:%u\n' $(stat -L -c '0x%t 0x%T' /dev/mapper/root) > /sys/power/resume
# If we're not resuming, mount the new root
mount -o noatime,discard -t ext4 /dev/mapper/root /new-root
# Unmount (cleanup) our devices
umount /proc
umount /sys
umount /dev
# Boot from the unencrypted partition
exec switch_root /new-root /sbin/init
6. Suspend should be working with:
echo shutdown > /sys/power/disk
echo disk > /sys/power/state
or preferably
loginctl hibernate
ChromeOS has a great separation of concerns and isolation of environments. I have my work profile and my personal profile, which are totally separate. I have my browser environment and my dev VM, which are totally separate. Different activities are cleanly partitioned.
This has obvious security benefits but also is just a really nice, simple way to manage the system. I can fuck up a dev VM without impacting anything else, I can click random links on my personal profile without impacting work, etc.
It also just does what I want it to do. I browse the internet, I program. It's good for those things. So... why Linux?
[1] https://old.reddit.com/r/Crostini/comments/b680wa/external_d...
don't they already support this on the existing framework?
I have not seen a remotely significant difference between ChromeOS and Linux (with Chrome Installed) for the vast majority of users.
It is true that Linux on ChromeOS is annoyingly fiddly and my suspicion is that this is the Google mind (perhaps subconsciously) not wanting to reveal how generally unnecessary "ChromeOS" would be in a world that collectively "knew that the Linux Desktop existed." And I do mean this "without modification," i.e. most of your top 20ish Distrowatch distros fare perfectly well here.
You provide IT support, eg for school kids, and somehow they grok Linux just as well as a browser? That is not my experience.