Linux Documentation Project Puns

Hello internet, I am just posting a quick little idea I had that you may be interested in.

I, like many (I would hope all) of you, am a GNU/Linux user. And during my quote-unquote 'linux journey' have found myself on The Linux Documentation Project website many a time. My visit typically consists of viewing a how-to of some sort. And every time it irks me that while likely thousands of people have viewed this very same page, it is still unstyled HTML. Not to mention many of these articles have not been updated for a decade (give or take). This is what we refer to as The Linux Document Project, and yet we choose to leave it in shambles. It is seemly a dead project, yet it still receives many visits annually.

So my idea here is to take a second look at what we have, and make an attempt at reviving this project for modern day use. My idea consists of a few things in this order:

• Fork the existing LDP project hosted on GitHub, and convert it into a simpler format (I like to use Asciidoc since it is standardized unlike its more popular Markdown cousins)
• Add a static site generator to the project (Again, my preference is Middleman since it is extremely simple and can be extended)
• Style the converted docs into something more pleasing to the eye (I find this especially important for new users). This will be quite simple using the static site generator mentioned above
• Try our best to modernize these documents where needed (This will obviously be the hardest part)

All in all, I think it is an achievable goal for a small group to get this up and running through git. My only concern is overall interest in the Linux community. So here are a few questions for you readers to answer:

• Would you be interested in using such a site?
• Would you be willing to contribute (small or large) changes to such a site?
• Do you have any naming suggestions for said new project? :P

Thank you for your time, and please, if you're interesting, tell your friends! And please, if you have any criticism for my plan, feel free to share that too.

P.S., I am aware of the Linux Journey, but it irks me for a few reasons, including that it is not truly open source (only the markdown is available through a repo) and it attempts to brainwash new users occasionally. For example, on its kernel installation page it uses apt-get as the way to install a kernel. If find this extremely short-sighted to cite

http://tldp.org/

I used that site extensively back in my early Linux days.

I just went to check it out and it looks like most of those docs are 10 years old or more.

I was trying to install java on linux today, everything installed perfectly but wont run java application

Set up a separate Ubuntu box to test speed differences be tween win10/ubuntu.

Chia is installed, and gui is installed. Gui syncs fine, but plots never progress past 1% and throw no logs.

So I figure I'll look at command line docs. It shows you how to start the node, and how to plot... But nothing else. Don't I need to feed it my keys somehow? Do I need to feed it my keys every time I launch it, or does it save somehow? The docs don't really explain the process in any coherent order.

My end goal here is plot on Linux, and move over to a smb share on the windows box, which has the larger slower array and runs the gui for farming.

Edit: The client is a family friend so I’m trying to help them out

Hi there.

I'm a junior in a smaller company with this being my first gig. Last week I was told I'll be assingned on a large fullstack project which doesn't have any documentation whatsoever. How to go about this? My lead and other peers will be at hand but I'm wondering if anyone has any tips or practises on how to figure stuff out faster without constantly asking for help.

Thnx.

Thank you all for the usefull info

In our stack, we have many "micro-services", I call them that with quotes cuz they are essentially monolithic services that talk to each other. But anyways.

All of these components are written in Node, and use express. They are, for the most part, RESTful HTTP services/components. They are not node packages, they are full fledge components. Most of these "micro-services" talk to each other via HTTP requests.

I see that there are a lot of README templates online that I think would help, but that's not really what I want. The thing with these templates is that they're really more geared towards contributing to an open source project or some node package, which is NOT what my component is. It's an internal component, and I need some document that helps explain how the component works.

So I'd like to have some sort of README template or perhaps documentation where it'll make it easier for any developer to hop on without me having to sit next to them and explain how the project is structured/how to make new routes/controllers, etc. Instead they can read this doc or the README and have a huge head start on 1. How this project fits in the stack, 2. how it is structured and works.

Currently, all the READMEs for each of the components don't have anything useful on them, some simply say "TODO: add readme" or just have a blank README. So I am at liberty to add whatever I want. I am not restricted by some "structure" already set on me. And keep in mind I am not restricting this to just the README, if it's some sort of UML that I have to create that's fine too. I would just like to see if anyone has experienced with this sort of situation, where they need a documentation that helps other developers understand how a Node component is structured and does.

