12 Matching Annotations
  1. Nov 2018
    1. This idea was brought into CP/M by Gary Kiddal in 1974. You could do neat things with it like copy data off the serial port into a text file, or print a textfile right from the command line! This is done in unix by having special files existing in special folders, like /dev/tty for the console or /dev/lp0 for the first printer. You can get infinite zeros from /dev/zero, random bytes from /dev/random, etc! but here's the problem: CP/M is designed for 8-bit computers with very little memory, and no hard drives. At best you've got an 8" floppy drive. So directories? you don't need 'em. Instead of directories, you just use different disks. but without directories you can't put all your special files over in a /dev/ directory. So they're just "everywhere", effectively. So if you have FOO.TXT and need to print it, you can do "PIP LST:=FOO.TXT" which copies foo.txt to the "file" LST, which is the printer. and it works where ever you are, because there are no directories! it's simple. but what about extensions? Here's the problem: programs like to name their files with the right extension. so if you're running a program and it goes "ENTER FILENAME TO SAVE LISTING TO" you could tell it LST to print it or PTP to punch it out to tape (cause it's 1974, remember?) but the program might try to put .TXT on the end of your filename! LST.TXT isn't the printer, right? Nah. It is. These special devices exist at all extensions, so that this works. so if "CON" is reserved to refer to the keyboard, so is CON.TXT and CON.WAT and CON.BUG

      special files in cp/m

  2. Sep 2017
    1. NixOS is a Linux distribution with a unique approach to package and configuration management.

      This is another approach to systems management and software as a services. I don't really understand in detail the difference between NixOS and docker, but googling NixOS vs Docker shows that its a topic that is ripe for a bunfight.

  3. Apr 2017
  4. Jul 2016
    1. /aftp/xx.yy.edu/pub/doc/README Fig 1. Some alternative tagged and untagged representations

      An alternative notation that was considered for URIs

  5. Aug 2015
    1. As I did 20 years ago, I still fervently believe that the only way to make software secure, reliable, and fast is to make it small. Fight Features.

      Fight Features.

  6. Jul 2015
    1. Much like a Unix power user will compose multiple single-purpose tools into a complex piped command, a functional programmer will combine single-purpose function invocations into chains of operations (think Map/Reduce).
  7. Feb 2015
  8. Feb 2014
    1. "We should have some ways of connecting programs like garden hose--screw in another segment when it becomes necessary to massage data in another way. This is the way of IO also."

      And here we are with a web of hoses (nee tubes) and we still only have simplistic linking mechanisms with no way to link directly to the content we are referring to: https://hypothes.is/a/G3usyxJQRFyvOS-bzyXaVQ

    1. 1. We should have some ways of connecting programs like garden hose--screw in another segment when it becomes when it becomes necessary to massage data in another way. This is the way of IO also.
    2. Point 1 is the interesting one. It provides the historical background for Doug's encouragement of the Unix pipe notation. The linked paper gives appropriate credit; in interviews, Doug has been explicit in saying that he very nearly exercised managerial control to get pipes installed.
    3. Advice from Doug Mcilroy

      I love finding these kinds of documents that capture the thoughts of moments in history where simple, profound ideas are made manifest and have the kind of longevity to still be the core of the foundation that the modern world is built on.

    1. What is missing is a space between the $( and the following (, to avoid the arithmetic expression syntax. The section on command substitution in the shell command language specification actually warns for that:

      This is a very good example of why shell scripting does not scale from simple scripts to large projects. This is not the only place where changes in whitespace can lead to scripts that are very difficult to debug. A well-meaning and experienced programmer from another language, but new to bash scripting, might decide to clean up formatting to make it more consistent-- a laudable goal, but one which can lead to unintentional semantic changes to the program.

      Flat, short bash scripts are extremely useful tools that I still employ regularly, but once they begin creeping in size and complexity it's time to switch to another language to handle that-- I think that is what (rightly) has driven things likes Python, Puppet, Ansible, Chef, etc.

      Despite the syntactic horrors lurking in shell scripts there is still a beautiful simplicity that drives their use which is a testament to the core unix philosophy.