lambda

> Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself.

Why is it that so many people feel like they need to make sweeping pronouncements on the exact compatibility guarantees that a project as large as the Linux kernel must maintain across its entire code base?

Different maintainers of different subsystems of the Linux kernel make their own decisions on compatibility and support effort. There are a few basic principles shared across the project as a whole, such as user-space ABI compat guarantees, lack of kernel-space ABI guarantees, module licensing requirements, etc.

Not every piece of hardware even exists in the form of a PCIe expansion card. Some drivers are for peripherals that are embedded into a specific line of systems-on-a-chip. If I'm writing a driver for some peripheral that only exists on an AWS Graviton chip, I don't see any reason why some HN commenter should dictate that that driver can't be written in Rust just because there isn't yet upstream LLVM support for DEC Alpha chips.

I feel like most of these takes are due to someone getting upset a couple of years ago because some core library in Gnome like librsvg added a dependency on a Rust compiler back when rustc didn't yet support m68k systems, and this got someone working on packaging upset due to conflicting distro packaging policies.

The world moves on, however. The Linux kernel drops support for old hardware all the time. It introduces features that might only work on certain hardware. Also, rustc has added support for more platforms, including moving some platforms like aarch64 to Tier 1 support, and adding support for m68k.

While maintaining backwards compatibility or wide portability of drivers is a good thing, so is the much easier ability to write maintainable and secure code that Rust brings, so the desire to simply block one good thing that works on the vast majority of machines running Linux in favor of some small niche use cases doesn't really seem like the soundest decision.

And what did Go do?

Yeah. My problem is that my "really bad cold that lingered" was in February 2020.

That is late enough in the timeline, and the testing at that time was so insufficient, that it's really hard to say.

I don't recall losing my sense of smell, but I have been struggling more with concentration issues and depression since then. Of course, that could also be due to all the stress over losing a friend to COVID, the lockdown, the political situation in the US, etc.

The biggest disappointment for me in the whole COVID response has been the complete failure of ramping up COVID testing and doing random testing or testing of those who hadn't traveled to China.

Heh. I guess I have an interview question to update.

One of my quick warm-up questions is asking about what data structure to choose if inserting an element after an element you already have a reference to is a common operation that you want to optimize for.

Of course, I don't consider there to be a right or wrong answer, but just make sure that people can intelligently discuss it. Some people start off with vec or the like, and then we discuss how fast that would be compared to a linked list. I generally stop after we get to the O(n) vs. O(1) comparison.

But maybe if we have some extra time I should also talk about the tradeoff with actually traversing the list.

After all, I suppose this is why things like gap buffers are popular for text editors, rather than linked lists.

Cool! Thanks for some more reading and inspiration.

Here's what I have in my notes buffer; I hadn't gotten much further than this.

  Ssn: /([0-9]{9})|([0-9]{3})-([0-9]{2})-([0-9]{4})/\1\2\3/
  People: Table
      first: String
      last: String
      dob: Date
      ssn: SSN

  Csv
      headings: True
      load people.csv
          as: People
      select first last dob
      filter dob.age > 21

Well, I had some discussion, alternate forms of the syntax, links to prior art, etc, but not much else worth sharing.

Will have to add your TreeNotation and Ohayo to that list, as well as these other links you've shared.

Hey, nice! I have a notes file experimenting with a similar tree-style minimalist data notation; it's definitely an area that needs more exploration.

I like what you've done with it, I'll need to take a closer look.

While I was thinking about it, I also decided to take a look into prior art, which took me all the way back to Landin's "The Next 700 Programming Languages" from 1966 which introduced the hypothetical language ISWIM, which was the first to introduce indentation based syntax and inspired the ML and Haskell family of languages (https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf)

It wasn't exactly what I was looking for, but it's fascinating to see how long we've been thinking about these kinds of issues.

What is Blender's funding model? I recall that its initial open source release was essentially crowdfunded before that was a trendy thing, but I haven't been keeping up with how they've been funding continuing development. They seem to be doing pretty well at that, so I'm curious about where the majority of revenue is coming from.

Argentina?

