stmw

"The C74-6502 is a homemade implementation of the venerable MOS 6502 microprocessor. The 6502 was revolutionary in its time, and widely adopted in early home computers and gaming consoles. This design is a microprogrammed, discrete-component 6502, an architecture that was prevalent in 1970s-era mainframe computers which pre-dated modern microprocessor technology.

The C74-6502 is plug-in compatible with a wide variety of 6502 systems, including classic computers from Commodore and Apple, as well as modern systems based around the 65C02 microprocessor still in production today. This CPU runs at speeds of up to 20MHz (vs. 1 MHz for the original MOS 6502)."

The customers are quite isolated, but it doesn't mean that some services or errors do not propagate. In public cloud terms, think back on some AWS or Azure or even Gmail outages - you probably wouldn't even hear about them if it didn't affect millions of users at once, across security and availability boundaries.

Despite all of the snark here, in my experience Salesforce SRE team is quite competent. The engineering challenges of running a large PaaS - not just with own apps, but with millions of customer-written apps running on it - are quite interesting, and sadly things happen. The status page makes sense to actual customers, it's the particular "pods" where a given service runs.

One of the important questions to always ask about solar is the energy inputs required to make a solar panel, and the time required to "earn it back" with solar electricity. This is different than "cheap price" because the energy consumed in manufacturing usually happens on a different continent, in a different currency, different regulatory regime and is thus easily obscured.

Indeed, he and Turing and a handful of approximate contemporaries had a very clear view that was wrong only in its timing.

"This rare episode of CBS’s Tomorrow series, produced to commemorate MIT’s 100th anniversary (1861–1961), explores the early days of artificial intelligence, robotics, and the potential of “thinking machines.” Hosted by actor David Wayne, this documentary-style special features interviews with pioneering computer scientists, including MIT President Jerome B. Wiesner and AI visionary Oliver G. Selfridge of MIT Lincoln Laboratory."

Also a good opportunity to read about https://en.wikipedia.org/wiki/Radia_Perlman in general (she is mentioned in the blog of course).

It's interesting because we learned this lesson with JVM applets, Flash and X controls in the browser, yet somehow insist on revisiting it...

JIC! That's funny. It may sound like inefficiency, but really it is an option on future flexibility. Just like the big box of cables.

also - https://www.freedomforum.org/remembering-bill-biggart-911-an...

It's what JIT (just-in-time) inventory and offshore manufacturing took away from us. Hold onto your spare parts.

Thanks for answering, not surprising. I think the transition from all-hardware to Windows-driven digital hard on Tektronix and many other storied engineering teams.

For a brief second, I thought this was about an original 7104.

Are there specific TDS models that you have found to be better, btw, reliability-wise?

Ineed, it's a very good book. Someone should make an animated website version, though.

Which MacOS version are you on, out of curiosity? Do others see the same software issues?

"Arm was officially founded as a company in November 1990 as Advanced RISC Machines Ltd, which was a joint venture between Acorn Computers, Apple Computer (now Apple Inc.), and VLSI Technology (now NXP Semiconductors N.V). "

When I say "unavoidable" I mean exactly things like your "a high allocation rate of long-lived objects (as one example), where the work that has to be done requires a significant number of CPU and memory cycles spent on memory management (manual or automatic).

When I say tradeoffs", I mean exactly things like "inherent increased footprint", or my earlier "wasting RAM" point.

At this point, I'm not sure that we're disagreeing about these details, but rather what we make of them... I view them as just years of continued tuning of tradeoffs (heap size vs CPU cycles vs memory cycles), while you them as major breakthrough that makes garbage collection much more desirable. Is that fair?

Someone runnning Kubernetes on an old unpatched on-prem Windows box, conducting a "failover test" by pulling one of its power supplies, spilling coffee on the other one, catching their house on fire, and waiting to call the fire department due to being embarrassed.

One shouldn't make jokes about a situation where people died. Just to sum up Chernobyl 1. no containment building 2. flawed reactor design 3. operators turned off safety systems and improperly operated the reactor 4. delayed / improper emergency response

This is the equivalent of a Kubernetes pod restarting.

To rephrase it: nothing happened, and reactor is back online generating clean electricity.

This is the equivalent of a Kubernetes pod restarting.

It is fair that there are many ways to be slow in any number of programming languages. I'm surprised to hear "Rust programs spending 30% of their CPU on memory management even when they're as small as a couple hundreds of thousands of LOC", although I can visualize some unique workloads where that's unavoidable irrespective of language & runtime.

Maybe I should've mentioned at the start that I've implemented several GCs and worked on several Java VM implementations, so I am generally familiar with the tradeoffs between GC algorithms and other runtime details.

Even in the very positive blog you linked, you see statements like * "ZGC has a fixed overhead 3% of the heap size, requiring more native memory than G1. .." and * "Reference processing is also only performed in major collections with ZGC. We paid particular attention to deallocation of direct byte buffers, but we haven’t seen any impact thus far. This difference in reference processing did cause a performance problem with JSON thread dump support, but that’s a unusual situation caused by a framework accidentally creating an unused ExecutorService instance for every request."

This was my point about how this sort of thing is a type of manual memory management.

As for waste more RAM, waste more cycles wasn't a statemnt about whether a particular GC is better-performing for certain situations, but that the overall improvement likely has more to do with improvements in CPU speeds and RAM size, than the latest GC version (which tends to simply make a different set of engineering tradeoffs).

As the OC, I think my view is somewhere in the middle - I am neither as optimistic about it being "great now" nor do I think that "rewrite in C++" 10 years ago was easier.

My reason for disagreeing with the former view is that improvements in physical RAM available and tendency towards smaller workloads have allowed many Java (or other GC runtimes) to essentially "fix their problems because hardware got better". So you can waste more RAM, waste more cycles, but "it doesn't matter", and likely it is fine in many cases - but it's is not the same thing as claiming the GC algorithms are responsivle for that outcome. We have been 3 years away from GC solving memory management for at least 30 years.

My reason for disagreeing with the latter view is that for those who don't have 100-250 GB long-lived heaps (or whatever the contemporary version of that is), the pain level is far lower than rewriting in C++ or Rust, or likely the pain level of hiring enough engineers who can do either. It's a completely different engineering culture.

It depends a lot on the scale of the system, which often means that those fewer users are actually doing things that are more complex and more valuable - either at the lower end or at the high end.

GC's haven't freed us from manual memory management, you just do all that manual work with environment variables, or making sure to "pick the right collector for the job", or debugging performance or heap size issues, or chasing down weak references or confused finalizers.

Interesting how much NPR articles changed in 20 years

That's nice. (Not uncommon in early RISC, (e.g. PowerPC had some similar limitations for 64 bit ints), and various assembly fun ensued).

Fun fact - Linus first trip to the United States was related to Linux-on-Alpha port and sponsored by Digital Equipment Corporation.

One thing I wonder about is how these high-profile startups handle their engineering hiring - in this case, it's just a link to an Ashby form.

They probably already got 10,000 resumes in the past 24 hours, wonder what they do and how effective this is.

Anyone already apply there, what was the process?

Good product management is mostly about saying No.