consent-o-matic failed on this site

I'd start from this - https://www.coursera.org/specializations/advanced-embedded-l...

I studied under him at the university. He's also active in open source communities around embedded space.

A lot of work here is working on vendor provided BSP (which can range from esoteric mix of ancient kernels/bootloaders to top-quality community maintained mainline kernels) to work on your custom board/product.

It’s the “embedded” part that people struggle with.

I can find systemd script gremlins all the live long day.

I can’t find anyone who can write device drivers for custom peripherals, then hook them to user space utilities in a sane way.

Isn't linking to commits enough to prove it?

There's the argument that Systemd is an operating system unto itself.

Despite its standard Homebrew warts, I've been using Homebrew on Linux for years now for my dev boxes and it's been great.

It's good for getting the latest versions of packages, both for things that aren't in the distro and even to override distro packages. So far almost everything Just Works alongside the distro packages (at least for Ubuntu LTS).

I have 30… first installed Slackware from a dozen or two floppies. :-p

probably customers, too

Yes, that's what I'm saying. The rise of ATS seems to be a big part of the problem. Don't think I'm even being seen. There's also been an explosion of stacks, and if you didn't work with the ZYZYXX stack for the last five years, no chance, because someone else has.

I wish it were broken, then it could be fixed.

I think it is changed. AI is today’s version of the computer, putting many out of long-held jobs while opening up new career paths for different skills.

Victim-blaming is not necessary in this hiring environment. In the last decade only small companies have been available to me which means there’s under five folks I can turn to directly for jobs, and all are not hiring now.

Frankly that is a pretty thoughtless response. Even if your anecdote were broadly applicable, it still doesn't logically follow that an employer giving lots of interviews somehow translates on the applicant side into "a better resume would get you interviews". In fact, the hiring process has become incredibly dysfunctional. The best conceivable resume is still unlikely even to be read by a human hiring manager when it's just one of literally thousands of others for the same role.

Maybe putting your email address in your public HN user details would help? :)

and be willing to endure the hazing ritual they call an application and interview process

Lie and learn.

I was a windows guy at a large auction site and started bringing linux in to my workflows and solutions. I'd already been gaining personal experience with linux and the BSDs, solaris, etc. That was my last "windows job."

I'd say there's really no "linux roles" out there. Entry level or not. Everyone collectively decided "devops" was a big bright beautiful tomorrow and made devs learn release management and made ops people get lost (or become the developer they never wanted to be). Everyone shifted their focus towards "as code" solutions because the SRE book said nobody should log in to servers or something. So we hire people that know the abstractions instead and assume nobody really needs to go deeper than that.

It sucks, but learning the abstractions is how you're gonna have to get started. If you're already a linux nerd then you may benefit from understanding what the abstraction is doing under the hood.

If I was starting out right now, I'd go work through Kelsey Hightower's 'Kubernetes The Hard Way' and build functional kubernetes clusters from scratch on a couple of the cloud providers. Do not copy&paste anything from the blog. Every line, every command, by hand. Type out those CSRs and manifests! Recognize what each component you're setting up is and what it's used for. Like "what is the CCM and what's it responsible for?" Or "What's going on with every step of the kubelet bootstrapping process? What controllers are involved and what are they doing?" Read EVERYTHING under kubernetes.io/docs. Understand the relationships between all the primitives.

If you already have some linux, networking, and containers knowledge to build on top of, I think you could work through all of that in less than 4 weeks and have a better understanding of kubernetes than 80%+ of engineers at any level and crush a kubernetes focused interview.

It’s been 17 years since I got my first Linux job in 2008. Where I live, that’s rare, 99% of the industry here is a 'Microsoft Shop,' and the biggest player in town is practically married to them.

I started out at a small Linux company working with Plone CMS. The pay wasn’t great, but it was the perfect place to learn Linux and Python. Since then, I’ve used Linux every single day, become a Java developer, and started a few businesses. Using Linux of course.

But lately, things are changing. Companies are realizing that when it comes to Data Engineering and Science, C# just can't compete with Python's ecosystem. Now that they need to pivot, they're looking for help, and there are very few people in this area with the experience to answer that call.

You can make almost any job into a Linux job. Use a linux VM on your desktop to solve a problem for the company. Things change once your employer knows its essential.

I've also seen Linux make inroads in "windows only" enterprises when it became essential for performance reasons. A couple of times, towards the start of a project, windows APIs were discovered to be too slow to meet requirements:

In one case, customer needed us to send a report packet every 40ms. But even when we passed "0" to the windows Sleep() function, it would sometimes stop our program for 100ms at a time. The sleep function on linux was highly accurate, so we shipped linux. Along the way 5-6 devs switched to, or got a second PC to run linux.

In another case, we needed to saturate a 10GbE link with a data stream. We evaluated windows with a simple program:

   while(1) send(sock, &buffer, len(buffer);

... but we found windows could only squeeze out 10% of the link capacity. Linux, on the other hand, could saturate the 10GbE link before we had even done any performance tuning. On linux, our production program met all requirements while using only 3% CPU usage. Windows simply couldn't touch this. More devs learned linux to support this product.

Those companies still don't require linux skills when hiring, because everyone there was once a windows guy who figured it out on the job. But when we see linux abilities on the resume it gives candidates a boost because we know they'll be up to speed faster.

I was working in a Windows-centric environment and started using ProxMox as the hypervisor instead of Windows Server. This combined with my self. Hosting hobby (Proxmox mini PC cluster, network diagrams of vlans, self hosting my own blog website, having a handful of small tools in my git repos) was what sold my current company on hiring me, more than my resume of working in tech.