I have been using Linux desktops for over five years. But I would really like to learn more. I want a deeper appreciation and understanding of the system. I remember the old days when one would buy a computer (Tandy, Comadore, Atari 800) and it came with a thick manual. That's all you had, a computer, a manual and a terminal prompt. It was a world of exploration and discovery.

So my question is this. Does any one have a suggestion of a book that will provide the same experience in learning to use Debian Linux?

---David

This message transmitted on 100% recycled electrons.
--- SBBSecho 3.00-Win32
* Origin: The Basement Theory - Sciotoville, Ohio USA (1:226/70)

Hallo hyde!

Does any one have a suggestion of a book that will provide the
same experience in learning to use Debian Linux?

I know of a much better idea that will definetly steer you towards what was probably closest to the original way (pre-Debian) one got a linux root/boot system off the ground. Check http://www.linuxfromscratch.org/ for all the gory
details.

As for the commandline any book/tutorial on shell scripting (eg bash) most often contains examples of using basic commands within a shell script which will shed light on the usage of such commands as well as learning basic builtin
shell commands. Things like sed, grep, tar, date, etc. are oft used commands within a shell script. This is probably the best way to learn linux as well as
any other unixie enviroment.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Re: A Terminal and a Manual
By: Maurice Kinal to hyde david on Tue Oct 15 2019 04:02 pm

root/boot system off the ground. Check http://www.linuxfromscratch.org/ for all the gory details.

Thank you for that suggestion. I have seen that site in passing. But honestly I thought it to be just too much for me to take one. But perhaps it is not. I shall try it out.

I found a number of free FOSS ebooks and they have tons of information. Unfortunately they are ebooks and I like physical books. I supposed I will print some of them out.

I discovered TMUX last night and am really enjoying it. I am comfortable with a few terminal apps, but it is the bash scripting and native commands that I really want to learn.

I also have ubuntu server running on a Raspberry Pi and last night I decided to use it like a remote desktop with the help of TMUX. It was awesome!

Maurice, thank you for your encouragement.

---David

This message transmitted on 100% recycled electrons.
--- SBBSecho 3.00-Win32
* Origin: The Basement Theory - Sciotoville, Ohio USA (1:226/70)

Hallo hyde!

Thank you for that suggestion. I have seen that site in passing.
But honestly I thought it to be just too much for me to take one.

It can be overwhelming at first but as always practice makes perfect. Also just reading the individual packages in "Chapter 6" can be an excellent source of what is provided by each package which will assist in further investigation and knowledge. For example, http://www.linuxfromscratch.org/lfs/view/development/chapter06/coreutils.html, lists under "6.54.2. Contents of Coreutils" the installed programs as well as a short descrption which can be very revealing. I use many of these programs in the bash script that actually is creating this reply.

I found a number of free FOSS ebooks and they have tons of information.

Excellent.

I discovered TMUX last night and am really enjoying it.

I have it here as well. It is definetly something worthwhile keeping close and
if it helps to further learning of commandline and/or shell scripting then bonus. :-)

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Re: A Terminal and a Manual
By: hyde david to All on Tue Oct 15 2019 11:53 am

I have been using Linux desktops for over five years. But I would really

like to

learn
more. I want a deeper appreciation and understanding of the system. I

remember the

old
days when one would buy a computer (Tandy, Comadore, Atari 800) and it came

with a

thick manual. That's all you had, a computer, a manual and a terminal

prompt. It

was a
world of exploration and discovery.

So my question is this. Does any one have a suggestion of a book that will

provide

the
same experience in learning to use Debian Linux?

I have a book about Bash scripting, "A Practical Guide to Linux Commands, Editors and Shell Programming". It is a nice starting point. It includes bash scripting and instructions for common tools and editors. It does not cover package management and it is not very Debian specific.

Linux News Media released a series of articles by Marcco Floretti (forget the typoes plz) about Bash scripting which are worth looking at. They also have a periodic special number covering Bash and common tools. I have not read any of those special numbers them but I bet they are good.

The Debian team used to publish a security manual that is totally worth reading
if you can find it.
--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello hyde!

15 Oct 19, hyde david wrote to All:

Atari 800) and it came with a thick manual. That's all you had, a computer, a manual and a terminal prompt. It was a world of
exploration and discovery.

Welcome back in the world of exploration, discovery and frustration. ;)

So my question is this. Does any one have a suggestion of a book that
will provide the same experience in learning to use Debian Linux?

No. Especially for Debian there is no actual complete manual. Many Tutorials for the core system are outdated because of the change of the init system from sysv to systemd. There is technical progress in other tools too. I'm fighting with the change from "ifconfig" to "ip". My knowledge with ifconfig is useless and i've to start as newbee with "ip" again (dislike).

I started my linux experiences with a study of the FHS, the filesystem hierarchy standard (see Wikipedia). It helped a lot to understand the basic structure of the system, where to look for which files.

In the past i used openbooks of o'reily but the actually published ones are not
what i've seen in the past. For germans i recommend the openbooks of rheinwerk-verlag.de/openbook there are unix and linux books. To find the old o'reilly book you can use archive.org and search for oreilly.com/openbook/ and go to the timeline of feb 2004 where you can find the openbook "Learning Debian/GNU Linux". The content is outdated in details but you can see that the book structure is very same as some docs you'll find if you go to the documentation section of debian.org.

The entry point is debian.org/doc/index.en.html Take your time with the Administrator's Handbook and the Debian Reference.

The Atari 800 came with it's operating system on ROM, read only, it was static with no changes. Actual operating systems are not static that's why you should use a dynamic manual too.

The linux from scratch is a more detailed way to learn system administration from the very beginning. You could build your own specific system environment that way.

My main tools on the system shell are "apropos", "man", "find", "grep" and "nano". If you liked DOS and NC then there is a clone called midnight commander
or short "mc" that can be installed with "apt install mc".

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Re: A Terminal and a Manual
By: Maurice Kinal to hyde david on Wed Oct 16 2019 03:46 pm

http://www.linuxfromscratch.org/lfs/view/development/chapter06/coreutils.h tml, lists under "6.54.2. Contents of Coreutils" the installed programs as well as a short descrption which can be very revealing. I use many of

Thank you! This is excellent! This is going to be very helpful.

Bash scripting is something that I am very interested in. I have created a basic menu of tasks in bash. I don't know if it qualifies as a "program", but it has allowed me to explore the functions I use most and make shorter work of them after I have successfully completed those commands mannually for a while.

I noticed base64 being a core util. I discovered base64 this past summer in a CEH course. As simple as it is I simply love it.

Again, thank you! I am very excited to learn of this resource. And I am very glad I asked. This very conversation is EXACTLY why BBS were created and reminds me that there are still awesome people in this world!

---David

This message transmitted on 100% recycled electrons.
--- SBBSecho 3.00-Win32
* Origin: The Basement Theory - Sciotoville, Ohio USA (1:226/70)

Re: A Terminal and a Manual
By: Richard Falken to hyde david on Wed Oct 16 2019 10:30 am

I have a book about Bash scripting, "A Practical Guide to Linux Commands, Editors and Shell Programming". It is a nice starting point. It includes

Thank you, Richard. I have found the 2nd edition of this book in PDF format. It looks great. If I find it helpful enough I'll likely purchase the 4th edition from Amazon. I noticed the section on the vim editor. I've stayed away from vim due to its learning curve. I've always considered it a neckbeard app. But a I grow older and shave less I suppose I should give it a shot.

Linux News Media released a series of articles by Marcco Floretti (forget

I did find Mr. Floretti's website and some other listings which I will certainly read as well.


Thank you for the suggestions and encouragement!

---David

This message transmitted on 100% recycled electrons.
--- SBBSecho 3.00-Win32
* Origin: The Basement Theory - Sciotoville, Ohio USA (1:226/70)

Re: A Terminal and a Manual
By: Kai Richter to hyde david on Wed Oct 16 2019 01:02 pm

tools too. I'm fighting with the change from "ifconfig" to "ip". My

I hear you there. Me as well.

The Atari 800 came with it's operating system on ROM, read only, it was static with no changes. Actual operating systems are not static that's why you should use a dynamic manual too.

Excellent point.

My main tools on the system shell are "apropos", "man", "find", "grep" and "nano". If you liked DOS and NC then there is a clone called midnight commander or short "mc" that can be installed with "apt install mc".

I have used mc for quite some time and have enjoyed it. It is one of my main tools as well when I install Linux on any system, especially my Raspberry
Pi server builds.

The thought of creating a system from scratch for a specific purpose now seems interesting to me. I think of the servers I have installed in the past that come with lots of utils and pkgs I have no need for. If I build my own server to complete only the tasks that I need. Speed and security could be greatly improved.

---David

This message transmitted on 100% recycled electrons.
--- SBBSecho 3.00-Win32
* Origin: The Basement Theory - Sciotoville, Ohio USA (1:226/70)

Hallo hyde!

This very conversation is EXACTLY why BBS were created and
reminds me that there are still awesome people in this world!

BBS? Have I stumbled into some sort of time warp to the distant past? I haven't heard about no BBS since hearing about a BBS from my grandpa just before he died.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-silvermont-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello hyde.

19 Oct 19 08:20, you wrote to Kai Richter:

My main tools on the system shell are "apropos", "man", "find",
"grep" and "nano". If you liked DOS and NC then there is a clone
called midnight commander or short "mc" that can be installed
with "apt install mc".

I have used mc for quite some time and have enjoyed it. It is one of
my main tools as well when I install Linux on any system, especially
my Raspberry Pi server builds.

There are some functionalities which I liked about mc, but if I shared shell with somebody, it was nightmare to search history and mc history to find out what he did wrong... And later, I recognized, is better to use "standard" tools
than others - simply if you want to fix system of somebody else, you can not tell him: "first you have to install mc and nano". So I stayed with tar, mv, vi
and so on - these are usualy there...

(I am using RHEL/Centos - and these rpm/yum related distros)

Karel

--- GoldED+/LNX 1.1.4.7
* Origin: Plast DATA (2:423/39)

Hello hyde!

19 Oct 19, hyde david wrote to Kai Richter:

I think of the servers I have installed in the past that come with
lots of utils and pkgs I have no need for. If I build my own server
to complete only the tasks that I need. Speed and security could be greatly improved.

I don't think so, because installed tools you don't need are placed on the storage but not active in memory or cpu. It may save some time during fscks, but greatly?

My experience is that i may need those tools sometimes in the future. If removed i've to find out why it's not working, reinstall the missing, maybe configure it, in short it needs my time. It's easier to rely on the maintainers
for the basic set of tools. For debain servers you could remove the desktop environments during installation and get a basic shell system of 300-400MB where you can install your server on top.

From scratch is a far longer journey but you'll learn many insides of the system.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hallo Kai!

a basic shell system of 300-400MB where you can install your
server on top.

I seriously doubt the above contains gcc and friends which as of gcc-9.2.0 takes up 455MB for the basic toolchain which in my humble guesstimation is the bare bones minimum to call a linux-gnu shell enviroment. Without gcc and friends the above is only a toy and doesn't even rate calling a evaluation system given the lack of development tools. Anything that cannot take care of itself isn't worth booting in the first place.

From scratch is a far longer journey but you'll learn many
insides of the system.

Which is what was asked for in the initial enquiry. I'd argue that it is a worthwhile document just for reading but if and when followed will provide one with the best possible system with whatever additional sources one adds to it.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Re: A Terminal and a Manual
By: Maurice Kinal to Kai Richter on Mon Oct 21 2019 09:18 pm

I seriously doubt the above contains gcc and friends which as of gcc-9.2.0

takes up 455MB for

the
basic toolchain which in my humble guesstimation is the bare bones minimum

to call a linux-gnu

shell enviroment. Without gcc and friends the above is only a toy and

doesn't even rate

calling a
evaluation system given the lack of development tools. Anything that

cannot take care of

itself
isn't worth booting in the first place.

Hmmm... so you do think that an operating system install that lacks a GCC compiler is, for lack of a better expression, not worth it?

I think that take is a bit extreme. Maybe you have a small computer farm and do
all your package building in a compiling cluster, then distribute your packages
from your local repository to your clients. I used to do something like that with OpenBSD. The client computers don't need to have a full GCC because you are doing the work somewhere else :)

But, hmmmm, if you are setting up for learning, and are running a single instance, then I think you actually need a good set of development tools in it. --- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hallo Richard!

so you do think that an operating system install that lacks a GCC
compiler is, for lack of a better expression, not worth it?

Yes. Also I might turn it up a notch and say that an operating system install that lacks a GCC isn't really an operating system, and hence not worth it even if it is free and required zero effort on the part of the user if indeed it will attract a user of said system in the first place.

But, hmmmm, if you are setting up for learning, and are running a
single instance, then I think you actually need a good set of
development tools in it.

I believe EVERY single instance of ALL unix enviroments are required to have a working c enviroment in order to truly be called a unix enviroment. Not only does gcc and friends count as a working c enviroment it exceeds that general idea and therefore the LFS ideology perhaps is the best document there currently is as far as linux-gnu developemt is concerned. Anything less would be a shiny example of what is wrong with a more Microsoft-ish enviroment which is what I see distributions like Debian.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello Maurice!

21 Oct 19, Maurice Kinal wrote to Kai Richter:

Hallo Kai!

a basic shell system of 300-400MB where you can install your
server on top.

I seriously doubt the above contains gcc and friends which as of
gcc-9.2.0 takes up 455MB for the basic toolchain

You are correct. That's why i said basic shell system, not basic build system.

Btw, you removed the context of my basic shell, before i wrote something like i
rely on the maintainers. They build on their machines, with their time and energy and i install the result as binary.

which in my humble guesstimation is the bare bones minimum to call a linux-gnu shell enviroment. Without gcc and friends the above is
only a toy and doesn't even rate calling a evaluation system given
the lack of development tools. Anything that cannot take care of
itself isn't worth booting in the first place.

I do not see that any system needs a dev and build environment. It is a waste of time and energy if every system is building from scratch and compiling it's software on its own. I doubt that you - if you're responsible for 100 computers
- would run a build environment on every machine and compile any software 100 times.

From scratch is a far longer journey but you'll learn many
insides of the system.

Which is what was asked for in the initial enquiry.

I do apologize if i did not understand that at first. I'm still not sure if it was a question for configuration or building.

I'd argue that it is a worthwhile document just for reading but if
and when followed will provide one with the best possible system with whatever additional sources one adds to it.

Good point. Maybe i see a question for a manual as a questions from the user point of view. I think a developer would ask for the source code because any detail is within. Finally he now have all choices.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hallo Kai!

I do not see that any system needs a dev and build environment.

More blasphemy! :::tsk, tsk:::

From this angle I can see 3 running systems that have dev and build environments, one of which I am typing this reply on. I wouldn't have it any other way.

I doubt that you - if you're responsible for 100 computers -
would run a build environment on every machine and compile any
software 100 times.

At the moment 3 is exactly enough. Also I have no need, nor the money, to have
100 computers at my disposal. The most I've had going at the same time is 4 and all had dev and build environments (gcc and friends).

I'm still not sure if it was a question for configuration or
building.

I believe it was about the best way to learn the inner workings of a commandline based linux system. The LFS document definetly contains a very good menu as to what is involved as to the basics needed for anyone to build such a system. I have found, and continue to find, it as a most valuable document to have handy. It is a keeper.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello Maurice!

27 Oct 19, Maurice Kinal wrote to Kai Richter:

I do not see that any system needs a dev and build environment.

More blasphemy! :::tsk, tsk:::

From this angle I can see 3 running systems that have dev and build environments, one of which I am typing this reply on. I wouldn't have
it any other way.

That's the great freedom of choice of open source software. Maybe it's left out
of consideration due to my translation but from my point of view we're talking about different things. You said a system without gcc is a toy. But now i see that your are talking about your computer systems only.

I was talking about servers in general. The job of a server is to provide service for specific task(s). A file server have to serve files, a web server have to deliver webpages.

I doubt that you - if you're responsible for 100 computers -
would run a build environment on every machine and compile any
software 100 times.

At the moment 3 is exactly enough. Also I have no need, nor the
money, to have 100 computers at my disposal. The most I've had going
at the same time is 4 and all had dev and build environments (gcc and friends).

That's fine but the next time please don't talk about "anything" if you're talking about "your" systems. I see and understand why "your" systems need a dev environment but that is not required for "any" existing system.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hallo Kai!

That's the great freedom of choice of open source software.

Agreed. However there is/was software that is part and parcel of every linux distribution. For me gcc is definetly one of those and has been since I first used it on Solaris based machines (Sparc stations) in the real world way back when no matter what their purpose was. Also C and Unix did grow up together way back in the late 60's when one wasn't possible without the other. I still believe that is true and there would be zero linux (bsd's too) distributions without a C compiler and gcc was there at the beginning.

I was talking about servers in general. The job of a server is to
provide service for specific task(s). A file server have to serve
files, a web server have to deliver webpages.

I have yet to see one of those in the real world, nevermind here where I am. Every Unixie machine I have ever encountered ALWAYS had a working gcc enviroment since the late 1980's and continues to be true although I only have access to the machines I currently am running. There are differences between the linux I originally ran back in the 1990's and today but gcc is still at the
heart of it all.

I see and understand why "your" systems need a dev environment
but that is not required for "any" existing system.

Understood. I could easily replicate a non dev enviroment but I'd use gcc to create it rather than rely on someone else's idea for such a crippled machine(s). Having said that I am not sure what I'd need from such a system. I am guessing it would sit in the corner collecting dust.

Bottomline is that LFS is an excellent document of how things fit together and gcc is an integral part of that which makes it an excellent learning tool.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

I believe yes, a c compiler is part of the unix specification. But linux by itself isnt unix, its unix when you add on a lot of gnu tools. There are
plenty of good use cases for an operating system with out a compiler, often
in the realm of limitation. Personally I like BSD systems due to them being complete unixes maintained and released as one piece(typing this post from FreeBSD).

Best way to learn and understand your tool set? In my opinion, dont open google, dont read an orielly book, stick to man or info and provided
handbooks- for everything. Sorta forces your brain to understand the information in the provided context.

--- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hey john!

I believe yes, a c compiler is part of the unix specification.

I am not sure about 'specification' but am certain that c and unix since day one have been welded together, sort of like the wave-particle duality in physics.

But linux by itself isnt unix, its unix when you add on a lot of
gnu tools.

gcc and glibc being the prime suspects in the above scheme. Up to this point in time they have been on my must-have list and after doing a bit of research on clang I am not convinced it will ever take gcc's place on any of the boxes I
have the pleasure working with. I believe I know why the bsd people find it attractive and have no issues with them as long as I stay away from joining them in their pursuit of that particular cause, if indeed I do have a handle on
the cause.

dont open google

Yeah they really have gone downhill and look to be getting worse as time goes on.

dont read an orielly book

I had a perl manual that wasn't too bad although the book itself fell apart at the seams. Shoddily bound for sure.

stick to man or info

I prefer info to man. Also the --help switch to many applications can be extremely helpful in a pinch.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

the reason i say "dont read an orielly book" because when you piece together the solutions yourself that orielly simplifies and extracts from others knowledge and man/info pages it sorta has the stackoverflow effect, they know how to do something but seem to not know why it does something. I mention
this for even myself - and im guilty of just finding the answer and using it rather than finding and understanding the answer and using it.

--- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hallo john!

and im guilty of just finding the answer and using it rather than
finding and understanding the answer and using it.

I understand you now. I suffer from that particular malady. so I cnnot honestly be too critical of others. However I don't author or publish such material and as a consumer I find it easier to be critical especially after shelling out the big bucks for very expensive and hard to find technical books on whatever subject, never published by orielly by the way. The perl manual I had was authored by Larry Wall who was the father of perl if I am not mistaken.
It was a long time ago and I am getting older and stupider with time. :-/

Bottomline is that I can relate to what you're saying.

Speaking of manpages, I did author a few way back in the very early 1990's for some inhouse programs running on Solaris. I was complimented for them but not so much for my communication skills but rather for my formatting talents. As for the progams the manpages were targetting I didn't have a clue how they worked since I never used them. ;-)

Strong like bull, smart like tractor.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.11(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello john!

06 Dec 19, john ford wrote to Maurice Kinal:

I believe yes, a c compiler is part of the unix specification. But
linux by itself isnt unix, its unix when you add on a lot of gnu
tools.

I tend to lol silently because that's a great logic. "Linux is unix when you add on a lot of 'GNU is not unix' tools." If i add 'not unix' tools how can make that anything unix? ;-)

Best way to learn and understand your tool set? In my opinion, dont
open google, dont read an orielly book, stick to man or info and
provided handbooks- for everything. Sorta forces your brain to
understand the information in the provided context.

I tried to do so and started with the FHS. Learning with man and info pages only is the very hard way because of the missing information to understand the context. The man pages explain how to use a switch or parameter but they do not
explain why or when this parameter is needed. E.g. if you don't know about tcp/ip concepts then you don't understand how to set a netmask or how to configure a firewall. I need to understand those concepts and i do refer to other sources to learn the missing knowledge.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

On Wed 16-Oct-2019 5:30 , Richard Falken@1:103/705.0 said to Hyde David:

The Debian team used to publish a security manual that is totally worth reading
if you can find it.

I just use google and search for iptables or debian firewall how to.
--- CNet/5
* Origin: 1:275/201.0 (1:275/201.30)