• 0 Posts
  • 48 Comments
Joined 2 years ago
cake
Cake day: May 29th, 2024

help-circle





  • Anyone interested in this concept should take a look at plan9. Everything is even more of a file there.

    Taking a screenshot, for example, can be done with:

    cat /dev/screen | topng > screenshot.png

    That combined with the way that parent processes can alter their children’s view of the filesystem namespace allows for extremely elegant abstractions. For example, every program just tries to write directly to screen or audio, but the desktop environment redirects their writes to the relevant servers. Which means that, in the absence of those servers, those same programs can run just fine and don’t care whether they’re being multiplexed or not. That also means that the plan9 userspace can be nested inside itself just using the normal mechanisms of how the OS works (that is, without a special tool like Docker).


  • The microcode in integrated CPUs took care of routing your inputs and outputs to where they need to be, and triggering the various arithmetic operations as desired.

    In the transition from plugboards to programmed sequence control the thing that took over the task of routing values between registers, through the ALU, and to/from IO ports was the control unit. Microcode being one way to implement functionality in the control unit.

    One other approach was to use what was basically a finite state machine, implemented physically in-circuit. The output of that FSM was fed into a series of logic gates along with the current instruction value, with the output of that combination being connected to the control lines of the various CPU elements. Thus the desired switching/routing behavior occured.

    Modern chips are really complicated hybrids of microcode and a ton of interacting finite state machines. Especially in x86 complex or less commonly used instructions will be implemented in microcode, whereas simple/common instructions will be implemented by being “hardwired”, somewhat similar to the FSM technique described above (although probably more complicated).




  • Its pretty well known that “lines of code” is a horrible metric to judge programmers with. It seems “number of new projects” is pretty similar, though at a higher level of abstraction.

    Unfortunately that metric is applied to a lot more than just programmers; and I think getting rid of it would involve completely restructuring the type of activity our society is oriented around, and would run up against the life philosophy of the people in charge.

    Of course I’m not against progress, but I’m talking about executives that don’t plan beyond the next quarter, politicians that don’t plan beyond the next election cycle, the endless pursuit of growth, and the inability of market economies to cope with the fact that sometimes inaction is more advantagous than action. All of this encourages endlessly churning out ‘new’ things, without designing those things to last or putting in the effort to maintain them.




  • I don’t know how Micro works, and I don’t actually use emacs day to day, but as I understand it emacs works a bit like:

    • When you press a key in emacs it invokes a Lisp function that takes as arguments the text buffer that has focus, the parameters of the ‘window’ into that buffer, and the cursor position in that window.
    • This is the case for any key you press in any context, even for typing normal letters.
    • A ‘mode’ in emacs is a set of bindings which associate specific keys with specific functions.
    • ‘modes’ can be stacked on top of each other, with higher modes being able to intercept key presses before they reach lower modes, and changes / manipulate lower modes (I think?)
    • All of the editor’s functionality, such as ‘search’ or ‘undo’, is implemented in that way.
    • All of this is completely customizable, so pressing a key combo can be made to do virtually anything or manipulate the rest of the editor’s systems in any way.

    Does Micro work anything like that?





  • It’s a tool, useful in some contexts and not useful in others.

    In my opinion this is a thought terminating cliche in programming and the IT industry in general. It can be, and is, said in response to any sentiment about any thing.

    Now, saying what sort of context you think something should or should not be used in, and what qualities of that thing make it desirable/undesirable in that context, could lead to fruitful discussion. But just “use the right tool for the right job” doesn’t contribute anything.



  • If your motivation is to see old html pages, with minimal style, well it’s impossible to do them reliably.

    Not only should your site be legible without JS, it should be legible without CSS, and infact without rendering the effects of the HTML tags (plain text after striping the tags).

    At one point in time this was the standard, that each layer was an enhancement on top of the one below it. Its seems that web devs now cannot even imagine writing a news article or a blog post like, something that has the entirety of its content contained within its text. A plain .txt file renders “reliably” on anything. You are the one adding extra complexity in there and then complaining that you’re forced to add even more to deal with the consequences of your actions.


  • FOSS doesn’t mean “we think people that make software should work for free because we like free shit”. It means:

    1. When you want to modify something someone else made to your benefit you should recognize the work they did for you and pay it back in the form of contributing those changes back to the project. Beyond that, it also benefits you directly because someone else might build on your improvements (well, that, but also its easier to stop your changes from breaking in new versions of the software if other people are aware of them). Like the other commenter said, its communal development, sure lots of people do it at least partly because they want to make the world a better place, but the primary reason it works is because the various parties mutually benefit from mutual cooperation.

    2. The belief that you should have complete control over your own computer, which you can’t do in practice without being able to view the source code of the software you run.