Hacker News new | past | comments | ask | show | jobs | submit login

  > 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




Regarding gatekeeping, there was one webforum I used to visit when I was a kid, which I think approached this in an interesting way. Most of the boards were available to the public, general users could post in them (other than the one that announced rules of course), but there was a subforum which could only be accessed by those who had demonstrated some minimum level of competency. Specifically this was a forum about programs for bots for a for-kids MMO (said MMO didn’t really have PVP that depended or gear or levels or anything, or a way of trading items or anything like that, so there wasn’t any player economy. So I think these cheats were pretty harmless. Well, except for the people making bots move in arrangements to make offensive symbols.). The process was, one could submit a program one had made that did something interesting, and they would judge whether it was sufficient to be allowed in to the subforum.

I think this had the benefits of:

• allowing people who don’t want to bother with newbies to not have to, if they stay in the subforum

• still having the places for “people who are skilled and willing to work with/help newbies” and “people who are skilled but don’t want to deal with newbies much” be in a sense the same place, while also having the place for the latter be the same as a place for newbies.

• provides an incentive for newbies to become skilled.

_____

Of course, this method doesn’t work if no one is willing to engage with the newbies. But I think it’s probably fine/reasonable to keep outsiders away from a few things provided that there is a reasonable path in.

Though, I’m not advocating that the approach that forum used be implemented everywhere. I just think it is something that a community could reasonably choose, depending on their priorities.


C'mon name the game. I need to know now.


It was “Club Penguin”.

The forum was primarily about the “Penguin Client Library” (or “Penguin Client System”, I think they went back and forth about the name?), which allowed writing PHP scripts to interact with the game servers.

Why PHP? I think maybe it was originally so people could use it to make web forms where people could put in their username and password and it would e.g. give them whatever item, but that kind of cheat was blocked very quickly, and I think it just remained in PHP for historical reasons, so instead you had a bunch of people running PHP on their local machine to run a bot doing normal game actions (but combined in unusual ways). Or maybe it was just the language the devs were most comfortable with, idk.


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.


  > 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.


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.


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


> Why gatekeep people from enjoying the same thing you enjoy?

That's an easy one to answer: they will eventually demand that Foo changes and remove things they do not like. It has happened to all media, it has happened to all software, you can be damn sure it will happen to something as modular as a Linux distribution.


This seems to falsely assume that technical users are more aligned with whatever the status quo is, and non-technical users are the ones who are looking to change things. In reality, technical users become technical users because they want to make changes, and 'casual' users just use whatever app/OS/etc is given to them, as-is.

Having bad or no support for your software isn't some good way to keep it 'pure', it's just keeping it less useful/relevant. Linux is OSS: fork it if you don't like something new, but don't hurt the ecosystem.

Deliberately hamstringing software or documentation so that others will stay away and not make changes is literally antithetical to OSS as a philosophy.


> This seems to falsely assume that technical users are more aligned with whatever the status quo is, and non-technical users are the ones who are looking to change things. In reality, technical users become technical users because they want to make changes, and 'casual' users just use whatever app/OS/etc is given to them, as-is.

Neither of this is true. There are plenty non-technical users that will be suggesting changes, there are plenty of technical users where they don't want things to change.

> Having bad or no support for your software isn't some good way to keep it 'pure', it's just keeping it less useful/relevant.

You are conflating "bad or no support" with "gate-keeping". Gate-keeping is about keeping riff raff out, but allowing those that are interesting to a path to being involved.

With respect to Linux distros. Linux is like a "kit". Different people offer you different "kits" called distros. Some of these kits may be given to you pre-assembled (Ubuntu/Fedora/Debian), other will require partial assembly (Arch) and some will require full assembly (Gentoo/LFS).

Arch/Void/Gentoo flavours of Linux don't advertise itself a user friendly distro like Ubuntu/Mint/Fedora. *It is expected you read the documentation and understand the command line*.

Thus why people were suggesting they should use the CLI tool. If a user doesn't want this, they should use something else.

Having a "noob" version of installation instructions for something like Arch/Gentoo will have the effect of allowing someone to fumble about and maybe achieve getting something functional, but they won't actually understand what they are actually doing and this will cause them problems in the future as they won't understand how to fix issues when they arise.

