Hot answers tagged

111

It's a line editor (meaning, you can't see all the text at a time. You query line numbers and it spits it back, but it came before vi, where you can use hjkl to navigate up and down the screen). How was it used? I find it hard to believe that people memorized their code well enough that they could remember what was going on in line 5 when working on line 20? ...


94

This is covered largely in the history section of Wikipedia’s entry on newlines. Basically there are two primary lineages of operating systems leading to modern-day desktop usage: Windows on the one hand, and Unix-like systems on the other. Windows descends from MS-DOS (because initially it was implemented on top of DOS), which itself inherits much of its ...


81

The short version is that X11 was the first widely-disseminated version, and it turned out to be good enough to remain as-is for thirty years. X is the X Window System, which at its core is a protocol; the number identifies the version of the protocol. X1 was released in 1984 inside MIT, and quickly evolved to X9 in 1985; an external port to RT/PC required ...


70

The message appears in sudo’s revision control (in its current guise) in June 1993, in the University of Colorado version of sudo, in a slightly shorter form: We trust you have received the usual lecture from the local Systems Administrator. It usually boils down to these two things: #1) Respect the privacy of others. #2) Think before you ...


66

The reason you can't keep a 20 line program in your head is because you don't have to any more. Same reason you probably don't know any phone numbers. But back in the day, we certainly did do this. I have written thousands of lines of code and text and documentation using line editors (not ed). At 110, 300, 1200 and 2400 baud. The 2400 baud terminals were ...


65

Primordial Unix on the PDP-7 was in many ways very different from what we know today. Directories existed but were very awkward to use; in practice most work was done in a single directory. Most importantly, paths did not yet exist. What was implemented early on though was a simple syntax for IO redirection on the commandline. Whereas on Multics one ...


61

The message was This program posts news to thousands of machines throughout the entire civilized world. Your message will cost the net hundreds if not thousands of dollars to send everywhere. Please be sure you know what you are doing. This message isn’t inherent to Usenet, it’s output by certain clients. It originated in rn, Larry Wall’s news ...


55

The I/O model on "Cutler systems" -- RSX-11M, VAX/VMS, Windows NT -- is an asynchronous packet-driven I/O model, rather than the fundamentally synchronous I/O model of Unix. At its core, you fire off an I/O request, and get a notification of when it's complete. Meanwhile, execution continues. Of course, it's trivial for the system to provide synchronous I/...


38

I’m not sure about specific events, but I think the main reason Base64 “won” is that it’s one of the binary encodings supported by MIME, and MIME took over. So perhaps the question then becomes two-fold: Why did MIME pick Base64 over UUencode? Possibly because Base64 is actually more resistant than UUencode: it only uses alphanumeric characters plus two ...


36

Having used ed years ago on a printing terminal (such as a teletype or a DECwriter), I think the reason for having no prompt was that on pressing RETURN after one command, you didn't have to wait for a prompt to be printed before starting to type the next command. Similar considerations made it better for ed to have ? as the only error message: you would ...


33

Going from “AT&T made phone switches” to the idea that Unix was intended to drive phone switches is quite a leap. The creators of Unix described its creation and development in some detail, e.g. in The Evolution of the Unix Time-sharing System: What we wanted to preserve was not just a good environment in which to do programming, but a system around ...


31

The team working on Unix at the time considered the PDP-7 to be obsolete, and had no interest in making Unix into a finished system to run on it; they only used it originally because the machine was available to them and they had little other use for it. Plus, Bell had little interest in developing operating systems per se, and only financed development of ...


31

From this list of Multics features, almost all are recognizable in modern UNIX-style systems in one form or another. Looking for distinctions between is two is made difficult due to the longevity of UNIX and the proliferation of its children. For me, the most interesting distinction between Multics and UNIX (and most operating systems to follow) was Multics'...


30

Before the advent of interactive terminals (and version control programs), most programmers were used to keeping their source code on 80-column punched cards. On the first mainframe that I worked on (a Honeywell system), work-flow was typically as follows: Initial source code would be entered on 80-column coding pads, and these would be transferred to ...


30

In 1986 (and for a few years after that still), /dev wasn’t handled by a special file system. It was generally a directory on the root file system, and its contents were largely static: a series of device nodes, created by mknod. Many systems had some way of creating the “standard” nodes, for example a Makefile in V7 or MAKEDEV. Each device node has a type, ...


29