RISC vs CISC isn't really about instructions doing "one simple thing period."

It's about increased orthogonality between ALU and memory operations, making it simpler and more predictable in an out-of-order superscalar design to decode instructions, properly track data dependencies, issue them to independent execution units, and to stitch the results back into something that complies with the memory model before committing to memory.

Having a few crazy-ass instructions which either offload to a specialized co-processor or get implemented as specialized microcode for compatibility once you realize that the co-processor is more trouble than it's worth doesn't affect this very much.

What ARM lacks are the huge variety of different instruction formats and addressing mode that Intel has; which substantially affect the size and complexity of the instruction decoder, and I'm willing to bet that creates a significant bottleneck on how large of a dispatch and reorder system they can have.

For a long time, Intel was able to make up this difference with process dominance, clever speculative execution tricks, and throwing a lot of silicon and energy at it which you can do on the server side where power and space are abundant.

But Intel is clearly losing the process dominance edge. Intel ceded the mobile race a long time ago. Power is becoming more important in the data center, which are struggling to keep up with providing reliable power and cooling to increasingly power-hungry machines. And Intel's speculative execution smarts came back to bite them in the big market they were winning in, the cloud, when it turned out that they could cause information leaks between multiple tenants, leading to them needing to disable a lot of them and lose some of their architectural performance edge.

And meanwhile, software has been catching up with the newer multi-threaded world. 10-15 years ago, dominance on single threaded workloads still paid off considerably, because workloads that could take advantage of multiple cores with fine-grained parallelism were fairly rare. But systems and applications have been catching up; the C11/C++11 memory model make it significantly more feasible to write portable lock-free concurrent code. Go, Rust, and Swift bring safer and easier parallelism for application authors, and I'm sure the .net and Java runtimes have seen improvements as well.

These increasingly parallel workloads are likely another reason that the more complex front-ends needed for Intel's instruction set, as well as their stricter memory ordering, are becoming increasingly problematic; it's becoming increasingly hard to fit more cores and threads into the same area, thermal, and power envelopes. Sure, they can do it on big power hungry server processors, but they've been missing out on all of the growth in mobile and embedded processors, which are now starting to scale up into laptops, desktops, and server workloads.

I should also say that I don't think this is the end of the road for Intel and x86. They have clearly had a number of setbacks of the last few years, but they've managed to survive and thrive through a number of issues before, and they have a lot of capital and market share. They have squeezed more life out of the x86 instruction set than I thought possible, and I wouldn't be shocked if they managed to keep doing that; they realized that their Itanium investment was a bust and were able to pivot to x86-64 and dominate there. They are facing a lot of challenges right now, and there's more opportunity than ever for other entrants to upset them, but they also have enough resources and talent that if they focus, they can probably come back and dominate for another few decades. It may be rough for a few years as they try to turn a very large boat, but I think it's possible.

Yeah, my tone was a bit incendiary at first, because I get a bit frustrated at the shallow dismissal you see so often on Hacker News (and any number of other tech discussion sites). This kind of snarky dismissive comment is easy to make, and has a tendency to get upvoted because it matches misconceptions that many people have.

These kinds of comments, and downvotes in place of discussion, are corrosive to honest, informative discussion, and I've seen way too many tech discussion communities get taken over by people who make low-effort dismissive comments and avoid engaging in actual substantive discussion.

Not just the standard library, but the core language. They are what you get if you write a string literal in your code.

Ah, thanks. It's been a while since I've used Ruby seriously. Still not quite sure why "Matz's ruby" is separate on the Benchmark Game rankings, while all other languages are grouped based on the best implementation of the language. Anyhow, that's pretty much irrelevant to my overall point.

Thanks for the kind words, not sure why it's getting downvoted other than that I called someone out on their lazy dismissal. But I wouldn't worry about it too much, I've been on HN and Reddit for long enough to not care too much about downvotes.

Here is an example which, while trivial, demonstrates some of the optimization issues you can run into in C and C++ but not in Rust, even with noalias currently only applying to &T.

C++: https://godbolt.org/z/dTPsbh Rust: https://rust.godbolt.org/z/Mdx87h

