I’m giving them a little empathy because they are frustrated; that’s all. We’ve all been there.

Yeha, but you can ask for help without taking a shit on the effort of thousands of engineers.

I doubt OP thought, ‘I’m going to take a shit on thousands of engineers.’ It’s okay to not know what to do, including asking for help. If they don’t know what to do with “error 2,” they’re obviously lost. This unwelcoming attitude to newcomers is a big problem, and in my opinion, it’s probably best not to contribute to it.

You can rephrase what you’re saying and provide better help to someone who’s completely lost in a much more polite and informative way. It’s better for everyone.

Also, try searching web before crying on social media. If you can’t solve your problems by searching the web then GNU/Linux probably isn’t for you.

Sheesh, let them be frustrated already. Besides, asking for help is totally valid.

Oh interesting! I suppose I have just been very careful with /etc/fstab and I haven’t seen systemd fail this way. TIL! Thanks for letting me know!

That’s just systemd failing to start Switch Root. Have you tried the systemctl status suggestion in the error, or reading the text file it generates?

systemd daemons are configured via /etc/systemd, and systemd itself lives in /usr/lib/systemd/systemd. How can systemd run or start the configured services without the root disk mounted? The initrd (from the boot partition) only contains enough of an environment to call the entrypoint for the init system, not contain the entirety of systemd (or the configured services).

The root filesystem mounted fine. That’s why the init is starting with all the services on the root disk.

That’s not a kernel panic

I believe that excellent communication can be had without engineers swearing at each other, and I don’t think there are is any good rationale that warrants such behavior. You believe that there is a time and purpose for the style of conversation that Linus portrayed, and it is warranted and effective behavior.

I’m going to agree to disagree from here. Thanks for the conversation.

Please defend these statements for me. I’m having a hard time understanding how this is language we should strive for in a code review, even with your explanation.

Additionally, if you can give me any pointers on how I can communicate this way, I’m all ears and would appreciate the help.

I kindly disagree with most of what you said. Linus is brilliant, and I appreciate his contributions not just to technology and freedom but also to society. However, this does not pardon the hardships he has also brought upon others.

It’s important to be honest in code reviews, but his language, while also honest, goes far and beyond that. We’re doing ourselves a disservice defending this behavior as if it’s a standard of communication quality that people should strive for, or learn how to behave like.

Neat.

Linus could also be kinder.

For sure. It’s funny in a way, but this is not a great way to treat folks that are trying to contribute, often on their own time. This could have been rephrased in so many other ways where Linus doesn’t come off as a total jerk, and still be “right” with the same message.

I haven’t had any issues with new hardware, either.

Every wireless adapter I’ve used in Linux for the last 10 years has worked flawlessly.

Vim handles remote files over SCP natively:

vim scp://192.168.1.2//data/editme.txt

Yeah, package maintainers should have their dependencies figured out. “Managing dependencies is too hard” is a distro packager’s problem to figure out, and isn’t a user problem. When they solve it and give you a package, you don’t need to figure it out anymore.

Plus, frequent breaking changes in library APIs is a big no-no, so this is avoided whenever possible by responsible authors. Additionally, authors relying on libs with shitty practices is also a no-no. But again, you don’t need to worry about dependences because your packager figured this out, included the correct files with working links, and gave them to you as a solved problem.

A package typically includes the program and its data inside the package. It’s not just an install script. Imagine if Chrome’s MSI installer was simply a wrapper that also downloaded the browser. Imagine if there was a vulnerability with this, and it downloaded and installed something else. Since the package didn’t include the program files, it wouldn’t be able to tell if they were genuine. It only fetched the MSI, which was a download that initially passed the expected checksum (if it even does that).

Additionally, file lists help ensure that programs and packages don’t conflict with one another. What if you wanted Chromium and Chrome at the same time. Can you do that? Simply wrapping an MSI doesn’t guarantee that. Perhaps there are conditionals in an installer that includes a vendored library under some circumstances, which would make them conflict.

What about package removals? Some programs leave a bunch of junk behind in their uninstaller. Typically, since packages very often contain their own files, they simply delete their files when they’re being upgraded or removed. If a package manager puts full trust in an MSI to always be exactly correct, then it loses complete control over correctly managing file removals.

I could go on and on, with more examples, but “run this binary installer” is the Wild West of putting software on your system. This is mostly the status quo on Windows, but this is a very poor standard. Other operating systems have solved this problem with proper packaging for decades.

When building a package from sources, it makes sense to wrap installers, but then you produce a package that is typically distributed by a mirror. These packages would then by downloaded by you, and contain the source of truth that is trusted to be what it is and that it’ll do what it’s supposed to do without any doubts to consistency and security.

Interesting. Not much of a package manager, then 🤔

Who packages chrome?