One other thing to compare is business and health regulations. Compliance with that is certainly more involved and costly today than in 1940 and would account for part of the price.
The problem with this model is that the staff and insurance are essentially fixed costs, so if they sell 500 burgers on Saturday but only 250 on Tuesday, then the insurance cost-per-burger on Tues is double what it is on Sat. Staffing might increase by an extra body or two on the busy days but won't double, so it also has a much higher cost-per-burger on Tues.
I am not a restauranteur, just a customer (and observer) but I dont think many restaurant operators understand this concept either. Many seem to be raising prices to cover higher costs-per-item due to fewer customers to spread the fixed costs over. And then the higher prices turn more people off, now prices need to be raised again. Death spiraling themselves.
Insurance is not a fixed cost. Property and auto insurance are, but liability is a percentage of sales, its fixed for a year then adjusted for next years planned sales.
Unfortunately no mention of prices, so increase in portion sizes might be below inflation; and I suspect the former could be a strategy of compensation for inflation by making it seem less drastic ("yes it costs more, but we also made it bigger!")
One time when I was a kid and my dad and I were in line at Fuddruckers, we overhead someone else in line say "I don't think I could eat a third of a pound, so I'll have to get a half a pound instead. It's still a reference we laugh about over two decades later.
Restaurant portion sizes have definitely increased - a lot - since the 1940s-50s. Maybe some minor pullback the last few years but still way larger than back then. A McDonald's Quarter-pounder was considered very large, that was in 1971, many sit-down restaurant burgers today are 5-8 oz.
> Because the 8086 had no facility for emulating an FPU (unlike the 80286 and later processors), the emulation mechanism was somewhat complex and required tight cooperation of assemblers/compilers, linkers, and run-time libraries.
The article goes into some detail on the extra effort required to implement FPU hardware emulation on a platform that did not especially support it.
Modern implementation of FPU emulation might be more straightforward.
I haven't worked with FPU emulation on microcontrollers, which is probably the most common use case these days.
> Modern implementation of FPU emulation might be more straightforward.
Most 32-bit designs throw an exception on an invalid instruction so it can be caught and handled at runtime. Even basic ARM Cortex-M0 chips throw a catchable exception on illegal instructions.
So one option is to just issue the FPU instructions as if the FPU exists, and then catch and emulate.
This is how operating systems emulated FPUs on processors like the 68020, the 386 and early RISC machines, if they didn't have an FPU.
I first studied back-propagation in 1988, at the same time I fell in love with HyperCard programming. This project helps me recall this elegant weapon for a more civilized age.
The playbook has been to manipulate "low-information voters" by promising that you will attack a marginalized group of people. Get the voters to believe that you are on their side by echoing the fear and hatred they have for The Enemy.
Action against The Enemy replaces any action to directly address economic and social marginalization.
It's how we process information. Avoiding this cognitive glitch takes practice.
The article states that "Playboy" magazine creators started "Omni", but I'm almost certain it was "Penthouse".
I would describe both Playboy and Penthouse as primarily pornography. As such, they were both wildly popular in the 1970s and early 1980s.
Omni was not that. I had a subscription to Omni from the first issue in 1978 until about 1983. Pop science, science fiction, fantasy art, interviews and features on space exploration policy... and junk science, UFOs, psychic powers, cults. News of the wierd.
> Playboy Magazine in the 50s and 60s had a reputation for, among other things, reviewing hi-fi systems, pop albums and surprisingly good fiction. Penthouse publisher Bob Guccione must have wanted some of the tech + fiction market because he and his wife Kathy Keeton launched Omni Magazine in 1978.
Either that got ninja-edited in the 8 minutes since you posted that comment, or you misread that paragraph.
Well, agreed that people didn't really buy Playboy or Penthouse for the articles. But it was pretty tame compared to PornHub and other online porn of today. You'd see breasts, maybe some pubic hair, but not much more, particulary in Playboy. Hustler was more explicit but none of them showed actual sex; you'd have to go to an "adult" bookstore or theater to find that.
I had something similar. A friend of mine gave me an issue because it had a Borges story in it. I mean, I looked at the centerfold, but mostly paid attention to the story.
In Phoenix, Arizona, there are solar panels over the parking lots at since of the grocery stores. Makes a huge difference in survivability when you get back to the car.
(Without huge infrastructure dedicated to car welfare, Phoenix is uninhabitable.)
It's car optimized because the 110F weather makes it un-walkable in the first place. When I lived in a walkable city, I would prefer to walk 30 minutes than drive. When I lived in Phoenix, I did not want to spend more than 30 seconds outside in the summer.
You can always start small and over decades grow the area. After all that is how cities like Copenhagen and Amsterdam became bike friendly, not just a few years, but decades of work.
As a fellow European: we're prone to underestimating how uninhabitable bits of America are that nonetheless have people living in them. Those are port cities and therefore stable and temperate. You cannot green Arizona.
Just FYI there's a lot of ways to re-green a desert without actually being wasteful with water. There's some really impressive case studies out there. Shaping the land with berms and swales, building walls of trees to prevent water from being leached away by the wind, etc.
100F days are fine, cakewalks, even, especially with misters + shade. We had 70+ days of 110°F two years ago, and over 20 days 115°F+. They are not the same. Those days are unbearable nightmare fuel, and worse, they turn into insanely miserable nights where the low temperature rarely dips below 95°. It is absolutely awful, dry or not.
Phoenix as well as other similar places (such as Las Vegas where I live part of the year) have an outsized benefit from installing solar compared to normal places. We basically never have to deal with rain or clouds. Installing solar here is a total no-brainer.
25 years ago, I configured GNOME to run a BeOS-like tabbed window manager. On a sun workstation.
But that's not what this is. Or not only:
Nexus Kernel Bridge
Nexus is Vitruvian's custom Linux kernel subsystem that brings BeOS-style node monitoring, device tracking, and messaging to Linux — making it possible to run Haiku applications on a standard Linux kernel.
It claims to run apps from Haiku, the current open-source implementation of a modern BeOS.
Looks like this is a thin translation layer for BeOS/Haiku syscalls. I wonder why they aren't relying on Syscall User Dispatch https://docs.kernel.org/6.19/admin-guide/syscall-user-dispat... which would enable them to put this compatibility layer in user space. It's already being used by recent Wine versions.
It's not really a translation layer, nexus implements the same BeOS/Haiku IPC in kernel but using linux kernel primitives.
It's not as much as a translation layer than any other IPC in the linux system, really BeOS/Haiku apps are first class citizens.
Most of BeOS IPC is in mainline Linux kernel [1] - the difference here seems to be implementing some of the services that are supposed to be available related to filesystem etc and the user land side of it (raw IPC does very little without another layer on top)
[1] - there's a reason why a bunch of BeBook reads the same as some of the oldest parts of Android documentation
BTW because that would not solve any problem for us, the technique you're linking can be useful only if what you want to achieve is binary compatibility otherwise it's useless. That's not really what we are after.
It's almost as if no healthcare legislation gets passed before private insurers have figured out how to extract shareholder value.
(Which makes the system worse. The fiction of a fiduciary responsibility to extract top dollar from a business regardless of consequences is the opposite of "capitalism". Which derives its name from the practice of sound investment to build something of lasting value.
To say nothing of the social deviance of for-profit healthcare.)
I think a read cache device gets set up like RAID0, interleaved reads rather than redundant data.
Examples of auxiliary devices where you want redundancy: there can be a write cache (the ZFS Intent Log, or ZIL). You can also dedicate a fast device for hot items like the deduplication tables, or a dedicated device for tiny files where data can be stored directly in the directory data, rather than allocating a separate data block.
We may have inflation in more than one sense: prices have gone up, and perhaps the size of burgers and hot dogs have also increased.
No doubt I can find portion size clues if I look around. Haven't done so yet.
reply