> Linux is OSS: fork it if you don't like something new, but don't hurt the ecosystem.

It is extremely difficult for even for large companies to run their own fork of large open source projects. Sure you can fork a smaller piece of software and maintain your own version, but anything significant you are unlikely to be able to do that. So you are forced either to use the changes you may not like, or you use something different, or you are are like the anti-systemd crowd essentially running a protest distro.

Also all the big forks in the software ecosystem is when two important factions have disagreed fundamentally on the direction of the project. We are not talking about individual users or developers, we are talking about the top tier developers/maintainers. A part-time/bedroom coder is unlikely to have any significant effect, even if they did it is often lead to burnout of these developers.

> Deliberately hamstringing software or documentation so that others will stay away and not make changes is literally antithetical to OSS as a philosophy.

Ignoring the fact that you are misstating the issue. It isn't antithetical to the philosophy at all. People decide their own level of involvement in any group activity. If you aren't willing to "pay your dues", then it maybe better for you to not be involved.

You will BTW see this to varying extents in Churches, Cricket Clubs and even your place of employment.

e.g. If you go to Church you have to accept certain tenants about the faith or at least respect them while you are there. I've been invited to Churches in my local area, by very nice people that I would like to get to know, but I can't believe in Christ, so I don't go.


> non-technical users that will be suggesting changes

Suggesting is not making. Non-technical users will not be making changes.

> You are conflating "bad or no support" with "gate-keeping".

If the support is intentionally removed with the goal of keeping out people, then it's both. That was the premise accepted by both of the comments above mine, hence my comment working from that premise.

> Having a "noob" version of installation instructions for something like Arch/Gentoo will have the effect of allowing someone to fumble about and maybe achieve getting something functional, but they won't actually understand what they are actually doing and this will cause them problems in the future as they won't understand how to fix issues when they arise.

Everyone is a noob at some point, so getting rid of documentation is only a means to prevent someone from learning. There is no cost to anyone if someone installs Arch without being an expert in the CLI.

> It is extremely difficult for even for large companies to run their own fork of large open source projects.

Agreed. And if there aren't enough people who are willing to support a fork to manage one, there aren't enough people to justify preventing a change that keeps the current version as it is (which is what in this case, that fork would be).

I.e. if there aren't enough people who support the current version, to maintain an unchanged version as a fork, there aren't enough people who support the current version to justify not changing it in the first place.

> If you aren't willing to "pay your dues", then it maybe better for you to not be involved.

Where are you getting this from? The whole conversation was newcomers making changes. Code contributions (i.e. changes) are explicitly the "dues" that OSS devs 'pay'.

> If you go to Church you have to accept certain tenants about the faith or at least respect them while you are there.

If enough of the congregation feels it needs to change, it will (or it will die out). Modern versions of religions look nothing like they did hundreds of years ago, and not all the changes happened due to schisms/ forks. Everything changes, or it dies.


  > There is no cost to anyone if someone installs Arch without being an expert in the CLI.
Actually there is. But the cost is in the future when we have fewer wizards ;)

(Just had to be a little snarky lol. I know you agree)

Part of being a "Senior" in any field is helping those below you. Just think back to all the people that helped us get to where we are today! Yeah, we put in a lot of work ourselves, but it would be insane to have such an ego as to believe we did it all alone. There is no self-made man. No one can pull themselves up by their bootstraps. Nor are there giants' shoulder's to stand upon. Those are just a bunch of normal people standing on one another's shoulders wrapped in a trench coat.


> If the support is intentionally removed with the goal of keeping out people, then it's both.

No it isn't. Stating it is doesn't make it so.

If I expect you to follow a particular procedure and not support another (which is deemed initially friendly) that is perfectly valid. If it keeps people out that wouldn't otherwise be able to follow it, that is a positive, not negative.

It can gatekeep and be authoritative.

> That was the premise accepted by both of the comments above mine, hence my comment working from that premise.

And the premise is incorrect. Thus my comment.

There are also other reasons. Like having two version of the documentation causes confusion in itself.

