devit

1. Using a proper programming language that doesn't allow you to setup arbitrary functions as signal handlers (since that's obviously unsafe on common libcs...) - e.g. you can't do that in safe Rust, or Java, etc.

2. Using a well-implemented libc that doesn't cause memory corruption when calling async-signal-unsafe functions but only deadlocks (this is very easy to achieve by treating code running in signals as a separate thread for thread-local storage access purposes), and preferably also doesn't deadlock (this requires no global mutexes, or the ability to resume interrupted code holding a mutex)

3. Thinking when changing and accepting code, not like the people who committed and accepted [1] which just arbitrarily removes an #ifdef with no justification

4. Using simple well-engineered software written by good programmers instead of OpenSSH

Seems written by an LLM for the most part.

The 630g Anker 737 PowerCore 24K might be a good option, and also the 765g HyperJuice 245W.

So this adds 0.3-0.45kg to the estimate.

- Car campers, vanlifers or people living in a place permanently, which can just use the heavy Starlink version or go where there is LTE coverage

- Thru-hikers who hike every waking hour and want to be as light as possible and for which this system isn't even remotely light enough

- Casual weekend hikers for which it's going to be too expensive and also unnecessary since they'll have Internet access on Monday again.

It's only really a consideration for those who regularly go on multiweek trips or live long-term in the wilderness and move camp on a weekly/monthly frequency (rather than daily or never), and these people seem to be relatively rare.

From an individual perspective, if you want Internet access and don't have to be in a specific place, the current alternative to Starlink is to simply limit your wilderness living to places with or near areas of cell phone coverage (which potentially results in tradeoffs, of course).

- FlexSolar 40W panel: 1.35kg

- Nitecore NB20000 ~75Wh battery: 300g

- Starlink Mini: 1.1kg

- Smartphone: 250g

For 3kg you have something that should give 2-3 hours of Internet usage on an average EU/USA good weather day (assuming 20% solar panel for 10 hours = 80Wh/day, 25-35W power usage of Starlink Mini + smartphone).

For each extra 1.65kg you get an additional 2-3 hours, resulting in 7.95kg for 8-12 hours, 11.25kg for 12-16 hours.

Not bad, but not good either.

If that's your identity, then not being able to solve hard Leetcode problems (which, to my knowledge, are not even actually hard, since they seem to be easier than the problems in actual top competitions like the IOI, ICPC, etc.) is completely unacceptable and thus you will study and practice relentlessly until you manage (if you can); conversely, if that's not your identity, it's probably going to be hard to find the motivation to do so.

This essentially turns GraphQL into a DSL for implementing REST endpoints, which is still a useful thing since it allows to write the REST endpoint with only knowledge of the GraphQL API rather than knowledge of the whole backend architecture, which is generally useful if the backend and frontend are written by different people or teams.

That's the way Facebook uses it on their main website: they pass the query id in the "doc_id" form field, the arguement in the "variables" field, the server gets the actual GraphQL query based on the doc_id from some sort of internal dictionary and AFAIK no GraphQL query string ever goes on the wire in production.

But Falcon 9 seems to cost $40-60 million and carries 200 tons of RP-1 which seems to cost $200-500k, and all other costs should either be small or removable by automation, so the reusable part is actually up to 98-99%, not 30%.

Of course if you just flush boatloads of money down the drain for each launch for no reason, reusing the booster doesn't change much.

Also in general that sort of mathematical modelling is usually worse than useless since the output is usually a straightforward function of the assumptions and the model just makes bullshit assumptions seem more legitimate.

Presumably and perhaps more compatibly can also call the DOS function with interrupts disabled but with an interrupt line active (e.g. a timer) and handle it.

Which includes "go to any website and run any app I can download from it, regardless of whether it's illegal or against any rules or against the interests of the phone maker" and "change any aspect of functionality that I don't like (e.g. apps being able to show ads) and that I can find out on the web how to change".

It doesn't include "Google or Apple make rules about what I can do with my phone that I can't override".

But you can't do that with a mobile app because only Android users can use it, while anyone with an iPhone can't use the app unless you submit to Apple's rules.

In my view, my phone is MY DEVICE. It is most definitely not "Google/Apple's platform"!

Google is merely manufacturing my phone, and I intend Google to have no rights or control whatsoever regarding my phone, and merely have the obligation (not right, obligation) to manufacture it correctly and provide open-source software for it that works correctly and properly provides Android interfaces (obviously, I don't use an Apple phone since Apple doesn't offer that, while Google does since they provide devices with unlocked bootloaders that run open-source OSes).

It only runs Android because Google with Android happened to win the adoption lottery and it would run PodunkOS by ACME if PodunkOS by ACME had been the one that managed to gain critical mass.

Again it is absolutely not even remotely close to "Google/Apple's platform", and I have no intention for Google to interfere in my use of it and certainly not interfere in any relations I might have with people providing software for my phone like taking a cut of the transaction or deciding how that software should behave.

It's kind of strange, because there is a single objectively correct rendering for any vector graphics scene given a pixel sampling function and colorspace metric (the one where each output pixel's value is the closest representable color to the convolution of that function with the scene, expressed as a function from R^2 to R and a linear color scheme respectively), and it seems like it would be achievable with GPU compute and some care with error bounds on either curve tessellation or numerical computation of the exact symbolic integrals of curves.

And it also seems easy to make such a solution have a tunable level of approximation to have faster rendering.

Sometimes they even adopt pre-release AOSP security patch levels or backport security fixes from unreleased AOSP or kernel sources.

Probably a lot of people are conditioned that they need to have a clean car.