Both of these oddities were addressed over 25 years ago when Mac OS X 10.0.0 "Cheetah" was released.
Many of the innovations of Mac OS X have been lost in later macOS, but this one stuck. Instead of saying literally "Program" it is the bolded name of the application. This serves the dual purpose of also identifying which program's window is active. Inside the application menu, you'll find both Preferences (now Settings) and Quit.
I'm trying to figure out if you are a Mac user taking a swipe at Windows or if you are genuinely unaware that more or less exactly what you describe has been implemented in a shipping product for over 25 years.
Are you sure IBM didn't care about 8080 compatibility? The PC was released in August 1981, a full 4 years before any of the other machines you speak of. That XT 5160-078 you speak of is a cost-reduced model with no hard drive from IBM, allowing dealers to install a compatible hard drive from a different supplier.
By 1985, the PC AT (286) had already been out since August 1984. And the original XT was October of 1983. And the XT itself is literally the same as a PC with more expandability: 8 slots instead of 5, beefier PSU, room for a hard drive.
It's unclear if IBM or for that matter anyone would have been able to start designing a 68000-based machine and bring it to market by the fall of 1981. Sun brought the Sun 1 to market in May 1982, so about 9 months later, and with a much higher price.
And what did the Sun run? UNIX. What did IBM run? Quick ports of the last several years of CP/M software made possible because DOS 1 was specifically designed to implement a CP/M-like API, and the 8086 was specifically designed to allow porting of 8080 assembler code directly to small model 8086 code.
Bribes are a feature of politically-controlled economies, not a bug.
Thirty years ago when this was all going down, I believed the narratives of the time. Greedy Bill Gates and Steve Ballmer pushing IBM's OS/2 out of the consumer market with aggressive DOS and Windows OEM deals.
I mean, they absolutely did do that, but I think the motivation was competitive survival.
The Steve Ballmer interview really shed a lot of light on this, particularly the portion about the IBM and Microsoft OS/2 divorce: https://youtu.be/CYC49_aeop0?t=1476
It was drop DTR. Most current documentation tells you that dropping DTR means the modem should hang up. That was an option, maybe even the default. But you could AT&D1 to make dropping DTR return you from data mode to command mode. It's so important there's even a DIP switch on the USR Courier to enable this mode.
I almost can't believe the USR site is still up. This is something I remember doing to run a BBS over 30 years ago. I still have my Courier with the brass not for resale plate.
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.
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.
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.
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.
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.
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.
Except it isn't a fact-check at all. As usual, Paul Krugman is light on real details and heavy on cherry-picked facts to suit his own personal narrative, not unlike Trump.
Canada's advertisement aired during one of the World Series games, after Trump's initial tweet. As others here have commented, Reagan's position was more nuanced than "tariffs bad", which is how the ad portrays it. Krugman himself admits this in his own article.
Then Krugman goes on the usual ad hominem attack against Donald Trump, because he just admitted that Reagan was in favor of using tariffs to settle political disputes, particularly in response to countries leveling tariffs against the U.S.
Which, mind you, is exactly what Donald Trump says he is doing, raising tariffs on Canada in response to several long-standing tariffs they have had on the importation of U.S. goods. Krugman doesn't dispute this. He cleverly doesn't bring it up at all and instead calls Trump a petulant child levying tariffs for his own political purposes.
Forgive me if I can't take Krugman or anyone else parroting Krugman seriously when he hasn't been able to make a soundly reasoned argument in decades. These low-on-facts high-on-rhetoric articles are empowering Trump.
It's common for wake-on-LAN clients to send UDP packets to port 9 to make sure they get discarded. This is particularly useful if using a multicast or broadcast destination, which is often the case because the ARP entry will have been discarded by the time you need to send the packet.
The hardware that looks for the magic packet ignores the framing.
I certainly wouldn't run a TCP discard service, but making sure that UDP packets to port 9 do not result in any ICMP port unreachable response, or any other response, is a good practice.
It's not just the nullability behavior. My experience with several databases is that IN is always (or almost always) executing the subquery then using its results to match the outer predicate. But EXISTS can work the other direction, matching the predicates from the outer query then passing those keys into the exists, allowing use of an FK index on the inner query's table.
This was an especially interesting read, having lived through using these versions of OS/2 on varying hardware.
I think the unfortunate answer is that two if not three drivers are going to have to be written to support the differing generations. GRADD to satisfy Warp 4 (and 3 w/ FixPack) is probably the easiest and most useful.
The way I see it, if I want to have some Workplace Shell nostalgia, but with modern amenities, I'm ok being limited to at least Warp 3 + FixPack. OS/2 2.1 and 3 are hardly different. A few colors changed for the better, and you gain the application's icon instead of the circle. Warp 3 still has the floating launcher thing introduced in 2.
Having to track down all the FixPacks to make the system work on hardware even slightly newer than what was available when that OS/2 version first shipped is part of the nostalgia. Put a 28.8k modem simulator in there, and we can really party like it's 1994.
Along those lines, if I really want OS/2 version 2 nostalgia, how badly do I want modern amenities like high-res, high-depth graphics? Whereas for OS/2 version 3 or 4 nostalgia, I would like to experience what those might have been like on newer hardware.