zlacker

>>fsflov+(OP)
I've got to say, some of the comments here are pretty funny.

> "The sideloading restriction is easily solved by installing GrapheneOS"

> "Unless they block ADB, I wouldn't say it's accurate to claim they're "blocking sideloading"".

Not to pick on these folks but it's like we on HN have forgotten that ordinary people use phones too. For some of us, it's not a limitation as long as we can solder a JTAG debugger to some test pads on the PCB and flash our own firmware, but for most users that's just about as possible as replacing the OS.

>>tdeck+o9
There was some Ubuntu (or Linux) forum where I had asked a question and I wanted an app or something (I can't recall now) which was easier to use and do repeatedly. Most of the people were replying with stuff like "why can't you just do <something that involves lots of CLI and more than an hour ro so>" or on the lines of it.

I, someone extremely new to Linux (hell, new to computers), was bewildered. Then a commenter replied with something that helped me and exactly what I needed. He added a note directed towards others which went something like - the battle for Linux as THE desktop OS was sabotaged by its most ardent practitioners.

>>crossr+Qh

  > the battle for Linux as THE desktop OS was sabotaged by its most ardent practitioners.

This definitely happened with Arch. For some reason they killed the noob guide (which I helped maintain). It was a great guide that helped people go from noob to kinda knowing linux.

You can't have wizards without first having noobs.

Why gatekeep people from enjoying the same thing you enjoy?

Well, I guess all that gave us EndeavourOS and Manjaro. But still, we need more places for people to learn that nitty gritty stuff.

Hell, I'd love to learn more about the hardware hacking the OP is talking about. Love to learn about those GPU hardware modifications people do. I know it's hacker news, but I'd actually love to learn about that hacker stuff. If these companies are going to continue to fight this hard to prevent us from owning the things we buy, it sounds like an important thing to learn. Or else we're soon going to have robot butlers that are just sending lidar maps and high resolution photos of our homes back to these companies. We don't need elitest pricks, we need wizards teaching noobs

>>godels+nn
Something I know from a past role is that teaching is demanding, and for any broad audience you've got to consider the range of different thought processes that you may need to provide your knowledge in different ways. As someone trying to increase my linux skills (and assess the best one for potentially migrating/supporting my parents) it doesn't help that a lot of linux documentation comes across as barebones, or very concise about the one way it's meant to be done with a certain distro (plus potentially outdated on an earlier version), and a general lack of explanations.

As example toy projects I'm trying to test out dnf-automatic because I'd prefer not to have the admin work of manually keeping on top of routine updates, but there's little feedback (although so far that's better than pacman on Arch which specifically expects atdmin), or learning why a distro has set up swap/zram/zswap the way they have, what the limits are on that config, how to measure what my system uses and if/how to adjust it. There's little guidance within the system to get you up to that level, and to open another can of worms the terminal-first approach in linux's DNA usually doesn't present anything but the bare essentials for whatever tool you're running, but any extra/wasteful information shown could nudge you where the next step is.

>>keyrin+Ku

  > teaching is demanding

But rewarding. What makes it less rewarding online is we don't see the benefits. We don't hear thanks. Which we should say more often

  > a lot of linux documentation comes across as barebones

One thing I try to encourage is writing documentation. People are extremely resilient to this and I'm not sure why. It has a lot of benefits. I forget what I did, it helps remind me.

But people often claim no one else will read it or it's obvious. I think we've all dealt with the frustration of dealing with undocumented code. Seen how much time it takes because of the lack of documentation. Why doesn't this encourage writing documentation?

When docs are scarce and you have access, add a little. It can be built over time. Some is better than none.

The other thing I do is write notes. I put a lot of them in my dotfiles actually. This means I keep them just text (or link for images) and these can get carried around with me. I hand them out frequently and am always happy to have others contribute or share theirs but honestly I don't know a single other person that does this. But I find it extremely helpful. I reference them all the time. Granted, they're written for me but I think more people should.

>>godels+dc1
Oh boy, I had many people telling me "please teach me how to use Linux [but I do not want to read any documentation!]". It gives me PTSD whenever I see people talk about documentation. I write documentation for myself and others who give a crap. I have been downvoted here for just simply stating that I wish people were less reluctant to read documentation, so y'know.

>>johnis+XB1
Yeah I think you've hit on the answer of why people don't write docs: they don't want to read docs...

But docs are kinda a necessary "evil". It would be great if we could instantly download information into our brain. Instead, we have to slowly download information into our brain (and it gets faster the more you do it).

People feel too rushed. But does the rushing get us anywhere faster? It's like rushing around in your car. You feel like your going faster, but if you time yourself or watch other cars that aren't rushing, you'll observe they still are ending up at the same stoplights you are. The speed only increases your anxiety and risk of accident. It feels faster, but it really isn't in 90% of cases.

Personally, I'd rather get to my destination more calm and safe. Might cost 1-2% in time, but most of the time I'll be better at my destination if I'm relaxed. Only rush when seconds matter.

With docs are useful and you shouldn't just jump to the parts you need. The surrounding context is a force multiplier. It helps you get into the mind of the writer. It helps you guess how things get put together. It helps you understand the larger picture. All of that is helps. You don't need to read a doc front to back, but just extracting one-liners is not helpful.

It is just rushing... good things take time