I have its local server and an instance of the alpha linux server on my cloud based dev box, hooked up via my tailnet.

I've played around with the iOS client a bit, but haven't had the need to do terminal stuff from my phone.

If I count my test suite for the ISO, I have ~2500 unit tests (placement groups tests, Raft behaviour tests, disk perf tests, SigV4 crypto tests, DHCP tests, kernel rollback tests), ~110 fault-injection tests (latency, network, RAM), ~60 block-store failure tests (e.g. network interrupt while two disks try to sync), "chaos tests" (generating random event scenarios for an hour), bit flip tests, "fsync lies to me" tests, power cut tests, round-trip tests, "power cut while in the middle of sync between datacenters", SMART degradation tests, load tests, memory pressure tests, file descriptor resource starvation, NTP drift tests, metadata DB loss tests, DNS failover, ....

Then for security everything is turned off, kernel modules are off, eBPF is off, io_uring is off (lots of CVEs), user namespaces are off, most network and file drivers are off, /bin/sh is off, S3 endpoint is minimal, etc.

Most rules from aerospace are said to be "written with blood", some crash caused this rule to be legalized. But with ~40k lines you can go through each line and say "what if this fails". With a kubernetes cluster it's more or less based on hope and happy-path testing.

I also scraped other competitors for user complaints, esp. about data loss / sync engine bugs and in total I now have about 4000 tests for 40k lines of backend code and another ~1000 tests for the 15k lines for the sync engine code (about 1 test for every 15 lines).

I'm still not entirely confident (still need lots of beta testing), but a chance of data loss of .01% would be pretty high. It really depends on the amount of testing whether you need an on-call person at all and most orgs are more engineered towards "just hire someone to be on-call" rather than doing proper testing.

My original career/learning path was for a traditional kind of SysAdmin role, because that's what I like. Doing Linux administration and such. Then our whole stack went AWS/cloud-native, so, ok. Seems like no one cares about someone who can actually SSH into a Linux server and figure out what the problem is--they want everything to be built into CloudFormation so that when a server is misbehaving you pull a switch to trapdoor it into oblivion and drop an identical one into its place, in the hope that this one works. I didn't relish the idea of moving away to the increasingly abstract, but alright, I can deal. Reformulating my learning path into being a Certified AWS Full-Stack Engineer or whatever.

As that was in progress, my company drank the AI kool-aid and went all in on AI. Now I honestly don't know what I should be training for. They've been pretty consistent on "No new staff, just AI", "You don't need X, you just need AI"--so I am honestly not even sure at this point if my company even wants me spending time diving more into the AWS stack, or if their attitude is "The AI knows everything--put all of your time into AI prompt engineering and just push whatever buttons the AI tells you to do."

The desired company skills continue to drift from my "personal" desired skills, but if this is an industry trend I'm not sure I have much of a choice, because I need my job.

Neither have I, I think you goofed up on your acronyms? For a driver as embedded as crowdstrike you need to recompile, there's no other way around it. Linux doesn't provide anything stable to target and a shim won't cut it in this case.

> the service ran as root, it UPDATED ITS OWN BINARIES as root!

Would you prefer if Linux allowed local users to replace the kernel and/or its modules without root? What kind of faux-outrage is this?

Or do you mean a customer was running it?

I’m being asked very open ended scenario-based questions, I’m answering honestly, and it seems to be going well (i’m moving through the interview funnel).

I’m not getting asked deeply technical questions. No weird obscure trivia. No stack-specific things. No linux internals. No weird networking trap questions. Coding part is essentially gone.

My interviewers so far have mostly been other senior SREs.

It looks like a market where a senior sre can recognise another senior sre. Some kind of closed circle.

So weird, so so weird.

    1. Good engineers should have had a firewall/waf/nat/thingy infront of their linux systems, and alerting at least on those directly exposed to reduce/eliminate blast radius
    2. Good engineers don't enable MTCP (which as far as I can tell is largely a desktop feature) on firewalls
    3. ???
    4. Profit!