> Everyone is a noob at some point, so getting rid of documentation is only a means to prevent someone from learning.

Not if the "noob" documentation obscures knowledge by letting people skip important parts of understanding the process.

> There is no cost to anyone if someone installs Arch without being an expert in the CLI.

Yes there is. That person will quiz people in discord, forums, voice chats, reddit etc when they will invariably be presented with an issue that they cannot resolve. Similarly that why people distro-hop.

RTFM response actually trains people to solve their own problems and is the correct way, by first following the process and then only asking when the process doesn't work.

> Where are you getting this from? The whole conversation was newcomers making changes. Code contributions (i.e. changes) are explicitly the "dues" that OSS devs 'pay'.

I was talking about the benefits of gate-keeping in general. I never said anything about specific about code contributions.

BTW, these people will affect code contributions. Much of the Linux desktop is a clone of other systems (typically Windows) to appease users that expect that UI. This actually dominated the conversation for about 15 years in linux.

If we are talking about the newbies. They have to prove they can follow the documentation provided i.e. RTFM.

> If enough of the congregation feels it needs to change, it will (or it will die out). Modern versions of religions look nothing like they did hundreds of years ago, and not all the changes happened due to schisms/ forks. Everything changes, or it dies.

Every group is lead by a minority. The minority in every group, set the agenda, not the majority. That is fact of life, if you think otherwise you are mistaken. Even revolts are usually led by people who are part of disgruntled minority. Every one of those changes would have been made either by someone important in the Church or the state (as the state and the church was typically tied).

Every single one of those changes were made by elites or governments at the time. Not the majority of the congregation. BTW many of the Churches in England and Europe didn't change that much, that why loads of these people migrated in the first place to the US.

BTW many young converts are going to the Orthodox Church because they see it as the most "OG" version of the Church, because some people crave what they believe to be the authentic experience.


I don't think anything you said is explicitly wrong, but I think there is a lot more nuance and that's where the conversation is breaking down.

Such as "RTFM". You're right. People do need to learn to train themselves. That's the most important skill. But the major problem is that noobs are at the beginning. They don't know where to look. They don't know what questions to ask.

The struggle is important, but it can also be too much at times. A senior shouldn't do everything for the junior, but neither should they let them struggle too much. The trick is in the balance. Let them struggle, but pull them back if they stray too far.

If you don't reign them in, then most of them just go far off course. Most of them just get lost and never return. That's not a good situation for anyone. Most wizards come from them not getting too lost while going on this confusing journey. It's more that we just ended up in similar places. But a lot of luck was involved with that. We know the journey itself is important, but you can't tell me that there weren't times that you tripped and fell and they didn't do anything to help you get where you are now (other than learning resilience). We can make things better.

So don't tell a noob to RTFM, they don't even know what the manual is! Point them to the manual, point them to the right section. Say "hey, give this a shot. Let us know how it goes. If you're still stuck we'll probably need to know what <xyz> is". Your "xyz" should always be a hint as to what your guess to the solution is. Gets them thinking about a certain thing they might not have. This still puts everything on them, lets them struggle, but helps prevent them from getting lost. That's not "RTFM" that's "HTM" (Here's the manual)


  > That's an easy one to answer
It was rhetorical

Really, I'm calling people dumb for gatekeeping the things they enjoy. Things change regardless.

With Linux, you can have your distorts. Because Linux people tend to understand that you don't build "products" but environments. Places to build from. To build in. It's not always but it's a good idea. You can't make a product for everyone, but you can make an environment for everyone. It's why a computer or a phone is so universal but iOS or Android isn't


Well Linux can be used to plot crimes against humanity, can’t it? Can’t let that happen, think of the children.


> You can't have wizards without first having noobs.

But maybe some wizards feel miserable when they are forced to interact 95% of the time with noobs, instead of other wizards? Maybe they want a circle for themselves, as a basic human need?


I'd follow "Thumper's Rule"[0].

If you don't want to interact, you don't have to comment or engage.

  > Maybe they want a circle for themselves, as a basic human need?
Fwiw, I'm a big fan of having private spaces and niches. It helps to filter this out. I think it is a mistake we make in our community designs, that everything needs to be public or whole cloth (e.g. Reddit doesn't allow subdivisions within the community). I do like that HN puts a threshold on the downvote, but I'd even like a lower threshold on the upvote. Allows people to wade into the community.

