With that logic, the Django orm should only support one database.

HBO owns Westworld and stopped streaming it to avoid paying residuals.

If they don't make their content available legally, then it should go into the public domain.

Don't want this to happen to your content? Then don't release it to the public.

We need to bring back explicit copyright registration and renewals.

Hoarding is never good for society. It is wild that we've adopted laws to reward it.

Wow. That is dysfunctional.

I would be curious how the financial wires got crossed.

I would have assumed residuals were proportional to views, and views valued proportionally as contributing to subscription demand. And it would be a rare viewer to watch one show like that, over & over. I.e. only upside. Something went sideways.

Thats how it used to work in the movie theater/cable days. Then Netflix said "I will pay you a ton of money up front to own everything" Creatives said amazing! Then the "war" for creative talent started because of the fragmentation of services, so you got people saying I will pay you X + a royalty regardless because you are so sought after, which eventually, as you see here, priced them out of their own content.

I think that a show like Westworld is a great example of the realities of the streaming era. If HBO kept streaming it on HBO Max it probably costs them $2-4 million in residual liabilities. HBO removed dozens of scripted shows during that phase, and had a mandate to cut around $3B in post merger costs.

After Year 1, WGA/SAG residual formulas decrease: Year 2: ~80% of Year 1 Year 3: ~55% Year 4+: sometimes stabilize at a “floor” rate

So what did they do? They ran it for a few years, ran the numbers, realized that Westworld was no longer profitable on the platform. (Profitable would have to mean draws enough new subscribers to the platform). AND THEN - Warner Bros. Discovery made new deals with other platforms with ads. I think you can still find Westworld on Tubi and other ad-supported platforms that actually pay Warner licensing fees.

Gracefully handling hardware faults is a software problem. The Air France Flight 447 crash was the result of bad software and bad hardware.

Crashes caused by pilots failing to execute proper stall recovery procedures are surprisingly common, and similar accidents have happened before in aircraft with traditional control schemes, so I’m skeptical that there are any hardware changes that would have made much difference. The official report doesn’t identify the hardware or software as significant factors.

The moment to avoid the accident was probably the very first moment when Bonin entered a steep climb when the plane was already at 35,000 feet, only 2000 feet below the maximum altitude for its configuration. This was already a sufficiently insane thing to do that the other less senior pilot should have taken control, had CRM been functioning effectively. What actually happened is that both of the pilots in the cockpit at the start of the incident failed to identify that the plane was stalled despite the fact that (i) several stall warnings had sounded and (ii) the plane had climbed above its maximum altitude (where it would inevitably either stall or overspeed) and was now descending. It’s never very satisfying to blame pilots, but this was a monumental fuck up.

If the pilots genuinely disagree about control inputs there is not much that hardware or software can do to help. Even on aircraft with traditional mechanically linked control columns like the 737, the linkage will break if enough pressure is applied in opposite directions by each pilot (a protection against jamming).

True. I would say, however, that every "concept" of airliner flight deck has its own gimmicks that can kill. The Airbus "dual input" is such a gimmick. Even though there was, for example, an AF accident with a 777 where there was hardware linkage between yokes and the two pilots were fighting... each other. Physically.

The official report doesn't identify the lack of sidestick linkage as a factor in the accident. Neither of the two pilots who were at the controls had any idea what was happening. Both pulled back on their sticks repeatedly right up to the moment of impact. The captain, who eventually realized (too late) that the plane was stalled, was standing behind them, and so would not have benefited from linked sticks.

There's a detailed breakdown here: https://admiralcloudberg.medium.com/the-long-way-down-the-cr...

There was more than one case where pilots would accidentally fight and break the linkage, or one would overpower the other.

One glider instructor talked about taking a stick with him in case of panicking student, so they could hit them hard enough so they would stop holding the controls.

And bad pilot training, if I recall correctly.

I suppose because they were not instructed to work around the software and hardware flaws.

No. The behavior was wrong, no matter what you are flying. Same problem with proper training would have result in a simple report.

Because they kept pitching up in a stall

And two pilots were trying to fly the plane without talking to each other. One learned “if something happens just pull back, this plane cannot stall”. No pilot learned to say “my plane” when flying. Way too many errors.

Although the pitot tubes on AF447 were due to be replaced with a type more resistant to icing, nonetheless there's no such thing as a 100% reliable pitot tube and there were procedures to follow in the event of unreliable airspeed indication. Had they been followed the accident would not have happened. Instead the co-pilot held back on his stick until the aircraft fell out of the sky.

I don't believe there was any issue identified with the software of the plane.

I'm reminded of the Apollo moon landing where the computer was rapidly rebooting and being in an OK-ish state to continue to be useful almost immediately

It wasn't rebooting, it ran out of memory and started aborting lower priority tasks. It was a excellent example of robust programming in the face of unexpected usage scenarios.

Of topic for the thread, but on for the comment: I was working in an automotive project 3 years ago. It was all about safety, and one hypothesis was the processor could get overloaded. I was astonished no one in a grouo of 20 “senior sw architecs” had any idea about the concept of load shedding. The proposed solution was “in that case, reboot”.

Mind you whatever came out of that project is rolling on the street today.

We really should mandate all that stuff to be open-source, so we can be aware of how defective everything is.

Fail safe/fail soft

I still design this into many of the things I work on, especially if I’m working close to the metal on controller systems. At some point it becomes ridiculous / impossible but I’m often thinking about how a system would handle memory corruption, bit flips, invalid sensor data, etc. These days, somebody should design a triple redundant microcontroller that runs quorum on the gpio at the hardware level. It could be a 0.30 part instead of 0.10 one, but I would specify it just about everywhere. Add $3 to BOM cost to categorically eliminate an entire class of failure would be ramrodded by legal into just about every medical device, PLC, critical automotive system, etc one would think. Seems like a good gambit for a riscV startup, but what do I know.

Ok so, turns out there are a lot of MCUs like this, including a riscV triple core lockstep with ECC lol. No super cheap ones, but microchip makes the AVR-SD which leverages a pair of their AVR8 cores in lockstep with ECC flash and RAM. It’s ~$1, so I think I’ll pick that as my next toy project to play with. Turns out, Simpsons already did it.

I'm very surprised that you find this surprising. Do you mostly stay at Airbnb? I expect this at any traditional hotel in the US.

Have you been… not traveling since COVID? Marriott and Hilton cut daily housekeeping during that period and then kept that by default at many properties (at least in the western US).

You have to request it special and some properties still won’t make the bed daily even with a request. They’ll just bring extra towels.

Hotels (at least the major ones) will always clean your room daily if you ask them to. The "new" part is that sometimes you have to ask because some hotels (especially since COVID) have moved to a more on-demand/personalized cleaning schedule rather than cleaning everyday by default.

I personally prefer on-demand.

I have stayed in Airbnb once in my life. I find very few hotels, including the big chains--and even leaving aside serviced apartments--do daily room service these days.

How is this relevant to just Mac users?

Because of the electricity flowing between your hands while charging.

That project is a pipe dream. They don't have what it takes to continue X11 alive once X.Org pulls the plug.

I bet you are the life of the party. Seriously though, what makes you write that so matter of factly?

Why go through the trouble of exploring such a bug, when you have the ability to just replace the binary with something with a backdoor?

AI Slop.

Here's this from my setup_windows.ps1 powershell script for maintaining windows: https://github.com/westurner/dotfiles/blob/develop/scripts/s... ;

  powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -InstallPSWindowsUpdate
  powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -UpdateWindows
  powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -InstallWSL
  powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -InstallChoco
  powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -InstallChocoPackage

So then the regular tasks are -UpdateWindows and -UpdateChocoPackages :

  powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -UpdateWindows
  powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -UpdateChocoPackages

It would be easier to ask google than post here. It's the first google result for "blocking website scaling"

Changing your user agent won't help. No half decent web developer has cared about since the 2000s.

Most Kobo books have DRM. There are a few publishers (TOR) and authors that are DRM free, but most of books I've wanted have it.

This is why I have a Boox Android eInk tablet, although I only use it with burner accounts. They run Ancient versions of Android.

True, but that DRM is relatively easy to handle, and is sort-of a standard (OK, I know Adobe handles it, but it's not a complete walled garden like Kindle). I can borrow an ebook from my library using my browser, download the DRM'ed file, fulfil it (using Adobe Digital Editions), copy to my ereader. I can buy books from Google and do the same. It's relatively straight forward to strip the DRM if you want to. Because it is reliant on a third-party service (Adobe) that has other clients/interests, it's not as likely to change as quickly or as onerously as Kindle's DRM.

Yes, most books you buy from Kobo do have DRM, but a Kobo handles DRM-free files you may acquire elsewhere (e.g. an author or publisher's site) better than Kindles do. Kobos support epub natively, while Kindle requires some sort of conversion that doesn't always work great.

This, my first eink reader was a Meebook M6, Boox didn't release their 6" model yet. My main selection criteria was "it runs android". It was a really good reader, Kobo, Kindle and co can just be ewaste as they're designed to be.

Kobo fully supports pointing your library at a Calibre server instance to pull books from. You can also access a bash shell by changing a setting. They're very open devices and IMO quite nice.