I was disappointed when Microsoft dropped original WSL.

I'll admit I wasn't a Windows user at the time, nor since for that matter. But I had been before.

I knew the history of the "Windows Services for UNIX" and thought that it was incredibly interesting to have the Windows kernel, full driver support, NTFS, and the ability to just use Windows normally, but also be able to just do UNIX-type stuff more or less normally.

Which is what I've been doing on my Mac since the early 2000s.

Then Microsoft had to make Windows a complete shit-show. Not like it hasn't happened before, but they really got themselves in deep this time.

> Tbh, though, the only computer I've ever seen Hibernate work well on are Macs. Every x86 computer usually has some sort of issue with it, except for maybe business laptop models (eg HP's Elitebook line).

This has always been my experience, going back I'd say at least to the early 2000s on cheap laptops, and all the way back to the earliest days of sleep and hibernate on desktops, where sleep just doesn't matter that much.

When I started dabbling in boot code around 2006, I read a bunch of the specs and one of them was ACPI, which I only scratched the surface of.

I think until then it had just not occurred to me that a modern paged protected OS would even want to call into any code supplied with the computer, vs. having it come from a driver disk, or be built in to the kernel where everyone can see it.

The whole idea of a bytecode interpreter running random code supplied by a fly-by-night system builder is a little unsettling.

I've only had batteries leak in remotes left unused for over a year. I just pick up Duracell or whatever is at Costco.

I've also bought two replacement remotes off of Amazon in the past year, one Samsung and one Insignia. I think they were $15-20 each, which seemed very reasonable to me.

Generally they won't have the manufacturer's logo, but everything else on the outside looks 100% identical, and all the buttons worked.

How long does the breakdown take?

Coke used to be mixed, bottled, and shipped out in an extremely quick timeframe. Inventory turned over fast.

I suspect the separated components wind up being equal to what a stale soda has, one that has been on the shelf. It’s like buying a soda whose sugar component has already gone stale.

Sure, the rest of the flavors are there and still fresh, unaffected by the carbonated water, but the sweetness one is off.

Correct.

Whoever downvoted your comment has either never driven this stretch of the 5 or they are the reason it is so bad.

It’s the idiots in cars who insist on doing exactly 65 in the left lane next to a semi that cause the problem. Get past just one idiot holding back hundreds of cars and you will find miles of completely open road.

Its all of those rolling hills where you are going up and down over and over. People don't pay attention and let their car slow down up hills, then let their cars roll up to 90 going back down the other side. Do it over and over and you get the whole centepede effect, except cars far enough back have to practically stop.

Did people just forget the era of CD burning? Cassettes sucked.

Normal non-tech people were ripping CDs with iTunes. "Rip. Mix. Burn." was a nationwide if not worldwide advertisement.

All of this still works, if you have a CD drive.

If you're going to bother buying a cassette player... what's the allure for that over a CD-R and a basic CD player. CD players in cars are going away, but they're still around in houses and inexpensive small boomboxes.

But then... what's the allure of that over say any old audio player that takes SD cards or just a USB stick. A lot of modern cars and also stereo receivers and TVs will take a USB stick and play files from it. These players are incredibly prevalent and very easy to use. And loading the music from a computer or even a tablet is easy.

Of these three, cassette is the absolute least likely to be available anywhere.

You can still have the experience of making a playlist and even putting the files on a USB stick for someone. Importantly, they can actually play it on their own listening device.

CDs skip very easily so they're not good for portability. So that limits their use to in the house, and they're you're competing with vinyl. Cassette fill a niche in the nostalgia world being something you can more easily use on the go.

I had lots of CD and mp3-CD players with good anti-skip. Some would even buffer enough or the song to stop the CD for several seconds at a time, especially so on my later mp3/ATRAC CD players. The crappier ones added crappy audio compression to fit it's tiny memory, but better ones could do the raw data and had no (at least to me) loss in quality and later the mp3/ATRAC ones would just buffer the actual file data.

I don't think I've ever experienced a car CD player skipping due to shock. I'm sure it could happen, but I don't do much trail driving at high speeds personally.

