6 ms·

Instead of creating multiple wikis with probably 80% of duplicate information between them, it would be great to have a cross distribution wiki with separate se

Instead of creating multiple wikis with probably 80% of duplicate information between them, it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense. Gentoo had a fantastic wiki before they lost it to disk array failure (IIRC) around ten years ago, now pretty much everyone is going to the Arch wiki, why not try to turn it into a shared project?

layer8 1y ago
There are not just differences between distributions to consider, but also different distributions being on different versions of things. This would be difficult to organize.
bawolff 1y ago
I don't know if i agree. Good documentation is focused. If you try to cover everything it becomes dilluted and confusing.
noirscape 1y ago
In the case of Debian, they have a pretty different stance when it comes to what the role of a distro is compared to Arch. Arch is essentially completely freeform; you, the user, are going to be making a lot of technical decisions on what you want your system to look like. It's perfectly okay for Arch to ship 4 different versions of the same type of tool, as long as all 4 are being used. The Arch wiki reflects this; it's focused around giving you a lot of options, while not going too in-depth on what you'd want to do with them. Want to swap out NetworkManager for wpa_supplicant because wpa_supplicant is easier to configure from a terminal? Perfectly fine, go ahead. Most arch packages as a result don't heavily deviate from upstream unless it's absolutely necessary to get them running. Debian uh... isn't that. Debian still offers choice, but Debian has set the unenviable goal for themselves to provide a "stable" userland experience. This means Debian offers less options, but the options they do offer are also fixed on certain versions with sometimes pretty derivative versions compares to upstream. Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does. A basic example here is setting up a webserver stack (so webserver, php and mysql); on Debian, you pick between apache2(+mod_php) or nginx/php-fpm and install mysql. Debian takes care of wiring all the permissions, user groups and all that stuff and giving you a "sane" default folder capable of serving PHP scripts on port 80 that anyone can use. It's a lot easier and nginx' configuration is specifically changed to resemble the apache2 vhosts. Arch doesn't do this; arch gives you the upstream versions of all these packages and then asks you to wire them together so that they work. It means they attract pretty different audiences as a result; Debian users value stability/set and forget (also helped by Debian release cycles basically lasting the same length as most LTS releases of other distros), while Arch users are more conditioned to having to occasionally change their config files on updates. That's also reflected in what their wikis aim at. Debian wikis generally can be version locked to their release; Arch wiki needs constant updating as things change. They're different extremes here; most distros usually sit on one side or the other of this sorta thing (with the only real correlation being that dpkg-based distros usually lean more towards the Debian model), but there's also the pseudo-rolling release distros like Fedora, which try to offer similar stability to Debian but much shorter release cycles, so you'll always be running something at least close to the latest version.
- pessimizer 1y ago
  > Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does. But the entire point is how much better Arch's wiki is than anyone else's. I've never run Arch, I've only ever used Arch's wiki to help with Debian. Doing this ironically helps you keep in mind every weird Debianism to figure out how to apply what you're reading.
slightwinder 1y ago
It probably just never worked out that way. Usually everyone starts with documenting the distro-specific parts first, and then adds more and more, until even general parts are there. But at the same time, everyone probably thinks that those general parts are supposed in the specific projects' documentation, so nobody really cares about sharing. Until the point is reached that some wiki is so big and successful, that it just silently took over the whole domain. Also, the whole sharing somehow seems to have died off over the decades. 25+ years ago, when wiki was new and shiny and everyone was experimental and motivated, there were strong movements for interwiki-content, sharing stuff between them openly. Then time happened, not much sharing was done, and every wiki-software slowly moved on, doing their own thing, becoming some semi-open silo or even a closed garden. And today we had this same movement arising in the knowledge management-community, around their tools, and mainly in the context of Markdown, and it also kinda died down and never turned into anything substantial. Maybe, in the end, sharing information and knowledge is a bit harder to execute than it seems?
- zdragnar 1y ago
  I think the sharing is easy. The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams? How do disagreements between teams over style and quality dealt with? Cost of hosting split? All of these are possible to answer, but they are also much easier to deal with when you're not sharing between different organizations.
  - slightwinder 1y ago
    > I think the sharing is easy The hard part about sharing is the different syntax of wikis, which could be slightly different even in the same wiki-software. Then there is the organization-part, and the sync-process itself. Of course, today, 25 years later, we do have better solutions and much more experience for those problems. > The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams? I would think those are pretty simply, as they all follow the same rules. I mean, handling vandalism isn't much different between Arch or Debian, it's always the same. And moderation really depends on the chosen sharing-mechanism. Which brings up again the hard part, just on a different level.
