The difference being that while people have a good intuition on one may spend their vacation and what one would talk about, it’s not so easy to extrapolate for other things.
Sure, everybody knows that media talks more about homicides and terrorism than the thousands of people dying or „old age“-kind of things, but it’s not always easy to keep in mind on how far apart these numbers are.
I think „manipulation“ may be to strong of a word here, since it assumes intent to manipulate, which is not necessarily to focus on „out of the ordinary“ events. But I think nonetheless that this infographic is interesting and important, because it reminds us that these biases exist and how big they are.
if you are in the business of buying parts, assembling them, and selling the assembly under your brand (as tuxedo and others like them are), then Apple is a indeed not an option. Their chips might be the best, but you still can only get them in Apple devices, in the specs Apple provides and with no official support for any OS beside macOS / iOS.
That's true. What I wanted to point out is the fact that the most tightly integrated and arguably the most locked down platform on the market is more open than a platform designed to be adapted by others and sold by many.
I don't expect any daily-driveable alternative operating systems on Apple systems since it's a continuously moving target, yet Apple doesn't have a such heavy-handed approach. They just do their thing and do not hinder things actively like NVIDIA and Qualcomm.
This comparison makes no sense. It's desktops/laptops vs phones. In either case Apple is the worst offender. You cannot even use Nvidia/AMD/Intel DGPUs with AS Macs, or install other OSes on iPhone.
> You cannot even use Nvidia/AMD/Intel DGPUs with AS Macs
afaik you technically can, except that m1/m2 force pcie bars to be mapped as device memory (forbids unaligned r/w), so most gpu software (and drivers) that just issue memcpys to vram and expect the fabric to behave sanely will sigbus. it's possible to work around this, and some people indeed have with amdgpu, but it'd absolutely destroy performance to fix in the general case
so it doesn't really have anything to do with apple themselves blocking it but rather a niche implementation detail of the AS platform that's essentially an erratum
don't see why they would care to put out docs on it considering macos doesn't even permit kexts anymore, there'd be no gpu drivers anyways. i figured it was obvious we're talking in the context of running linux on these things, given the parent topic.
> There's also an Apple VP saying unified memory on AS doesn't leave room for DGPUs and separate VRAM
can you link to this? my intuition is that they're speaking on whether apple would include dgpus inside AS systems like they used to with nvidia and amd chips in macbooks, which i agree wouldn't make much sense atp
There were uses for DGPUs in MacOS before AS, those uses could have continued, but Apple left no choice. It's weird how continuity wasn't as important to Apple in this case.
Whatever kernel or hardware facilities are available to Apple's own GPU driver, should be available to other GPU drivers. Anything else is myopic thinking, which I realize might be common for Apple, but it is also monopolistic.
Linux also allows userspace drivers with less performance I think, but I don't think DGPU use can be made performant because of AS hardware choices.
I am predisposed to ignoring link requests for things that can be easily googled.
I thought about that as well, but it's really just so core to every aspect of the product that Tritium needs to own it 100%. We just don't have the capacity to take a tradeoff that is favorable to the broader use case. I highlighted this issue in particular but there were other places where Tritium's needs diverged from the docx_rs approach. (e.g., dealing with references)
its easy as in "simple to implement and execute" but not cheap, because it may require scanning large amounts of memory. You have to visit every list entry.
Whats trivial for a very small list, may be a no-go for gigabyte-sized lists.
I am somewhat surprised (and happy) germany is not in on it already.
There are already (afaik voluntary) block lists ISPs are applying, but I am surprised its not breaking things on a similar scale to italy and spain, an that the DFB isn't already piping /dev/urandom-domains into it...
Some of the issues have been addressed. For example, iirc, there was a bug where pulling out the power plug while the lid was closed would trigger the device to wake up.
Some other issues remain. Largest I am aware of is independent from the hardware, but an issue with suspend-to-disk & kernel lockdown, which prevents deep sleep.
The complaint about power usage in suspend is especially sad because it’s pretty much a common problem for Linux on laptops. Not sure if that’s what applies here, but the numbers about match what I see with my Framework. Basically: if you want to use secure boot you usually also want kernel lockdown mode, and you cannot hibernate a lockdowned kernel. At least not without out-of-tree patches.
IMHO that’s a giant issue. If you can’t hibernate (aka suspend to disk) you will never be able to get that power consumption low. And telling people to not run secure boot or lockdown is not really a good answer either. Especially since the default installer already sets those things up.
I get that „Linux on laptops“ is not a priority big enough to get a proper fix for that. And that it’s not an easy issue to fix. But the current state is really really sad.
This is not a Linux issue (Though the hibernate issues are!). It's a PC issue. Microsoft went on a crusade making hardware vendors implement S0 next to S3 but most hardware vendors now _only_ implement S0. So that the laptop can keep phoning home and download updates etc whilst closed. Which means it's impossible to turn off the CPU during suspend. it's always on.
Shouldn't that mean that the relatively open platforms like Framework should work better, since they lack the incentive to defy the user/owner like the locked-down platforms do? What would prevent Framework or anything similar from implementing the other sleep states?
Framework doesn't produce it's own CPUs. It buys them directly from Intel. Producing your own CPU is really difficult, if you want it to be competitive with other state-of-the-art CPUs.
They don't need to make their own CPUs for that. Framework can write its own BIOS and ACPI drivers for Windows and Linux to have proper sleep support. But that's more R&D expenditure they probably can't afford.
For example, for my home lab, I bought a used Intel 12th gen industrial PC from a specialized Taiwanese embedded systems company, whose BIOS allows very granular control of all sleep states plus individual power control of most peripherals, probably because that's a must-have for customers in that space over stuff like benchmark scores and bang for the buck.
So technically, IT IS possible to do, just probably not very cost effective for consumer devices.
Do those settings actually work? My HP laptop with a 10th gen intel has an option for this. Windows manages to suspend, but it doesn't come back to life. Linux is broken, too.
As I remember, sleep state are mostly implemented by the CPU (or require the CPU collaboration), and neither intel nor AMD does s3 sleep on their proc anymore.
With 32 GiB of memory it's just too slow. A laptop, to me, is supposed to be a device much like a phone in that I can just flip it open and do what I need to do, suspend is supposed to be that, but if I don't charge my Dell precision every single day it'll just run down to 0 for absolutely no reason.
S0 is a step forward. Disabling CPU entirely is just a "workaround". Both S3 and hibernation has a lot of security implications which S0 solves. Apple uses their own S0 alternative and it works... Perfectly?
The real problem is that both AMD and Intel S0 implementations are mediocre at best and this is what they should fix. Also most vendors are dickheads and cannot even verify that their system even goes to S0ix states without any problem before releasing it. Because of their laziness you can buy brand new certified "Linux ready" machine which won't even achieve S0ix states out of the box.
Wouldn't that mean that Intel Macs would have a much worse battery life than they did while suspended? Even suspended they did better than the same laptop running Linux.
Microsoft is not to blame for Linux’s abysmal battery lift. Linux has never ever had good battery life. It’s the only issue preventing me from replacing my MacBook.
My personal machine is a Framework 13 AMD (first gen of AMD for them) and my work machine is a MB Pro M4. The Mac Book just keeps battery _forever_ while suspended, where as I've found the Framework (running Ubuntu 24) loses about 1% an hour while suspended. 1% per hour is acceptable for me, but the Mac Book's power to performance ration is just insane.
I can't blame Framework, of course. Upstart laptop manufacturer that is open about repair vs tech giant who's spent years optimizing hardware and batteries.
All that said, I'm optimistic for better batteries, better suspend software/hardware support, and more efficient mobile processors outside of the Apple ecosystem in the coming years. The M-series Apple processors are definitely kicking others in the industry into gear.
I don’t think there’s much framework can do about this. The same happens with Windows on HP and Dell laptops, except windows tends to quickly enter hibernation (if it doesn’t somehow hang and burn up your bag).
We used to have better suspend before, when s3 was thing, on both Linux and windows. Maybe not as great as Macs, but way better than the current shitshow. Now I’m not saying pcs are great hardware, but I think this particular issue should be pinned on Microsoft, who tried to copy apple’s power nap, only doing it halfassedly as they usually do.
Does Framework operate at the same abstraction level as Apple? I thought because of scale, Apple can dictate terms from its suppliers to get everything custom. I would imagine Dell, Lenovo, and HP simply don't care enough and Framework and System 76 and the like don't have enough scale to get custom parts or custom code from vendors?
It's up to Framework what level they work at. If they want to make a competitive product rather than just throwing together what currently exists will dictate what they need to do. I would think it would be in Dell, Lenovo, and HP's interest to compete against Apple, but Framework shouldn't let others software that they should have bad suspend functionality.
I really do not understand why hibernate under secure boot is not implemented on Linux and this continues for years.
It is as if the features are implemented by completely different people. But this is not obviously the case since systemd supports both and actively improving both.
Note for me hibernation is a security measure and not about saving battery. I am traveling sometimes with the laptop and risk of theft is non-trivial. If it is hibernated, then it is just a property loss. But with just suspend there is a chance that the data can be extracted. So I configured it to hibernate automatically after 15 minutes in suspension. Surprisingly it has been working reliably with Linux.
To add some context: man kernel_lockdown[1] reads "Unencrypted hibernation/suspend to swap are disallowed as the kernel image is saved to a medium that can then be accessed.". And to my understanding there is currently no way to tell a (mainline) kernel that allows "encrypted hibernate", i.e. no way to tell the kernel that its hibernation disk is "secure".
So its not a direct "linux prevents hibernate on secure boot", its "linux recommends kernel_lockdown when secure booting", "kernel_lockdown prevents hibernate with unencrypted swap" and "theres no well to make the kernel believe the hibernation disk is encrypted", but the result is the same.
You can "just" run secure boot without lockdown. Its a cmdline, you can just omit it.
You can run custom patch sets that add cmdline options so the kernel allows hibernation in lockdown (if you pinky-promise the swap is encrypted).
But neither of these are easily accessible to the average user.
A UKI is a kernel+initramfs+boot-arguments bundle all as a single WinPE/UEFI executable using the "EFI Stub Loader".
You configure your system firmware to execute it, passing no arguments. It boots using the command line you set earlier. It's signed, and verified by the platform secure boot.
It doesn't, it's just another bootstrapping method that happens to work fine with hibernation.
UKI allows you to extend your chain of trust from the bootloader to ramdisk, instead of just your bootloader and kernel. From there, you can enable kernel lockdown and checking of module signatures if you want to.
I think you can do the same thing without UKI (I forget tbh), but UKI simplifies it with one UEFI executable that doesn't even need a bootloader.
The swap file that memory is dumped to during hibernation is on an encrypted disk. Upon wake, you need to unlock the disk before you can resume from hibernation.
This may or may not apply to your situation, but at least some motherboards have an integrated bootloader. You need to register the options with it (via efibootmgr for example). Then pressing a key (check your manual) presents you with the options.
This has worked with both Linux and Widows on all my machines: handbuilt 3rd gen intel with an asus MB, 6th gen with some msi, 10th gen with a cheap Gigabyte, and an assorted bunch of HP Elite desks and books with intel and AMD.
I understand there’s even a way for them to auto detect the options, but since this has been a set it forget it type thing, I never bothered to look into it.
Unless it's a really old SSD, lifetime is so massively extended over 15+ old SSDs, that it's not even a consideration any more. People use consumer grade SSDs for databases which last years, even when mostly full.
I expect many of the servers I have deployed, again consumer grade SSDs, would have more writes in a day than you in a year -- even with several suspends a day.
I cannot of course address the specific model you have, or the size of RAM you're suspending to swap space.
There’s also the fact that some laptops have laughably slow SSDs. I’m thinking my 2020 HP elitebook whose nvme drive is basically always slower than my 2012 sata drives… it takes forever to write the 32 GB of ram to it. It’s actually a better experience tu turn it completely off and on, unless there’s something I absolutely need to keep in its current state.
I was excited to see news about AMD beginning work on ACPI C4 in the Linux kernel (1) – my Framework loses about 10% a day in suspend, sometimes more, which is OK for me but of course I’d love for it to be better!
I authored a patch (I still use it to this day, and I think others do too) that allows this, and sent it to the LKML as an RFC, and was rejected, for some background.
"I've got to warn you that I have an allergic reaction to arguments
that start with "the right solution is really hard, so let's pick the
easier, worse solution." ;)"
Proceeds to continue enforcing objectively worse solution (evidenced by the existence of this entire thread).
Let’s see how long DHH & co can keep harvesting low hanging fruit of Linux laptop problems. I’d expect they’ll plateau soon but I would love to be surprised.
I’m torn between my instinct to classify anything from DHH as mostly hype, my faith in Linux kernel developers, and my cynicism toward Linux kernel developers.
At the very minimum, omarchy and omakub already provide out of the box seamless fixes for all the common issues that are “fixed” but need tedious involved configuration nonetheless.
Honestly, given my experience from distro hopping, I am certain that collecting solutions across distributions and implementing them in one can go very far. It's almost as if distributions contributors too rarely try out other distributions to then steal what the other distribution does better.
Small enthusiast distributions with a bit of a hype can gain good features in by just pulling in knowledgable users missing things from their previous distro - and they can move a lot faster than the Debians or Fedoras of the world can, no committee decisions to be made first.
> On Windows/macOS it just works, on Linux you'll probably break secure boot with it.
The way it works on my Windows laptop is it’ll stay in sleep overnight, then when I open the laptop in the morning it’ll wake up, then hibernate itself, then I have to wait for the computer to turn itself back on. Thankfully this feature can be turned off.
The way it works on mine is that I open it in the morning to find it powered off because it chose to force quit my running applications to apply updates.
That's because MSFT doesn't really do hibernate any more but does "modern sleep" where it functions like a phone with the screen off. It keeps active network connections, downloads patches and keeps checking for notifications and other such nonsense.
BIOS support for proper hibernation has been getting worse too because with MSFT demanding it, there is little reason to continue support.
I've had older laptops that do the sleep->hibernate setup without too much issue but now it is a crap-shoot on if it is even supported in the hardware.
That's because the goal is not to have functional hibernation, but to start up faster. If the goal can be achieved by using less power instead of shutting down the whole machine and restoring it identically and that's easier it's a valid alternative.
You used to be able to edit ACPI tables to reenable S3 sleep but these days they're stripping the functionality from firmware entirely.
For example, HP's enterprise lines have S3 stubs in their firmware. If you enable them, nothing happens, because someone deliberately removed the S3 blobs entirely.
In most cases your kernel will tell you it's "locked down" and refuse to hibernate. In my case - on a cutting edge kernel no less with Fedora - it refused to believe that the default disk encryption setup with Swap on encrypted LVM actually is encrypted and locked me out.
Linux security bros followed Apple and others here and refused to add any ability for us to configure or tell kernel that it's wrong about that and to fscking allow resume.
This stuff just works out of the box on both macOS and even the mess that is Windows.
What's exasperating is that this has been going on for literally 20 years:
> Pretty much exactly 19 years ago I got on a train to Oxford and made Mark Shuttleworth's laptop successfully suspend and resume using ACPI and that was the turning point in my entire career [1]
Windows on my case, since Windows 7, although I kept a netbook with Linux around until it died.
While I can understand random Joe and Jane are at the mercy of reverse engineering while installing a Linux distro over the weekend, I expect that anyone selling Linux laptops as OEM, to actually get the specifications and have everything working as any other hardware vendor.
This is also something that is ideally fixed in hardware. Suspend to RAM should take extremely low energy (about 10 milliwatts). Apple has this down to an art while other laptops have quite of bit of random power draw from motherboard components. A laptop battery should be able to power suspend to RAM for months.
It does not make any sense to write 32 or 64G data to secondary memory every time you close your laptop lid, that will accelerate the lifespan of most SSDs.
This is a seriously annoying Linux problem that never get acknowledged by hardcore Desktop Linux fans. On any Linux thread on HN, one can argue till one is blue in the face, but they will always finally deflect with: it works fine for me on X hardware. Usually, the first response is that suspend works completely fine on Linux and it is Windows that is worse.
That's what I thought, so I disagree with OP, we don't want hybernation for Linux, we simply need way better power management and hardware that can sustain low power drain for weeks.
Mac M series don't do hibernation, probably because sleep has so little impact on battery life (my MacBook lasts for about a month in sleep mode) and Apple doesn't like to burden users with questions like 'what sleep mode to use'.
Ah yes, I think I've seen this before, it still resumes impressively fast from it, and I think since I normally notice the battery is almost dead it gives itself a good excuse.
As I understand it, the complaint isn't about battery life during usage. The issue compared to a mac is that I could close the lid on the macbook air m1 that I'm typing this on mid sentence, and then open the lid in two weeks, and have lost basically 0% battery.
I'm not sure if that's possible on windows. I know my work laptop doesn't work that way, but then, it probably runs all sorts of enterprise settings.
I'm on an AMD machine that System76 wrote the firmware for, and they specifically wrote in S3 sleep functionality despite the base firmware missing it.
The firmware vendor contracted System76 to develop the feature specifically for Linux compatibility.
I'm unaware of how much access Framework has to the underlying firmware blobs. If they don't have source/license/keys/etc for the right parts, they might be at the mercy of their own vendors for S3 support.
> If you can’t hibernate (aka suspend to disk) you will never be able to get that power consumption low.
This is cope. An Apple Silicon Macbook does not need to suspend to block devices to save energy (they only do this when the battery is empty). ChromeOS doesn't offer hibernate at all. The only reason that a Framework can't have good battery life in an operating state is that nobody is paying attention to the details.
Correct. I've got a ThinkPad T480s. Hibernation is disabled, but suspend works great. Keeps charge for at least a week. Running recent Debian. I think that Lenovo, for all their faults, just does better with Linux than Framework.
Thanks, I did not knew that. My understanding was that keeping the memory alive for suspend-to-idle was the main issue here. But that also might be something a vertically integrated Apple Silicon can win vs. that x86 madness there every day.
And to be sure, I do not claim that there is nothing to gain in s2idle. I bet theres still a lot of headroom to safe energy. Its just that it would be easy to safe a lot of power if s2disk "just worked".
Keeping memory alive is how sleep worked for over a decade and is incredibly power efficient.
The issue is that Modern Standby goes ones step further and keeps the CPU and peripherals in low power states instead of just the memory. This will use more power than S3 sleep by default, and each SoC will need deep integration with the kernel for that to ever be power efficient. That means it will require heavy investment from AMD and Intel to enable efficient Modern Standby in Linux, along with heavy vendor investment to ensure each model they sell implements Modern Standby efficiently.
It isn't a matter of Framework dropping the ball, it's matter of hardware platforms being shitty and platform owners not investing as much resources into Linux as they do Windows.
While I don't have any suggestions on how to look at the relevant metrics, a big part of the issue is the parts selection and having them power off properly.
1%/h is just 0.5W (for a 50Wh battery) which isn't a lot, but fail to bring a component or two to shutdown or sufficiently low power state and you'll observe exactly this behaviour. Of course some drain is going to be almost inevitable just to keep memory contents sufficiently refreshed, but with proper power-saving states memory can go appreciably below 0.5W.
Timer coalescing, idle wakeup minimization, race-to-idle optimization, etc.
It's not a single oversight, it's a massive project that needs to be carried out throughout an operating system. Linux's usual advantage of decentralization and wide distro variety with massive customization potential is a disadvantage here. To have a power-efficient system you need all of the software to be working toward the same goal. One bad actor process can completely hose the system's power efficiency.
> Linux's usual advantage of decentralization and wide distro variety with massive customization potential is a disadvantage here.
How so? You need each thing to do its part, but that decentralizes perfectly well because it isn't actually integration at all, it's just a hundred different pieces each doing it right.
And open source has the further advantage that you're not beholden to the maintainer. If Framework notices that piece #37 is wasting power, they have the code and can fix it themselves. If the upstream isn't completely asleep at the switch they'll accept the patch, and even if they are you can still ship it on your own device.
Where this can get messed up is in one of two ways. The first is if something is not open source and then the vendor fails to fix it but also fails to supply anyone else with the capacity to fix it. But this isn't a problem with integration, it's a problem with filthy knuckleheads not keeping their heads on straight and calls for some new competitors to show them how to do it.
The second is something like an actual trade off, e.g. if you want the machine to be able to wake via network packet or pressing a key on the keyboard then you'd need the network controller or USB controller to stay in a low power state instead of being dead off. And then that might cost you half a watt, but you're paying it in order to get something, and then somebody has to decide if Linux users would typically want a default where that feature works or one where the battery can last a month in standby, since it's one or the other.
You’re right that it’s “a hundred different pieces each doing it right” but you gloss over the disadvantage of decentralization: getting everybody on board with the project. With a centralized product (such as at Apple) the CEO can say “I want to increase battery life on existing hardware by 20% before next release or you’re fired” and people will work 80 hours a week to get that done. With open source? You’ve got ten thousand different projects, each with their own leadership and their own priorities. You have no leverage at all to get them all to work on power efficiency, so naturally it takes a back seat to them working on their favourite features.
Because it's not actually a disadvantage, because if it's actually open source no one can stop anyone else from doing it. If you or your company wants to work 80 hour weeks to improve power efficiency on Linux, you can submit patches to all the different projects where nobody else is doing the work.
And that actually happens in real life. Most of the projects care to begin with because they use their own stuff and don't want to ruin their own battery life or have a competitive disadvantage over the alternative. Then other third parties that find business value in having it work pay someone to clean up the odd stragglers when one of them didn't do it or have the resources to do it themselves.
The main problem is when some vendor both doesn't do it and is hostile to anyone else doing it.
And that actually happens in real life. Most of the projects care to begin with because they use their own stuff and don't want to ruin their own battery life or have a competitive disadvantage over the alternative.
Sure, they try not to ruin the battery life, but who is investing the amount of engineering resources into Linux battery life that Apple invests into macOS's? No one, of course, because the ROI of doing that for Apple is much higher than doing the same for Linux. Linux's open nature means that going for SotA battery life does not yield a competitive advantage, so no one does it.
If you or your company wants to work 80 hour weeks to improve power efficiency on Linux, you can submit patches to all the different projects where nobody else is doing the work.
In other words, centralize the battery life project. Who is doing that?
> Sure, they try not to ruin the battery life, but who is investing the amount of engineering resources into Linux battery life that Apple invests into macOS's? No one, of course, because the ROI of doing that for Apple is much higher than doing the same for Linux.
The answer is rather that everyone is doing it. Then most people care about it a little so they do a little, but because it's most people that adds up to being the majority of what needs to be done. A smaller number care about it a lot but all that's left is for them to shave off the rough edges.
> Linux's open nature means that going for SotA battery life does not yield a competitive advantage, so no one does it.
How does it not yield a competitive advantage? If you're Framework, Dell, System76, Canonical, Red Hat, etc., you want people to use your product instead of buying a Mac or some competitor's Windows laptop.
> In other words, centralize the battery life project.
I don't understand how this is centralization.
Suppose Intel does the work to make good open source drivers and make sure their hardware has low idle power consumption, Red Hat does the work to make systemd behave in a way which is power inefficient in the hardware-independent ways, etc. Then Framework does an analysis of where power is going on their systems and finds that Intel and Red Hat did a good job but there's a bug in the third party network controller driver preventing it from going to sleep, so they fix the bug.
Where is the centralization? The work is being done by all different companies who aren't even necessarily interacting with each other. Some of the bugs in third party software are fixed by hobbyists or other vendors. Then Framework is left with a limited amount of work to do and they do it.
The problem comes when they go to do that analysis and find that the thing using more power than it should is a piece of hardware that the vendor both failed to document and failed to provide source code for the firmware, so that no one else can fix it when they don't. In other words, it's caused by a thing that isn't open source.
Something's wrong. Maybe a setting or a random app is preventing your laptop from sleeping properly. You have many threads here saying that MacBooks can go weeks on sleep, and that's also my experience (M1 Pro).
There was a thread about just this issue another day.
I don't daily drive an MBP anymore, only occasionally. But I had one for a week or so, and once or twice I've noticed that my backlit keyboard still had its lights on, which is unusual when the computer sleeps. The screen was dark, though, so it can be confusing.
If the swap file is encrypted and memory encryption is turned on, I don't see why lockdown shouldn't be allowed.
You're already relying on the hardware platform for Secure Boot, it's not far fetched to apply the same view to hibernate if the platform protects memory and disk.
That said, S3 is still a viable option, and IMO, the best option. Some hardware vendors still implement S3 sleep for their Linux laptops.
>power usage in suspend is especially sad because it’s pretty much a common problem for Linux on laptops
I don't know what you're talking about, is this an apple Silcon marketing ploy? my linux laptops lose less battery in suspend than my macbooks do powered down
While I don't deny that suspend is an issue on Linux I've just never seen this as a major problem? I simply turn off my laptop and turn it on when I need it - boot times are less than a minute so it really isn't a issue for me, just flick the power switch, wait for a bit then I'm good to go.
This, so much. I read that comment and immediately recoiled at the idea of waiting "less than a minute" to be able to do anything. I'd estimate that 1/3 of the time I even open my laptop, I'm done with what I needed in less time than that boot up sequence takes and have closed it and moved on to something else. So often I just pop it open, do/check something and close it within seconds.
I go _months_ without rebooting/proper shut downs. And this is on a MacOS install that I've migrated from one Macbook to another for 5 macbooks now O.O
...recoiled... Some people go to work, switch on their computer and turn it off when they leave. I would say most in the world do that. Sure they don't know the diff between clapping their macbook shut or switching something off, but 1 minute does not make people 'recoil'. Very strange.
Totally understandable. You're right that those people are highly unlikely to really care between 2 seconds to being functional and 60 seconds. They're at the coffee machine anyway.
I've been obsessed with building things since I got my first lincoln logs set. I don't "clock out". There's no work computer and life computer, or even more foreign to me, no computer when not at work. I take my laptop nearly everywhere with me and have been known to pull over into the nearest gas station or any parking lot, pull it out and immediately write some code or make some notes due to something I'd just then had some breakthrough or idea about. There's no way I'm doing that if it takes a full minute to boot up and I'm there looking at a fresh rebooted OS. But if I can open it, touch my finger to the fingerprint reader and _immediately_ be productive? Happens all the time.
Hell, I'll walk across the room and open my laptop when my phone is in my pocket because it's just easier to use and it's immediately functional.
Different strokes for different folks, but I'd venture to bet that my experience mimics that of many others.
I'm reminded of this Steve Jobs story: So it's the MacBook Air guy's turn. He comes in and places his prototype down in front of Steve. Steve opens the lid. Two seconds later he picks up the laptop and heaves it so hard it skipped across the table like a stone on water: "I said fxxking INSTANT ON!!"
I know it's poor form to speak ill of the dead in general and of St Jobs in particular, but I do not see how anyone gets much more from stories like this than "Steve Jobs was an ill-tempered dick of a bully" and "power made Steve Jobs immune to getting his head kicked in which is absolutely what happens if you behave that way outside of an air-conditioned Silicon Valley office".
I've never used sleep on my laptop. I always have the lid set to 'do nothing' when closed (i.e., stay on and keep running). In the past I gave up on using a macbook for many reasons, but a key one was that I couldn't keep the machine on when closing the lid. I can't fathom having to reconnect terminal sessions or other similar connections every time I want to move from one meeting room to another. Carrying my laptop awkwardly with the lid open between rooms just seems silly. I just close my lid and let the laptop keep running and then hibernate at the end of the day, resuming the next morning. True instant-on, and no downsides to me.
It's a failing that I need to pre-empt every situation where I don't want the machine to sleep and run a tool to prevent it from sleeping, when I could usually just say 'don't sleep when I shut the lid'.
S3 sleep is a solved problem and security issues around it are solved by Secure Boot and memory and disk encryption.
The issue is that firmware vendors disable S3 sleep in favor of s0ix/Modern Standby instead, which just puts hardware into low power states instead of stopping them entirely. This will inherently drain more power over time than just keeping memory powered in S3 sleep.
Modern Standby requires heavy integration with the OS to be power efficient. Turns out that takes a lot of reverse engineering because vendors will not release documentation or tune the kernel for their firmware.
Not just laptops but affects computers too. I have a brand-new Mini PC with Windows 11 and when you turn it "off" it continues to pull 6-10 watts. Not a lot but still over a year if you were to only used it minimally that's 52-83kwh or around $25-45/year at PG&E rates. Vendors are removing support for classic standby/hibernate so the only way to go to <1 watt is to pull the plug. It shouldn't be this way.
My thinking is that Microsoft is basically the most influential in that, as they badly want to do their "stuff" while the laptop is not in use. Their "stuff" requires network connectivity and seemingly they believe they can do updates, or any other "optimizations" when the laptop is in "modern sleep" mode.
I'm surprised this required implementing a whole new sleep mode. Since it seems to be mostly used for async background tasks, why not configure the RTC to wake the laptop every hour or so (I think every laptop in existence already supports suspend with timeout) and go back to suspend if no tasks need to be done?
My main use for laptops is as a notepad. If it takes a minute to start when I need it it's vastly inferior to a sheet of paper. If it can't remember what page I was on that's doubly so. Windows works more or less like a sheet of paper (though automatic reboots to apply security updates are a point in favor of paper that has no such issues.)
And I often use my laptop for things where seconds matter. I've got things on the stove that could burn, I may not have 5 seconds to spare locating the next step in the recipe.
For those use cases that I love my Chromebook. Underpowered, yes, but also it can basically sleep forever and also wakes up from sleep fast. Even if I need to turn it on if it is powered off it takes just a few seconds to boot.
There are often browser tabs and other documents windows I would like to keep openers and I want to jump back to exactly where I left off as soon as possible.
Let me preface this reply with that I'm not trying to preach or tell you how to live your digital life - everyone is different and if you have setup that works for you then great, keep on trucking.
That said, I worked the same way many years ago, with browser tabs and desktop sessions that were precious and I didn't want to drop them. But what I ended up realizing was that the stress of losing that state due to random power failures or software bugs was too much. I found it far better for my sanity and actual productivity to instead make sure I had a sane note taking system, where I could track what was actually important to me.
It was a great relief to my mental state and general stress to allow myself to shut down all processes and start clean every day.
While I understand your perspective here - let me counter with mine. I have the same issue where I maintain a 'state' that I'd prefer to maintain but my interest in maintaining it does have this anxiety you describe.
It's just a huge waste of time to get it all back. I see it no different than being in the middle of a heavy coding/mental task and being interrupted to the point that you have to 'start over' in the sense of getting all that context back in the right places.
Sure, I _could_ neatly close everything out and have a pristine perfect work/desktop environment. But, personally, when I see the work/desk environment of someone and it's absolutely pristine all I can think about is how they're spending energy to maintain that.
To give another example - in my workshop (woodworking), if I'm in the middle of something and need to take a break/leave the shop... I'm not putting _anything_ away. I turn off the lights and walk out. That way when I return I don't have to set everything back up. Now - when I finish something, then I go through and clean up and organize and get the state freshened up. Same thing with my laptop/computer.
Zero anxiety about it all - it's not about losing anything but time. And that's what's most important.
When I moved to Obsidian, I created a great note taking system that I use to track all my research. I didn't realize until you said this that I don't need to have my applications open any more because of this. Wow. Out of sight, out of mind I guess.
As someone who’s using steam daily for probably 50-75% of their lifetime now: I don’t love them, but it’s the lesser evil for sure.
Sure, if GOG had even 20% of steams catalog and useability, it be no. 1 without question. But since we‘re sadly limited to this one reality, there is no alternative.
XBOX GamePass is a trap I expect to spring every day, Uplay and EA Origin are just a splash screen I see when starting a game in steam, and I almost forgot the epic store exists, despite their “free game”
Marketing campaign.
It’s not perfect, it’s anti-consumer way to often, and it’s for sure a monopoly’s, but steam is still my favorite poison
And yes, if they decide to disable me account and cut me off my pile of shame I will have an impact.
But owning games does not seem to be an option generally. Exceptions exist, ofc.
GOG is great but I'd like them even more if they did some of the wine/proton work that Steam does for Linux users. For the dosbox games at least it's not much to do (for them nor for myself to be fair.)
Steam is simultaneously hard to like, as a DRM service, but also hard to dislike as they put so much care into getting games running on Linux and have a very reasonable return policy, full refunds for the game not working makes it easy for Linux users especially.
I won’t complain about anyone investing into wine/proton. GOG/CDPR just seem less willing or less capable of spending that money.
Valve is essentially printing money. From sales, but also from other, morally less likeable sources like gambling. It’s nice to see them spending at least a tiny part of this in ways that serve the greater good (besides their own business).
Same point: it’s not good, but that’s reality for you.
To be clear, there are many games on Steam without DRM. It's up to the publisher whether Steam DRM is used or not (or if any other 3rd party DRM is used, for that matter).
I suspect almost all of the games on GoG, if they are also on Steam, also don't have DRM on Steam.
DRM and especially 3rd party launchers are both things that get me to skip games on Steam. I wish Steam made it simpler to just filter those games out of your store view.
I’ll never get over the hypocrisy of people loving steam and its exclusives while hating EGS and its exclusives. I’ve never seen an almost purely tech-focused crowd pull so hard for a monopoly before.
Yeah, I can't think of any explicitly Steam-exclusive games off the top of my head, other than maybe Valve's own titles.
Given Steam's history and market position, they don't need exclusives at this point. I do remember the likes of Outer Wilds and Final Fantasy 7 Remake being EGS exclusives for the first year of their respective PC releases.
I think „manipulation“ may be to strong of a word here, since it assumes intent to manipulate, which is not necessarily to focus on „out of the ordinary“ events. But I think nonetheless that this infographic is interesting and important, because it reminds us that these biases exist and how big they are.
reply