I listened to my CD players while biking, hiking, and more. No reason to leave the CDs at home unless you already upgraded to one of those fancy hard drive mp3 players.

Yeah it was probably around 2003 I listened to all my music on MP3 CDs I made and it had like 30 seconds solid of buffering that I never managed to hit unless I sat their purposefully shaking my player in my hands to watch the buffer meter go down.

There were many portable CD players with enough buffering that they'd never skip. Panasonic Shockwave (IIRC) for example. And car heatunits.

You had to get a very old or seriously cheap portable player to get skipping.

Cassettes get distorted too when moving (.e.g running). There’s very cool tech in some models that prevent this distortion but they are more expensive.

This is a time-tested winning strategy that too few corporate owners embrace.

When you look at some of the most well-known industrial companies, their founders basically did this.

Difficulty: give away too much of the company trying to raise capital and most investors won't let you do this. Of course, you aren't really the owner then anymore, are you?

I think that's the allure of effective altruism. You founded a company or were early enough in a company to have enough shares to sell to investors. Those investors want big returns. The company is now at their mercy, but hey, they gave you a pile of cash so you can spend it on feeling good.

It's been a long while since I did anything with UEFI, but my recollection is that the standard data structures are reasonably well documented, especially when they are meant to be part of booting an OS

I imagine that whatever UEFI extension implements loading a disk image over the network probably also implements some way of knowing where the sectors are in RAM so that the OS bootloader can choose to hand off access to the memory disk to the OS.

Is such support implemented in any bootloaders? I have no idea. My guess is probably not because people would rather just have the bootloader use the available services to download the disk image itself.

True PXE doesn't require coordination with the DHCP server.

https://en.wikipedia.org/wiki/Preboot_Execution_Environment

The network client boot stack sends a DHCPDISCOVER as a broadcast. Any machine can be listening on UDP 67 (bootps) for this. The real DHCP server responds with the DHCPOFFER containing the IP address the client should use. Around the same time, the PXE server responds with its own DHCPOFFER that does not issue an address, but does contain the values for the requested DHCP options.

The client basically keeps broadcasting DHCPDISCOVER until it gets both, then it does the unicast DHCPREQUEST and wait for unicast DHCPACK with the normal DHCP server.

Now, that said, I've only ever seen this work with commercial PXE servers like Microsoft RIS. To my knowledge, ISC DHCPD is unable to send a DHCPOFFER with options but no address. But my knowledge is at least a decade out of date.

At home I just set the options on the main DHCP server like every other hobbyist does, but this isn't true PXE, this is just plain old DHCP+TFTP remote boot.

Let's say you do have such a server that sends DHCPOFFER with the options and no IP address. If it's on its own machine, then it can listen on port 67, same as the real DHCP server on another machine. But, if it's on the same machine as the DHCP server, it has to listen on port 4011. In this case the client behaves a little differently. For this to work, the DHCP server must send as part of the DHCPOFFER an unsolicited option 60 to indicate that the client should go ahead and accept the IP then send a second unicast DHCPDISCOVER to port 4011 and await a DHCPOFFER from that port. Option 60 is only needed, and can only be used, if the independent PXE server is running on the same host as the DHCP server.

So there's basically 3 scenarios: * Hobbyist: just configure the booting options on the real DHCP server * Real PXE, separate machine: Both real DHCP and PXE listen for broadcast DHCPDISCOVER and respond with complementary DHCPOFFER. Real DHCP server has no knowledge whatsoever about booting. * Real PXE, same machine: Real DHCP server responds with unsolicited option 60 no matter what. This is the extend of its knowledge of booting. Separate PXE server runs on port 4011 instead of 67, and everything is unicast.

There may finally be hobbyist projects that support this model, but when I last did this stuff, there were not. Learning how RIS worked was a revelation for me, and it really made me wonder why the hobbyist community of the time seemed hellbent on not doing PXE correctly, which annoyingly requires control over the options set by the real DHCP server, and often makes it impossible to do fun stuff like use different boot files for different clients.

Bill Kristol is the same asshole he always was.