This is the kind of link I like to see on HN because the content is not pre-chewed clickbait -- you have to do a bit of work to figure out the context, and that makes you think harder about what's being said.
This is the kind of link that makes me scratch my head when I see it on HN, because my preconceived notion of "hacker" includes "understands operating systems", in which case this knowledge is old hat (as he acknowledges). If you don't already know OS minutia, nothing written here is going to shed much insight.
How much do you know about web-dev technologies? Big data techniques? Java vs C vs Go vs Rust?
There's miles of abstraction between OS minutia and literally any other part of modern computing. There's miles of abstraction between different parts of the Linux kernel for that matter.
The point being made here is a very valid one too: its oft-forgotten, with the rise of Docker, that processes are a form of virtualization, they just have/had poor isolation between each other. Also worth while if you're wondering about whether bare-metal hypervisors are better vs something like KVM which runs VMs as processes.
I find it difficult to believe that the rise of Docker (which is a tool for easily separating processes) isn't inversely releated with people forgetting this!
It is a valid point, but it's presented here in the wrong packaging.
I flagged it for exactly that reason. File descriptors 0, 1, and 2 have a per-process meaning -- stdin/stdout/stderr -- and one only needs a cursory knowledge of C or operating systems to know that Linux has a per-process table.
The post in question is a succinct explanation of the Unix process model. It's nothing new (obviously!), but trust me, a lot of people have either forgotten the specifics or never really learned them. I certainly appreciated the quick refresher.
Honestly I feel you're abusing HN's flag feature if you regularly use it on links like this one.
It's not the content of the link but the title. nazri1 chose the title "File descriptor table isn't ..." based on the first line of the response.
But that knowledge is introductory material, rather like saying that "function calls use a stack" or "ASCII is a character encoding" or "Javascript expressions use operator precedence". (If I had a list of links I've flagged I could give some real examples.)
The guidelines suggest 'please use the original title, unless it is misleading or linkbait'. The original title is indeed misleading. But so is this title. Did you find the article interesting because you thought the file descriptor table in Linux is global?
I originally went to the page, went to the where the question was asked, saw that the person didn't known even the basics, so understood why the page was structured as a tutorial type response. I figured that the HN submitter was equally inexperienced, so gave a poor title on the assumption that most HN readers would also be surprised to know that the file descriptor table in Unix not global. Which makes no sense, and isn't the type of title I think is relevant, so the guidelines suggest to flag and move on. And yes, submitters sometimes do exactly that.
Yes, I could have researched it even further to suggest that "how the unix process model works" might be a better title. But how much responsibility is there on me to infer that submitter's intent is different than that suggested by the title? If it helps any, I have unflagged the link.
BTW, I also flag linkbait titles without even reading the content to see if it's actually interesting or relevant to HN.
I am not a beginner, but I felt it was worth reading the email for the reminder of the perspective that processes themselves are a form of virtualization. I've known about kernels and threads and process isolation for so long that it has become a sort of "atomic" notion in my mind, and it was nice to get a reminder that the current direction of virtualization is an extension of the past.
This is the kind of article that makes me scratch
my head when I see it in the New England Journal of
Medicine, because my preconceived notion of "doctor"
includes "can perform thoracic surgery", in which case
this knowledge is old hat (as he acknowledges). If you
don't already know how to perform a heart bypass,
nothing written here is going to shed much insight.
There are lots of hackers with deep, deep knowledge in other areas of "hacking" that are miles away from Unix file descriptors and so forth. A lot of "true hacking" doesn't even involve Unix, just like a lot of talented medical doctors aren't qualified to perform a heart bypass.
How about the crazy geniuses that made the first wire-wrapped Amiga prototypes? Or the heroic coders who pulled off various feats of assembly language coding on the incredibly constrained hardware in various game consoles? Or the people who write web frameworks. Or the people who build robots, or the people who built the chips that Unix runs on?
Word "hacker" has become very vague lately, but the definition used 10 years ago, did not include "people who build robots, or the people who built the chips that Unix runs on". Those were called Electric Engineers AFAIR. "Hacker" literally meant a guy involved with cybersecurity and therefore deeply into OS internals. Then the word went through transformation and today may easily mean "an Arduino hacker who made an automated bird feeder", "a RoR hacker who made a homepage with it etc.".
I believe your view of the definition 10 years ago is the incorrect one. Paraphrasing he Djikstra (misatributed quote) [1] hacking is no more about computer security hacking than astronomy is about telescopes.
AS can be seen in the Jargon File ("a collection of slang terms used by various subcultures of computer hackers" [2]) the definition for hacker "seems to have been first adopted as a badge in the 1960s" and "it was used in a sense close to this entry's by teenage radio hams and electronics tinkerers in the mid-1950s." [3]
In the past years hacking (thanks to the connotation given by the mass media) became synonymous with "miscelaneous computer mischief, sometimes malicious and often related to computer network security" but that's a very recent phenomenon.
Even that definition is not all encompassing, more of a guide if anything. To be true, the definition of "hacker" is not something system-wide - it belongs to a process...
15 comments
[ 3.2 ms ] story [ 46.3 ms ] threadThere's miles of abstraction between OS minutia and literally any other part of modern computing. There's miles of abstraction between different parts of the Linux kernel for that matter.
The point being made here is a very valid one too: its oft-forgotten, with the rise of Docker, that processes are a form of virtualization, they just have/had poor isolation between each other. Also worth while if you're wondering about whether bare-metal hypervisors are better vs something like KVM which runs VMs as processes.
It is a valid point, but it's presented here in the wrong packaging.
The post in question is a succinct explanation of the Unix process model. It's nothing new (obviously!), but trust me, a lot of people have either forgotten the specifics or never really learned them. I certainly appreciated the quick refresher.
Honestly I feel you're abusing HN's flag feature if you regularly use it on links like this one.
But that knowledge is introductory material, rather like saying that "function calls use a stack" or "ASCII is a character encoding" or "Javascript expressions use operator precedence". (If I had a list of links I've flagged I could give some real examples.)
The guidelines suggest 'please use the original title, unless it is misleading or linkbait'. The original title is indeed misleading. But so is this title. Did you find the article interesting because you thought the file descriptor table in Linux is global?
I originally went to the page, went to the where the question was asked, saw that the person didn't known even the basics, so understood why the page was structured as a tutorial type response. I figured that the HN submitter was equally inexperienced, so gave a poor title on the assumption that most HN readers would also be surprised to know that the file descriptor table in Unix not global. Which makes no sense, and isn't the type of title I think is relevant, so the guidelines suggest to flag and move on. And yes, submitters sometimes do exactly that.
Yes, I could have researched it even further to suggest that "how the unix process model works" might be a better title. But how much responsibility is there on me to infer that submitter's intent is different than that suggested by the title? If it helps any, I have unflagged the link.
BTW, I also flag linkbait titles without even reading the content to see if it's actually interesting or relevant to HN.
How about the crazy geniuses that made the first wire-wrapped Amiga prototypes? Or the heroic coders who pulled off various feats of assembly language coding on the incredibly constrained hardware in various game consoles? Or the people who write web frameworks. Or the people who build robots, or the people who built the chips that Unix runs on?
AS can be seen in the Jargon File ("a collection of slang terms used by various subcultures of computer hackers" [2]) the definition for hacker "seems to have been first adopted as a badge in the 1960s" and "it was used in a sense close to this entry's by teenage radio hams and electronics tinkerers in the mid-1950s." [3]
In the past years hacking (thanks to the connotation given by the mass media) became synonymous with "miscelaneous computer mischief, sometimes malicious and often related to computer network security" but that's a very recent phenomenon.
[1] https://en.wikiquote.org/wiki/Computer_science#Disputed
[2] http://www.catb.org/jargon/html/introduction.html
[3] http://www.catb.org/jargon/html/H/hacker.html
http://www.catb.org/jargon/html/H/hacker.html
Even that definition is not all encompassing, more of a guide if anything. To be true, the definition of "hacker" is not something system-wide - it belongs to a process...