In C and C++, compilers are allowed to infer "noalias" based on pointer types; two pointers of different type are not allowed to alias. This is known as type-based alias analysis. But char * is given special treatment, because of its use as a generic pointer type; so if one of your arguments is char * or even signed char * , that disables any optimizations which were relying on type-based alias analysis.

This provides both for performance and undefined-behavior footguns. If you ever try to use some pointer type other than char * or signed char * to refer to data of another type, you may inadvertently cause type-based alias analysis to kick in, causing invalid optimizations and miscompilation. On the other hand, if you have a function which takes both a char * and another pointer, the compiler may not apply optimizations that it otherwise could because char * is allowed to alias anything.

In Rust, there is no such undefined behavior footgun. Because of the LLVM bug, noalias isn't applied to &mut pointers so there are still some cases which could be better optimized, though it sounds like there is some progress being made on the LLVM front so it should be fixed at some point, and there are already places where the compiler can do better optimizations with better safety due to the stronger semantics of &T.

> I know I can safely ignore such benchmark

And yet, rather than ignoring it, you are commenting on it, with a pithy retort which dismisses the entire benchmark without actually providing any additional insight.

Programming languages, compilers, library ecosystems, the groups of people who decide to sit down and try to produce a better result for a given language, and the benchmark maintainers who decide what submissions count for a given language (does a C solution that just uses entirely inline ASM count?) are incredibly complex systems. Any single metric is never going to capture the full richness of the language, is never going to be representative of the experience you will have for every single program, etc.

But does that make metrics useless? No, it just means that you should be informed about their limitations. You shouldn't just look at a single number, but instead make sure you understand well enough what is being measured to know how well that number represents anything useful.

So rather than just dismissing this benchmark, it would be useful to ask "why are the C++ results better than the C results on this benchmark?"

Some benchmark challenges like this allow pretty much any program that accepts the right input and produces the right output; which means you get results in which no computation is actually done, the output is simply hard-coded and you are basically just measuring the startup time or request time of the language or library.

This particular set of benchmarks imposes some constraints to avoid that kind of behavior. Programs have to follow the same basic algorithm, so you can't figure out some clever algorithmic optimization which applies only for the particular input used in this benchmark. For things like the regex challenge, you are expected to use either the built-in regex in your languages standard library, or a common general-purpose regex implementation, not a specialized regex implementation optimized just for this particular benchmark.

The goal of this set of benchmarks is to provide a reasonable set of reasonably realistic small problems, implemented using the same algorithm, and using the normal language and library features. It uses small simple problems in order to make it easy to read the programs and learn about the performance characteristics of the language.

So rather than dismissing, why don't we take a look at the fastest C and C++ implementations of some of the problems?

Here's the fastest implementation of the k-nucleotide problem in C and C++:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I haven't sat down to do detailed profiling and performance comparison of each; but just off the top of my head, here are a few things I see which could be relevant.

The C++ implementation takes advantage of a number of C++ features; it uses a hash table from GNU pb_ds, a C++ container library which allows for a good amount of customization based on template parameters. The C implementation uses khash, a very fast hash table implementation which uses macros for similar customization.

The C++ implementation makes note of using move semantics in a number of places, which potentially allows for certain optimizations that wouldn't be possible if the compiler had to copy data.

The C++ implementation uses insertion into a templated ordered map to sort the results, while the C implementation uses the standard library qsort. This allows the comparison function to be inlined into the C++ sort, while it's called through a function pointer in the C implementation.

Without actually doing some experimentation and profiling, it's hard to say which of these makes a difference, or if it's something else. But this does show that C++ provides facilities for generic container and algorithm types that C does not. In the C implementation, macros are used to work around this for the hash table case, while function pointers are used for sorting.

Anyhow, rather than simply dismissing these results, why not dig into where the difference really lies, and provide a better implementation in C if you think that you can?

No one set of benchmark results should be taken as gospel. But I think this particular benchmark game is fairly useful for getting a rough sense of "if I write all of my code in this particular language, using either the standard library or commonly available off the shelf libraries, how much of a performance penalty am I likely to pay?"

