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.
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.
Yet after 20 years of Linux distros, we still see Linux struggling with getting a simple desktop together without X or Wayland crashing itself and logging you out because of someone wanting to tweak their desktop via a custom init script or systemd script.
Let me know when I can support 100% of all Linux distros and users like I can with macOS and Windows.
There's only one macOS and only one Windows. You can support only the big distros (basically Debian/Ubuntu or/and Fedora/openSUSE; for example that's what Chrome does) and let respective distro maintainers handle issues to other ones. Or just use Snap or/and Flatpak.
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.
IIRC that was one of the two/three main ways forward discussed and planned for after Be Inc went belly up.
- OpenBeOS (Haiku) - rewrite from scratch
- Option 2 (can't remember if it had a name) - was just to Implement BeOS userland on a Linux, to get free access to drivers etc. Most of the Be community was not interested, and I cannot remember if they even got started..?
- (YellowTab - Some company had access to BeOS sources and started releasing and somewhat updating the OS on a commercial basis - but don't think they actually had the rights to do that....)
This would probably have meant that the Mac wouldn't have become so popular amongst developers. At least that was the reason for me to switch to Mac because it's a "proper" UNIX with a window system that actually works ("Linux on the desktop" has mostly caught up in the meantime, but 10 years ago that was quite different).
BeOS was less compatible. There were also many improvements to it in the later versions. When NeXT bought Apple[0], BeOS was not even in its pre-release phase. Its heyday, such as it were, was really on Intel, with R5 and the Personal Edition, in the last few years of the 90's.
I would love to see a hardware company pick up Haiku and “do an Apple”: make a small set of focused computers with excellent support for a specified set of hardware.
Intel should do this. It's rounding error and they can use it to push the envelope. Intel should have done this with Linux, Solaris, Beos years ago to push Microsoft.
The NDK wouldn't be a problem, but requiring powerful devices speaks volumes about how lacking is Android in that field, when one can build low latency synthesizers and effects using a cheap old Raspberry PI 3.
https://www.youtube.com/watch?v=YtU8jMtbplE
True low-latency workloads on modern Linux (and 10ms is definitely low-latency!) still require a custom patchset (namely PREEMPT_RT). It's slowly making its way through the process of being upstreamed, but still.
I'm glad you mention audio because I'm going to spend 60€ on a dedicated microphone just because Linux cannot use simultaneously my Bluetooth headphones and their integrated mic without manually changing the codec (which additionally sucks when using the mic). Some problems improve but others simply never dissapear, like audio. Maybe there is a lack of interest or maybe is a design or a process problem, I don't know.
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.
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.
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).
HIView and HIWindow were added, if I recall correctly, because it allowed other toolkits (tk, Qt (who only recently moved off this), etc) to draw the native look “properly”. It was never actually up to date or well documented, and they kept it around just so the OS didn’t look so totally bizarre as you moved through it (like you see on Windows).
Bolting on Retina support to that is such a no-brainer that I hesitate to call it adding features - that was table stakes in making sure the switch to retina didn’t look like total ass.
None of this stuff ever changed how Carbon was deprecated. People just sat around not listening to Apple, and then the last two years the bigger GUI toolkits finally did the work to transition properly.
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.
Toolkits that used HIView/HIWindow looked very out of date compared to proper Cocoa implementations (Qt, contrary to popular belief, wasn't really "native" for the longest time since they did this - it's part of why it always looked off).
There are very valid reasons to be frustrated with Apple, but the writing has been on the wall for this stuff for years now. Nobody should be complaining at this point.
Exactly. In the days of WWDC 2003/2004 there were numerous separate Cocoa/Carbon sessions, and the Carbon message was to go fully to HIToolbox and Carbon Events.
Carbon NIBs even existed, although the format (XML) and concept (definitely not “freeze-dried objects”) were totally different from anything Cocoa. Xcode 4 and up couldn’t edit or view Carbon NIBs, which made that tech deprecation pretty clear.
To the best of my knowledge, there wasn’t much of a difference in programming style going from GC to ARC except for a few exceptions like all those pesky CFMakeCollectable calls that ended up being no-ops anyway.
You don't have to explicitly mark things as strong as it's the default. Having to manually break references cycles with weak pointers does make the migration not as simple as just changing the compiler flags, but I've never heard of it being all that difficult. Apple managed to migrate Xcode in a single version.
Garbage collection was deprecated almost immediately after it was released and has never been supported on iOS (which let’s be honest is the target for 95% of all cocoa developers)
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.
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.
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.
