6 ms·

> This meme is a silly amateur-hour wheel re-invention and ignorance of history. Just a note on the tone of the discussion: Everyone is a silly amateur at one

by catzaa 17y ago

> This meme is a silly amateur-hour wheel re-invention and ignorance of history. Just a note on the tone of the discussion: Everyone is a silly amateur at one stage when learning something – there is nothing wrong with it. You have to do things that are silly and immature to learn. Most of us did some silly things in areas where we are not yet specialists.

antonovka 17y ago
I think it's a responsibility of everyone in any scientific or engineering field -- specialists and "not-yet-specialists" alike -- to think long and hard about advocating an approach without studying the large body of academic and practical work that exists for nearly every subject imaginable.
- dschobel 17y ago
  And with one deft stroke you've just eliminated 98% of the CS-related content on the internet. Bravo!
- catzaa 17y ago
  That is true in some sense. Yet, on the other hand, the first versions of Linux were written without consulting the extensive literature (which was all about microkernels) [1]. As another example – a guy studying with me made his own circuit boards (had his own acid production line project going on in his dorm room). You would never use such a circuit board in any professional setting. Yet he learned a lot about other stuff with his electronics projects. Sometimes the goal of learning isn’t really implementing something directly. As an example, a recursive function isn’t really the best way to calculate Fibonacci numbers. If someone wants to learn about forking by writing a simple web-server thingy then it may be a good idea? Most of these projects were probably done in their free time. Who would be the better programmer – the guy that wrote this, or the guy that knocked back a beer and sat in front of the TV? [1] I am not an operating system expert, but this is at least the impression I got after reading the flame-wars email.
  - antonovka 17y ago
    Yet, on the other hand, the first versions of Linux were written without consulting the extensive literature (which was all about microkernels) [1]. In the early 90s nearly all of the operating system research was going into Microkernels, but there was already 30+ years of standing research to borrow from (and Linux very much did -- the fact that it's similar enough to run the same software as Solaris and BSD systems is not due to spontaneous re-invention). Despite the fact that Linux and the BSDs did not adopt the microkernel architecture -- and pure microkernels, for most purposes, died out -- quite a bit of value did come from that research, such as the Mach VM system, which was then borrowed by 4.4BSD operating systems and others. Most of these projects were probably done in their free time. Who would be the better programmer – the guy that wrote this, or the guy that knocked back a beer and sat in front of the TV? Rather than taking an incredibly assertive but misguided blog post at face value (and propagating it further), what is wrong about reading the widely available, easily discovered literature and implementing an event-based/event+thread-based implementation instead?
    - Scriptor 17y ago
      What's a good first step to finding this literature?
      - antonovka 17y ago
        In this case -- start by picking something you know to scale well, and find out how it does it. For instance, if you're familiar with nginx through web development, you'd find this on the nginx web page: "Architecture and scalability:" * kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), event ports (Solaris 10), select, and poll support; Once you've narrowed your search, start looking for well-respected books on the subject -- there's a long list of them in the thread below.
    - paulsmith 17y ago
      You've spent a lot of effort commenting on this post, and I think you've missed the point entirely. In Jacob's and Ryan's originals, the point wasn't to assert that preforking is the right way to structure a server -- that's not really the salient issue. (And I'd suspect that these two -- serious Web devs who are familiar with deployment -- probably are well familiar with {epoll, select, kqueue}-based and similar non-blocking, concurrent I/O servers.) The point was that, as Rubyists and Pythonistas and Perl hoo-has, we shouldn't be afraid to delve into POSIX syscalls and take advantage of the wealth of functionality they provide, and that our languages have thin wrappers over those bare syscalls that make it easy to write idiomatic code that utilizes them. The examples were echo servers, for murphy's sake -- are you really worried that we'd have a rash of poorly-thought-through, inefficient echo servers bogging down poor servers across the Internet? They're clearly intended to be simple examples about syscalls not the (yes! very important!) issue of how to handle concurrent connections efficiently.
- petercooper 17y ago
  Disagreed - it's the responsibility of those who are professionally or academically publishing such materials, not "everyone." It's also important for readers to consider their sources and realize that personal blogs are hardly to be taken at face value. Publishing things that are imperfect or incorrect is essential in order to get feedback and to improve. If it were necessary to do significant study before making a blog post or a similarly ephemeral statement, hardly anyone would bother and the field would be dead for lack of newcomers.
  - antonovka 17y ago
    Publishing on a blog is still publishing, not a short-lived ephemeral aside to an audience of peers. The fact that this misguided meme was picked up here and echoed rather widely over days is indicative of the non-ephemeral impact of blogs, despite how you (or I) believe they should be perceived.
    - petercooper 17y ago
      It would be bizarre if you would only make a blog post after "studying [a] large body of academic and practical work" relating to the content. Almost no-one outside of an elite of developers or researchers would have the time, let alone the inclination. I'm glad people - amateurs and professionals alike - have the freedom to publish what they want. There are cons ("reader beware!") but the pros outweigh them. If I want peer reviewed scientific papers, I know where to find them.
      - antonovka 17y ago
        It would be bizarre if you could only make blog posts after "studying [a] large body of academic and practical work" relating to the post. Almost no-one outside of an elite of developers or researchers would have the time, let alone the inclination. Reductio ad absurdum; you don't need to read the compendium of human knowledge -- spending an afternoon with Google getting a solid grasp on the state of the art is usually enough to get started. For most subjects, there's even a seminal book that's easily acquired. I'm glad people - amateurs and professionals alike - have the freedom to publish what they want. There are cons ("reader beware!") but the pros outweigh them. If I want peer reviewed scientific papers, I know where to find them. Yes, and we're also free to point out significant fallacies, as well as ignorance of standing research and implementations. This is healthy.

by catzaa 17y ago

antonovka 17y ago

I think it's a responsibility of everyone in any scientific or engineering field -- specialists and "not-yet-specialists" alike -- to think long and hard about advocating an approach without studying the large body of academic and practical work that exists for nearly every subject imaginable.

dschobel 17y ago
And with one deft stroke you've just eliminated 98% of the CS-related content on the internet. Bravo!
catzaa 17y ago
That is true in some sense. Yet, on the other hand, the first versions of Linux were written without consulting the extensive literature (which was all about microkernels) [1]. As another example – a guy studying with me made his own circuit boards (had his own acid production line project going on in his dorm room). You would never use such a circuit board in any professional setting. Yet he learned a lot about other stuff with his electronics projects. Sometimes the goal of learning isn’t really implementing something directly. As an example, a recursive function isn’t really the best way to calculate Fibonacci numbers. If someone wants to learn about forking by writing a simple web-server thingy then it may be a good idea? Most of these projects were probably done in their free time. Who would be the better programmer – the guy that wrote this, or the guy that knocked back a beer and sat in front of the TV? [1] I am not an operating system expert, but this is at least the impression I got after reading the flame-wars email.
- antonovka 17y ago
  Yet, on the other hand, the first versions of Linux were written without consulting the extensive literature (which was all about microkernels) [1]. In the early 90s nearly all of the operating system research was going into Microkernels, but there was already 30+ years of standing research to borrow from (and Linux very much did -- the fact that it's similar enough to run the same software as Solaris and BSD systems is not due to spontaneous re-invention). Despite the fact that Linux and the BSDs did not adopt the microkernel architecture -- and pure microkernels, for most purposes, died out -- quite a bit of value did come from that research, such as the Mach VM system, which was then borrowed by 4.4BSD operating systems and others. Most of these projects were probably done in their free time. Who would be the better programmer – the guy that wrote this, or the guy that knocked back a beer and sat in front of the TV? Rather than taking an incredibly assertive but misguided blog post at face value (and propagating it further), what is wrong about reading the widely available, easily discovered literature and implementing an event-based/event+thread-based implementation instead?
  - Scriptor 17y ago
    What's a good first step to finding this literature?
    - antonovka 17y ago
      In this case -- start by picking something you know to scale well, and find out how it does it. For instance, if you're familiar with nginx through web development, you'd find this on the nginx web page: "Architecture and scalability:" * kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), event ports (Solaris 10), select, and poll support; Once you've narrowed your search, start looking for well-respected books on the subject -- there's a long list of them in the thread below.
  - paulsmith 17y ago
    You've spent a lot of effort commenting on this post, and I think you've missed the point entirely. In Jacob's and Ryan's originals, the point wasn't to assert that preforking is the right way to structure a server -- that's not really the salient issue. (And I'd suspect that these two -- serious Web devs who are familiar with deployment -- probably are well familiar with {epoll, select, kqueue}-based and similar non-blocking, concurrent I/O servers.) The point was that, as Rubyists and Pythonistas and Perl hoo-has, we shouldn't be afraid to delve into POSIX syscalls and take advantage of the wealth of functionality they provide, and that our languages have thin wrappers over those bare syscalls that make it easy to write idiomatic code that utilizes them. The examples were echo servers, for murphy's sake -- are you really worried that we'd have a rash of poorly-thought-through, inefficient echo servers bogging down poor servers across the Internet? They're clearly intended to be simple examples about syscalls not the (yes! very important!) issue of how to handle concurrent connections efficiently.
petercooper 17y ago
Disagreed - it's the responsibility of those who are professionally or academically publishing such materials, not "everyone." It's also important for readers to consider their sources and realize that personal blogs are hardly to be taken at face value. Publishing things that are imperfect or incorrect is essential in order to get feedback and to improve. If it were necessary to do significant study before making a blog post or a similarly ephemeral statement, hardly anyone would bother and the field would be dead for lack of newcomers.
- antonovka 17y ago
  Publishing on a blog is still publishing, not a short-lived ephemeral aside to an audience of peers. The fact that this misguided meme was picked up here and echoed rather widely over days is indicative of the non-ephemeral impact of blogs, despite how you (or I) believe they should be perceived.
  - petercooper 17y ago
    It would be bizarre if you would only make a blog post after "studying [a] large body of academic and practical work" relating to the content. Almost no-one outside of an elite of developers or researchers would have the time, let alone the inclination. I'm glad people - amateurs and professionals alike - have the freedom to publish what they want. There are cons ("reader beware!") but the pros outweigh them. If I want peer reviewed scientific papers, I know where to find them.
    - antonovka 17y ago
      It would be bizarre if you could only make blog posts after "studying [a] large body of academic and practical work" relating to the post. Almost no-one outside of an elite of developers or researchers would have the time, let alone the inclination. Reductio ad absurdum; you don't need to read the compendium of human knowledge -- spending an afternoon with Google getting a solid grasp on the state of the art is usually enough to get started. For most subjects, there's even a seminal book that's easily acquired. I'm glad people - amateurs and professionals alike - have the freedom to publish what they want. There are cons ("reader beware!") but the pros outweigh them. If I want peer reviewed scientific papers, I know where to find them. Yes, and we're also free to point out significant fallacies, as well as ignorance of standing research and implementations. This is healthy.