A Generic Guide to *Nix Systems

I’ve been pondering for a while what a generic any *nix book would look like. Not a guide to fedora, or debuan or FreeBSD. But like the broad stokes of what anyone might need to know when getting their feet wet with any distro or BSD for the first time.

What chapters would such a book need? Assuming we’re limited it to 64bit x86 computers? and assuming its aimed at desktop computers?

Here is a first pass:

  • Partition Tables MBR/GUID
    • Swap Partitions
  • Common Installation Questions
  • Bootloaders
  • Intro to basic shell commands
  • Guided tour of common desktop environments
    • Gnome
    • KDE
    • XFCE
    • etc…
  • Basic Packagemanagement and Ports trees
    • RPM
    • DEB
    • Pacman
    • Ports
    • Portage
    • Pkgsrc
    • Guix
  • Basic control of services & configuration
    • systemd
    • BSD style rc.conf
    • OpenRC
    • etc…
3 Likes

This is an awesome idea and I love it.

I still remember trying to come over from the M$FT world, and it was a tough transition. What I’ve never seen anywhere, but I think could be invaluable, is within the book explain the Windows parallel, to assist in understanding.

ex. talking about partition tables. “Generally in Windows, the system has one big partition on your disk. With *nix, we have finer-grain control.”

Same for how programs install, or desktop environments, etc.

2 Likes

Not a bad idea. My idea for this is something I can point someone too nomatter what distribution or BSD has grabbed their attention. Its probably safe to assume their coming from Windows.

Maybe footnotes or side bars for how everything compares to Windows and macOS?

EDIT

Oh and if such a thing allready exists please tell me. No need to duplicate work. Just most things ive found tend to be distro specific; and id like something that was rather linux/bsd/distro agnostic.

I haven’t seen anything that is a guide for *nix that didn’t feel like it was written for either sysadmins or computer science majors.

Good idea. I was curious how close a series of enwp articles could come. Not terrible in some respects, but far from the mark overall.








and of course

1 Like

I feel like this could be very doable. I would like to try to write my own version of it. Since I have an interest in technical documentation, this could help me practice writing it.

1 Like

You should try writing it with a bunch of other people. I’ve rarely written technical docs in a work capacity by myself. :slight_smile:

1 Like

Would you be open to collaborating on it? Cause ive been mulling on it for a while as something I might otta do; and I hate to duplicate work?

1 Like

This is a half-baked idea, but I don’t have time to flesh it out at the moment.

I like the transclusion technique used on many Wikipedia articles where there is an opening paragraph, and a link to the “Main article for $Subtopic”. Think of when a TV series lists a short list of episodes for a season, but links to an article that has a more verbose list. Or when a basic understanding of a high level concept is included.

Anyhow, that’s what I’ve imagined producing: a smartly written, transcluded guidebook. This is one of those places where I get “web-appy”, because I think one could mark a domain of knowledge as “known” and the UI would change the content. For instance, maybe I never need links to installing software, or updating the system. I can get my tutorials with less checklist links to other minitutorials.

One thing I notice about the Wikipedia lead-in paragraph approach is I’d template the content, so it is edited in a single place and replicated throughout. That creates an interesting and unique editing challenge, though. You’d have to really be in sync with other folks to ensure not just a standard tone, but also are building narrative journeys that scale to user level.

I think their are a lot of interesting technical solutions. From some sort of markup language in text documents in version control repos; to Wikis, to things I haven’t thought of. I’ve also kinda got opinions about also eventually about wanting lots of possible output formats; but I also wanna see who is (if anyone) is interesting in collaborating and at what comfort level before we suss out technical stuffs.

I also am still curious to if their are any other topics im not thinking of that ought to be in scope.

1 Like

I’m in, though I’m pretty dedicated to producing only public domain works. It makes a lot of sense to me, and is like the most important thing to me, so I wanted to put that up front and try to get others excited about producing a CC0 work. :slight_smile:

My half-baked idea was very Wikipedia heavy in example, but only because I’ve only ever seen that content pattern there. But it is about the content pattern, not a wiki. My preference for writing content is vim + markdown, so text version control is my jam.

Another content pattern I love is Wirecutter articles. I think they basically follow the same pattern, where they lead in with everything you need to know, then they deep dive in sections that make sense for the topic.

I’m not suggesting one way or another, tech-wise, at this point. I’ve just got ideas on how I’ve planned such a guide. I am obvious wallowing over here in semantic databases and inference, but I think a guide like this is more about being human accessible, meaning explaining concepts for a person not used to searching databases and correlating data. They just need to, ya know, figure out how to get this second drive recognized… :slight_smile:

When I look at the shape of the collaboration, I wish we had the resources to book sprint. Maybe one day! Leading up to FOSDEM!

Are you thinking of package manager of distributed (and or offline) version control? :slight_smile:

Your list is a great start. I only ever need a bare frame to get started, and then fill out more topics as needed.

That might be something too; while I think we got a lot of room to collaborate under CC0, for this particular project, I think its apropriate to discuss copyleft in the text; and Id like to enforce it on the text itself too. id also like a license on this particular thing that would prevent someone from wrapping it up in DRM in the future for example too.

Well now I’m interested in writing a guide for licenses!

  1. What is such a license?
  2. I am against it. :slight_smile:

I don’t personally have the capacity to enforce such a license, and I’ve got not problems with people putting stuff in DRM; DRM is an anti-pattern, but I can’t describe DRM is a way that excludes usage that I support, so I let it all go.

Not to say I won’t contribute! My contributions would just be more portable than others’. :sunglasses:

Sure! I would definitely be open for that of thing! Just contact me over XMPP so we can iron out the details!

GNU Free Document License 1.3, with no Invariant Sections; is usually my goto for something which is FreeCulture, Copyleft with a no DRM clause.

Im going to let this bubble in talkgroup for a little while, and then maybe if we get more volunteers we can make an XMPP room or something; since @maiki has me thinking thats the fashionable thing to do.

My fiance is also has a degree in english; and a pretty decent writer. So we might be able to draft him for editing and stylistic help. Though he’s not big on XMPP; I might be able to act as a proxy.

2 Likes

I don’t have a problem with that. The more the merrier!

Your fiance sounds awesome. So I guess if XMPP ultimately wouldn’t work out we could try something Matrix or what? Just curious!

No problem! Ill hit you up on jabber on that one though; because the answer is complex. Im not sure he is using any comms platform thats quite suited for us here.

Fashionable, as well as policy-filled! Such grown up!

Actually it occured to me I ought to back off this. I wanna seriously make more progress on Pellucidar and Lisp work before I start on a new big thing. (Im trying to be more focused.)

If @Fuuko and @Maiki wanna run with it their way, and lemme collaborate in with their plans thats probably for the best for now.