cschmatzler

This is also not correct in this case since they recently rewrote the Artifacts backend from Zig to TypeScript.

A year ago in the initial announcement post you explicitly mentioned open sourcing it.

> When we are ready we will release Neki as an open source project suitable for running the most demanding Postgres workloads.

Has this changed?

This is making my current work 100 times easier. Very welcome timing.

Front fell off, people deplaned (while still horizontal) which shifted the balance backwards. It’s sitting on the rear bulkhead,

This won’t fit the usual hate, but.. https://epc.tesla.com Vast majority of parts can be ordered directly from the catalogue.

fwiw, Bunny are the people that announced S3 compatibility for their object storage in Q2 2022 [1] > We can’t wait to have this available as a preview later in Q2 and truly make global storage a breeze, so keep an eye out!

then apologised for missing that in September 2023 [2]

> We initially announced that we were working on S3 support for Bunny Storage all the way back in 2022. Today, as 2023 is slowly coming to an end, many of our customers continue to follow our blog, hoping for good news about the release.

changing the roadmap to early 2024 [2]

> But we are working aggressively toward shipping S3 compatibility in early 2024.

That same post also has the beautiful "At bunny.net, we value transparency." quote. It's early 2026, and they're literally ignoring my support requests asking about what the roadmap is looking like for this now.

So, do not trust their product or leadership at all.

[1] https://bunny.net/blog/introducing-edge-storage-sftp-support... [2] https://bunny.net/blog/whats-happening-with-s3-compatibility...

I agree that this decision is insane and the whole Optimus/xAI bullshit is tiring, especially with the shareholders actually voting against the xAI investment, but you should try today's FSD. It's genuinely good and shouldn't be discarded wholesale because the guy sucks.

yeah nobody should use this based on reliability and support alone

This had nothing to do with any of that tho.

and again we can tell based on how the x isn’t centered in the close button

Yeah I strongly emphasise with them getting their money - the only problem with headless components being behind a paid license is that you cannot build a design system on top of them and open source it.

A 787 can still climb with flaps up and two healthy engines. In the video that was posted everywhere, you can CLEARLY hear the RAT spin, which gets deployed automatically when both engines go out.

Both slats and flaps were on maximum during the entire flight.

It’s nice seeing a major outage a day after this.

Thought the same. I’d say it’s _too_ obvious because every time I have someone new in the passenger seat I have to warn them when they grab it.

Use lexical instead of elixirls and most of your worries will be gone

Methane and oxygen are not very toxic.

ExDoc is arguably one of the nicest documentation systems out there, and Erlang moving to it means two things: 1. The Erlang devs do not need to implement and maintain their own anymore. 2. ExDoc will improve faster since people previously working on Erlang’s documentation system shift to it.

It’s really a win for both, and I love it.

They were required to by an airworthiness directive. https://www.federalregister.gov/documents/2017/06/29/2017-13...

Neither. It’s an error by whoever last did maintenance on the engine and didn’t latch the door properly, and the pilot doing the walk around missing that error. Not a Boeing issue whatsoever.

Because Boeing didn’t have the same issue Airbus did. The latches on A320 family cowlings were kinda hidden from view, which made them less likely to be seen during the pilot’s walk around before departure. The EASA (and then subsequently the FAA) issued an airworthiness directive [1] that required the visibility to be resolved. For this case, it’s simply both the mechanic forgetting to latch it properly _and_ the pilot missing that fact during the walk around. Either way, it’s not really a safety critical incident, just rather embarrassing. [1] https://www.federalregister.gov/documents/2017/06/29/2017-13...

Whoever did not latch the door properly after doing maintenance checks. Which is either a mechanic at the airline itself or someone at a maintenance hub that is contracted by the airline. Not the job of the manufacturer whatsoever.

This is not related to Boeing at all. Engine covers not being closed properly is a relatively common (still rare in the grand scheme of things) incident and happens a lot more frequently on Airbus models to the point that Airbus modified the door latch.

The server is optional and opt-in, stuff is saved to a local SQLite database by default.

If you use MySQL, Planetscale’s branching is really amazing. Not using them, but wish I could for that. Gives you a complete diff of what you’re doing, and can also pre-plan migrations and only apply them when you need with their gating.

Reliability and support. Having even “the entire node went down” tickets get an auto-response to “please go fuck off into the community forum” is insane. What is the community forum gonna do about your reliability issues? I can get a 4€/mo server at Hetzner and have actual people in the datacenter respond to my technical inquiries within minutes.

The A320neo family has a backlog of over 7000 orders. As much as Airbus is ramping up production in the past few years, with their current ~600 goal for 2024 that’s still a 12 year wait if you order one today.

The 787 is absolutely plagued with quality control issues.

In particular, deliveries were stopped for almost two full years from September 2020 to August 2022, with more issues found recently. The Charleston plant is considered the worse one compared to Everett.

https://www.seattletimes.com/business/boeing-aerospace/boein...

That’s an underlying QEMU bug, which is used by Lima [1]. Add `ENV ERL_FLAGS="+JPperf true"` to your Dockerfile and it will build just fine cross platform. The flag just changes some things during build time and won’t affect runtime performance.

[1] https://gitlab.com/qemu-project/qemu/-/issues/1034

This post is missing one huge point: its tooling is bad. Like, real bad. The language server will regularly crash, does not support code actions _at all_, messes up formatting regularly by ignoring the configuration. Then credo, the popular linter, will tell you that your imports are not alphabetically ordered but there’s no fix mode, meaning you’ll go back to order them yourself. I love the language, am using it during my day job right now, and have published multiple libraries, but the development experience can be infuriating.