One thing to keep in mind when looking at GNU programs is that they're often intentionally written in an odd style to remove all questions of Unix copyright infringement at the time that they were written.

The long-standing advice when writing GNU utilities used to be that if the program you were replacing was optimized for minimizing CPU use, write yours to minimize memory use, or vice-versa. Or in this case, if the program was optimized for simplicity, optimize for throughput.

It would have been very easy for the nascent GNU project to unintentionally produce a line-by-line equivalent of BSD yes.c, which would have potentially landed them in the 80/90s equivalent of the Google v.s. Oracle case.

I think that's related to how commenters are reacting. The OP sort of implies the only contact he had with instructors was at the beginning of the year when they received their assignment.

I left a comment above about how I left MIT (which doesn't teach as much as it provides an infrastructure for taking tests students use to demonstrate mastery) for a state school (that actually taught the courses offered and provided students with ample lab opportunities.)

I'm now thinking one of the great benefits from being taught by an actual professor (instead of an upper-classman fraternity brother) is that you get a context that is formed over the lifetime of a research career. I learned equations by reading the textbook. But how they were developed, why they were developed, what equations were used before and why they needed better models? I don't think you're going to get that from your fraternity brother.

So... yes... hopefully the UTokyo team had access to the faculty to direct them towards the most fruitful areas of the academic garden. And yes... I think there are some very good CS students out there in the states that could do the same thing. But as I mentioned above, it's great to hear a tale about smart kids working together as a team.

These things are much easier for the average person when a course provides motivation, deadlines, requirements, and office hours.

I would expect any Western student at a top school who self-selects into taking OS to be capable of this with the right course structure.

I keep seeing people say that Musk had little to do with SpaceX's technical side, and I wonder where this meme (in the original Dawkins sense of the word) is coming from.

If you watch the EverydayAstronaut interviews with Musk it shows that he has a deep understanding of the engineering tradeoffs and design reasons for many components of the rocket, and in fact is being quite careful with what he can share due to not wanting to leak company secrets. In fact, some of the questions that were asked in the earlier interview were re-referenced in a later interview as having been considered and leading to design changes.

I think Musk is a smart engineering type who sees finance, PR, politics etc as just another engineering problem, with all the pros and cons that creates. He's had a ton of success in hard-tech fields just by not being an idiotic pointy-haired-boss in a world where finance and political people are repeatedly being put in charge of projects and companies whose tech they don't understand. This doesn't mean he is likeable, or someone you'd want to have a beer with, or moral, or anything else. But it does mean he is capable of managing a tech company better than most, if we use the success of the company as our capable-of-managing-a-company metric.

> can't be caught off guard by China as EU was caught off guard by Russia.

There's always a bigger fish.

The last time nations were obsessed with autarky, we got WW1, and soon after, WW2.

Most countries (i.e. every country not suffering from a drastic case of the resource curse) have the nature that if they trade a lot with another country, either country would lose economic value if they invade the other, _even if_ that invasion goes off stellarly well with almost no losses: The populace doesn't like being subjugated and produces significantly less.

In an inbalanced trade/dependency relationship, such as Saudi Arabia's oil vs. the rest of the world, or Russia's gas vs. europe, it's actually _both_ sides that are dependent on the other. It's the dutch curse all over again.

Go back in time:

* Europe wants more gas to grow its economy, and doesn't have enough on its own soil. * Russia has more than plenty and is willing to sell it. * We enter a period of years where europe companies and countries more and more build industry that isn't going to work out without the relatively cheap russian gas. As these industries continue to succeed and russia continues to be a reliable supplier, ever more industry takes the leap and becomes dependent on it. * This sounds like handing off quite the 'weapon' to your supplier, but, the problem is, that supplier is now just as dependent on this relationship as the consumer is: Russian economy falls apart without the trade of europe-produced goods (a lot of it by industries that run on russian gas), just as fast as europe falls apart without russian gas.

Thus, if russia were to invade europe, russia's economic value falls off a cliff, and the same applies to a lesser extent to europe. The only reason europe could in theory invade russia (assumes a perfect invasion, no nukes, no significant resistance at all, just a dejected populace), is because russia's primary value is not particularly dependent on human capital.

My theory about why this theory didn't work out and russia invades ukraine is a mix of:

* Misunderstanding by Russia of world/Europe response to this invasion. * Too much power in one person, who, like most people surrounded by yay-sayers for 20 years, has lost grip on reality. * Most of all, a ticking clock: Europe has stated they want to wean themselves off of fossil fuel within a decade or so. And so they should, but it's a torpedo to the trade dependency relationship between europe and russia.

That last one is the economic argument: Russia had to do something or their economy would fall apart if europe delivers on their plans to rapidly reduce their dependence on (russian-supplied) gas.

Thus, autarky -> war. Because if you're doing economically better than your neighbouring country, you produce more weapons and more people, and just invade em, why not.

We can trade the risk of what happened to europe, or what is likely to happen if china and the west become autarkic relative to each other (namely, that china invades taiwan) - with nukes and MAD. But that's got its own problems.

There's a LOT more to this discussion.

SiFive claims they can fit a RV32E core into 13.5k gates, but to my knowledge, that's just the core itself without any of the IO, memory, etc.

A small 8051 implementation can be made in 2.7k gates with a lot of typical implementations using between 8 and 14k gates (but with a lot of proprietary features not actually in the spec).

Setting aside the question of power efficiency of 8-bit cores, the real question becomes one of instruction density as that determines the size of the storage and RAM (increasing these can have dramatic cost differences). To my knowledge, RV32E doesn't have a compressed instruction variant meaning every instruction is 32 bits long. 8051 instructions are between 8 and 24-bits long (generally, 8-bit for math, 16-bit for MOV, and 24-bit for immediates).

If you're working mostly on 8 or 16-bit data like a TON of MC work is, then I don't see how RV32E could have any advantage. If you're working with a lot of 32 or 64-bit data, then I can easily see a RV32E chip requiring less space for the same results.

A 16-bit only variant of RISC-V that repurposes the remaining 50% of the instruction space (used for marking 32 and 48-bit instructions) would be a much more interesting option here IMO.

Let alone which ones are the good ones. That only comes from experience.

AWS never cancels anything... but they never complete anything either and they abandon 80% of their products in minimum viable state, where "viable" is defined by the PM's bonus packet, not by anyone who has to use the damn thing.

There was a lot of government money, directly or indirectly, involved in keeping Apple afloat and before that, bringing noticeable revenue. Then there's more state rather than federal, if you care about the difference, money from school systems hooked onto Apple II, which made it so that it was produced up to early 1990s.

Similarly a non-trivial point in financial history of Sun was contracts that indirectly depended on NSA.

Then you have third-order money flows, where lots of govt money flew into various projects, which enriched people enough that they could buy Apple products.

I'd argue that the biggest difference is that the government money was very free flowing, and often goal-oriented and who actually got it was a detail that wasn't even taken into account unless you failed to deliver. Meanwhile a lot of EU funding grants, depending on country, involves a lot of paperwork instead of just govt buying from you.

Apple's federal sales division was one of the strongest sources of revenue during Apple's lowest points, thanks to very good integrated sales & support team that kept islands of Macs in various governmental locations, often doing specialised tasks as graphics/audio workstations and the like.

But to get those contracts there had to be appropriate spending by government, and that's what I meant in my comment.

Also z/OS (formerly known as MVS) -large chunks of it are written in an IBM-internal-use-only PL/I dialect called PL/X.

The core of the AS/400 operating system, OS/400, the Licensed Internal Code (LIC), used to be written in another IBM-only PL/I dialect, PL/MP. In, the 1990s, while porting the AS/400 from CISC to RISC, they rewrote all the PL/MP code into C++. But IBM has another private dialect of PL/I called PL/MI, which was used to write the higher level part of OS/400, the XPF - basically PL/MI compiled to the virtual machine bytecode but PL/MP compiled to the machine code of the physical hardware. From what I understand, parts of the XPF are still written in PL/MP even in the latest versions of OS/400 (now called IBM i OS), although newer components tend to be developed in C/C++ instead. Other parts of the XPF were written in Modula 2, and I believe there is still some Modula 2 code surviving in the most recent versions as well.

IBM has had even more secret proprietary PL/I variants. The long defunct IBM 8100 line’s DPPX operating system was a written in PL/DS. Another dialect, PL.8, used to be used to write IBM’s compilers (although I believe it has now been replaced by C++) and also some of the firmware for the mainframes. IBM even wrote a GCC front-end for PL.8, although it appears they never released it.