haunter 1y ago
>Instead of creating multiple wikis with probably 80% of duplicate information between them >why not try to turn it into a shared project? This is basically both the highlight and the bane of the Linux world. Why have another DE when there are already multiple ones? [0] Why have another package manager when there are already multiple ones? [1] Why have another distro when there are already multiple ones? [2] So having another wiki makes perfect sense (or not depending on your POV) 0, https://en.wikipedia.org/wiki/Comparison_of_X_Window_System_desktop_environments https://en.wikipedia.org/wiki/Comparison_of_X_Window_System_... 1, https://en.wikipedia.org/wiki/List_of_software_package_management_systems https://en.wikipedia.org/wiki/List_of_software_package_manag... 2, https://distrowatch.com/dwres.php?resource=popularity https://distrowatch.com/dwres.php?resource=popularity
- account42 1y ago
  Bane? It's what makes the Linux desktop great. I get to choose a system that works like I want. Imagine if there was only Gnome or whatever unholy monstrosity is the most popular DE these days.
  - BirAdam 1y ago
    If there were only one, someone would launch a new one within a week. Just how Linux is.
- zahlman 1y ago
  >Why make a green bikeshed when there's already a red bikeshed? Because then you have two bikesheds. An important aspect of the fact that the bikeshed exists, as a separate entity not integrated with the house, is that you can choose a different one. Specifically, the one that's already painted the way you want. Maybe you don't think this is a feature in your current circumstance. Others do, which is why it persists.
kzrdude 1y ago
If the scope is too wide, then it's hard to see when content is outdated or irrelevant. The clear focus helps archwiki for example to not turn into a graveyard of obsolete howtos.
wolvesechoes 1y ago
What would be even better - just a single, unified distro. Imagine if all those man-hours where actually focused on delivering a single working and polished FOSS OS. I know, FOSS is all about choice, yada yada.
- tremon 1y ago
  Then you get to handle all the same criticisms that are usually lobbed at MS Office: no single user ever needs more than 15% of the functionality, but still receives the additional baggage of the other 85% -- whether in terms of memory footprint, reduced performance or UI clutter. The ability of FOSS to be optimized for specific use cases is one of its biggest strengths, and that has nothing to do with "choice" itself, no matter how much you try to disparage it.
  - wolvesechoes 1y ago
    And I thought that free software is about human freedom. Well, enjoy your optimized memory consumption instead.
    - tremon 1y ago
      I'm not sure I understand your position. You seem to be saying that allowing customization is bad for human freedom? Would you mind ELI5'ing that for me?
      - wolvesechoes 1y ago
        See my reply to sibling comment. What is customization, if all you can customize are countless half-baked distros for tinkerers, teared through constant drama, ambitions of snowflake devs trying to make 100 competing solutions obsolete by introducing 101st, and forking, and, as a typical non-dev computer user, you are more and more dependent on adversary Big Techs? If Cyberpunk dystopia ever comes, I am sure we still will be able to choose between GNOME and KDE, and there will be people saying that we are still good, for we have a choice.
    - 1y ago
