Hot answers tagged

101

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 ...


77

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 ...


74

This is covered largely in the history section of Wikipedia’s entry on newlines. Basically there are two lineages of operating systems leading to modern-day 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 behaviour from CP/M. CP/...


66

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 ...


63

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 ...


62

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 ...


37

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 ...


32

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 ...


30

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 ...


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

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 ...


26

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 ...


26

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 ...


25

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 ...


23

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

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 ...


23

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 ...


22

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), ...


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 ...


19

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 ...


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) ...


19

The a_midmag field contains a machine identifier, which can be used on platforms which support that field. a_midmag is a 32-bit value stored in host byte-order (fun already), and bits 16 to 23 give the machine type. The most comprehensive list of machine identifiers I’ve found so far is the list used by libbfd, which shows that the field has been used for ...


19

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 ...


18

ed was the standard Unix editor, and is present on all POSIX certified systems (though it's not installed by default in Debian, FWIW). Indeed it was and when I first went to University in 1984, they taught me how to use it. Then they said "there's also vi, type man vi". vi by the way was actually little more than some extensions on another line editor ...


15

Yes, you could use uppercase and special characters in passwords in early Unix. No, there was no Unix-related reason Ken Thompson wouldn’t have been able to use uppercase or special characters. Many of the passwords found in 2014 used special characters; none used uppercase, which doesn’t say anything about the original password requirements, only about the ...


14

In short: not very. Older versions of Xenix are based on V7 or System III (which are very similar to each other). They had the bourne shell, and large parts of the standard library were already available, e.g. stdio, malloc, alarm, lseek, getenv, but they were lacking many things you'd take for granted: there was no networking beyond serial ports, no ...


14

The short answer is: early Unix systems did not bother to track which architecture an executable was for. In general, the architecture an executable was for, was the one the executable was found on. If you're on a PDP-11, /bin will contain PDP-11 executables. If you're on a VAX, /bin will contain VAX executables. Multiple architectures all trying to ...


14

To start with, the only hardware needed for preemptive multitasking is an interrupt capable timer. Everything else can be done in software. Though, some memory management would be helpful. Besides custom solutions, that hardware was already ready available off the shelf for 8-bit CPUs. Beside more generic solutions like TI's 74610 series, more advanced ...


13

Each terminal gets its own set of processes: first getty, which sets the terminal link up and waits for a login, then replaces itself with login to handle the actual login, and finally login runs the user’s shell. So yes, each terminal gets its own shell (once a user has logged in). This doesn’t happen automatically, it’s set up by init which uses the ...


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