I also find that the grouping of languages that he does, based on the minima of the kernel density estimation of their geometric mean scores, to be a bit more informative than absolute ranking within those groups. That gives a sense of the general class of languages. There's one group for C, C++, and Rust; languages which allow for performance without compromise, at the expense of lack of safety, higher complexity or learning curve, or both.

There's a next big group with a lot of languages; most of them have been around for a while, or been designed with an eye towards performance, but still have some amount of overhead due to GC or pointer chasing or greater thread synchronizaiton overhead or any number of other reasons; this group includes Fortran, Ada, C#, Java, Go, Haskell, etc.

Then there are a few groups of fairly high-level, dynamic languages, designed for scripting or rapid development, and which require you to trade off a fairly significant amount of performance for this. Dart, PHP, Python, Erlang, Ruby.

And finally, there's Matz's Ruby, all alone in a group at the end, slower than pretty much everything else. I'm not quite sure why it's separated out from Ruby, which seems to refer to yarv, but maybe it's so people who come here wondering what they can do about their slow Ruby programs can see that they can at least get a big boost by switching to yarv.

Anyhow, this benchmark and this grouping helps if you're considering what to do about some performance bottleneck you have in some code base; or if you're starting a project for something which will potentially be performance critical. Moving between languages in one group isn't all that likely to make a substantial difference; but moving to a language in another group would. For example, it lets you know that there's a pretty good chance that just rewriting a Python program that's a performance bottleneck in Go would improve that performance; but rewriting a Go program in Java, or vice versa, is less likely to be a performance win.

Huh. That's an interesting question. I looked up the original LISP paper (http://www-formal.stanford.edu/jmc/recursive.pdf), and it looks like the -p convention hadn't been established yet at that point, none of the predicates have that suffix in the paper. But it does say this:

  (LABEL, SUBST, (LAMBDA, (X, Y, Z), (COND ((ATOM, Z), 
  (COND,(EQ, Y, Z), X), ((QUOTE, T), Z))), ((QUOTE, T), (CONS, 
  (SUBST, X, Y,(CAR Z)), (SUBST, X, Y, (CDR, Z)))))))

  This notation is writable and somewhat readable. It can be 
  made easier to read and write at the cost of making its 
  structure less regular.  If more characters were available 
  on the computer, it could be improved considerably.[4]
  
  ----
  [4] 1995: More characters were made available on SAIL and 
  later on the Lisp machines.Alas, the world went back to 
  inferior character sets again—though not as far back as 
  when this paper was written in early 1959

So at the very least, some of the syntactic conventions of LISP were mostly due to limited character sets at the time.

