10 ms·

A few drawings about Linux

187 points by josephscott 10y ago

dri_ft 10y ago
I thought I knew a thing or two about linux, but I had no idea about /proc. Neat!
partycoder 10y ago
Note that hard disks are not aware of files. Files are a file system construct. Your disk is like... music disks. You seek to a position, read... and when you read the position advances.
omribahumi 10y ago
Another signal that can't be caught is SIGSTOP
vkou 10y ago
The file/syscall abstraction breaks down when we want to do something as simple as copy and pasting from a spreadsheet to a text editor. This is not a slide that should be surrounded by happy people!
- lisivka 10y ago
  I opened LibreOffice Calc and pasted spreadsheet it into Writer window without a problem. :-/ I even able to edit it.
  - digi_owl 10y ago
    He is likely talking about the amount of wrangling of memory ranges and whatsnot that needs to be done to turn the source data into something that can be understood by the destination.
  - mwfunk 10y ago
    Well sure, I would hope so- if copying and pasting from one LibreOffice application to another didn't work that would be an even worse state of affairs.
    - lisivka 10y ago
      Yep, pasting from Google spreadsheet into Notepad does not work. Hope is lost. :-(
- slrz 10y ago
  It doesn't have to. A text editor could easily present its current buffer and other properties in the form of a file system interface. See e.g. how Linux allows to interact with processes through the /proc file system. There's no reason to restrict this to kernel objects. FUSE also allows user processes to implement a file system but it's clunky as it breaks a lot of old assumptions. See the Plan 9 operating system for an earlier clean implementation of this concept, including programmatic interaction with your text editor through file APIs.
  - wahern 10y ago
    More specifically, Plan 9 devised the plumber framework for copy+paste and similar IPC. https://en.wikipedia.org/wiki/Plumber_(program) https://en.wikipedia.org/wiki/Plumber_(program) http://www.mostlymaths.net/2013/04/just-as-mario-using-plan9-plumber.html http://www.mostlymaths.net/2013/04/just-as-mario-using-plan9...
_RPM 10y ago
Comparing Windows to Linux. I find Linux much more simpler. Is this by design? Why does Windows seem much more complicated and complex? Compare the Windows API to Linux API.
- amyjess 10y ago
  One thing to keep in mind is that the "everything is a file" paradigm breaks down with newer hardware. For example, you can't use the file metaphor to eject a CD. To get around this, we have the ioctl subsystem, which adds a whole lot of complexity. Modern I/O programming involves heavy use of ioctl and thus isn't nearly as simple as those drawings suggest. Per Wikipedia, "A kernel that provides several hundred system calls may provide several thousand ioctl calls." https://en.wikipedia.org/wiki/Ioctl https://en.wikipedia.org/wiki/Ioctl
  - wahern 10y ago
    FILE *fh = fopen("/dev/cd/do", "w"); fputs("eject\n", fh); AFAIU, people use ioctl because it's a more strongly typed interface compared to juggling strings (usually the implementation defines the interface via /usr/include headers, useful from C), and because historically implementing an ioctl interface for a new device was easier in kernel implementations, including early Linux (and arguably still).
- jcheng 10y ago
  I've probably spent 2% or less of my programming career coding directly against Win32 and POSIX APIs, so I'm not the best person to be answering, but I find the other replies miss an important point. Linux developers look at the Win32 API and think it's too complex. But Win32 developers might look at Linux (or any POSIX) and think it just pushes the complexity out into user code. Someone in this thread brought up process creation (fork/exec vs. CreateProcess). fork/exec is simple, but there are a lot of pitfalls you have to be aware of. If you don't care about the result of the process, too bad, you still have to set up a SIGCHLD handler to waitpid or whatever or else you'll end up with a zombie process--which you probably won't notice, but your customers eventually will, at the most inconvenient moment. Or if your process is running as root and you want to launch a child process as a different user, you have to do this VERY carefully (calling setsid, setgid, setgroups in exactly the right order--oh and I almost forget about seteuid and setresuid, setegid and setresgid). Or take a look at writing to a socket; the individual APIs involved are all very simple but you have to know to ignore SIGPIPE or else your process will terminate if the connection is broken while you're writing. Bottom line is that when I write against Windows I spend more time reading docs, and when I write against POSIX I spend more time googling and debugging.
nichochar 10y ago
These are amazing! So descriptive and easy to remember, I love learning stuff this way, thanks for making them!

187 points by josephscott 10y ago

I thought I knew a thing or two about linux, but I had no idea about /proc. Neat!

Note that hard disks are not aware of files. Files are a file system construct. Your disk is like... music disks. You seek to a position, read... and when you read the position advances.

omribahumi 10y ago

Another signal that can't be caught is SIGSTOP

vkou 10y ago

The file/syscall abstraction breaks down when we want to do something as simple as copy and pasting from a spreadsheet to a text editor. This is not a slide that should be surrounded by happy people!

lisivka 10y ago
I opened LibreOffice Calc and pasted spreadsheet it into Writer window without a problem. :-/ I even able to edit it.
- digi_owl 10y ago
  He is likely talking about the amount of wrangling of memory ranges and whatsnot that needs to be done to turn the source data into something that can be understood by the destination.
- mwfunk 10y ago
  Well sure, I would hope so- if copying and pasting from one LibreOffice application to another didn't work that would be an even worse state of affairs.
  - lisivka 10y ago
    Yep, pasting from Google spreadsheet into Notepad does not work. Hope is lost. :-(
slrz 10y ago
It doesn't have to. A text editor could easily present its current buffer and other properties in the form of a file system interface. See e.g. how Linux allows to interact with processes through the /proc file system. There's no reason to restrict this to kernel objects. FUSE also allows user processes to implement a file system but it's clunky as it breaks a lot of old assumptions. See the Plan 9 operating system for an earlier clean implementation of this concept, including programmatic interaction with your text editor through file APIs.
- wahern 10y ago
  More specifically, Plan 9 devised the plumber framework for copy+paste and similar IPC. https://en.wikipedia.org/wiki/Plumber_(program) https://en.wikipedia.org/wiki/Plumber_(program) http://www.mostlymaths.net/2013/04/just-as-mario-using-plan9-plumber.html http://www.mostlymaths.net/2013/04/just-as-mario-using-plan9...

_RPM 10y ago

Comparing Windows to Linux. I find Linux much more simpler. Is this by design? Why does Windows seem much more complicated and complex? Compare the Windows API to Linux API.

amyjess 10y ago
One thing to keep in mind is that the "everything is a file" paradigm breaks down with newer hardware. For example, you can't use the file metaphor to eject a CD. To get around this, we have the ioctl subsystem, which adds a whole lot of complexity. Modern I/O programming involves heavy use of ioctl and thus isn't nearly as simple as those drawings suggest. Per Wikipedia, "A kernel that provides several hundred system calls may provide several thousand ioctl calls." https://en.wikipedia.org/wiki/Ioctl https://en.wikipedia.org/wiki/Ioctl
- wahern 10y ago
  FILE *fh = fopen("/dev/cd/do", "w"); fputs("eject\n", fh); AFAIU, people use ioctl because it's a more strongly typed interface compared to juggling strings (usually the implementation defines the interface via /usr/include headers, useful from C), and because historically implementing an ioctl interface for a new device was easier in kernel implementations, including early Linux (and arguably still).
jcheng 10y ago
I've probably spent 2% or less of my programming career coding directly against Win32 and POSIX APIs, so I'm not the best person to be answering, but I find the other replies miss an important point. Linux developers look at the Win32 API and think it's too complex. But Win32 developers might look at Linux (or any POSIX) and think it just pushes the complexity out into user code. Someone in this thread brought up process creation (fork/exec vs. CreateProcess). fork/exec is simple, but there are a lot of pitfalls you have to be aware of. If you don't care about the result of the process, too bad, you still have to set up a SIGCHLD handler to waitpid or whatever or else you'll end up with a zombie process--which you probably won't notice, but your customers eventually will, at the most inconvenient moment. Or if your process is running as root and you want to launch a child process as a different user, you have to do this VERY carefully (calling setsid, setgid, setgroups in exactly the right order--oh and I almost forget about seteuid and setresuid, setegid and setresgid). Or take a look at writing to a socket; the individual APIs involved are all very simple but you have to know to ignore SIGPIPE or else your process will terminate if the connection is broken while you're writing. Bottom line is that when I write against Windows I spend more time reading docs, and when I write against POSIX I spend more time googling and debugging.

nichochar 10y ago

These are amazing! So descriptive and easy to remember, I love learning stuff this way, thanks for making them!