I just wanted to read the source locally. I know things are getting worse by the month for developers on Windows because other developers are increasingly not giving a shit to support it, but it's odd to have a repo that doesn't even clone on windows.

Not building is common, not passing tests even if it builds is extremely common, but not even cloning is a new one.

I guess eventually I'll give up and switch to linux, but I'm still paid to work on Windows. I guess maybe it's finally time to look into a real dev-container setup for this kind of thing and I can do this all a bit more securely too.

Fist program to be installed.

If you never used, you don't know what is "going" on the pc.

That being said, I think it is important to consider: in a hypothetical world where the BSDs and other copyfree operating systems didn't exist we *still* wouldn't get those patches from Sony. The alternative is not "we have to use Linux now and make our work public", it is "we have to use one of the many commercially available operating systems". Just look at all the devices that ship with QNX.

https://en.wikipedia.org/wiki/QNX

> GP: EACv2 can't accept self-signed kernels and bootloaders

Also, from what I understand from the NixOS discussion[1] on this, it's using mok. That does put which keys are trusted in Epic's hands (which also isn't perfect, but is still vastly better than Microsoft). That article author seems to be poorly informed, or may be spreading FUD.

[1]: https://discourse.nixos.org/t/eac-linux-v2-requirements-vs-b...

Their Linux stuff has gotten much better but besides the (insanely huge) recent windows debacle I've found them to be a great product

Popular in:

2024 (118 points, 13 comments) https://news.ycombinator.com/item?id=42545009

2017 (337 points, 219 comments) https://news.ycombinator.com/item?id=13443858

Recently available for Linux too (1378 points, 474 comments) https://news.ycombinator.com/item?id=47697870

I've been missing powertoys color picker when i switched to Linux, i have taken a look at the popular color pickers, some didn't work on Wayland, other lacked features powertoys had, so i made one and I'm here to share it

You can pick any pixel with a 10× magnifier (live on X11, freeze-frame on Wayland)

A color card showing your first format on the color itself, with its name

You can search colors by name, word, or code ( Ctrl+F ) it'll even work with a typo ( it's smart-ish search )

9 formats (HEX, RGB, HSL, HSV, CMYK, HSLA, OKLCH, OKLab, HWB), reorderable

Global hotkey, auto-copy on pick, works completely offline, MIT Packages: Fedora , Arch AUR , .deb and an AppImage.

Made with Rust and Slint.

GitHub: https://github.com/Mujtaba1i/Archtoys

If EAC signs a custom kernel I will just boot into that one when I want to play video games. Unlike dual-booting Windows it won't delete my Linux boot entries and I can use all my applications.

Machines (esp. Virtual Machines) are ultimately predictable and crashes don't "just randomly happen". But it's what this entire "enterprise cloud" culture has brought in, the idea that it's impossible to simulate all possible failure conditions of a cluster locally and therefore we shouldn't even try doing it. Maybe that's true at Google scale, but most companies are simply not, not, not Google-scale.

As a counter-example, I recently built a simple "cloud storage" system with a minimal Linux ISO: everything is stripped down to the absolute minimum to just boot, start a minimal S3 server and pull (encrypted and signed) update commands from an SQL "control plane" database. The entire userspace is ~50k lines of Rust (minus 10k init system) and I can simulate the entire VM locally and play with the "cluster" of VMs locally. The ISO is ~20 megabytes large and I can simulate entire datacenters "burning down", virtually, locally, before it happens for real. I can simulate everything: network failures, disk failures, slowdowns, latency, try getting Fable to hack it, etc.

But in the kubernetes "enterprise" world, I can't do any of this. First I need 10.000 values.yaml files, 10 add-ons for logging and metrics (because pushing metrics to some collection endpoint over HTTP is clearly PhD level complexity) and on top you need a service mesh to restrict random containers talking to each other because nobody knows anymore what services can talk to which other services. The results are constant outages because of misconfigurations and someone having to be on-call at all time.

Needing on-call at all (except for maybe security alerts, but those are usually not part of DevOps) is the result of this Google-influenced "crashes just happen" nonsense where "manager" culture is preferred over results (aka uptime).