>>992613
>Unix is a waste of effort. The amount of work that it took for it to survive this long was enormous and it's still a broken piece of shit anyway. There has to be something wrong there when OSs made by 6 people work better than something as huge as Unix.
That's exactly right. Even the amount of work put into Multics and other mainframe OSes is miniscule compared to Linux, but most of that was R&D work, like inventing new hardware architectures, file storage structures, programming languages, storage devices, and so on. Linux needs 15,600 "programmers" just for a kernel of a clone of a PDP-11 OS.
>>996241
UNIX weenies mean the ability to replace a UNIX "tool" with a GNU "tool" that behaves identically. What really sucks is that everything is based on text instead of APIs and binary, so you end up never being able to fix text formats because computers depend on text being a specific sequence of bytes instead of being for people to read.
>>996253
>In this simple example, you use a terminal, a shell, an editor, a compiler, a linker, and a debugger, for the relatively simple task of writing a program.
That's the UNIX workflow. The Lisp, Smalltalk, BASIC, and FORTH workflow is using a REPL/prompt to directly alter the program and state of the machine. All of that is combined into one program, the opposite of the UNIX philosophy.
>>998962
>For instance, there's no "select" call to see which FID has data available, you simple rfork a new process to do this for you.
That's as "simple and elegant" as using a PDP-11 tape backup program to copy a directory hierarchy.
>>999149
>Unix philosophy is basically small, simple programs cooperating to archive a bigger task. Are you against that?
That's bullshit. UNIX pipes are much worse for making programs cooperate than dynamic linking and Multics segments. Most uses of pipelines are because the shell sucks at text processing so you need all these other programs that also suck.
>I agree with this, we should've been using an evolution to Unix like Inferno or even The Octopus from LSUB but we're stuck with 70's state of the art computing using abstractions like teletypes thanks to HP, IBM, DEC and Sun for their Unix wars from the 80's ~ 90's and now Linux.
Calling UNIX "70's state of the art computing" is like calling shitting in the streets "70's state of the art plumbing." Xerox Alto, VMS, and many other good systems are from the 70s. I never heard of "The Octopus" but it's more UNIX bullshit with the same UNIX problems.
http://lsub.org/ls/octopus.html
>The system derives from Plan B, therefore it is heavily influenced by Plan 9, and shares most of the source code with both systems.
Plan 9 itself shares most of its source code with UNIX.
>>999389
The problem with GNU Emacs is that it's bloated due to running on top of UNIX. Most of the UNIX Haters were Lispers who like Emacs and used a variant on ITS, Multics, or Lisp machines. They hate how much code GNU Emacs needs compared to the other versions because C and UNIX suck.
With respect to Emacs, may I remind you that the original
version ran on ITS on a PDP-10, whose address space was 1
moby, i.e. 256 thousand 36-bit words (that's a little over 1
Mbyte). It had plenty of space to contain many large files,
and the actual program was a not-too-large fraction of that
space.
There are many reasons why GNU Emacs is as big as it is
while its original ITS counterpart was much smaller:
- C is a horrible language in which to implement such things
as a Lisp interpreter and an interactive program. In
particular any program that wants to be careful not to crash
(and dump core) in the presence of errors has to become
bloated because it has to check everywhere. A reasonable
condition system would reduce the size of the code.
- Unix is a horrible operating system for which to write an
Emacs-like editor because it does not provide adequate
support for anything except trivial "Hello world" programs.
In particular, there is no standard good way (or even any in
many variants) to control your virtual memory sharing
properties.
- Unix presents such a poor interaction environment to users
(the various shells are pitiful) that GNU Emacs has had to
import a lot of the functionality that a minimally adequate
"shell" would provide. Many programmers at TLA never
directly interact with the shell, GNU Emacs IS their shell,
because it is the only adequate choice, and isolates them
from the various Unix (and even OS) variants.
Don't complain about TLA programs vs. Unix. The typical
workstation Unix requires 3 - 6 Mb just for the kernel, and
provides less functionality (at the OS level) than the OSs
of yesteryear. It is not surprising that programs that ran
on adequate amounts of memory under those OSs have to
reimplement some of the functionality that Unix has never
provided.