There are job ads with "bare metal" in them.

I still don't get how I can "accidentally" type "rm -rf /" and assemle it.

What do you mean?

It's the "skinned, but still living body" part that got me.

"Bare metal" stands for SW which works on HW without any OS yet.

OS is the metaphorical skin. And/or rather user mode is skin on. The skin can be put both on and off - in kernel mode it's with the skin off.

But you accidentally can remove files. And the point is that standard "C" library ('glibc' in Linux) "belongs" to "C"; in assembly it would be logical to use system calls. So, you make a mistake in a system call and delete a file instead of reading from it.

Even if I would be doing file operations, wouldn't I be doing them on test files I specially made?

And it's the shell, not glibc, that processes wildcards.

The point is that you may accidentally delete a file.

You're close to convincing me that the next time I experiment trying to learn bash scripting I should be in a different account containing nothing else of value.

But I don't think anyone is convincing anyone either way about the merits of that level of paranoia for learning asm.

Not knowing the language still only makes it easy to do by accident things that are fairly easy to do.

Very destructive programs are easy to write by accident in bash, but hard to write by accident in asm. Even if you know near zero asm and are blindly changing tutorials you don't understand and even if you're fairly competent in bash, you experiments in asm are still less likely to do serious harm than your experiments in bash.

BTW, I loved the metaphor:
But it ought to say "programming in assembly without an OS"

Programming in assembly without an OS is a more obscure skill than programming in assembly with an OS. I think there is plenty of justification for learning asm with OS, but never learning asm without OS. Even if you want to learn asm without OS, it is best to get some solid skills in asm with OS first. So despite the fun metaphor, I think that whole subject area is outside the focus of this thread.

You probably will accidentally delete a file.

At least once (long ago) while testing C programs I was writing, I accidentally deleted a file. More than once while trying to correct someone else's bad Python programs. More than once while experimenting with bash. And despite my incredible asm skills, at least once (very long ago) while learning to do file I/O in asm, I accidentally deleted a file.

I wouldn't do such experiments even in the directory where I have important files. When I'm at all uncertain of file I/O operations, I generally avoid even working with file names similar to important files elsewhere.

Since I tend to multi task with a lot of open windows, experimenting in a different directory from real work is natural. Experimenting in a different login from real work is a significant step less convenient and I generally wouldn't do it.

Agreed.

This is the way I initially tested Skype for Linux - a closed source app, who knows what it is doing

In my professional life programming in assembly without an OS was a must, i.e. a job duty. I.e. I do not see too much sense in learning an assembly nowadays unless ultimately it will be used for programming without an OS.

Well, but if someone is going to write a full fledged compiler, it's another story.

Why not start simple with an OS then maybe move on to without an OS?

But this will complete the sweet procrastination, won't it ?

Even if you will never write a useful line of asm code, learning to code in asm with an OS, is a valuable skill that will improve the quality of your programming in languages like C++ as well as your skill at debugging.

Learning to code in asm without an OS would mostly be useful if you intend someday to write or significantly modify an OS. (I myself have done so, but don't expect to do so again).

Coding and debugging C++ is a more commonly useful skill than modifying an OS. So asm with an OS is more relevant knowledge than asm without an OS.

1 members found this post helpful.

Not at all. I am from HW world, so, say, when a chip with CPU inside needs to be simulated using an HDL, someone has to provide the model with code which works from reset on. And at least reset and exception handling routines were written in assembly.

Likewise, when the chip is taped out, it needs to be tested - no OS at all is present. So reset and IRSs are written in assembly, and the rest in "C".

In HW world there is a term "bring up" - it the place for assembly.