WhyNotHugo 1y ago
> Instead of creating multiple wikis with probably 80% of duplicate information between them Wikis do tend to link a lot across one another. On the Alpine Wiki, I prefer to link to the ArchWiki when applicable, rather than copy content over.
kbolino 1y ago
What matters in the long run for making a good wiki are the people and policies. Young and niche wikis are happy to take any contributions they can get. The quality and timeliness of any given bit of text soon ends up wildly different from page to page or even section to section. Some people may decide to take their time not just contributing new content but also editing existing content. However, it becomes difficult to balance creation vs. curation. Too much creation, and the editors get overwhelmed, and then the users can never be sure what to trust, and so the wiki becomes irrelevant. Too much curation, and the information becomes uniformly stale and lowest-common-denominator, so the users start going elsewhere, and so the wiki becomes irrelevant. Different wikis means each one can have its own people and policies. If the people who made one wiki great leave, there are still other wikis out there. If the policies choke the life out of one wiki, there are still other wikis out there. Some wiki can be full of deletionists while another wiki is full of inclusionists. Some wiki can be full of mergers while another wiki is full of splitters. Forcing everybody onto one wiki forces them all to work together, but this is an entirely volunteer effort, and so many will just leave. Even if they were paid, some individuals would dominate while others would get crowded out. One can point to Wikipedia as a glaring exception, standing as basically the only wiki of note of its kind, but I think it's the exception that proves the rule.
- kayodelycaon 1y ago
  Wikipedia is definitely the exception. It works because almost everyone on the Internet uses it.
  - account42 1y ago
    And it's not without problems, not the least of with is that being the default Wiki attracts the kind of people would would love to control the definite source of information.
kelipso 1y ago
I remember a while ago there was a small computer vision wiki that was very useful and somewhat widely used, not that many computer vision people at the time. Then, after around 2010 they decided to move the wiki to Wikipedia. You can guess what happened, original wiki was gone, very few articles survived because, of course, it's Wikipedia. A great resource just gone.
delfinom 1y ago
> it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense. This doesn't work as well as you think. We did this in one large OSS project for documenting operations just for installs/setup/build/etc. The problem is: 1. The list of differences get large fast if you aren't within the same family of OS like Debian/Ubuntu/Mint 2. Information will get out of date for some distros over others. Unhelpful pricks start bitching and moaning and nobody wants to deal with it at that point. 3. Unhelpful pricks will also bitch and moan you delete the out of date sections

layer8 1y ago

There are not just differences between distributions to consider, but also different distributions being on different versions of things. This would be difficult to organize.

bawolff 1y ago

I don't know if i agree. Good documentation is focused. If you try to cover everything it becomes dilluted and confusing.

noirscape 1y ago

In the case of Debian, they have a pretty different stance when it comes to what the role of a distro is compared to Arch. Arch is essentially completely freeform; you, the user, are going to be making a lot of technical decisions on what you want your system to look like. It's perfectly okay for Arch to ship 4 different versions of the same type of tool, as long as all 4 are being used. The Arch wiki reflects this; it's focused around giving you a lot of options, while not going too in-depth on what you'd want to do with them. Want to swap out NetworkManager for wpa_supplicant because wpa_supplicant is easier to configure from a terminal? Perfectly fine, go ahead. Most arch packages as a result don't heavily deviate from upstream unless it's absolutely necessary to get them running. Debian uh... isn't that. Debian still offers choice, but Debian has set the unenviable goal for themselves to provide a "stable" userland experience. This means Debian offers less options, but the options they do offer are also fixed on certain versions with sometimes pretty derivative versions compares to upstream. Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does. A basic example here is setting up a webserver stack (so webserver, php and mysql); on Debian, you pick between apache2(+mod_php) or nginx/php-fpm and install mysql. Debian takes care of wiring all the permissions, user groups and all that stuff and giving you a "sane" default folder capable of serving PHP scripts on port 80 that anyone can use. It's a lot easier and nginx' configuration is specifically changed to resemble the apache2 vhosts. Arch doesn't do this; arch gives you the upstream versions of all these packages and then asks you to wire them together so that they work. It means they attract pretty different audiences as a result; Debian users value stability/set and forget (also helped by Debian release cycles basically lasting the same length as most LTS releases of other distros), while Arch users are more conditioned to having to occasionally change their config files on updates. That's also reflected in what their wikis aim at. Debian wikis generally can be version locked to their release; Arch wiki needs constant updating as things change. They're different extremes here; most distros usually sit on one side or the other of this sorta thing (with the only real correlation being that dpkg-based distros usually lean more towards the Debian model), but there's also the pseudo-rolling release distros like Fedora, which try to offer similar stability to Debian but much shorter release cycles, so you'll always be running something at least close to the latest version.