TL;DR: I need some sort of guide or template on how to create this "this is how this project works, and how it is structured". NOT a documentation that says "npm install and you're good, and read here for our contribution guide and how to get started".

The former Burstcoin Community Website & Documentation Project has been updated for the Signum rebrand and has moved to https://signum.community/ with a new design and new materials. To contribute to this long-form website, click the small downfacing arrow at the end of most sections to reveal a submission form. This will open a work ticket for an editor to review and determine the best way to update the collection. Many thanks to everyone who has contributed to this project.

Hello everyone!

I am a volunteer working with the Jewish Languages Documentation and Revitalization Project at Wikitongues. We are working to collect eight hours of oral histories in every Jewish diaspora language (see list below). If you are interested (or know someone who is), please let me know or email us at hello@wikitongues.org. Thank you!

Jewish Languages:

Yiddish (Standardized, Eastern, Western, Palestinian)
Israeli Sign Language
Judeo-Arabic (Iraqi, Moroccan, Tripolitanian/Libyan, Tunisian, Yemeni, Aleppine/Syrian, Egyptian)
Judeo-Aramaic
Yevanic (Judeo-Greek)
Judeo-Persian
Bukhari (Judeo-Tajik)
Juhuri (Judeo-Tat)
Judeo-Shirazi
Judeo-Median/Judeo-Hamedani
Lotera'i
Judezmo (Ladino)
Haketía (Ladino)
Judeo-Italian (Roman, Venetian, Livornese, Emilia-Romagnan, Piedmontese, Florentine, Corfiot)
Judeo-Malayalam
Karaim
Krymchak
Judeo-Berber
Ghardaia Sign Language (Jewish Algerian Sign Language)
Qwara (Judeo-Qimant)
Kayla (Judeo-Qimant)
Judeo-Amharic
Judeo-Georgian
Jewish Latin American Spanish
Jewish Swedish
Jewish English
Jewish Hungarian
Jewish Russian
Judeo-Portuguese
Judeo-Occitan

Heading into training finals, every trainee has to pull through one-man-projects and a corresponding 30 pages documentation. I've put a lot of work to aim for best marks possible.

This guy is the typical "I only write to you when I need something" type of guy. If he was just asking me on help how to do X, I wouldn't bother helping.

But I refuse to send him a full copy so he can copy 90% of the documents structure and just change the content to match his project. I also don't want to take any risks on plagiarism claims.

How do I gently tell him that he is not getting it, at least not before evaluation?

Right now, Arch Wiki holds a lot of the best documentation. And it makes sense, since Arch is a DIY distro, so there needs to be a good manual to read, otherwise there is no distro.

But I'm not sure it's healthy to tie some of the best documentation to one distro. Sure, Arch ain't going away anytime soon, but what if there was also room for documentation of Debian or Gentoo software? What if, instead of fragmenting documentation for various programs across various sites, manuals and wikis, we had one central repository that built on the efforts of more specific sources? Not to mention that Arch pages tend to focus on making software work for Arch, obviously. A standard wiki would contain tutorials and tweaks for more distros.

So, I'm thinking of starting LinuxWiki, using ArchWiki as a base, since I don't see the point of rewriting already good documentation. Instead I'd rather give it room to grow and become more universal.

I just started a lead role with my company and have was curious if anyone else has done something similar. Basically, I will be leading (and helping develop) efforts towards curating a use case list, choosing, of that list, what we'll be working on, based on business value, and executing those solutions. This effort started a couple of weeks before I began the new role, so I am catching up. Our executive leader has some passion around developing and using some tools we do not already have, so there is a bit of focus on graph analytics right now, but other ML and AI solutions are not out of the question, I just need work with my team to decide on the use cases and create a document for our plan.

I've done this for other projects that were not DS related, but was curious if anyone has any sort of template or guidance for a format that worked really well for them. Maybe even an outline of what should be included and how it should be organized. I don't have a lot of direction, since I am being asked to run with this, so I thought this community might have some good suggestions. Thanks so much!

The former Burstcoin Community Website & Documentation Project has been updated for the Signum rebrand and has moved to https://signum.community/ with a new design and new materials. To contribute to this long-form website, click the small downfacing arrow at the end of most sections to reveal a submission form. This will open a work ticket for an editor to review and determine the best way to update the collection. Many thanks to everyone who has contributed to this project.