Captain Steve discusses mental health issues amongst pilots during his discussion of the AI events after this most recent news. He's a trained counselor who got into counseling pilots exactly because of mental health issues he's seen with colleagues and students https://youtu.be/MD64uYK926o?t=742 .
If you work in a job where the lives of hundreds could be ended in seconds due to an error or intentional action then there is no excuse to not have critical control surfaces recorded at all times. Non-commercial/private flights/flight instructors and trainees have cameras, trains have camera, stores have cameras, casinos have cameras, buses have cameras, workers who work for ride hailing services have cameras as do millions of other people who just drive.
Hopefully other countries will start deploying recording systems or start forcing manufacturers of planes to have these integrated into cockpits.
TX for this! My older kid and I are learning Rust with Rustlings, but this will help me add a physical element to it (even though it's simulated), eventually we may get an esp32. Younger kid loves doing Microsoft microbit, he will definitely be interested in this.
This kit connects a BBC Microbit v2 to a USB-chargeable Li-Ion battery on a mountable expansion board with connectors for Motors for LEGOs ® and a sonar:bit ultrasonic sensor:
"ELECFREAKS micro:bit 32 IN 1 Wonder Building Kit, Programmable K12 Educational Learning Kit with [MOC blocks / Technics®] Building Blocks/Sensors/Wukong Expansion Board" https://shop.elecfreaks.com/products/elecfreaks-micro-bit-32...
> For future people who come across this issue: you can still simulate Rust on Raspberry Pi Pico with Wokwi, but you'll have to compile the firmware yourself. Then you can load it into Wokwi for VS Code or Wokwi for Intellij.
This is amazing work! If folks have ever wondered why suspend is so difficult to get working on linux and why debugging it is equally difficult, this is a single datapoint with lots of information about all the things that can go wrong. Even now I have a thinkpad P1G4 where the fans won't turn off automatically unless I turn them off before going into suspend. Recently I also started having crackling issues with my bluetooth headphones after resuming from suspend and had to disable node suspension there also (https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_d...).
Remarkable that it's 2025 and laptop sleep/suspend still doesn't work right on linux. I think the first time I encountered this was probably 15 years ago now?
Power control is the kind of stuff that benefits from very tight integration, and PCs just don’t have that.
Firmware is seen by most vendors as a pure cost to minimize, so you get a fragmented market full of subcontractors delivering the bare minimum that is considered “working”. Manufacturers also know most people aren’t going to use a big part of the functions they’re supposed to provide to OSes, and no one is really checking them, so it’s very common for devices to have only partial support for things they supposedly do.
Even Apple struggled to get it working perfectly in my experience across several models in the PPC/x86 era. Yes they are better(-ish) but when I had Apple laptops I'd still see weird sleep/wake issues in around 1 in every ~50 sleep/wake cycles. I also had one Apple laptop which had its battery going from 100% to 0% overnight during sleep requiring a cold start in the morning on a regular basis despite it being put to sleep the evening before and seemingly going to sleep without issues. Lenovo manages to do sleep/wake fine in Linux almost as well as Apple in my experience and I sleep/wake my Lenovo laptop regularly -- this is across two different models I have used so far (X1 and X390). Hopefully Apple has improved this in their ARM laptops but haven't used them much so can't really comment on ARM.
Even now on ARM it's not perfect. my M1 Mini will wake from sleep to a greenscreen and then crash/reboot ~once every few months, irrespective of uptime.
My work mac (M1 Pro) occasionally locks up and reboots when waking from sleep too, at about the same frequency.
Always wondered why this was such a difficult problem to solve, seemingly irrespective of operating system. (Linux has never been acceptable or reliable in this respect, IME, regardless of distro and hardware configuration.)
I've never had an issue with wake/sleep on any of my M1/2/4 devices. The only issue I can ever recall with sleep was the 2019 16" Intel (which had a host of issues).
> Lenovo manages to do sleep/wake fine in Linux almost as well as Apple in my experience and I sleep/wake my Lenovo laptop regularly -- this is across two different models I have used so far (X1 and X390).
I'd rate my OpenBSD X1 as not terrible too. Not as smooth as MacBook but adequate.
I always had the suspicion that this has more to do with a lot of kernel hackers using Thinkpads, so they fix them up, rather than Lenovo doing a good job.
It’s much better on ARM. And their external monitor support is so much faster and reliable now. Having control over all their hardware has made a noticeable improvement.
This is not my experience. My M1 Pro MacBook has very strange issues with sound over HDMI. I usually need to reboot it when I connect it to my TV or media won't play if the sound is output over HDMI.
I don't think so. In that state, video will jump and stutter wildly, run very fast, and audio will be very broken. It's not just the sound that's affected.
Which all could be caused by a broken HDMI implementation (refresh, synchronization and audio are all encoded and synchronized).
But of course I could be wrong and every M1 Mac has severe issues connecting to HDMI TV's.
I've tried a recent LG OLED, and a bunch of other TVs at friends and it happens every time if the laptop has been sleeping previously. If it's a fresh boot it never happens. That leads me to believe it's something on the laptop side.
I was amazed when I got an 11th-generation Intel NUC and it didn't sleep/wake properly.
I would have expected it with a cheap clone, but this was a fully integrated computer made by the same people who designed and manufactured the processor itself!
I can't remember if it ever fixed it - maybe after a year or two there were finally newer EFI and graphics drivers that fixed the issue, but maybe it never did? In the end I ended up getting a newer machine to replace it anyway and it became my home server so just runs Proxmox now and doesn't need to ever sleep...
I know the NUC I had had it's ethernet port put PERMANENTLY to sleep.
There was, eventually, a Windows program which hacked the device to take it out of sleep. But I had no Windows OS on it. Before I got around to installing enough Windows, the NUC died for other reasons :-(
Or Macintosh. My $DAYJOB Macbook sleeps properly about about 2 out of 10 times, at best. Most of the time it fails to sleep and by the next morning when I open it up, the battery is dead. :-(
For comparison, my System76 laptop running PopOS! sleeps perfectly, every time with no issues. shrug
> My $DAYJOB Macbook sleeps properly about about 2 out of 10 times, at best. Most of the time it fails to sleep and by the next morning when I open it up, the battery is dead. :-(
Important to remember that work laptops typically install all sorts of crap spyware and fleet management software that causes the system to misbehave. That’s not as much on Apple although not protecting their brand against such software is on them.
Good point. And this machine does have the typical stack of enterprise spyware crapola. Curiously enough though, sleep / suspend do work occasionally. Just not consistently.
What's strange is that it never used to be a problem. There are five Windows laptops floating around our house at various times (mixture of work and personal) and suspend works properly on none of them. Oddly, it works on my personal laptop with Debian Stable almost every time, failing maybe 1/25 times. Other distros are about the same as Windows.
Modern Standby. Windows wanted to do the Apple "power nap" stuff, but never realized how painful it'd be if you don't control all the hardware and have millions of different hardware permutations (with a lot of terrible drivers) instead of just a few. Not that it would've helped, half the time my machine is either overheating or off it seems to be wake timers doing windows updates (which yes, you can disable, but most wouldn't).
I don't get why S3 sleep had to die for this, but it did.
Because you don't have to reinitialize hardware if you don't shut it off. Which is hard and causes problems. It's easier to just go into power saving++.
> Windows wanted to do the Apple "power nap" stuff
On Linux, you can run a systemd unit file that will trigger `rfkill` on sleep and a different `rfkill` invocation on wake and you effectively dodge all that crap because the laptop isn't connected to WiFi and thus will sit around realizing its spinning its wheels and wil shut down further down the s0 chain.
> I don't get why S3 sleep had to die for this, but it did.
Worse yet, the dirty little secret is that many laptops that offer both S0 and S3 will actually drain more energy in S3 than in S0 because the S3 mode has had poor QA.
My colleague showed me his windows machine recently. The rubber on the back around the fans has melted from the times he forgot to shut it down and sleep didn't trigger when he packed it away in his backpack.
Linus tech tips on YouTube did a video about a windows bug where sleeping while charging would allow the laptop to wake up to check for updates etc but often caused this issue of turning on in a bag
It wouldn't happen that this feature was released around early/mid 2020? Windows sleep used to be semi-reliable but one it's been shit for a couple of years.
Search "LTT Windows Modern Standby" on YouTube. Sadly all the workarounds to turn it off no longer work reliably. For reliable sleep, buy a Framework (only current Windows laptop that still supports S3 Sleep) or Macbook.
Are there issues in Windows? Sure but if you give me 100 laptops, 80% will do this right without any issue. Maybe 30% of those laptops will work right on any Linux distro without major fucking around with bullshit trying to make it work.
Yes those numbers are made up but I have been running versions of Linux since Slackware in the 90s.
I still have a desktop with an amd cpu and nvidia gpu that I can’t get to sleep/suspend right. Works fine when dual boated in windows.
I just gave up and manually do shit now when using Linux
Oh no, Windows Modern Standby is infamously terrible and unreliable. Here is a youtube video with millions of views explaining the problems in detail: https://youtu.be/OHKKcd3sx2c
This space is problematic enough that you could reliably segfault 2017-2019 Intel MacBooks by closing the lid before unplugging HID peripherals, preventing suspend (and cooking it in your bag on the commute home).
It also plagues Windows on custom PC builds, even when there are vendor drivers. Not every component plays nicely with suspend states, ASPM, C-sates, load line calibration, etc. And while often the capability exists natively to address issues (in BIOS, Linux, etc), how many people know how to start looking?
Hmm I thought that was a feature, not a bug. I used to leave everything plugged and close the lid if I wanted big downloads to keep going or wanted an even quicker start up.
My custom-build desktop had an issue with the previous AM4 motherboard I had where if you told Windows to hibernate, the entire machine would shut down as normal, but then a few seconds later it'd wake back up by itself and unhibernate. I had to turn off the PSU power switch during those few moments to keep it in hibernate mode. New mobo and that's gone now. BIOS updates never helped. Really odd.
After my (closed) gaming laptop started making annoying Windows noises earlier today, I'm led to believe that it doesn't work properly on Windows either.
It seems like it's basically hardware whack-a-mole at this point. The only reason Apple does it reasonably well is they control more of the stack and they support less hardware. The only reason Windows does it better than Linux is they have more eyes on it.
The reason it works better on Mac and windows is because they're designed to be desktop OSs. On Linux the funding goes to things cloud services and Android use, which decidedly does not include suspension or other desktop features
The article we're replying under has the author working with Mario Limonciello, an AMD employee and kernel developer.
I've interacted with him countless times on the kernel mailing list and bug tracker, he's literally paid by AMD to work on Linux support for AMD's consumer desktop hardware.
It doesn't work right on Windows either to be fair. With a mixed laptop fleet at work, we've just disabled sleep/hibernate company wide because it causes way too many problems.
I mean I totally get it. At the end of the day I have a billion tabs open and 14 instances of notepad. But after getting burned by sleep failing enough times, you gotta change your habits.
Firefox preserves opened tabs on close/re-open, and so does Notepad++/Sublime (and for those, it works even for tabs you've never saved as files). And let's be honest, losing most of those browser is inconsequential.
So while I get the "I just want sleep to work, dangit" attitude (it really should just work, to be honest) the fact is that it barely does work. Seriously, it took this long to realize that VRAM contents may not fit into RAM entirely, so powering down the drives that hold the swap should probably be postponed to the last moment.
That won't restore my 3+ neovim instances, including loaded buffers, associated undo trees, tabs, and splits. Neither will it restore the various PDFs I have open, the file browser instances pointed at specific locations, nor the containing window and desktop layouts for all of that.
It's pretty unbelievable when you think about it. The majority of mainstream progress on application state management has taken place in mobile operating systems and essentially amounts to the expectation that you won't lose data if and when your process is unexpectedly forced to terminate without user interaction. Forget actually picking up exactly where you left off.
And as long as I'm complaining. All of my sshfs mounts tend to break if I sleep-wake as well. Remounting them generally doesn't fix programs that were using them (for obvious reasons) - I usually have to manually close and reopen all of that.
LOL yeah... this always makes me laugh. I always get the "well it should work". My response, "Well, should's don't mean anything when it comes to computer technology". People want to conform to what the technology may be able to do, instead of working around it when it can't do what it designed to do, its a huge time sink for most people.
Just change your fucking habits and move on. I think Linus Tech tips complained about a unrelated but equally frustrating issue with S0 awhile back. I fucking hate S0 it makes me feel like tech companies are trying to force people to have always on computers by removing S3 support entirely from modern hardware.
If you have a modern machine with S0 sleep, which is "modern standby" it's very much solved. What it does is it pauses all userspace processes, disables all cores but one and keeps it running on the lowest frequency. The system stays "on" but all devices go in power-saving state which is good enough for days.
So it's not really a problem unless you really wanna do deeper sleeps.
My honest experience is that S0 is a godsend, when you use a device on a weekly basis S0 is good enough and it just works, no messing and fiddling and tweaking, just running.
Chasing "real sleep" gives me nothing but pain. Also Android devices "sleep" fully awake so it's really "what people are doing".
Recent Windows laptops have even more issues. My wife literally never suspends her Windows laptop for this reason. Meanwhile my Intel/Nvidia laptop running Debian works flawlessly (albeit with Nouveau drivers, gave up on the proprietary ones for reasons unrelated to suspend).
It can be really hit-or-miss, and it can be really hard to debug errors like in the post.
A lot of workarounds that are suggested for various issues are also not really viable. Some of the workarounds involve turning off different power-saving modes; however, the point of enabling sleep is often to increase the amount of usable time between charges, and turning off these power-saving modes can often dramatically shorten battery life.
But getting sleep to work (even S0ix!) is not impossible.
I have a bunch of handheld AMD 7840U and AMD 8840U devices that I have installed Arch Linux on: GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3, OneXPlayer X1 Ryzen. These devices were not designed with Linux support in mind. I would be very surprised if the companies that made them ever tested them with Linux. Yet with just a small amount of work (generally fiddling with `/proc/acpi/wakeup` and `/sys/devices/*/*/*/power/wakeup` to disable sources of spurious wakeups,) I have gotten essentially flawless S0ix support (… on all but the newest OneXPlayer X1 Ryzen.)
(In general, out-of-the-box stock Linux kernel support on these devices is fantastic. Touchscreens work, pen input works, wifi and Bluetooth work well. The only gap I've seen is fingerprint reader support.)
I suspect that given how small these manufacturers are (and how small their production batches must be,) there's much less extreme-customization and tight-integration of components. This is visibly evident in the form-factors of these devices, which many millimeters thicker than they might otherwise be. (Of course, these devices are primarily advertised to a gaming audience who are eager to avoid the thermal-throttling that happens with ultra-thin devices like Surface Pro…) I partially suspect that the lack of extreme-customization, the lack of tight-integration, and the smaller production batches means that the manufacturers make much more conservative choices in components. Maybe this explains the exceptional Linux support?
To add: for the end user, the way to easily get working suspend is to buy known-good compatible hardware.
It's been solid on every business Thinkpad for a long long time for me and consistently seems people on Windows with the same models have more sleep problems.
what you're telling me is that SMCI doesn't care if NVDA or INTC or even AMD outperforms on their hardware, they'll make axes and shovels for anyone and profit either way :)
There's also this : https://www.reuters.com/technology/cybersecurity/cyber-secur... , this hack caused by malware from 2021, caused huge portions of their employee base tied to optum and their change healthcare acquisitions to be unable to work for days (and it's still ongoing!). I guess their employees got a "vacation" out of it while everyone else waiting on prescriptions at CVS, etc got shafted. It literally took a huge portion of the US pharmacy network to go down for the US to realize what a big problem UNH is.
Former Optum/UHG employee, worked in automating things in IT. While I was there they went on a years long spree to get rid of everyone under 40. I finally got laid off and in my group of 153, 17 were under 40. I had automated most everything in my area,and although I meticulously documented everything, when you get the plug pulled like that you don't get time to do any hand off, so it hit things pretty hard. They did this for months (laying off people under 40). They gave me a large enough severance to cover a long time out of work, and the severance agreement stated if I sued for EIRSA I had to pay it back. I took it, but the entire thing painted a picture of management totally disconnected from the people putting code to programs.
We were later in contact with an account that we blocked who claimed they were
using their account to perform automated scraping of our results, which is not
something our terms allow for."
Set QPS limits for every possible incoming RPC / API / HTTP request , especially public ones!
We had a search function with typeahead abilities. I had intentionally removed the rate limit from that endpoint to support fast typers.
One day around 6AM, someone in Tennessee came into work and put their purse down on their keyboard. The purse depressed a single key and started hitting the API with each keystroke.
Of course after 15 minutes of this the db became very unhappy. Then a web server crashed because the db was lagging too much. Cascading failures until that whole prod cluster crashed.
Needless to say the rate limit was readded that day ;).
This is a reminder that "we want to support bursts" is much more common thing than "we want a higher ratelimit". Often multiple levels of bursts are reasonable (e.g. support 10 requests per minute, but only 100 requests per day; support 10 requests per user, but only 100 requests across all users).
There are several ways to track history with just a couple variables (or, if you do have the history, but only accessing a couple of variables); the key observation is that you usually don't have to be exact, only put a bound on it.
For history approximations in general, one thing I'm generally fond of is using an exponential moving average (often with λ=1/8 so it can be done with shifts `ema -= ema>>3; ema += datum>>3` and it's obvious overflow can't happen). You do have to be careful that you aren't getting hyperbolic behavior though; I'm not sure I would use this for a rate limiter in particular.