pessimizer 1y ago
> Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does. But the entire point is how much better Arch's wiki is than anyone else's. I've never run Arch, I've only ever used Arch's wiki to help with Debian. Doing this ironically helps you keep in mind every weird Debianism to figure out how to apply what you're reading.

slightwinder 1y ago

It probably just never worked out that way. Usually everyone starts with documenting the distro-specific parts first, and then adds more and more, until even general parts are there. But at the same time, everyone probably thinks that those general parts are supposed in the specific projects' documentation, so nobody really cares about sharing. Until the point is reached that some wiki is so big and successful, that it just silently took over the whole domain. Also, the whole sharing somehow seems to have died off over the decades. 25+ years ago, when wiki was new and shiny and everyone was experimental and motivated, there were strong movements for interwiki-content, sharing stuff between them openly. Then time happened, not much sharing was done, and every wiki-software slowly moved on, doing their own thing, becoming some semi-open silo or even a closed garden. And today we had this same movement arising in the knowledge management-community, around their tools, and mainly in the context of Markdown, and it also kinda died down and never turned into anything substantial. Maybe, in the end, sharing information and knowledge is a bit harder to execute than it seems?

zdragnar 1y ago
I think the sharing is easy. The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams? How do disagreements between teams over style and quality dealt with? Cost of hosting split? All of these are possible to answer, but they are also much easier to deal with when you're not sharing between different organizations.
- slightwinder 1y ago
  > I think the sharing is easy The hard part about sharing is the different syntax of wikis, which could be slightly different even in the same wiki-software. Then there is the organization-part, and the sync-process itself. Of course, today, 25 years later, we do have better solutions and much more experience for those problems. > The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams? I would think those are pretty simply, as they all follow the same rules. I mean, handling vandalism isn't much different between Arch or Debian, it's always the same. And moderation really depends on the chosen sharing-mechanism. Which brings up again the hard part, just on a different level.

haunter 1y ago

>Instead of creating multiple wikis with probably 80% of duplicate information between them >why not try to turn it into a shared project? This is basically both the highlight and the bane of the Linux world. Why have another DE when there are already multiple ones? [0] Why have another package manager when there are already multiple ones? [1] Why have another distro when there are already multiple ones? [2] So having another wiki makes perfect sense (or not depending on your POV) 0, https://en.wikipedia.org/wiki/Comparison_of_X_Window_System_desktop_environments https://en.wikipedia.org/wiki/Comparison_of_X_Window_System_... 1, https://en.wikipedia.org/wiki/List_of_software_package_management_systems https://en.wikipedia.org/wiki/List_of_software_package_manag... 2, https://distrowatch.com/dwres.php?resource=popularity https://distrowatch.com/dwres.php?resource=popularity

account42 1y ago
Bane? It's what makes the Linux desktop great. I get to choose a system that works like I want. Imagine if there was only Gnome or whatever unholy monstrosity is the most popular DE these days.
- BirAdam 1y ago
  If there were only one, someone would launch a new one within a week. Just how Linux is.
zahlman 1y ago
>Why make a green bikeshed when there's already a red bikeshed? Because then you have two bikesheds. An important aspect of the fact that the bikeshed exists, as a separate entity not integrated with the house, is that you can choose a different one. Specifically, the one that's already painted the way you want. Maybe you don't think this is a feature in your current circumstance. Others do, which is why it persists.

kzrdude 1y ago

