If you think that’s dedication: I met Dominic (DA) who they interviewed in this article almost 20 years ago in the Spanish desert, where taught us Euroburners the art of MOOP cleanup. He’s been at it for a long time now.
I’ve had a similar FAANG experience. They approached me, I made “no relocation” a non-negotiable condition from the start. We started talking, I did the marathon interview until late in the night (CET vs PT), put my formal application in their system, and after two months they said they were ready to make me an offer. On the same day, it turned out that they had not even bothered to look up the pay range for my country. Instead, I was asked for the fifth time if I were willing to move to California.
I would love to see a BeOS/Haiku userland on top, of the Linux Kernel. That would bring wide hardware support, including HW accelerated 3D (something BeOS was always lacking). It is not going to happen though, the attempts that were didn’t go far and porting the entirety of Haiku would be a gigantic effort that no one is volunteering for.
Linux 20 years ago wasn’t what it is today. Low latency audio for example, that was something that BeOS in the late 90s could do out of the box, a similar experience on Linux required special kernel patches and some compromises or it simply wasn’t there at all.
Audio latencies of less than 10ms on consumer hardware were otherwise unheard of. Windows, out of the box, was still operating in the 100+ms range.
Part of it is pure luck - being at the right place at the right time. An on site internship gave me a foot in the door for my first remote job. After that, I had experience in a certain niche and a couple of open source contributions under my belt.
Another part is just having the guts to ask for a remote job straight away and accept getting turned down dozens of times.
German here as well - the lack of employer flexibility is why in the last 15 years, I have been working exclusively for companies overseas, remotely. I found it much easier to negotiate remote work with an employer based in San Francisco than one in Berlin or Munich.
HIView was up to date and documented, and there were WWDC sessions teaching developers why they should move to HIView and how to do it. Likewise, Apple provided documentation about how to port your Carbon application to 64 bit Carbon. Maxon reportedly even had a 64bit Carbon version of Cinema 4D ready to ship when Apple suddenly announced that they would abandon 64bit Carbon - telling developers to disregard the 64bit Carbon they were still shipping in betas.
Apple may initially have intended Carbon as temporary, but has changed their stance when they started adding new APIs that never existed in MacOS 9 - HIView/HIWindow was intended to unify Carbon and Cocoa, there was even a 64 buy version of Carbon that shipped in Mac OS betas, and when Retina-Display Hardware shipped, Carbon received new APIs to deal with that.
Likewise, Cocoa in 10.0 was buggy and incomplete. It took until about 10.4, 10.5 for Cocoa to reach feature parity with Carbon and many Cocoa applications were using Carbon for certain features (in facts, last time I checked, Cocoa menus were implemented in Carbon).
Besides, we’re already using render farms where each machine has 20+ cores and 256GB RAM. A future render farm might as well be built from machines with specs similar to the new Mac PRo.
Remember the joke of “never underestimate the bandwidth of a 747 full of hard drives”? That’s the render farm. Throw a ton of work at it, and it’ll get done faster than a big single machine could. What would have taken a week now takes a day.
The Mac Pro in our analogy is 5G wireless: not nearly as much bandwidth as the 747, but at much lower latency. Lots of interactive/real time applications are possible that in a farm would be bottlenecked by network bandwidth alone.
I worked as one of several in-house Blender developers on "Next Gen". In some cases, were able to get fixed builds into our artists' hands in within 24h of a bug report. I have not had such a quick turnaround with any commercial software vendor yet.
"Normal days" changed during the course of the project. In the beginning, it was work on new features for months if necessary, towards the end it were overnight patches for "frame x in shot y looks wrong/crashes/takes forever".