5 ms·

Ancient flamewar topics are insanely boring

by frou_dh 8y ago

jacquesm 8y ago
Agreed, unless the purpose is to extract lessons learned. I can think of several where that has not happened yet.
- giancarlostoro 8y ago
  One thing I always do when they happen is read through the comments anyway, sometimes people bring up some rather insightful things about a language, editor or whatever. Having heard from an emacs user why he prefers it over vim made me really appreciate emacs. I'll use either vim or emacs though, just don't care personally as long as I can: open a file, edit a file, and save a file. I also use full blown "bloated" IDEs. Of course I ignore a lot of comments, but try to go for the ones that seems intelligible.
  - cube2222 8y ago
    What was it that he said about emacs?
    - giancarlostoro 8y ago
      It was some blogpost I can't seem to find, but they explained all the different things they can do from within emacs, which were lots of things vim doesn't seem to be capable of doing, things such as SSH'ing to a remote system to open files remotely, fully being capable of handling mail through emacs, being able to use emacs as a web browser as well which is interesting, and other things which were fascinating enough to me. There's also the built-in git functionality, which some people use emacs exclusively to manage their usage of git. The emacs editor really is an Operating System to it's own extent. I really fell in love with the idea of being able to just work all day with nothing but emacs, I have not gotten to that point yet though. Being able to not leave my editor for anything sounds pretty useful if done right.
- ci5er 8y ago
  > I can think of several where that has not happened yet. Tell me more! :-)
  - jacquesm 8y ago
    Monolith vs Microkernel. I suspect in the long run that one will be settled in favor of the microkernel, but it will take a long long time to get there. Missed chance if there ever was one, but I can see some ulterior motives to keep the kernel as complex and hard to contribute to as possible. If everybody could write drivers then where would be the glory in that...
    - ci5er 8y ago
      > If everybody could write drivers then where would be the glory in that... Everyone can write drivers. It's one of the few things we can do in monolith-land. I guess I'm probably missing your point.
      - jacquesm 8y ago
        > I guess I'm probably missing your point. Yes you are, but that's fine. I totally see why the difference between 'can' and 'actually does' is lost. The reason for that is simple: device driver writing on a monolithic kernel is something of a black art, even with all the tools we have at our disposal today. On a microkernel you'd just be writing any other user process, with access to a couple of ports and and maybe a special hook to handle hw interrupts, but other than that you would not be able to tell the difference. Debugging would be almost as easy as debugging any other user process. You could use a whole slew of high level languages to do your device driver writing. If the interpreters on the system would take care of the lower levels of interacting with the kernel to deal with IO and/or interrupts then you could do your device driver writing in interpreted languages. But, you'll have to wait a little longer to be able to do that. Or try to locate a copy of QnX...
        zozbot123 8y ago
        > On a microkernel you'd just be writing any other user process, with access to a couple of ports and and maybe a special hook to handle hw interrupts This is a fiction. Hint: if a "user process" can wreak havoc on the system simply by misbehaving (in a way that may or may not be malicious), as drivers interacting with low-level hardware can, it's not a user process in practice, and should not be understood as one. The whole point of making that kernel vs. user space distinction in the first place is so that user programs can't wreak havoc on the system. There are plenty of things that can and should be done in userland (and oftentimes they are, see e.g. Plan9), but drivers are not among these unless you can always rely on something like IOMMU to make sure that the hardware cannot be made to misbehave in a way that affects security guarantees.
projectramo 8y ago
You sound like someone who uses vim instead of emacs. So many keys for each operation!
- bayindirh 8y ago
  It's not heavy as a complex operating system on the other hand. Also it handles latency on laggy connections much better. P.S.: This comment is written just for fun. It's just an Nerf attack, a little play. Thanks.

Ancient flamewar topics are insanely boring

jacquesm 8y ago

Agreed, unless the purpose is to extract lessons learned. I can think of several where that has not happened yet.

giancarlostoro 8y ago
One thing I always do when they happen is read through the comments anyway, sometimes people bring up some rather insightful things about a language, editor or whatever. Having heard from an emacs user why he prefers it over vim made me really appreciate emacs. I'll use either vim or emacs though, just don't care personally as long as I can: open a file, edit a file, and save a file. I also use full blown "bloated" IDEs. Of course I ignore a lot of comments, but try to go for the ones that seems intelligible.
- cube2222 8y ago
  What was it that he said about emacs?
  - giancarlostoro 8y ago
    It was some blogpost I can't seem to find, but they explained all the different things they can do from within emacs, which were lots of things vim doesn't seem to be capable of doing, things such as SSH'ing to a remote system to open files remotely, fully being capable of handling mail through emacs, being able to use emacs as a web browser as well which is interesting, and other things which were fascinating enough to me. There's also the built-in git functionality, which some people use emacs exclusively to manage their usage of git. The emacs editor really is an Operating System to it's own extent. I really fell in love with the idea of being able to just work all day with nothing but emacs, I have not gotten to that point yet though. Being able to not leave my editor for anything sounds pretty useful if done right.
ci5er 8y ago
> I can think of several where that has not happened yet. Tell me more! :-)
- jacquesm 8y ago
  Monolith vs Microkernel. I suspect in the long run that one will be settled in favor of the microkernel, but it will take a long long time to get there. Missed chance if there ever was one, but I can see some ulterior motives to keep the kernel as complex and hard to contribute to as possible. If everybody could write drivers then where would be the glory in that...
  - ci5er 8y ago
    > If everybody could write drivers then where would be the glory in that... Everyone can write drivers. It's one of the few things we can do in monolith-land. I guess I'm probably missing your point.
    - jacquesm 8y ago
      > I guess I'm probably missing your point. Yes you are, but that's fine. I totally see why the difference between 'can' and 'actually does' is lost. The reason for that is simple: device driver writing on a monolithic kernel is something of a black art, even with all the tools we have at our disposal today. On a microkernel you'd just be writing any other user process, with access to a couple of ports and and maybe a special hook to handle hw interrupts, but other than that you would not be able to tell the difference. Debugging would be almost as easy as debugging any other user process. You could use a whole slew of high level languages to do your device driver writing. If the interpreters on the system would take care of the lower levels of interacting with the kernel to deal with IO and/or interrupts then you could do your device driver writing in interpreted languages. But, you'll have to wait a little longer to be able to do that. Or try to locate a copy of QnX...
      - zozbot123 8y ago
        > On a microkernel you'd just be writing any other user process, with access to a couple of ports and and maybe a special hook to handle hw interrupts This is a fiction. Hint: if a "user process" can wreak havoc on the system simply by misbehaving (in a way that may or may not be malicious), as drivers interacting with low-level hardware can, it's not a user process in practice, and should not be understood as one. The whole point of making that kernel vs. user space distinction in the first place is so that user programs can't wreak havoc on the system. There are plenty of things that can and should be done in userland (and oftentimes they are, see e.g. Plan9), but drivers are not among these unless you can always rely on something like IOMMU to make sure that the hardware cannot be made to misbehave in a way that affects security guarantees.

projectramo 8y ago

You sound like someone who uses vim instead of emacs. So many keys for each operation!

bayindirh 8y ago
It's not heavy as a complex operating system on the other hand. Also it handles latency on laggy connections much better. P.S.: This comment is written just for fun. It's just an Nerf attack, a little play. Thanks.