But yeah, I think there is a problem now that the majority of communities have no ability to self filter and self form hierarchies. Without this, noob voices tend to drown out experts and frankly, noobs begin to believe they are experts. I'm sure we've all seen the typical CS stereotype of "read first line of wikipedia article, assume I know the rest" type of person...

[0] https://www.youtube.com/watch?v=9fYngTUZeUQ


Oh I am so pissed about the noob guide thing. I have intentionally removed my post about my bad interactions with the Arch community from my website, but if you're curious it's in the history: https://github.com/VegaDeftwing/OpGuidesHugoSrc/commit/dcc07...

The TL;DR: Arch gets harder year over year as the number of ways to setup/options for each piece of your system grows. Hell, even picking a bootloader among 10 options is confusing. A guide that just at least says "This is common for X, this for Y, the others are interesting and may be worth trying. If you don't want to investigate now, use X" Is DESPRATELY needed.

I tried to have that on my site, and a pretty high level arch forum admin came buy and told me to delete my website and made a PR just deleting the page. It was honestly one of the most rude and hateful interactions I've ever had online.


> 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.

This, I feel like ever since the fall of Twitter, a true hackerspace has been missing for awhile.


> For some reason they killed the noob guide (which I helped maintain).

Is it up or archived anywhere?


You can probably find an archive somewhere but it's utility is probably low. It did need constant maintenance. Which was fine. There were enough of us.

In fact, I even got more people to contribute. I used to say the best way to learn Linux is to install arch. To come back to me after your third failure. It's rough, but you learn a ton and accelerate really fast. Telling people to expect failure helps. They know it's not them being dumb and they won't ruin their computer. Plus, they have a safety net and I promise I will help, but the real lesson is the struggle.


Are you referring to the Installation Guide that had everything on one page? The guide now consists of many links, it is no longer on one page which is kind of annoying (still helpful, but there is more friction when using links/lynx).

I do not remember the "Noob guide" otherwise, but I do remember the old Installation Guide which was great as it had everything on one page!


No, it was a bit different. Basically the install guide cut down with more direct suggestions for typical setups. I believe this is it[0] and I also found this reddit post from 9 years ago talking about the migration[1]. Today, that link will redirect to the standard installation guide.

[0] https://web.archive.org/web/20130116090332/https://wiki.arch...

[1] https://www.reddit.com/r/archlinux/comments/4z7z0i/the_begin...


Oh, that archive is exactly what I wanted! I wish it as up to date. :(


Sorry we lost the fight. I'm hoping our loss can serve as a lesson for how not to lose other fights.

But given how things are now, I'd highly recommend https://endeavouros.com/ if you're doing standard things (good with Nvidia GPUs)


I have not heard of it, but considering it seems easy to install, I might recommend it to others.

I will keep installing Void and Arch on my own systems, however.

Thanks for the suggestion!

BTW, according to the archive.org you sent me, Begginer's Guide indeed turned out to be the Installation Guide: https://web.archive.org/web/20200708051126/https://wiki.arch...

(I just selected a newer version from your link).

So I think it indeed was the Beginner's Guide, or even the old version of Installation Guide that I really liked, it had all the things you need to get it up and running. Now everything is in its own wiki page and it is really annoying when I just want to use links in one or two tty and do the installing from tty1.


Yeah I've had less time to play around with some stuff so Endeavour is a good fit. Only had one graphics issue with my Nvidia card in 3 years. It was the bad combination of a kernel and driver update (Arch, so both beta). Not a hard fix compared to things I've faced in the past. Been spending more time learning Systemd, dracut, and btrfs (I really like btrfs btw).

There used to be two guides. They kinda merged them, so the install guide got better but the noob guide got worse. Here's the comparison...

Beginner's (relink): https://web.archive.org/web/20130116090332/https://wiki.arch...

Old Install: https://web.archive.org/web/20130116102330/https://wiki.arch...


hear hear




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: