theclaw

That seems more like five degrees of freedom than five dimensions.

Link to source (University of Southamton): https://www.southampton.ac.uk/news/2016/02/5d-data-storage-u...

The description of the scheduler[1] explains why:

“The RSP executes both graphics and audio processes. A graphics process sometimes extends over one frame, but an audio process must be provided in each frame to prevent inappropriate pausing. Therefore, in each frame, if the graphics task is executing, the Scheduler suspends it and saves the task state. Then it starts the audio task executing and prepares the RSP for the restart of the graphics task execution when the audio task finishes.”

[1] http://n64.icequake.net/doc/n64intro/kantan/step2/1-7.html

It’s the socket that’s rated, not the cable.

I don’t understand. I thought the brain does the isolation of single voices from an audio stream, not the ear drum.

> The U.S. crew tested this by setting up a 737-Next Generation simulator at 10,000 ft., 250 kt. and 2 deg. nose up stabilizer trim. This is slightly higher altitude but otherwise similar to what the ET302 crew faced as it de-powered the trim motors 3 min. into the 6 min. flight, and about 1 min. after the first uncommanded MCAS input

That's not slightly higher, that's a lot higher. The graphs in the preliminary report [0] note that the flight starts at around 7,500 ft. since Addis Ababa Bole International Airport is 7,625 ft. above sea level [1]. Their radar altitude "about 1 min. after the first uncommanded MCAS input" was ~1,000 ft. The highest they got above ground was around 6,500 ft. around 5 mins 30 seconds into the flight.

> The excessive descent rates during the first two steps meant the crew got as low as 2,000 ft. during the recovery.

If you assume they meant they were 10,000 ft. above sea level in the first quote, then this quote means they'd be 5,625 ft. under ground at their lowest point.

[0] http://www.ecaa.gov.et/documents/20435/0/Preliminary+Report+...

[1] https://en.wikipedia.org/wiki/Addis_Ababa_Bole_International...

edit: oops, refs.

It's a "roller coaster" procedure where the plane is pitched down to lessen aerodynamic forces on the stabiliser, allowing the trim wheels to be manually turned, then pitched up to regain altitude. The process is repeated as necessary until the trim wheels can be manually moved without it.

Boeing could simply rebrand the plane. Take ‘MAX’ out of the name, call it a 737-8. I think most people have absolutely no idea what model of plane they’re flying on anyway.

We used to do this but found it was error prone since the down migrations would have bugs and wouldn’t always catch everything. We have dedicated SQL devs that write the migrations by hand and so moving to generated code is a slow and painful process. We now encourage developers working on the DB to thrash out their design in a local SQL Server Express instance before baking their changes into a migration script that will be automatically run into our dev env by octopus. If the scripts don’t run or the tests against the temporary DB fail during build then they never get to our shared dev DB.

That is our upgrade process, yes.

We use dbup[0]. Its philosophy[1] is that you should treat your DB changes like code changes in source control, and only perform up migrations. I agree with this. We previously spent a lot of time and effort writing down migrations that were never, ever used. If you need a down migration, take a backup before running your up migrations.

We're a C# shop. Our DB migration scripts are simply named with a datestamp and a change description. The scripts are added to a console exe project as embedded resources and everything is committed to source control. These exe projects are very thin and contain a single line of C# code that passes the command line arguments directly into an in-house DB deployment library which is installed via nuget. This library handles command line parsing and executing dbup in various ways, using the scripts embedded in the calling assembly.

The result is a simple executable file that, depending on its command line, can upgrade the DB directly, preview which scripts would run against a particular DB instance, test the DB deployment against a clean SQL Server LocalDB instance, or generate SQL scripts for DBAs.

One nice feature is that the exe can also return the connection string of the SQL Server LocalDB test instance to external code as a test fixture. We can use this to directly unit test our repository types against a real, clean database. When the test fixture is disposed by XUnit, the temporary DB is cleaned up and removed.

The console projects are built and tested as part of our CI builds, then pushed to Octopus Deploy[2] as packages. The Octopus deployment process simply runs the executable and passes it the connection string of the DB to update.

[0] https://dbup.github.io/

[1] https://dbup.readthedocs.io/en/latest/philosophy-behind-dbup...

[2] https://octopus.com/

Erm, isn’t the syntax the whole point of this discussion?

Two immediately spring to mind, Oculus in 2018 [0] and Zune in 2008 [1]

[0] https://www.neowin.net/news/every-oculus-rift-vr-headset-bri...

[1] https://gizmodo.com/30gb-zunes-failing-everywhere-all-at-onc...