If the scope is too wide, then it's hard to see when content is outdated or irrelevant. The clear focus helps archwiki for example to not turn into a graveyard of obsolete howtos.

wolvesechoes 1y ago

What would be even better - just a single, unified distro. Imagine if all those man-hours where actually focused on delivering a single working and polished FOSS OS. I know, FOSS is all about choice, yada yada.

tremon 1y ago
Then you get to handle all the same criticisms that are usually lobbed at MS Office: no single user ever needs more than 15% of the functionality, but still receives the additional baggage of the other 85% -- whether in terms of memory footprint, reduced performance or UI clutter. The ability of FOSS to be optimized for specific use cases is one of its biggest strengths, and that has nothing to do with "choice" itself, no matter how much you try to disparage it.
- wolvesechoes 1y ago
  And I thought that free software is about human freedom. Well, enjoy your optimized memory consumption instead.
  - tremon 1y ago
    I'm not sure I understand your position. You seem to be saying that allowing customization is bad for human freedom? Would you mind ELI5'ing that for me?
    - wolvesechoes 1y ago
      See my reply to sibling comment. What is customization, if all you can customize are countless half-baked distros for tinkerers, teared through constant drama, ambitions of snowflake devs trying to make 100 competing solutions obsolete by introducing 101st, and forking, and, as a typical non-dev computer user, you are more and more dependent on adversary Big Techs? If Cyberpunk dystopia ever comes, I am sure we still will be able to choose between GNOME and KDE, and there will be people saying that we are still good, for we have a choice.
  - 1y ago

WhyNotHugo 1y ago

> Instead of creating multiple wikis with probably 80% of duplicate information between them Wikis do tend to link a lot across one another. On the Alpine Wiki, I prefer to link to the ArchWiki when applicable, rather than copy content over.

kbolino 1y ago

What matters in the long run for making a good wiki are the people and policies. Young and niche wikis are happy to take any contributions they can get. The quality and timeliness of any given bit of text soon ends up wildly different from page to page or even section to section. Some people may decide to take their time not just contributing new content but also editing existing content. However, it becomes difficult to balance creation vs. curation. Too much creation, and the editors get overwhelmed, and then the users can never be sure what to trust, and so the wiki becomes irrelevant. Too much curation, and the information becomes uniformly stale and lowest-common-denominator, so the users start going elsewhere, and so the wiki becomes irrelevant. Different wikis means each one can have its own people and policies. If the people who made one wiki great leave, there are still other wikis out there. If the policies choke the life out of one wiki, there are still other wikis out there. Some wiki can be full of deletionists while another wiki is full of inclusionists. Some wiki can be full of mergers while another wiki is full of splitters. Forcing everybody onto one wiki forces them all to work together, but this is an entirely volunteer effort, and so many will just leave. Even if they were paid, some individuals would dominate while others would get crowded out. One can point to Wikipedia as a glaring exception, standing as basically the only wiki of note of its kind, but I think it's the exception that proves the rule.

kayodelycaon 1y ago
Wikipedia is definitely the exception. It works because almost everyone on the Internet uses it.
- account42 1y ago
  And it's not without problems, not the least of with is that being the default Wiki attracts the kind of people would would love to control the definite source of information.

kelipso 1y ago

I remember a while ago there was a small computer vision wiki that was very useful and somewhat widely used, not that many computer vision people at the time. Then, after around 2010 they decided to move the wiki to Wikipedia. You can guess what happened, original wiki was gone, very few articles survived because, of course, it's Wikipedia. A great resource just gone.

delfinom 1y ago

> it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense. This doesn't work as well as you think. We did this in one large OSS project for documenting operations just for installs/setup/build/etc. The problem is: 1. The list of differences get large fast if you aren't within the same family of OS like Debian/Ubuntu/Mint 2. Information will get out of date for some distros over others. Unhelpful pricks start bitching and moaning and nobody wants to deal with it at that point. 3. Unhelpful pricks will also bitch and moan you delete the out of date sections