I'm still looking for a remote linux gig iffn' anyone is looking for that sort of thing.
#syseng
My employer is an EFF-approved independent ISP, and we're hiring a Senior Systems Engineer https://grnh.se/a6b53dbd1us
Key technologies involved: Linux (RedHat), MySQL/MariaDB, VMware,Proxmox, Ansible, Perl, Python and Shell.
Salary starts at $145k. Can be fully remote (within US), but preference if able to work in our northern california office one day a week.
See link for details (and better accuracy).
#syseng #sysadmin #sre #devops #hiring
Our last TechTalkThursday in March – it was already event number 23 of this series – was a complete success: interested listeners, exciting speeches and lively discussions in the community. 🤝 By the way: You can also find everything about our TechTalkThursdays here https://www.meetup.com/ninetechtalkthursday/events on Meetup in our group – the next dates, the topics of the talks and much more. 🔗👈 We would be delighted to meet you at one of the next TechTalkThursdays. 💙 #techtalkthursday #devops #syseng #event #nine
The Return of Infrastructure Independence: Breaking Free from US Hyperscalers
In the rapidly evolving landscape of technology, we sometimes find ourselves experiencing a sense of déjà vu. The current state of cloud computing and infrastructure management feels remarkably similar to the late 1990s server market—a time of major technological transition that ultimately rewarded those who maintained traditional expertise.
The Great Windows Server Migration of the Late ’90s
Cast your mind back to the late 1990s. Windows NT was gaining significant traction in the enterprise server space. Microsoft’s marketing machine was in full swing, promoting Windows as the future of server technology. The interface was familiar, the management tools were accessible, and the promise was enticing: simplify your infrastructure and reduce costs.
Many companies bought into this vision. They let go of their Unix administrators—the wizards who understood the deep intricacies of system architecture—and pivoted toward the seemingly more accessible Windows ecosystem. Unix expertise was deemed outdated, a relic of computing’s past.
But then something unexpected happened: Linux emerged as a powerful force. This open-source Unix-like operating system combined the robustness of traditional Unix with modern development approaches. Companies that had maintained their Unix expertise found themselves with a significant competitive advantage, while those who had discarded that knowledge scrambled to adapt.
Today’s Dangerous Dependency on US Hyperscalers
Fast forward to today, and we’re witnessing a similar phenomenon, but with far greater geopolitical implications. The cloud market has become dominated by a handful of US-based hyperscalers: AWS, Azure, and Google Cloud Platform. These giants now control the backbone of global digital infrastructure, creating an unprecedented level of dependency.
Organizations worldwide have entrusted their mission-critical systems, data, and intellectual property to these American corporations. This concentration of digital power in the hands of a few US companies presents significant risks:
- Geopolitical Vulnerability: Non-US entities are subject to American data regulations, surveillance capabilities, and political whims
- Sovereignty Concerns: Nations and regions have limited control over their own digital infrastructure
- Single Points of Failure: Global dependence on a handful of providers creates systemic risks
- Compliance Challenges: Navigating complex and sometimes contradictory regulations across jurisdictions
Today’s developers and systems engineers often have limited exposure to building and maintaining independent infrastructure stacks. The knowledge of creating self-sufficient, sovereign digital platforms has been sacrificed at the altar of convenience offered by the hyperscalers.
The Coming Era of Regional Digital Sovereignty
As geopolitical tensions rise and concerns about surveillance escalate, we’re approaching a breaking point that parallels the Linux revolution of the early 2000s. The excessive centralization of cloud infrastructure in the hands of US corporations is becoming increasingly untenable for many regions and organizations around the world.
Europe, in particular, stands at a crossroads. With its strong regulatory framework through GDPR and emphasis on digital sovereignty, the continent has the potential to lead a shift toward regional cloud infrastructure. A “European Cloud” built on open standards and operated independently of US hyperscalers could provide a template for other regions seeking digital autonomy.
This is where those 50+ year-old systems engineers—the ones who understand how to build infrastructure from the ground up—will become invaluable again. Their knowledge of architecting complete technology stacks without reliance on hyperscaler ecosystems will be crucial as organizations and regions work to establish independent digital capabilities.
Building Regional Digital Independence
The path to reducing dependency on US hyperscalers requires:
- Regional Infrastructure Initiatives: Government-backed programs to develop sovereign cloud capabilities within specific geographic or political boundaries
- Open Source Foundations: Building on open source technologies to avoid vendor lock-in and enable collaboration
- Knowledge Preservation: Actively maintaining expertise in full-stack infrastructure management
- Hybrid Approaches: Developing gradual migration paths that balance hyperscaler advantages with sovereignty requirements
- International Cooperation: Creating alliances between nations with shared interests in digital sovereignty
The Role of Experienced Infrastructure Engineers
The systems engineers who remember a world before AWS, Azure, and Google Cloud will play a pivotal role in this transition. Their experience building and managing independent data centers, designing network architectures without reliance on hyperscaler services, and understanding the full technology stack from hardware to application will be essential.
These veterans know what it takes to build robust, independent infrastructure. They understand the pitfalls, requirements, and strategic considerations that younger engineers, raised entirely in the hyperscaler era, may overlook.
Conclusion
The technology industry has always moved in cycles. What seems obsolete today may become critical tomorrow. Just as Linux vindicated those Unix administrators who maintained their expertise through the Windows NT revolution, the growing movement toward digital sovereignty could similarly elevate those who’ve preserved their knowledge of building independent infrastructure.
As regions like Europe work to establish their own cloud ecosystems and reduce dependency on US hyperscalers, the experienced systems engineers who understand how to build truly independent technology stacks will become not just relevant, but essential to our digital future.
The coming years may well see a renaissance of regional infrastructure expertise, as organizations and nations alike recognize that true digital resilience requires breaking free from excessive dependency on the American tech giants that currently dominate our global digital landscape.
See also: https://berthub.eu/articles/posts/you-can-no-longer-base-your-government-and-society-on-us-clouds/
Bit of "fun" with O365 email for us this week...
Background: Our main email domain's MX records are on-prem servers that do a bunch of things, and email for our O365 domain relays through them. These on-prem MX servers have been dual-stack (ipv4 and ipv6) for many years now.
Not sure exactly when MS made various changes, but our example-com.mail.protection.outlook.com records have both ipv4 (A) and ipv6 (AAAA) addresses.
And they enforce that email they receive has to be via a "trusted connector" for your domain, pass SPF, or pass DKIM.
> 450 4.7.26 Service does not accept messages sent over IPv6 [dead::beef::1] unless they pass either SPF or DKIM validation (message not signed)
But O365 doesn't yet support adding ipv6 IPs/ranges to the trusted/connector list.
So, suddenly email sent to us without DKIM signatures was getting stuck in the MX server queues.
Our temporary workaround is we added egress firewall rules on the MX servers themselves blocking SMTP to 2a01:111:f400::/48 and 2a01:111:f403::/48 (the published ranges for their MX servers). Not ideal, but at least mail is flowing again.
Our TechTalkThursday #21 was a complete success – thanks to the great speakers and the interested audience. 🥳🙏 You can take a look at the photos of the event here https://www.meetup.com/ninetechtalkthursday/photos/34854711/ – and register for the next event here https://www.meetup.com/en-US/ninetechtalkthursday/events/302803153/. 📅👈 Many thanks again to all the speakers, guests, sponsors and helpers – you were just awesome! ✅ #techtalkthursday #devops #syseng #event #nine
@Jerry [holding my Initech mug] [my very best Bill Lumbergh voice] mmmmmmyeah, so, the "incompetent woman" who wrote that KB is the worldwide expert engineer for database integration, and, mmmyyyyeahhh, you're, mmmmm, some guy who works in tech support, so, yyyyeahh, if you could, ya knowwwww, just go ahead and head out to the front desk, to be escorted off the property, that would be grrrrreeeeeeat.
oh Bhyve, why must you "(exit status 4)" whenever I need you most?! :bsdhead:
catastrophizing? not necessarily, but I did debug it for some hours, sufficiently short of spinning up a gdb host.
alas, latest 14.1-RELEASE and Bhyve is not interested in handling IRQs and passthru for one of the A4000 GPU in my workstation.
https://p.bsd-unix.net/?3f247ee56451edeb#4g15QSXkqfrbTkPd4NdE8hd9iejXZDPryvj45TsuUxL4
#FreeBSD #Bhyve #virtualization #patience #GPUcompute #GPU #HPC #ML #hardware #engineering #syseng
seems that I'm predisposed to embedded systems running on DiN rails..
- partially due to industrial automation standards
- partially due to the near perfect ability to physically compartmentalize and hierarchically manage a full production environment using RS-485 🫠
- sometimes 19" standards are limiting and boring, and I don't do well with that state of apathy
so in this video there's a triplex of GoWin R86s micro nodes, under the desk and connected to a UPS. I'll be moving them to PoE+ powered using a QNAP 20-port switch that runs 1G, 2.5G and 10G... the PoE splitters are from Linovision and their ethernet port runs at 2.5G -- this is the only well made splitter that operates faster than 1G (which I could find).
More videos and parts of this little cluster coming soon...
💞 So Much Fun! 💞
No plans yet on Thursday, May 2nd, 2024, at 5:30 PM? 📅 Join us and our TechTalkThursday #20, learn a lot of new things, participate in interesting discussions, and enjoy free snacks & beer. 🍻🍕 More info and registration: https://www.meetup.com/de-DE/ninetechtalkthursday/events/300283740/ 🔗💻 #techtalkthursday #snacks #drinks #devops #syseng #it #tech #nine
I'm looking for a gig as a Lead/Staff level Linux Engineer. Devops, Sysadmin, Techops, InfEng - whatever we want to call it today.
I know linux real well, I'm on a machine learning patent and was technical reviewer for a book on system monitoring.
If anyone out there is looking for a linux guy I'd love to talk to you.
Thanks!!
#SysEng #wroBookMark
got myself a 😎 book
ISBN 978-1-118-44236-5
System Engineering Analysis, Design, and Development: Concepts, Principles, and Practices (Wiley Series in Systems Engineering and Management) by Charles S. Wasson
published by https://www.wiley.com/
Configuration is not a set of toggles, it's not a YAML file.
Sometimes it's more applicable to configure the system by switching out elements and rebuilding.
It's great that software engineering has developed amazing facilities for text-based configurations, but often application of those is supreficial and lacking.
In this long-toot: a recipe to detect and deal with "anagram-bullshiters" even if you don't know anything about the problem domain within which they're trying to sell you something.
I noticed that #haskell people and #science people are giving abstractions specific names that are nouns. Sometimes semantic: "functor, bifunctor, lens, prism", sometimes borrowed: "monoid, magma", sometimes of loose semantic power: "monad, joker and clown".
Or was it clown and joker?..
#java people and #engineering people love abbreviations. Just today whilst studying #syseng, I got tripped up by "StRS vs BRS vs SRS". Not because I can't tell stakeholder requirements from system requirements or business requirements, but because I simply got lost in the abbreviations.
But I observed an interesting thing: when you ask a haskeller to explain a monad, a lens or a bifunctor, it's very easy to call #bullshit: they won't be able to give you a concrete answer (no matter how long or #eli5-esque), while engineering bullshiters have that fallback of just spelling out an anagram they learned and explaining it word by word. This is a red flag, but maybe a person is simply bad at explaining or defining stuff?
What I suggest to be able to determine if you're facing an anagram-bullshiter or not is to ask these questions:
1. How would one use XYZ?
2. In which situations is XYZ applicable / usable / optimal?
3. What are the alternatives to XYZ and in which situations are they applicable / usable / optimal?
Even if you know nothing about problem domain, you should now have a reasonable amount of information to determine if the person is pretending to be more knowledgable than they are.
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst