Hacker Newsnew | past | comments | ask | show | jobs | submit | fduran's commentslogin

Fedora may be becoming the default for desktops, not for servers (Debian possibly the default for servers).


Actually on servers RHEL is still the default (43% server OS market share), followed by Ubuntu at 34%, Debian at 16% and SuSE at 11%.

https://commandlinux.com/statistics/linux-server-market-shar...


No sources cited, and the supposed author churns out multiple articles a day on Linux, gambling, and AI content strategy.

Not sure I'd put any weight whatsoever on those figures!

(and how would they even compare a commercial offering with something like Debian that doesn't even have popcon enabled by default?)


Enterprises love RHEL because of the paid support, even if they never use it, it's "there".


CYA is SOP. gotta have an escalation path or other fallbacks.


Red Hat will also support you using 15 year old versions of Linux if you pay them enough, the military love that.


They're talking about billions of dollars of market share, so how does debian get a mention being free? I'm suspicious of their methodology.

At least the infographics down the bottom are obviously full of slop


Fedora is upstream for RHEL, which is absolutely dominant in the server space some sectors that require enterprise support.


Why do you think Debian for servers only ? Did you use Debian SID or Testing as a desktop ?


Yes, the website is for prospective (and current) clients.

A small annoyance in startup circles is getting feedback about my website front page along the lines of "I didn't understand your hero, everybody should understand in one sentence what you do". Well, no, my clients will self-select as in not everybody needs to understand what "troubleshooting servers" or "devops" is :-)


There is def some luck involved, as in you don't know beforehand what's going to be successful.

"You find a problem in a niche, say accounting for plumbers, and build for that, then you just go and market to these people". It's way better to work on something you are familiar with and you like.


They have saved _more_ than two hours per dev and week. There's a compound factor and now code can be more reliable (less outages or emergencies fixing bugs) etc. Also having a sane working environment helps engineers not quitting, which is very expensive if they are replaced.


Nice, this is like SadServers with a twist, excellent :-)


Thanks! SadServers is great - love what Fernando built there. The main twist here is that the scenarios are built from real postmortems rather than generic server puzzles. The terraform one is modeled directly on the Claude Code incident from last week.

Lots more to come


Suerte! Unrelated, growing up in Spain it always baffled me that identification was based on a photo on your DNI. Stories of siblings or even friends that had a passing resemblance to each other sharing DNIs was a common story.


Spain didn’t really integrate many of the newer innovations in identity verification for a long time. Luckily things are improving, and we’re already working with some great companies there. Saludos!


> This is not a new or novel idea

Yep https://x.com/fduran/status/1134283398594387969


hello, thanks for the feedback. Just deployed a new image that only checks for the objective, not at what docker network somebody uses.

It is hard to have a checker that eliminates both false positives and false negatives in general, but we always try to minimize false negatives and we failed initially here.


Hello, SadServers guy here.

We have scenarios running on k8s, both on single VMs (the ones you can see in the scenario list) and we also have a beta/PoC k8s cluster where we currently run a couple of scenarios as single pod (a docker container) or as a full system (the "kubernetes playgrounds", which is kind of hidden while we test it).

Is this what you were wondering? we do have pending to introduce podman scenarios as well


Hello, creator here. Have you checked your dashboard? otherwise please contact us (email or form in the website) and we'll be happy to help


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: