DOS vs. Linux

[Nominal Animal]

I recommend taking a look at Linux From Scratch.  It is basically an online book by Gerard Beekmans, Matthew Burgess, Bruce Dubbs, and others, for how to build a Linux system directly from sources.

You need be a Linux user in order to benefit from this book, so it seems a bit cart before horse. If that's the route to take, I would recommend cross-compiling Linux on the OS the user is comfortable with (and since we're talking DOS presumably that would be Windows). If  nothing else, it would introduce the user to where those CLI 'commands' come from and how to get them

Cart before horse? Stop twisting my words!

I wrote

Story time:

When I developed a self-replicating USB stick [...]

If that sort of thing interests you, I recommend taking a look at Linux From Scratch.

I was NOT putting a cart before a horse, and recommending someone with DOS experience to go build Linux From Scratch.
I told a personal story, about building a custom dedicated Linux OS from sources, and how basic that environment was; but if that sort of thing interests one, that book is the way to go.

I DO NOT recommend building Linux from Scratch, or going say Gentoo way, as a way to learn Linux.  It is a way to learn how to build a Linux system.

[Ed.Kloonk]

I DO NOT recommend building Linux from Scratch, or going say Gentoo way, as a way to learn Linux.  It is a way to learn how to build a Linux system.

I think that it is imperative that cranky newbie Linux users do indeed try LFS. Only then will they appreciate the work that goes in to preparing a downloadable ISO.

The double-edged sword is that there are many who think that LFS is as easy as a pre-prepared distro (until they try to do it). And when it doesn't work out for them, the whole internet needs to hear about it.

[Mechatrommer]

some people dont want to build oscilloscope, they just want to use it for other purpose. let the building of oscilloscope to the oscilloscope maker.

[Nominal Animal]

I DO NOT recommend building Linux from Scratch, or going say Gentoo way, as a way to learn Linux.  It is a way to learn how to build a Linux system.

I think that it is imperative that cranky newbie Linux users do indeed try LFS. Only then will they appreciate the work that goes in to preparing a downloadable ISO.

The double-edged sword is that there are many who think that LFS is as easy as a pre-prepared distro (until they try to do it). And when it doesn't work out for them, the whole internet needs to hear about it.

I disagree, because after all, it is just a tool, and you don't need to be aware of the effort or cost that went into the tool to wield it properly.
(Which is basically what Mechatrommer said above.)