The PDP-7 was too small and too slow; quoting Dennis M. Ritchie in The Development of the C Language: On the PDP-7 Unix system, only a few things were written in B except B itself, because the machine was too small and too slow to do more than experiment; rewriting the operating system and the utilities wholly into B was too expensive a step to seem ...


29

Memory protection. It's not that preemptive multi-tasking is expensive, or hard. It's not. It's easy. It costs (or can cost) essentially the same as cooperative multitasking. You have to save process state in both cases. But what was holding back the older systems was their early reliance on systems without inherent memory protection, and those legacies ...


28

In later versions of Unix, Ken Thompson would most certainly have been able to use upper-case characters but it's unclear whether he would have wanted to. It's not that Unix itself prevented it, but rather that there were still plenty of terminals at that time that supported only the 64-character ASCII character set, which were upper-case only. The "7th ...


26

Slackware still claims to support 486s: Below is a list of minimum system requirements needed to install and run Slackware. 486 processor 64MB RAM (1GB+ suggested) About 5GB+ of hard disk space for a full install CD or DVD drive (if not bootable, then a bootable USB flash stick or PXE server/network card) Knoppix also still claims to support 486s, ...


25

The Unix Assembly Reference Manual by Dennis M. Ritchie, at §8.1 notes that: The syntax of the address forms is identical to that in DEC assemblers, except that ‘‘*’’ has been substituted for ‘‘@’’ and ‘‘$’’ for ‘‘#’’; the UNIX typing conventions make ‘‘@’’ and ‘‘#’’ rather inconvenient. In a SO answer, and in this comment, fuz notes that this is ...


24

You have to remember that 'ed', originally, was as often as not being used on a teletype, not a video terminal, so the line-oriented paradigm made sense. Even then, knowing enough 'ed' to get around files was valuable when, for example, you were using a really dumb terminal (I recall an IBM 3101 that for reasons I forget I was forced to use occasionally ...


23

Linux still supports the 80486 SX: the SX was simply a DX without the FPU, and the FPU emulation code is still present (Processor type and features->Math emulation). Finding a distro is a bit trickier. Gentoo still supports the 486 in theory (when the installation instructions call for downloading a "stage 3" archive, simply download the "i486" version), ...


23

According to the Unix history repository, V1 had 4,501 lines of assembly code for its kernel, initialisation and shell. Of those, 3,976 account for the kernel, and 374 for the shell. For comparison, current dash has 14,455 lines of C, and the current Linux kernel has 372,988 lines of C for its core functions only (kernel, lib and mm in the kernel source ...


22

While I am sure that the merits of Cutler's stated "low opinion" could be debated, I'm interested to better understand exactly what he was referring to here. There's no citation, and I haven't found a good explanation critiquing his criticism. Honestly, at face value, it's a naive criticism. Cutler was not naive, so, it's likely just a sound bite poke ...


21

Speaking for the Macintosh here. TL;DR: It wasn't possible to do this in a compatible manner after the hardware was capable enough. Compatible to the already existing application base. You'll need to see this in context with the heritage of the Macintosh Operating System itself. It was built to run in an considerably limited environment, regarding CPU power ...


20

I have had great success with Gentoo Linux on the earliest generation of Intel 80486 processors, though I had to patch it (below). It works on the later ones too (486DX2 and 486DX4, both clock multiplied and having the back-ported Pentium CPUID instruction). I have it working on a Compaq LTE Elite 4/75CX laptop with a whopping 24MiB of memory. Bugs have ...


20

The problem with uuencode is that the format was not robust in the face of some of the really crufty mail software and gateways into and out of proprietary non-SMTP and non-ASCII mail systems of the day. Just to liven things up further, there were multiple EBCDIC variants which had different code points for some ASCII characters used by uuencode, opening up ...


20

When I was a lad, the only reason ed was included at all in our environment is because it was used by the standard system scripts. Originally, having to clean the 'prompts' out of ed output to clean up the data would have just made everything more difficult -- much more difficult. Later, having ed default to something different would have just broken all ...


19

PC/MS-DOS 1 used the slash (/) as the command line switch indicator (like DEC's RSX11 and DG's RTOS before), so when DOS 2.0 introduced subdirectories, they did need a new one. Backslash (\) came somewhat natural - at least on US keyboards. With 2.0 IBM/Microsoft also tried to reverse that decision and introduce a syscall (INT 21h function 3700h and 3701h) ...


Only top voted, non community-wiki answers of a minimum length are eligible