Yes I agree, they knew about the possibility of runaway stabiliser and they were not morons. Boeing’s guidance was useless to them because it left out a description of how MCAS operates, and I’m not sure it even mentioned it by name but I may be wrong on that.

If they had known that MCAS is disabled for 15 seconds by pilot trim inputs, they could have saved the plane. Toward the end of the flight they went off-book and re-enabled auto trim, blipped the trim a few times and 15 seconds later MCAS jumps on and dives them into the ground. All they needed to do was keep making small trims.

Well that fills me with confidence for the future of safe air travel. What could possibly go wrong?

The disagree alert/indicator was previously an optional extra[0]. Boeing are saying it will now be fitted as standard on all 737-MAX, including those already out there.

[0] https://www.reuters.com/article/us-indonesia-crash-boeing-ao...

I’ve not read anything that suggested they knew about MCAS. They knew about automatic stabiliser trim, which is a different system also present on the older 737 NG. The way MCAS monitors angle of attack, and the way it is temporarily disabled by pilot trim inputs was not known to them.

It’s not like the plane was uncontrollable without MCAS, it’s more that it did not fly like a 737-NG, and so would have required extra pilot training to compensate, which would have made the plane less attractive to airlines.

If there’s any corner cutting here it’s around AoA sensor redundancy and flight worthiness testing.

The reason MCAS is there is that the 737 was too low to the ground to fit newer, bigger, more fuel-efficient engines under the wing, which is what Boeing’s customers wanted, so they had to move the engines forward and compensate for the resulting handling effects in software.

Without some form of MCAS there would be no 737-MAX at all, and it’s not fair to say that the whole plane was a corner cutting exercise either, it was an attempt to improve an older, proven design driven by customer demand.

Not everyone agrees. There is some argument over why they did not throttle back and ended up overspeeding, which meant they could not manually trim, and why they re-engaged automatic stabiliser trim when the memory items explicitly state not to do so. The throttles were at maximum during the entire episode. My understanding is somewhat limited but I’ve read that the stick shaker activation might have made them leave the throttles alone, and that they may have re-enabled automatic trim because the manual trim wheels were impossible to move at such high velocity. Re-enabling auto trim is what ultimately allowed MCAS to push the nose down for the last time, but it’s not clear to me as a layman whether they could have saved the plane given their situation prior to re-enabling it anyway.

This is why you should not write your own tests. Where were the FAA when this system was verified? Did they even know it existed?

Video of Muilenburg press conference: https://youtu.be/xOQmQpKHVWA

He says MCAS is a “system that’s designed to provide handling qualities to the pilot that meet pilot preferences.” That’s somewhat economical with the truth. It’s designed more to meet the airline’s preference not to have to retrain their pilots, and Boeing’s preference to recover lost market share from Airbus.

While I agree that all these PC storefronts are a complete PITA, none of them charge a subscription fee like these streaming TV services do. The added cost is in terms CPU, RAM and convenience.

The multitude of stores is proving very difficult for independent developers that would ideally release on every store, because each one comes with different APIs, DRM and community features that require bespoke integrations in both the game and game server (if you have one). The documentation for this stuff is rarely great due in part to the secrecy surrounding the industry, and the speed at which publishers are knocking their own stores together.

No. It’s not the crux. It’s still Apple’s app store, GP should have asked “So you want Apple to sell spyware in their store?”

Mobile safari does the collapsed address bar.

In the context of creating debugging UIs for games and graphics applications, Dear imGUI is a godsend. Programmers love it because there is literally only the code to worry about. It's very easy to get it up and running, and all the code that handles the UI drawing and interaction is in one place so it's easy to reason about.

It works very well in the context where you already have fast graphics and an update loop, and you're already expecting to redraw the whole screen every frame. It does not really suit more complex, text-heavy UIs where you're rendering thousands of glyphs with proper kerning and ligatures and anti-aliasing, etc, and want the result of that hard work to be retained in the framebuffer unless it absolutely needs to change.

Very simple - the server can push to the client when joining a channel. This would require the channel to be logged server-side and that the user authenticates with nickserv before joining channels. It does not need client-side changes so you could still use any client.

Apps use undocumented APIs to track which apps you’re using and prevent you from opening certain apps, Apple realises this is a potential security/privacy problem, so builds screentime into the OS so it can plug the security hole.

What they should have done is allow apps access to the screentime data if the user gives permission to the app to manage screentime.

You might be interested in the Dark Reader extension: https://darkreader.org/

It’s able to make pretty much any website dark themed.

I think the fact that it's audio recordings makes it seem more emotive and intimate than plain text.

It's like when you're on the phone to some robot booking service and a real person takes over you're suddenly embarrassed to have been talking to the robot at all.