Trying to binary search through history to figure out when the -p convention was introduced, I checked the original Scheme paper (https://web.archive.org/web/20171201033214/http://repository...), which has some examples in Scheme as well as implementation code in MacLISP. It looks like the predicate convention wasn't really strongly established at that point; in a few places, they use variables with a trailing `?` in the Scheme code, but I don't see any use of a predicate convention in the MacLISP implementation code.

Going back a bit, I do see the predicate convention mentioned in an Interlisp manual from 1974, but without an explanation of its origin (http://bitsavers.trailing-edge.com/pdf/xerox/interlisp/Inter...).

A MacLISP manual from the same year also mentions the -p convention, but not its origins. So looks like it had been firmly established by 1974: http://www.softwarepreservation.org/projects/LISP/MIT/Moon-M...

Going back further, the LISP 1.5 manual (second edition, 1965, though the printing was from 1979) has a number of numeric predicates with the -p suffix, but it does not make note of the suffix convention (https://archive.org/details/lisp15programmer00john/page/26/m... , free registration required). It does use a lot of language discussing "predicate" and use the term "p position of a conditional expression" (https://archive.org/details/lisp15programmer00john/page/22/m...), so the use of "p" for "predicate" rather than "?" seems to be somewhat well established. LISP 1.5 had a very restrictive syntax for identifiers, they were just alphanumeric.

So, I'm going to say that while it's possible that the usage of P for this purpose comes from substitutiong P for ?, all of the sources I've found seem to indicate that it stands for "predicate."

That part is a slight amount of hyperbole for humor value.

But the fact of the matter is, the submitter did actually reproduce the problem enough times that they were able to effectively characterize the problem.

And that's what I love about this story. Given how many bug reports I get in which no effort has been put in to trying to reproduce, characterize, or minimize the problem, I love that this reporter was willing to do enough of that to file a good bug report even for a problem that caused a fire in a piece of expensive equipment.

Yes! This is why I love this story so much. I triage so many bug reports that don't even have the barest of effort putting in to reproducing or minimizing them, so it's like pulling teeth to figure out what the problem actually is.

The fact that someone put enough effort in to reproducing and characterizing a bug report for a bug that actually caused a fire is amazing!

Yes, that's pretty much what I was picturing as well. Sorry if it didn't come through in the way I told the story.

But yeah, the part of this story that I love is that as someone who reads and triages a lot of bug reports, I'm always disappointed by how few people put in even the barest of efforts to reproduce and characterize a bug.

This person, on the other hand, spent the time and effort to reproduce a bug that would actually cause a fire, and characterize it well enough that it could be reproduced and fixed.

One of the funny things about the Intel/Arm situation is that in many ways, it mirrors how Intel itself started out on low-end microcontrollers and microprocessors for PCs, and grew to displace pretty much everyone else for the high end supercomputers, data centers, and the like. For many years, it has been fairly apparent that the same thing was happening with Arm; when Arm thoroughly cemented its position on top of the smartphone market, it seemed pretty clear that they would eventually be able to push up into the laptop market and beyond, the main question was when.

Unfortunately for Intel, they've been hit by a couple of major blows in quick succession; Spectre and other microarchitectural vulnerabilities, and the fact that the mitigations wiped out a lot of their architectural advantages, their trouble with manufacturing at new process nodes, allowing AMD to take the lead from them on high-performance x86, and Arm finally catching up with them in the desktop/laptop space, and also starting to make some small inroads in the server space (though mostly on cost, not performance at the moment).

One thing which may have made them more susceptible to the innovators dilemma problem is the fact that they were already a victim of the second system effect with their Itanium failure. They poured a lot of resources into a major new ISA, and it was a flop and was replaced by the incremental x86-64. Despite that, their incremental improvements on the x86 architecture managed to wipe out all of the RISC competitors on the high end; so there's probably even more organizational oppositions to major new architectural changes which could have kept Arm at bay.

I think it's interesting that it has taken this long for RISC to really pay off. The whole idea behind RISC was to optimize the ISA for modern, pipelined, OoO architectures, but it turns out that for a long time, a bit of extra complexity in the instruction decoder wasn't that much of a price to pay, and things like Moore's law and other architectural improvements kept it mostly irrelevant as a competitive advantage.

But finally, Intel has run out of running room on process dominance, and other things have happened like hitting more power limits and software that's able to take advantage of more available threads and relaxed memory models. Once you start to try to run more threads, the extra cost and complexity of those decoders starts to add up, and the strong memory ordering constraints mean that your hands are a bit more tied on huge OoO dispatch.

Anyhow, Intel is still the biggest semiconductor company in the world, and they have weathered other major issues like the famous Pentium floating point bug, Itanium, and Spectre. It will take a lot to dethrone them, and with their revenue and market share, they can lose a lot of battles and invest a lot of money into new technology or companies before they lose the war.

But the last few years make it clear that they need some big wins soon, or they risk turning into the next IBM, slowly losing relevance as they milk their cash cows while the world moves on.

My dad had a similar story about a bug report. This was back in the day when terminals still used paper rather than CRTs; actual teletypes. The bug report was something like "if I print a page feed on such and such terminal model, it will catch fire."

The bug report form (which was paper in those days) had a few of the usual checkboxes and fields to fill in, including one for "is the problem reproducible?" That box was checked. Someone had actually gone to the effort of standing by their terminal with a fire extinguisher, running the same command and putting out the fire when it caught fire again.

It turns out the problem was in some software that emulated page feeds by doing repeated line feeds. Some overflow or underflow bug caused an integer to wrap around, so instead of advancing a few lines to the next page, it would try to advance thousands or millions of lines. This particular terminal model was a new, high speed one, so it would try to advance the paper really fast. It was using those perforated strips at the sides, with the pegs that went into the holes. The pegs and holes weren't perfectly aligned, so the pegs would sometimes clip the holes a bit, causing some bits of paper to shred and get kicked up as dust. Along with a spark, I don't recall if it was from the motor or just static buildup caused by the friction of the paper, and the paper dust would ignite, causing the terminal to catch fire.

I just love the image of whoever submitted that bug report, seeing the "is it reproducible" checkbox on the form, and standing by the terminal with a fire extinguisher to put it out while doing the same thing to make sure the problem was reproducible.

This comment confuses me so much.

Mozilla absolutely has been helping to keep web standards in check. Maybe not to the degree that you would like, but if it were up to Google, we'd all have some ancient under-specified version of SQLite and LLVM encoded in web standards, as they tried to just drop those in for database storage and NaCL.

Mozilla pushed back on those, demanding documented standards that could have independent implementations.

WASM is the cross-browser, much better specified alternative to NaCL.

Formal standards in an executable language are by far the exception rather than the norm. For something with as big a surface area as web browsers, I'm sure they would cost an ungodly amount of time and money to complete. And while you may prefer to reduce the surface area to deal with this, no one wants to break compatibility with existing sites.

I'm a bit puzzled by what you actually want. Mozilla did scale back its investment in Rust, WASM, and the experimental browser engine Servo, to focus more on its core browser, in the recent round of layoffs. But the existing investment has paid off; a number of projects that started off in Servo, and were written in Rust, like the CSS parser and Webrender, are now part of Firefox, providing safe, parallel styling and GPU rendering. WASM is widely supported across browsers, providing an efficient compilation target which is much better specified and easier to work with than JavaScript as a compilation target, or something like NaCL.

And some of the other efforts, like Rust and WASM, have now achieved sufficient industry adoption that other companies are picking up the slack; Amazon, Microsoft, Google, Fastly, and others are all hiring and paying people to work on Rust and WASM full time.

It seems that other than funding Thunderbird development, Mozilla is doing what you want, but you somehow still seem unhappy with it. Why is that?

It does say "Every six months we have a meeting to revisit this policy. Email ... if you want to attend the next meeting."

It sounds like he's willing to listen to feedback about the policy, but would rather have focused time dedicated to discussing it rather than long drawn out inconclusive tickets.

Since most articles with titles like this can be answered with "no", I'd like to point out for anyone reading the comments but not the whole article that the answer in this one is "yes," since Apache Arrow targets a different workload and can be considerably more efficient for that workload.

I have not flagged any of your posts, but remember that "free speech" means freedom from government interference with speech, not freedom from a particular community deciding that your speech is disruptive to that community.

I notice looking through your comment history that you spend a lot of time discussing abortion and gun control, the two primary culture war wedge issues in American politics, and which are mostly off-topic for a technology and startup focused discussion site.

I tried to answer your question in good faith, and hope that you appreciate the information, but I don't really think this is the best forum for discussing the ethics of embryonic stem cell research.

I will just leave you with this article which has some good history on the anti-abortion movement in the US and how it came to be associated with the evangelical Christian movement: https://www.politico.com/magazine/story/2014/05/religious-ri...

The fact that you use the term "flesh of murdered babies" to refer to embryonic stem cells, which even the Catholic Church simply refers to as "aborted fetal cell lines", indicates that you've bought way too heavily into the right-wing American culture war.

But anyhow, to answer your question despite the terrible way it was asked, no, the Moderna vaccine did not use embryonic stem cells in its development or production. Some partners, such as NIAID, did use embryonic stem cells for in-vitro testing of the vaccine: http://phillycatholiclife.org/life-affirming-choices-3/covid..., but the Catholic church does not consider that to make the Moderna vaccine unethical, as it's its direct development and production have never involved the use of embryonic stem cells.

There are options for pro athletes after their athletic career, as trainers, speakers, organizers of amateur events, etc.

For the major US pro sports, some or all of their draft is from colleges in order to encourage post-secondary education and leave players with more options after their career. I'm not sure how many pro cyclists do college, but I knew some folks when I went to college who were fairly high amateur and I believe looking to go pro.

> Rust is pretty cool, but Servo is pretty immature, and it seems like Mozilla just fired all those people. I dunno. I don't see a bright future there.

Well, yeah, that's the problem.

Until now, I felt like despite its issues, Mozilla was mostly on the right track. There have been a few mistakes here and there, but it was fundamentally doing good work.

However, cutting Servo, and it looks like maybe Cranelift as well (not sure about that, but Dan Gohmen aka sunfishcode, who seemed to be one of the lead contributors, has been laid off) is a huge blow.

While Servo as a whole browser is pretty immature, a number of components of it were adopted by Firefox, such as its CSS parser, Webrender, its GPU accelerated parallel rendering engine, and more.

You had asked about what Mozilla had done recently, and I listed a few things. But it looks like they are cutting a lot of that. They mentioned focusing on wasmtime and the Bytecode alliance, but I don't see how cutting one of their lead contributors helps out with that.

And they seem to be slowly cutting the head count on Rust; it's less apparent because there are enough people not at Mozilla contributing, and some of the core contributors have been moved onto other projects which use Rust at Mozilla so while they're not contributing directly they are still somewhat involved; and some folks have left of their own accord.

But now it looks like some of those other teams are being cut, like Servo and at least some of the wasmtime team, so I really hope that more companies can put some more investment directly in Rust, as well as the WASM ecosystem.

> Safari made third party tracking impossible by gradually fully segmenting everything - HTTP caches, LocalStorage, cookies, etc. -

I haven't been following exact features between browsers too closely recently, but Firefox's Tracking Protection has been around for a while and improving for years; and of course, Firefox is where AdBlock/uBlock originated. What does Safari provide that Firefox does not? How does it affect web compat?

> and Chrome made JIT exploitation and then Spectre attacks in JavaScript impossible by using process boundary separations and applying sandboxes to purpose built processes.

This feature has been a long time coming in Firefox, and it's still not all the way there.

But Firefox did just release an opt-in process isolation feature for Firefox, which applies stricter cross-origin controls for a variety of content, and in exchange gives web developers access to SharedArrayBuffer, the feature that needed to be disabled to mitigate Spectre attacks.

So site isolation is progressing, and the first iteration of it has been released.

> What awesome technical choices do you think Mozilla has made recently?

The development of Rust. Servo, which acted as an experimental testbed for a parallel browser engine and has led to its CSS parser, WebRender, and a number of other components being used by Firefox. Asm.js as an alternative to NaCl, which led to the joint development of WASM.

Quite a lot.

Take a look at a recent snapshot of changesets and lines of code to the Linux kernel contributed by various employers: https://lwn.net/Articles/816162/

Arm themselves is listed at 1.8% by changesets; but Linaro is a software development shop funded by Arm and other Arm licensees to work on Arm support in various free software, and they contributed 4% of changesets and 8.8% by lines of code. And Code Aurora Forum is an effort to help various hardware vendors, many of whom are Arm vendors, get drivers upstreamed, and they contributed 1.8% by changesets and 10.1% by lines changed. A number of other top companies listed are also Arm licensees, though their support may be for random drivers or other CPU architectures as well.

However, Arm and companies in the Arm ecosystem do make up a fairly large amount of the code contributed to Linux, even if much of it is just drivers for random hardware.

And Arm and Linaro developers also contribute to GCC, LLVM, Rust, and more.

Ah, sorry, I was looking at the wrong item on "Can I Use...", @font-face: font-variation-settings, rather than the "Variable Fonts" item which covers font-variation-settings outside of @font-face rules.

https://caniuse.com/#search=font-variation-settings

And I am running an ancient version of macOS, 10.12, which explains my issue, as it's only supported on macOS 10.13+ in Firefox.

I have a new (non-macOS) laptop in transit, but my current daily driver is an old Mac.

Sorry for the alarm!