That is a very good point. Why buy big iron "pets" when you can buy x86 "cattle"? It works for a lot of stateless apps and services. A node dies, and k8s quickly moves the workloads to new nodes.
It does take some work to accomplish this on more complex apps, though. Things like SQL databases and rabbitmq are very often single points of failure in practice. At smaller companies, it's often easier to stick them on more resilient hardware than to architect an active/active or active/failover system. I agree that this isn't the best way to do it, and IMHO any important service should have HA of some sort.
That said, I use x86 based machines for all my personal projects, and I wouldn't buy IBM systems if I owned a tech startup just because they're like 10x the price of x86.
And now that they bought RedHat, they're eagerly dropping support for all linux distros that are not RedHat, and they're attempting to lock out anyone who wants a personally affordable RedHat-like system (CentOS...). If they succeed, it may even be hard to find decent RedHat sysadmins in the future.
It's hard to keep up a trained workforce when they lock the doors so tight.
Aside: I hate the popup subscription CTA that asks for my email address in the middle of reading the article. How could I know whether I want to subscribe before I finish reading, and why interrupt my reading the article at all?
There are clearly marked "Subscribe" buttons at the header and the footer of the page that I could use if I wanted emails. But there's no RSS/Atom feed.
I'm just a grumpy programmer that gets annoyed by unnecessary interruptions. I'll see myself out...
Former P-series/AIX SME here. I agree 100%. IBM's training programs are a joke.
P-series and mainframe machines have a lot of cool tech, and they're very resilient. They can even lose a CPU or some RAM and keep running. x86 systems would more likely freeze/crash immediately.
But the only reason I know P-series/AIX at all is because one small branch of IBM hired me for my linux skills back in 2011, and I learned on the job. But I quit after 5 years, because the pay wasn't sustainable. The machines are too expensive to play around with otherwise. If you learn by doing (which seems vital to be a good sysadmin or programmer), even a license to use AIX is out of the hobbyist's price range. Training courses are limited lab environments. You won't get nearly as much out of that as you would from a 12-month AWS subscription, or a $5/month VPS, or an x86 virtual machine, or a raspberry pi. etc, etc.
And IBM ended their developer machine licensing. So now employers can't even afford to maintain extra P-series machines for devs/sysadmins to play around with and learn.
But don't worry, IBM will keep shooting their feet off until they no longer exist. There will likely be a panic, similar to Y2K, where everyone's feverishly re-writing and porting and emulating and migrating things off of IBM iron and onto x86 machines.
As a former P-series/AIX specialist, I can say that the pay is not as good as a decent linux job, and the career growth potential is very low. Your career options are basically to maintain legacy systems until they can figure out how to migrate it all to linux.
And if you get laid off (happens a lot at IBM lately), your career prospects are to either wait for someone to retire/die or learn linux.
No matter how important they say maintaining the legacy systems is, the pay is low enough to easily convince people to take any other IT career path.
My Windows PC is only for gaming. That said, I found a simple way to avoid the worst of the Windows update problems: Always stay at least one major version behind.
That means lagging on Windows 7 or 8 when 10 was current, and lagging on Windows 10 until Windows 12 comes out. Microsoft puts most of their offensive junk on the latest Windows, but still back-ports useful features to Windows 10, like WSLg.
It's not a perfect system, and I may get malware someday from missing security updates if Windows 10 goes EoL before Windows 12 comes out, but having the occasional ransomware hit a gaming PC seems almost less annoying than the current nasty Windows updates. I wish I were joking. I have enough stress in my life where I don't want to fight with my OS as well.
I run linux/NixOS on all my important machines, including work.
Ask for more stock/promotions/pay. You won't get what you don't ask for. As an early employee, you have value in your company knowledge.
Otherwise, I'd probably just leave for a company with better pay and better work/life balance.
I've done the startup rodeo before. Worked several nights till 1am. Once worked till 4:30am, slept 3 hours and then right back to the office. After 18 months at that job, badly burnt-out, I was rewarded with layoff and had to find a new job. Never again.
It's much less stressful to just get a higher paying job where you only have to work 6-8 hours a day, with maybe an on-call rotation.
Yeah, but if the phone/browser decides to delete some of the PWA's code to save space, you won't be able to use any maps at all until you connect back to the internet.
Before you say "just download the code to your phone as a file", I'm going to assert that's exactly what an app is ;)
Yes, "Add to home screen" is exactly how you install a PWA to your phone =)
It's a bit confusing, isn't it? "Add to home screen" makes it seem like you're just adding a link, but it's installing the PWA, possibly enabling notifications, and etc.
The UI looks pretty neat, but the install instructions are essentially "curl {url}/install.sh | bash -", which is kind of icky and runs a bunch of sudo commands. Since you're using Docker anyway, why not provide human-readable instructions?
Or, alternately, separate the config process from the install process. I'd be much more comfortable running config commands from a script inside the docker container, or as a first-run setup UI, or as a simple .yaml config.
It does look like something I'd like to try out later, though. Either after the install process is cleaned up a bit, or once I have time to read through the whole install.sh script.
Edit: In case it matters, my personal preference is to install things as linux packages instead of Docker, but I understand that this is a stretch for early-access software.
If Go does have some kind of "__builtin_expect" equivalent, I can't find it.
I'd say it probably doesn't exist. Even if it _did_ exist, the Go compiler authors would reserve it for internal use only, like they do with most other Go compiler directives.
Author here. Thanks for the advice! That's a very good point.
Maybe it's worth doing a follow-up on this? I originally thought of doing unit tests to ensure it's actually running in constant time for different inputs, but I'm not sure they would run well on anything that wasn't bare-metal (probably too inconsistent).
Have you done this with Go or any other compiled language? I remember a colleague of mine was looking into C++ assembly generation rules a few years ago, but I haven't heard how far he got.
In that case, the code would probably work like the C code example I gave. So... I guess you're right. It _can_ be done in Go without `if` if we use unsafe. I can't argue with that =)
In general, I try to to avoid using unsafe as much as possible. Not because I worry that it's "unsafe" or prone to errors (I'm experienced in C, C++, and assembly), but because it makes the code harder to read, and I don't think my coworkers would appreciate that. ;)
It does take some work to accomplish this on more complex apps, though. Things like SQL databases and rabbitmq are very often single points of failure in practice. At smaller companies, it's often easier to stick them on more resilient hardware than to architect an active/active or active/failover system. I agree that this isn't the best way to do it, and IMHO any important service should have HA of some sort.
That said, I use x86 based machines for all my personal projects, and I wouldn't buy IBM systems if I owned a tech startup just because they're like 10x the price of x86.