fafner

Unfortunately some customer changes will need to go out quickly and globally for a CDN. Going much slower might not be a good option.

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.

Authentication/trust is simply unrelated to this outage. The post you linked seems to have no relevance.

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.

I believe Unicode support was improved in this (6.1) release

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.

Have they been uploaded to Wikipedia (Commons)?

The example seems to be wrong https://github.com/Wilfred/remacs#porting-c-functions-to-rus...

fn Fnumberp(object: LispObject) -> LispObject { if lisp::SYMBOLP(object) { unsafe { Qt } } else { Qnil } }

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.

And that does not include any external packets...

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)

In C++ - unlike C - you can actually implement quite good matrix/vector support. E.g., Eigen3 http://eigen.tuxfamily.org/index.php?title=Main_Page or Blaze https://bitbucket.org/blaze-lib/blaze or if you have a specific BLAS library tuned to your cluster then maybe FLENS http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/index.html

Those scripts and more for Linux (3.2 or newer) using perf_events/ftrace:

https://github.com/brendangregg/perf-tools

I think the GNU Octave folks are using libgccjit to write a JIT for their Matlab-like language.

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)

That's already explained in the original blog post

http://googleprojectzero.blogspot.com/2015/03/exploiting-dra...

Well the OpenBSD devs seem to use Comic Sans in their presentations though

E.g., http://www.openbsd.org/papers/ru13-deraadt/index.html

I know about TRAMP. But that's a different use case. In this case it's about keeping the Emacs session on a remote host.

At least they added Comic Neue. I'm a bit disappointed that a project like OpenBSD that is so vocal about free software is promoting a proprietary font like Comic Sans MS.

Akonadi really annoys me. Who thought it would be a good idea to run mysql on each desktop to store email metadata? That's just ridiculous bloat. Mysql is among the top 10 entries for me in powertop. Why would MySQL be needed to deal with the metadata? All other mail applications seem to do fine with Maildir and an index.

And in case anybody thought that using MySQL would allow them to scale (you know because people receiving a million mails/s is such a common use case) then the answer is no! Thanks to Nepomuk many operations were bound by the RDF triple store they used. Maybe it has improved now thanks to Baloo. But once I tried to delete a folder containing a mailing list with a few thousand mails and I wondered why my laptop got so hot until I realised that Nepomuk was struggling.

Maybe the situation has improved now though. But the whole KMail transition was really painful for no tangible benefits to the user. This really feels like a prime example of overengineering.

It offers one advantage: You can run it in a GNU Screen session on a remote host.

(Unless it is somehow possible to run a graphical emacsclient over network)

Google Code was such an improvement over SourceForge. I think the real problem of Google Code was that it took them too long to support git. When GitHub started Google Code was still SVN only and later they only added Mercurial support. This made people look at GitHub and GitHub could shine with some new ideas, like making code contributions extremely easy and placing the code first. Which of course further increased the popularity of git and so on. By the time Google Code added git support many major projects had moved and GitHub was simply the place to be.