stmw

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.

One of the interesting things they have is an in-browser visual simulation of the 6502 die - http://www.visual6502.org/JSSim/index.html - "In the summer of 2009, working from a single 6502, we exposed the silicon die, photographed its surface at high resolution and also photographed its substrate. Using these two highly detailed aligned photographs, we created vector polygon models of each of the chip's physical components - about 20,000 of them in total for the 6502. These components form circuits in a few simple ways according to how they contact each other, so by intersecting our polygons, we were able to create a complete digital model and transistor-level simulation of the chip.

This model is very accurate and can run classic 6502 programs, including Atari games. By rendering our polygons with colors corresponding to their 'high' or 'low' logic state, we can show, visually, exactly how the chip operates: how it reads data and instructions from memory, how its registers and internal busses operate, and how toggling a single input pin (the 'clock') on and off drives the entire chip to step through a program and get things done."

Previously posted by me here - https://news.ycombinator.com/item?id=46182669 - but didn't get any interest, not complaiing, good that it got noticed this time.

Indeed, it is often amazing to me to see what catches on and what doesn't. However, the concept of cooperative, event-based processing coupled with an existing and popular language is probably what was decisive wrt Node.js.

Sorry, that's annoying indeed - not my site..

"General Radio was founded in Cambridge in 1915 by Melville Eastham and four other investors to manufacture radio measuring instruments and parts. Initially, the company focused on transmitting and receiving components and precision measuring instruments, as well as a few complete receiving sets. ... By 1924, General Radio began its decades of dominance of the high-end instrument market. During the time, the company introduced a host of unique instruments, including the first commercially available oscilloscope. Two products developed in the 1930s found major uses during World War II: the Variac variable autotransformer and the Strobotac, the first commercial strobe light. "

Am I the only one who read this to mean a Urinary Tract Infection has afflicted the latest versions of MacOS and iOS, perhaps some special case of markdown ens--ttification?

But apparently no, it's good news.

"The superjunction (SJ) charge balancing concept has been successfully implemented in silicon (Si) MOSFET power devices. Greater focus is now being placed on improving the performance metrics of wide bandgap (WBG) power devices with this technique. In this article, we summarize initial results that show promise in the application of the SJ structure in a lateral gallium nitride (GaN) Schottky diode."

There are few in the same category, perhaps Widlar or Gilbert for pure analog circuit design, or Bill Atkinson in later Mac software? It's a very short list.

Indeed. I have often wondered why university courses tend to use their own made-up machines to teach this stuff, as opposed to using the Apple II (or some of its near-contemporaries).

Agree, that's why I think it is so interesting - but it's also a rule that works in both directions (hardware->software and software->hardware).

The copy-protection stuff was completely puzzling back when it mattered, but of course makes complete sense now.

I hadn't seen the applesaucefdc.com stuff, that's great.

Not for this data, but in the past, yes - there is persistent pressure to do that for any maker of password managers, be it independent, in-browser or in-OS. (Source: I was a cofounder of a company that made a password manager as part of our product).