The possible workflows differ a lot.  Some users do not need to know the OS details at all.  They might even have good grasp of Bash scripting to batch-ify repeated workflows; and that is right now quite portable between Linux, BSDs, and Mac OS; possibly even partially Windows (although I don't know if/how Bash and native Windows apps mesh).  With just a few command-line tools, say inotifywait on Linux, fswatch on Mac, you can do magical folders (that automate format conversions and other such stuff, to another folder), saving a lot of time in certain work situations.

Some users can benefit from OS customization.  For me, small things like personalized splash screens (my own one is Tux rolling his eyes in opposite directions) make it more mine.  An organization certainly benefits from their machines having some such visual details (it changes how cow-orkers treat their machines; they're more willing to consider, ask, and invent better workflows), and the sorts of customizations a capable Linux admin can do.  However, those admins rarely have done any of the work the people there do, and therefore cannot usually imagine what kind of changes would make workflows better.  So, if you have users who understand the basics enough to have suggestions, or at least identify slow/problematic parts of their workflows, they can describe them to the admins in a way the admins can actually act upon.

(Whenever I've talked about Linux to organizations, I've always first done some informal interviews, finding out exactly how people do their jobs.  Which kind of added to my depression; it is amazing how much unnecessary stuff and extra efforts people spend in their day-to-day work.  Easily makes one lose all hope for humanity, if you do it too much, really.)

In other words, I don't even think that ordinary Linux users need to be able to customize their own workflows; but I do believe they need rough understanding enough to describe the problems they are having, in a way that those with the skill (but not the experience with that particular workflow) can suggest and implement the changes.
See?  There are lots of different "depths" of knowledge, and even a rough understanding is extremely useful.  Not everyone needs to be a Linux admin, but everyone should have enough understanding to be able to describe their problems in a manner that can be acted upon.

[rstofer]

some people dont want to build oscilloscope, they just want to use it for other purpose. let the building of oscilloscope to the oscilloscope maker.

That is exactly the case for most users.  I use Mint, I don't care how it is cooked, I just want a bootable ISO image file and reasonable setup instructions.  Me and Google, that's all it takes.  Google will be the most used tool for new Linux users.

[rstofer]

apropos ...

It  does no good to sit at the command line, staring at the screen, while having no idea what to type.  Say you want a list of USB devices

Code: [Select]

$ apropos usb
[/font]

gives

Code: [Select]

~ $ apropos usb
lsusb (8)            - list USB devices
sane-canon630u (5)   - SANE backend for the Canon 630u USB flat...
sane-cardscan (5)    - SANE backend for Corex CardScan usb scan...
sane-epjitsu (5)     - SANE backend for Epson-based Fujitsu USB...
sane-find-scanner (1) - find SCSI and USB scanners and their de...
sane-genesys (5)     - SANE backend for GL646, GL841, GL843, GL...
sane-gt68xx (5)      - SANE backend for GT-68XX based USB flatb...
sane-kvs1025 (5)     - SANE backend for Panasonic KV-S102xC USB...
sane-kvs20xx (5)     - SANE backend for Panasonic KV-S20xxC USB...
sane-kvs40xx (5)     - SANE backend for Panasonic KV-S40xxC USB...
sane-ma1509 (5)      - SANE backend for Mustek BearPaw 1200F US...
sane-mustek_usb (5)  - SANE backend for Mustek USB flatbed scan...
sane-mustek_usb2 (5) - SANE backend for SQ113 based USB flatbed...
sane-pieusb (5)      - SANE backend for USB-connected PIE Power...
sane-plustek (5)     - SANE backend for LM983[1/2/3] based USB ...
sane-sm3600 (5)      - SANE backend for Microtek scanners with ...
sane-sm3840 (5)      - SANE backend for Microtek scanners with ...
sane-u12 (5)         - SANE backend for Plustek USB flatbed sca...
sane-usb (5)         - USB configuration tips for SANE
usb-devices (1)      - print USB device details
usb_modeswitch (1)   - control the mode of 'multi-state' USB de...
usb_modeswitch_dispatcher (1) - Linux wrapper for usb_modeswitc...
usbhid-dump (8)      - dump USB HID device report descriptors a...
[/font]

The items of interest at the command line are tagged (1) for ordinary users and [8] for super users.  How do I know that?

https://linux.die.net/man/

Sorry about the square brackets, parenthesis 8 seems to include an icon

Here's the output of 'lsusb' on my Pi 400

Code: [Select]

~ $ sudo lsusb
Bus 002 Device 009: ID 0781:5581 SanDisk Corp. Ultra
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 04d9:0007 Holtek Semiconductor, Inc.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[/font]

You can see that it has recognized my SanDisk thumb drive

Want to know a bit about Python?

Code: [Select]

~ $ apropos python
[/font]

One of the entries is 'thonny', an IDE for Python  It also shows up in the Programming menu but I have never tried it.

Code: [Select]

thonny (1)           - Python IDE for beginners
[/font]

[PlainName]

The items of interest at the command line are tagged (1) for ordinary users and [8] for super users.  How do I know that?

https://linux.die.net/man/

So we have a new user who is trying to find his way around, and the command you go for is the only one marked 'superuser' rather than the one marked 'you, yes you, the new ordinary user'?

[PlainName]

Fuck you, you quoted me off context, twisting my words!

You're welcome.

It's always difficult trimming walls of text to highlight just the relevant part. What may seem relevant to me at that time perhaps won't to you coming back to it with a different mindset.  Don't forget that this thread is in the context of a new user, not a guru wanting to check the nuts and bolts.

Any twisting was unintentional, but I accept that what I was seeing may not have been what you intended to be seen or still think it looks like.

Er... I guess this could go downhill so better add the wall for reference too. Please don't take me on for top-posting!

I recommend taking a look at Linux From Scratch.  It is basically an online book by Gerard Beekmans, Matthew Burgess, Bruce Dubbs, and others, for how to build a Linux system directly from sources.

You need be a Linux user in order to benefit from this book, so it seems a bit cart before horse. If that's the route to take, I would recommend cross-compiling Linux on the OS the user is comfortable with (and since we're talking DOS presumably that would be Windows). If  nothing else, it would introduce the user to where those CLI 'commands' come from and how to get them

Cart before horse? Fuck you, you quoted me off context, twisting my words!

I wrote

Story time:

When I developed a self-replicating USB stick [...]

If that sort of thing interests you, I recommend taking a look at Linux From Scratch.

I was NOT putting a cart before a horse, and recommending someone with DOS experience to go build Linux From Scratch.
I told a personal story, about building a custom dedicated Linux OS from sources, and how basic that environment was; but if that sort of thing interests one, that book is the way to go.

I DO NOT recommend building Linux from Scratch, or going say Gentoo way, as a way to learn Linux.  It is a way to learn how to build a Linux system.

[rstofer]

The items of interest at the command line are tagged (1) for ordinary users and [8] for super users.  How do I know that?

https://linux.die.net/man/

So we have a new user who is trying to find his way around, and the command you go for is the only one marked 'superuser' rather than the one marked 'you, yes you, the new ordinary user'?

In the default Pi environment, the user 'pi' is automatically a superuser.  Totally insecure but that's the way it works.  'sudo' doesn't even require a password!

I'm running as an ordinary user on the Pi and lsusb works because it, and all the other ls... commands in /usr/bin have permissions 755.  The apropos entry is incorrect.

Same story in Mint - all ls... commands have permissions = 755

A new user won't spend 5 minutes configuring Linux from the command line without running into 'sudo' and the requirement for the user to be in the 'sudo' group.  Unfortunately, using 'addgroup' requires superuser permissions and this is the reason that, in the RPi world, the default user is automatically a superuser.

In the Mint world, you need to log in as 'root' to add the first user to the sudo group.

And this is why Linux is on less than 2% of workstations.  The learning curve is STEEP!

[Nominal Animal]

Don't use linux.die.net for man pages, use the proper upstream, https://www.kernel.org/doc/man-pages/ (for the directory), or direct links to https://man7.org/linux/man-pages/.

Section 8 is for "administration and privileged commands".  It includes commands that work for all users (lsusb, lspci, and lsof being commonly used by all users).  Just because a command is described in section 8, does not mean it is only available to superuser.

[PlainName]

all ls... commands have permissions = 755

OK. It is easy to conflate the semantic differences when talking about user abilities. Is a superuser someone who knows what they are doing - a guru, perhaps - or someone with a technical attribute (here, a security clearance)? The context of this thread, which concerns a user not well versed in the art of Linux, has a bearing on it.

[Nominal Animal]

Don't forget that this thread is in the context of a new user, not a guru wanting to check the nuts and bolts.

I think that "If that sort of thing interests you, then ..." is quite a limited recommendation, because the sort of thing that was described was obviously quite a lot of work that not many Linux users would be interested in.  Changes the meaning of the entire sentence.

Any twisting was unintentional, [...]

In that case, I need to use less angry language.  (Edited that post to reflect that.)

[Nominal Animal]

Is a superuser someone who knows what they are doing - a guru, perhaps - or someone with a technical attribute (here, a security clearance)?

Superuser is (a user controlling) a process that has full root privileges; one whose actions the Linux kernel will not restrict.

There are two ways to have those:

• Have UID 0.  This is the traditional root, and the default target user when using sudo.
  or
• Have all relevant Linux capabilities, regardless of the UID of the current process.

Linux capabilities are usually granted to a process by setting filesystem capability flags.  (This itself requires either UID 0, or the CAP_SETFCAP capability.) See man 8 setcap for the utility for doing this.
For example, if you want a binary program foo to be able to switch to root user, but don't want to make it setuid root, give it the CAP_SETUID and CAP_SETGID capabilities via setcap cap_setuid,cap_setgid=pe foo .
Linux capabilities can also be inherited from the parent process, but it requires the capabilities to be inheritable (i in the mask set; p is permitted and e is effective).
The capabilities a process can obtain from filesystem capability flags can also be restricted (this is called the bounding set), as the bounding set is inherited from the parent process.  Once dropped from the bounding set, that capability is impossible to regain by the current process or by any child processes.

(There is also secure execution filters; see man 2 seccomp, that can be used to limit the current process and any child processes to a subset of syscalls or syscall parameters.  It is useful when one wants to run e.g. untrusted code without allowing any access to syscalls, or only to a subset of "deemed safe" syscalls like read/recv/pread, write/send/pwrite, clock_gettime() and so on.  But this is completely separate from Linux capabilities, and is basically a filtering mechanism applied by the kernel at the userspace-kernel boundary.)

I don't like using "root" to indicate the technical can-do-anything-user-account, as there is that other option, Linux capabilities, that is completely separate.

But whenever I use "superuser", I mean it in the technical sense: (user running) a process that the Linux kernel allows to do anything.

[brucehoult]

'sudo' doesn't even require a password!

That's not really a big problem. It still means you have to think and type something extra before the really dangerous actions.

On a personal system, someone finding your screen unlocked and typing "rm -rf ~" or "sudo rm -rf /" makes little practical difference to you.

[Ed.Kloonk]

'sudo' doesn't even require a password!

That's not really a big problem. It still means you have to think and type something extra before the really dangerous actions.

On a personal system, someone finding your screen unlocked and typing "rm -rf ~" or "sudo rm -rf /" makes little practical difference to you.

That's the best way I know how to completely fsck a Linux system.

[brucehoult]

'sudo' doesn't even require a password!

That's not really a big problem. It still means you have to think and type something extra before the really dangerous actions.

On a personal system, someone finding your screen unlocked and typing "rm -rf ~" or "sudo rm -rf /" makes little practical difference to you.

That's the best way I know how to completely fsck a Linux system.

I expect sudo dd if=/dev/null of=/ bs=1M would work about as well.

[rstofer]

Late in the book "Raspberry Pi For Secret Agents" there is an example of  a script that wipes the user's home directory if there were 3 failed attempts at logging in.  It also creates a new, empty, home directory.

Not to worry, the script follows the part in the book where they show how to encrypt the home directory such that low level scans don't produce useful information.

https://www.amazon.com/Raspberry-Pi-Secret-Agents-Third-ebook/dp/B01HF2HS7S

Somehow it wound up in my Kindle directory so I must have clicked on something.  I'm pretty sure I wound up paying for it...

[Monkeh]

all ls... commands have permissions = 755

OK. It is easy to conflate the semantic differences when talking about user abilities. Is a superuser someone who knows what they are doing - a guru, perhaps - or someone with a technical attribute (here, a security clearance)? The context of this thread, which concerns a user not well versed in the art of Linux, has a bearing on it.

'superuser' has nothing to do with it anyway. The definition of section 1 is "general commands", and 8 "system administration commands" - listing USB devices is not 'general' and does indeed belong in section 8.

[PlainName]

Thanks for the clarification.

[bpiphany]

I expect sudo dd if=/dev/null of=/ bs=1M would work about as well.

I often have to correct myself too, but that doesn't do anything. You meant
dd if=/dev/zero of=/
add
status=progress
to see exactly how much damage you manage to cause.

Another fun thing to do is
kill 1
which fails (since you really meant %1), and you follow up with
sudo !!


edit: it actually looks like
dd if=/dev/zero of=/
doesn't do anything either. Without trying it as root '/' is not a file and cannot be written to this way.

[DiTBho]

Code: [Select]

highlander# uptime
 09:15 up 11 years

highlander# whoami
root

highlander# last | head -n1
root     tty1                          Thu Dec 03 2009 - 20:19

highlander# last | grep `mydate-today`
root     pts/0        192.168.1.14     Thu Dec 03 2020 - 09:15

Well, I have been using my Linux console as root for *exactly* 11 years
and anything catastrophic hasn't yet happened

what am I doing wrong?

[DiTBho]

Code: [Select]

highlander# sudo
not found in the current path

highlander# su
not found in the current path


[Ed.Kloonk]

Code: [Select]

highlander# uptime
 09:15 up 11 years

highlander# whoami
root

highlander# last | head -n1
root     tty1                          Thu Dec 03 2009 - 20:19

highlander# last | grep `mydate-today`
root     pts/0        192.168.1.14     Thu Dec 03 2020 - 09:15

Well, I have been using my Linux console as root for *exactly* 11 years
and anything catastrophic hasn't yet happened

what am I doing wrong?

That's a lot more than five nines there. Amazeballs.

[DiTBho]

Guys, if you are worried about that, I would suggest to exercise on a LiveCD-demo so you can't cause any permanent issues since it's a read-only media with the rootfs copied from the CD into into the ram at every boot.

11 years ago, I preferred to practice this way for a couple of months (on Minix) in order to understand things and how to manage stress rather than hiding the fear of causing some damage behind a "sudo" command, which was not even installed.

[golden_labels]

Guys, if you are worried about that, I would suggest to exercise on a LiveCD-demo so you can't cause any permanent issues since it's a read-only media with the rootfs copied from the CD into into the ram at every boot.

One should not forget that the local media are still available and their content can be destroyed. A virtual machine is the safest option. With the added benefits of being able to act as root and damage everything without consequences. Damging things is good, just like in electronics.

11 years ago, I preferred to practice this way for a couple of months (on Minix) in order to understand things and how to manage stress rather than hiding the fear of causing some damage behind a "sudo" command, which was not even installed.

And here the important note: sudo exists to limit risk. Unlike logging in as root, with sudo one has control over what, how and by whom can be invoked.