Zero trust seems to be very unrelated to this issue. The issue seems to have been a poison config breaking fastly stack. Zero trust is about verifying authentication of devices/users. Unrelated things really.
I wish they'd rather use python or Julia. GNU Octave is great. But as a clone of Matlab it's constraint by compatibility and doomed to always be second* and at worst an enabler for Matlab. I'd rather break the dominance that Matlab has in many fields and replace it with free software.
* There are a few aspects where it is better. For example I believe the variable editor introduced one or two releases ago is nicer as it allows inline evaluation.
Yep. Having each front end needing to scale with the overall size of the front end sounds is obviously going to hit some scaling limit. It's not clear to me from the summary why they are doing that. If it's for the shard-map or cache? Maybe if the front end is stateful that's a way to do stickiness? Seems we can only guess.
From the summary I don't understand why front end servers need to talk to each other ("continuous processing of messages from other Kinesis front-end servers"). It sounds like this is part of building the shard map or the cache. Well in the end an unfortunate design decision. #hugops for the team handling this. Cascading failures are the worst.
More like hardware from 20 years. Yeah I hope the TI monopoly gets broken. Numworks looks exactly like the calculator I was dreaming about when I was in uni.
Imagine a future where whenever the energy price drops in a region suddenly companies show up with a bunch of such tubes drop them in the ocean. Do some batch processing and once the energy price rises they pull it out and move on.
In reality of course connectivity would be a major problem and energy price differences are probably not large enough to make it viable.
It uses SYMBOLP instead of NUMBERP. Highlighting the risk of introducing new bugs.
Which leads to the question, why Remacs can't just auto-wrap the lisp::* functions, which I assume are the Rust versions of the C Macros. If you look at Emacs' C code there are a lot of functions and macros that implement Elisp primitives in a C way. E.g., NUMBERP(x) will return 1 if x is a number or else 0. So you can use this function to deal with lisp objects in C code. The function that exports this primitive to elisp is Fnumberp. Rust has a better type system than C and supports meta-programming. So why not have a simple wrapper that can take a (LispObject) -> bool and turn it into a (LispObject) -> LispObject. Similar for other Elisp<->Rust types.
However unless GNU Emacs is willing to accept the Rust replacement code I don't think this will succeed. It is a lot of work and it takes quite some time until it actually pays off. It seems simpler to do what GCC and GDB have done and switch from C to (a strict subset of) C++ to simplify at least some of the more painful C hackeries.
And the reasoning given in the announcement are rather weak:
* "We can leverage the rapidly-growing crate ecosystem." Emacs recently added module support allowing leveraging all kinds of ecosystems
* "We can drop support legacy compilers and platforms (looking at you, MS-DOS)." how is that an opportunity when it effectively removes support for platforms.
Yes, there is no way Emacs will get rid of elisp. That's why Guile Emacs includes writing an elisp frontend for Guile. (There is also a Frontend for ECMAScript and an experimental one for Lua)
Isn't that largely because the LibreSSL team refused the invite to the exclusive OpenSSL security list? At least that was the case the last time the LibreSSL devs complained about not receiving any vuln info in advance...
Yes, that's truly annoying. I have a few code examples that are complete but it refuses to accept them without giving any reason. If I try to step forward it says I have to go back.
Also in the first example it complained when I was using Math.round for the index calculation and only wanted to accept Math.floor. (although not applicable in this case, I think Math.floor is not the best choice since it won't behave like ints in negative cases)
Canarying should detect this. Not clear if they do this or the canary failed to report this.
Sharding by customers could help reduce blast radius. But maybe not by much of this was a very big customer.