Search Results

Search found 2 results on 1 pages for 'rparadox'.

Page 1/1 | 1 

  • Understanding the levels of computing

    - by RParadox
    Sorry, for my confused question. I'm looking for some pointers. Up to now I have been working mostly with Java and Python on the application layer and I have only a vague understanding of operating systems and hardware. I want to understand much more about the lower levels of computing, but it gets really overwhelming somehow. At university I took a class about microprogramming, i.e. how processors get hard-wired to implement the ASM codes. Up to now I always thought I wouldn't get more done if learned more about the "low level". One question I have is: how is it even possible that hardware gets hidden almost completely from the developer? Is it accurate to say that the operating system is a software layer for the hardware? One small example: in programming I have never come across the need to understand what L2 or L3 Cache is. For the typical business application environment one almost never needs to understand assembler and the lower levels of computing, because nowadays there is a technology stack for almost anything. I guess the whole point of these lower levels is to provide an interface to higher levels. On the other hand I wonder how much influence the lower levels can have, for example this whole graphics computing thing. So, on the other hand, there is this theoretical computer science branch, which works on abstract computing models. However, I also rarely encountered situations, where I found it helpful thinking in the categories of complexity models, proof verification, etc. I sort of know, that there is a complexity class called NP, and that they are kind of impossible to solve for a big number of N. What I'm missing is a reference for a framework to think about these things. It seems to me, that there all kinds of different camps, who rarely interact. The last few weeks I have been reading about security issues. Here somehow, much of the different layers come together. Attacks and exploits almost always occur on the lower level, so in this case it is necessary to learn about the details of the OSI layers, the inner workings of an OS, etc.

    Read the article

  • Are there new flexible texteditors? [closed]

    - by RParadox
    Vi(m) and Emacs are almost 40 years old. Why are they still the standard, and what attempts have been made at coming up with a new flexible editor? Are there any features which can not be built into vim/emacs? My question is similar to this one: Time to drop Emacs and vi? No one had a suggestion, which surprises me. I would have thought that the core of a texteditor is very small and that people brew their own. Perhaps nobody wants to deal with supporting all the modes? Edit to clarify my question: Instead of writing modes and scripts I ask myself, why there is not a much lightweight project, which lets people custom the editor more directly? Vim has 365395 LOC (C lines all included), Emacs 1.5 million LOC. Why is there a project with say 50k LOC, which is the core, why people can use more freely? Perhaps there is such project, I haven't looked very far. I thought about putting together modules from Vim myself and experimenting with some ideas. The core of editing shouldn't be more than 10k? Vim has a lot optimizations which is really an overkill nowadays. Basically I'm looking for a code base for my own editor and Vi/Emacs are I believe not intended to be used in this way. Bill Joy said the following about vi. http://web.cecs.pdx.edu/~kirkenda/joy84.html The fundamental problem with vi is that it doesn't have a mouse and therefore you've got all these commands. In some sense, its backwards from the kind of thing you'd get from a mouse-oriented thing. I think multiple levels of undo would be wonderful, too. But fundamentally, vi is still ed inside. You can't really fool it. Its like one of those pinatas - things that have candy inside but has layer after layer of paper mache on top. It doesn't really have a unified concept. I think if I were going to go back - I wouldn't go back, but start over again.

    Read the article

1