Instability just means that they don't naturally return to stable flight. Fighter jets benefit from this because when you want to make a maneuver, you're not fighting the plane's natural inclination to stay where it's pointing. You don't need particularly powerful hardware to do this kind of control, quadcopters are an even more obviously inherently unstable example, because any thrust imbalance will immediately make it roll. Quadcopter control loops only need to run at a few hundred hertz to achieve stability.
The total water usage of the largest concentration of datacenters in the world is only using 10% of the water consumption of the county, about half of which is non-potable reclaimed water that would otherwise be dumped into a river [1], and you think this is a bad thing?
> Those are contradictory. Either the code is extremely portable, or it can't support "obscure" platforms, but not both.
I think it's perfectly valid to call code 'extremely portable' without supporting every special snowflake architecture. There's a spectrum from assumptions that hold on everything that isn't some esoteric joke architecture or archaeology to something that I would probably consider required for 'extremely portable'.
I would personally consider something that failed to support anything on this list above big endian as still being extremely portable: you'll build for any serious modern architecture that isn't a DSP.
- non twos complement integers
- (int) nullptr != 0
- segmented addressing
- non-8 bit char
- big endian
- missing floating point
ARM's done a good job of making it so that you can't assume the traditional x86 assumptions of being able to access any pointer unaligned or having sequentially consistent semantics on memory ordering (with the help of compilers getting better at reordering resulting in you needing to have proper semantics on x86 as well).
It makes liberal use of u64 all over the place rather than a more appropriate, machine adaptive unsigned int or unsigned long. It isn't a good fit for anything "exotic" like non-64-bit platforms. I wouldn't consider that in the spirit of portability when it compiles into bloated code with unnecessarily large structs.
> This is why, for example, despite the existence of jumbo jets (which have a better mass:payload ration than smaller planes), most passenger flights are not on jumbo jets, because there's just not enough demand on most routes.
Airlines used to use a hub and spoke model where it would make sense to have larger planes between hubs and smaller ones to get to and from the hubs, but consumers strongly preferred direct routing, so it didn't work out. For orbital payloads, most payloads probably do not mind too much if it takes a month or more to boost/deboost themselves to their intended orbits.
> Because when people say “avoid politics” they usually mean it as a derogatory term for “all the disagreements that I dont personally care about” - and conveniently exclude the issues they care about from “politics”.
People use "politics" as shorthand for "things that are divisive issues that split your purported represented class". You're not going to get anyone to join your union if all you do is advocate for things that the vast majority of employees at best don't care about, or worse, disagree with.
> Is Python's GC bad, or are there cyclic reference issues?
Unless you're being pedantic and including reference counting without cycle detection as GC, if your GC has cyclic reference issues, your GC is bad.
> Is it possible to detect cyclic references perfectly?
Yes? That's the entire point of tracing GC. You have some set of root objects that you start with (globals, objects on thread stacks, etc.) and then you mark every object that's reachable from them. Anything that's not reachable is garbage, even if there are cycles within them.
Better yet, you could add more pins and switch them to using differential pairs to make it extensible for more use cases. While you're at it, you could have pins on both the top and bottom of the connector, and use a pair of sense pins to detect orientation, so that super specialized use cases can use every single pin available on the connector.
If only you could buy receptacles for this for like five cents a pop...
(If you do this, make sure that you don't send more than 3.3ish V over a pin, and that you're tolerant of 3.3V incoming, so that you don't explode yourself or victim devices if people randomly plug you into things. https://github.com/google/usb-cereal is a reference design for a UART over USB-C SBU adapter used for Pixel phones)
I also pointed out in that comment that USB-C debug accessory detection does not support orientation detection - and neither does the Google adapter you linked (it doesn't use debug accessory mode, and doesn't have some other solution either). As they say: "Determine correct orientation - top vs. bottom - the tool operates correctly only when SBU1 pin corresponds to TX and SBU2 pin corresponds to RX."
The fact that you can't detect orientation in debug accessory mode is a direct result of how it works: both CC lines are connected to the peer; normally the cable pulls one of the two to ground which is then your orientation reference for all the other pins. (This is also why you can't use a regular USB-C receptacle for debug accessories, it has to be direct to plug, the 2nd CC line doesn't go through the cable.)
So, if you use the SBU pins, it's not reversible anymore. If I remember correctly, debug accessories must still put USB on D+/D-, so the remaining option is to put serial RX/TX on the high speed pins, twice each on 180° positions.
Why should it only be valuable if the effects were to be publicly known?
There are plenty of places in industrial computing where reproducible builds have prevented subterfuge within the organizations themselves. Injecting binaries to do inf-/exfiltration is a long-standing industrial espionage activity which is of immense value to all users of the operating system - not just the consumer users.
My magic beans have prevented thousands of tiger attacks in top secret underground moon bases, never you mind that there's no way for me to actually prove this.
There's a certain irony in pushing for verifiable builds with completely unverifiable claims.
I've worked at several of the biggest targets for espionage, industrial or otherwise, and to the best of my knowledge, the only thing that's ever been discovered by their reproducible build efforts has been failing hardware on build reproducers
You probably don’t have enough experience with professional enterprise IT departments. Rootfs audits are a thing made a lot easier, and more effective, with reproducible builds.
This question is meaningless. Attackers will pick the best attack if they have more at their disposal. The fact that they didn't push a commit shows it's better not to. So closing that attack is good.
There is meaning. The difference in detection time does have meaning. If the improvement of detection time was marginal there may have been a different project time could have been invested in to make it even faster to catch such things than reproducible builds.
“Hasn’t happened” is quite naive. It happens internally - putting unscrupulous code in a company’s distro before torching the place is a surprisingly regular occurrence in places which have long since adopted Debian as a platform host. IT departments around the globe will benefit from this immensely.
The one single fail point they prevent is infected build hosts.
That might be some reasonable benefit for the company if it is building it on public architecture, but for projects like Debian that insist build hosts are basically offline (package in, package out with no internet access during build process) it is very fringe benefit.
Local privilege escalation is largely irrelevant on Windows because basically no one uses it in a multi-user system, and application sandboxing is effectively nonexistent.
I get that multiple human users on a same machine is rare nowadays, and that per-app users were never a thing.
But windows still has a root and a lower privilege user. You typically need to click on "run as admin" to elevate privileges to, for example, alter system binaries.
I know that Chrome on Windows tries to lower its privileges to mitigate exploits, and although it's not very popular, the MS Store app platform does try to do full isolation of apps. So actually, per-app separation of users kinda does happen, or is attempted on Windows.
Sure, but that's mostly academic: compromise of the user account is game over for any real user. Not actually being Administrator isn't much consolation when the regular user account can extract your cookie jar, record all of your keystrokes and mouse movements, record all desktop video (except for DRM-protected content, heh) etc.
reply