> Caveat: this is my first ever kernel module, so I may have committed more mistakes than I intended.
lol. Reminds me of the "hypocrite commits" fiasco where researchers at the University of Minnesota submitted kernel patches with what they thought were security vulnerabilities, but because of their inexperience, the first patch they sent was actually valid and had no vulnerabilities whatsoever[1].
It doesn't sound like it was "because of their inexperience" but rather because determining whether Linux C code is buggy is really hard. That's kind of the whole point.
It's interesting how comments tend to be held to much higher standards on HN than the submissions themselves. I wonder if that's purely because there's no downvote button for submissions or if there are other reasons.
Don't know if you've ever tried to submit links here, but it's kind of random whether your submission gets to the front page or not. I believe the click-baitniness of the title has a lot to do with "success" there. You can see a similar effect on YouTube, a lot of videos have really click-baity titles even if the video itself is high quality.
100% it's the click-baity aspects of the title. Just like reddit, or anywhere, there's enough people who see the title and upvote without reading it, if the title is appealing enough.
Source: I submitted an article with a direct quote from the abstract as the title. It gained a lot of interest before the title was changed to word salad of the original. https://news.ycombinator.com/item?id=28400659
I spent a day tracking down obscure module dependency issues just two days ago because of systemd. It's always a good sign when the thing doesn't work with an After= graphical.target, but did with a multi-user.target and a 2 s sleep before the executable was called. I've got idea why, and found debugging it really obtuse.
I tend to downvote jokes or non-substantive comments about systemd (although I haven't downvoted any of the comments on this post).
Like any other software system, anyone is welcome to question or doubt or disagree with systemd's design decisions. But some people seem to have an almost irrational hatred for it, far beyond what a mere software package calls for. Even if a person making a joke about systemd isn't themselves like that, being reminded of it all makes me want to reach for that downvote button. And the topic gets tiring after a while anyway, it has been done to death already.
> But some people seem to have an almost irrational hatred for it, far beyond what a mere software package calls for.
That could be because somehow it's managed to become the default init on all mainstream distros, leaving few good options for those who would prefer to avoid it. I don't want to use a distro whose main raison-d'ètre is avoiding systemd.
Looks like you have to do a bit of tinkering to ensure it stays free of systemd. Same with Debian, which I use with SysV init. But it took a couple of hours tweaking to switch - perhaps one of the other inits might have been easier to switch to.
My friend, usenet KILL files were absolutely shared. I ran a usenet NNTP server back in the day. There were many killfiles shared and usenet admins could also institute certain kinds of blocks. See http://www.kibo.com/kibokill/
Systemd of course has had its share of issues. But a lot of also comes down as natural resistance of change by sysadmins, which is a well documented psychological phenomenom
> But a lot of also comes down as natural resistance of change by sysadmins...
I find this "meh, you're just being stubborn" labeling is a bit dismissive. Especially when a lengthy technical comment about systemd is replied with the tone of "You just used to old ways eh? Time to freshen your knowledge, hehe".
Today's sysadmin dynamics doesn't allow one to stagnate with old knowledge either. Yes it's very useful, but not eternally. Instead it allows you to build knowledge faster.
It's not remotely unique to sysadmins. If anything, devs are worse.
Have you seen how many Python 2 packages there still are out there? How often do we see opinions on HN that amount to "C > *" whenever Rust, Go, Java, C++, etc. are in the submission? That's the exact same "resistance to change".
Change isn't a light switch. It doesn't go from 100% old to 100% new. Change is a long, slow, time consuming, and difficult process that requires extra effort at every stage in the process. There are several different stages:
1. Not knowing the new and being confused.
2. Identifying the new and having to develop special processes.
3. Accepting that the new is here to stay and translating or adapting the processes and procedures from the old, and spending effort to re-learn the same features in the new system to maintain business as usual.
4. Discovering all the new ways that the old process doesn't fit the new system or the new system isn't designed for your existing business processes, and fixing them one catastrophe at a time.
5. Running the old and new, simultaneously, for the lifespan of the systems that depend on them.
6. Having the new significantly overtake the old such that it's now unusual, and being frustrated that the old still exists.
7. Forgetting knowledge of the old via atrophy.
8. Encountering the old and being confused.
And that's when the new system proves itself to be better than the old.
I'm a young-ish (late 20s) sysadmin and I've been reflecting on how I'm becoming increasingly cynical and resistant to change over time. I will probably organize my thoughts at some point, but here are some unsorted ones:
* Infrastructure is often untestable. I've been bitten by the silliest changes in unexpected ways. We use IaC extensively, which makes things more organized and easier to operate, but still, testing stuff is insanely hard and time consuming, often impossible.
* Infrastructure is often thightly coupled. Many architectural decisions will come back to haunt you in the future, in very serious and unexpected ways.
* Infrastructure is often shared. Consequently, balancing requirements from different teams with different goals is very hard.
* Often, I have no skin in the game. I will not earn more money to implement changes that will benefit my peers, but my life will suck more if I do. Often, being a intransigent bureaucrat is the most rational path I can take.
* Often, devs have no skin in the game. They will earn more money if features get delivered, but won't have to deal with the long term operational and security consequences of the changes they ask for.
That was already repeated ad nauseam by others, but my best professional experiences were:
* The times I was responsible for software and infrastructure of a project.
* The times I was working in a small team, very close to devs and thinking about a single project.
I systemd because I deeply disagree with the philosophy of it's developers. You shouldn't write system critical software if you don't understand how and why said system works. I'll give you It's much better now, but I don't forgive easily. I till haven't touched debian after they disabled crypot-randomness either. I've also gotta say, it's a little annoying to see someone condense all the issues surounding systemd as "hur dur, change is scary... grok no like change"
I tend to downvote snarky, off-topic jokes here because I want this site to keep a high signal/noise ratio. If you visit the /r/science subreddit, you can see why. The comments used to be excellent, not they are full with lame jokes and anecdotes.
Just look at what a long thread your comment has spawned below. And most, if not all, of these comments have nothing to do with the topic the article is about.
It's not just a lack of appreciation for jokes, it actively hijacks the conversation and, as a reader, I have to now start collapsing whole threads and hunting and pecking to get back on topic.
And here I am adding to the mess I'm complaining about...
I appreciate a good joke and there are definitely appropriate ways to slip one in on HN but this is not one of those and I'd say it's less about it being a joke and more about it being off-topic.
Edit: Just to add to this, I just refreshed the page and the majority of the comments here are now replies to the PP about SD and another, similar, joke about how the article must be referring to the NVidia kernel driver. Actual comments about TFA are minimal and the whole post seems to just have been completely taken over by content that's not relevant to the discussion. Now please down-vote me for wasting every one's time by pointing this out!
To add to others, I prefer not to have jokes here, as I would rather to come here for a good discussion. I really don't want to have to wade through low effort jokes/memes to find such a discussion.
Having a sense of humour is not frowned upon here.
Posting low-effort cookie-cutter jokes is frowned upon here, because (1) they usually aren't actually very funny and (2) empirically it seems that communities where that sort of joking is popular are at risk of having it take over until there is nothing but low-effort cookie-cutter jokes.
> empirically it seems that communities where that sort of joking is popular are at risk of having it take over until there is nothing but low-effort cookie-cutter jokes.
That also seems to be true of memes, trolling, and political propagandizing. Any forum where these things are allowed quickly becomes nothing but these things.
lol. Reminds me of the "hypocrite commits" fiasco where researchers at the University of Minnesota submitted kernel patches with what they thought were security vulnerabilities, but because of their inexperience, the first patch they sent was actually valid and had no vulnerabilities whatsoever[1].
[1] https://www-users.cse.umn.edu/~kjlu/papers/full-disclosure.p...