The Unix-Haters Handbook (1994) [pdf]
web.mit.edu
web.mit.edu
As for me? I switched to the Mac. No more grep, no more piping, no more SED scripts. Just a simple, elegant life: “Your application has unexpectedly quit due to error number –1. OK?”
The great thing about a Mac is that I get to have my user level UNIX without having to know anything about the system level UNIX. I don't need to be a sysadmin to run the thing. I get grep and pipes without having to know all the crazy commands to tweak networks settings and display timings and boot scripts. When OSX came out, that was the state of Linux, you couldn't be just a user of it, you had to know way too much to get it running.
Mac resurgence is more of a perception than reality. In 2016, Apple sold ~18.5M Macs, down from the previous two years [1] and off more than 10% from last year.
Granted that the Mac numbers are falling at a slower pace than the PC market as a whole, but resurgence is probably an over-characterization.
[1] http://finance.yahoo.com/news/state-apples-device-sales-1940...
Given that Mac has gone from well under half a percent market share to over 7% today, I'd say "resurgence" is an under-characterization, relative to what I was talking about. ;) OS9 never had the market share that OSX has, so it's less coming back, and more dominating like it never did before.
The team behind WSL is also very responsive to issues reported at github.
Luckily, that is basically true for modern Linux as well.
I ask as I type from my Dell XPS 13" DE (aka Sputnik).
All the time the argument is given that OS X has much better hardware support than Linux, which is just not true. It might be true for OS X on a Mac compared to Linux on unspecified hardware. However, if you constrain the hardware choices even half as much as you do for OS X, that's not the case anymore.
> http://www.cnx-software.com/2016/10/14/ubuntu-16-10-images-r...
Seemingly confirmed here:
> http://linuxiumcomau.blogspot.com/2016/10/running-ubuntu-on-...
Where this guy updated to say that current ISOs of 16.10 should work...
> Whilst two ISO sets of various Ubuntu flavours for both 16.04.1 and 16.10 releases are provided, I recommend first trying one of the 16.10 ISOs as these are the most recent and incorporate the latest kernel, patch sets and fixes based on previous releases and feedback. In particular, the Yakkety 16.10 ISO kernels support micro SD cards (although with some limitations), includes a patch for I2C bus, has improved RTL8723BS wifi and bluetooth support and most recently I've included support for full disk encryption on Lubuntu and fixed the home directory encryption for all flavours.
OpenSource tends to have a lag time to hardware by nature...but I do believe there was some exaggeration here.
Fedora/Gnome here. I never use this sort of stuff, and modern power users really don't have to. That's why I categorically state that practically no-one in the real world "uses Unix", even though most OS-es incl mainstream mobile ones derive directly or indirectly from it, save for Windows and esoteric ones.
Do I enjoy modern Linux? Heck yeah. Do I want to use Unix? Piping and grepping and cat'ing and touch'ing and so forth? It's not rocket science but it's also a doggerel not smooth UX for me, and "not smooth" means not productive.
If I need to compose functionality for "shell"-based task automation, I whip up a small Go program. Portable across OSes should I ever move, bin dir is in PATH, compiles fast enough to not need script interpreter for iterating the "script" (tool) at hand, and the syntax and semantics are saner to me than sh scripts, aka no impedance mismatch vs other coding tasks.
(Sure enough though, for one-offs "search these for that" while already in the bash/etc, the built-in old-school tools still come in handy occasionally)
OTOH working on some non-trivial code bases, maybe including system level code, typically requires grepping and piping, for at least some developers of the team, to be productive.
I too don't gratuitously use cat and touch and grep when I don't need to. I even less often use cmd stuff under Windows (using one of the dozen of bash that exists there is better for interactive command line use, when needed, on computers where I can have those), but if I need to I can do it.
Do I use Unix or not when I'm not typing into a traditional command line shell, but still using a Unix-based system as my direct terminal (or a light terminal connected to it)? "Interesting" question. Do I use an internal combustion engine when I'm driving a car? Do I use electricity when I switch on the light? I don't think we can answer any of those questions in a truly absolute way. But most of the time I would probably say yes.
I bought a macbook thinking I'd learn how to use it... but after 3 years, all I can do on a Mac is open a web browser and terminal.
Using Finder, XCode, Objective-C and Swift frameworks,...
Objective-C looks like a clusterfuck and I never want to touch it. Swift seems like a quite good solution to that and I hope it eventually becomes the full replacement - but now more non-Apple laptops have high DPI screens, so I don't think I'll be around to see it happen.
This is pretty much moot now, the Apple world is abandoning Obj-C, but AFAIK it's just old, not bad. Like, came out at the same time as C++ old, and has seen fewer changes to the language than C++ has. It's a compiled, C-like language, so yeah, hard to use and very easy to crash, just like C & C++.
Interested to hear your point of view on what makes it seem like a cluster, if you want to share. (And I'm only interested in hearing and understanding your opinion, not on debating or contradicting your experience.)
Obj-C had a pretty cool calling mechanism underneath, known as "message passing" -- more or less the analogy to C++'s virtual member functions. But it is the only compiled language I know where you can actually call functions by name, like construct a string dynamically and call, and you get those dynamic calls at the same speed as compiled code (minus a fast function lookup you can usually do once).
I used that mechanism in some games to build a nice state machine class for actor behavior. I did the same in C++, and the Objective-C code was way nicer & easier to use.
It's called by various names - not sure if there is an official one - such as dispatch tables, jump tables, dynamic dispatch, etc. It's a pretty old technique, I would say it probably dates from the time of early high-level languages, and I seem to remember that it was used in assembly languages too (so probably even earlier), by using various addressing modes (indexed, indirect indexed, etc. (those terms are from long-forgotten 6502 instruction set BTW), storing the address of a function at a location and then jumping to that address (where the address is dynamically set at run time by some other bit of code based on some condition), etc.
Here is a simple example in Python:
Simulating the C switch statement in Python:
https://jugad2.blogspot.in/2016/12/simulating-c-switch-state...
Edit: Googled and got a couple of relevant links:
You can do this as a hack in most compiled languages by exporting symbols from a shared library and just using the OS specific dynamic linker but this is ugly, slow, and pointless in a static language.
Know what drives me the most nuts? That there's a single default key (Enter) to rename a folder, while you have to use a key chord (Command-O) to enter a folder. It's so backwards, renaming is not something I spend even remotely as much time doing as moving around. That's not to mention the so completely obvious missed opportunity to let the Enter key do what it says and Enter the folder.
I use Command+Down, which opens Finder shell-objects generally. It's the "descend" to Command+Up's "ascend."
Still, all navigating should be single-key-able, right? I guess it is technically, with left & right arrow keys in the List & Columns views, but I don't use those or like those as much, for whatever reason.
>I don't know why people seem to think Apple is some sort of UI god when they can't even make a usable file manager.
I know! I ask myself how this is possible every time.
The nice thing is that it is configurable.
The irony is now I run Linux in a VM because the toolchains for the embedded work I do all run there. In principle I can make it all work in MacOS, but it already works in Linux.
Don't get me wrong, I am big fan of UNIX, but I hope I will be alive around the time(but I doubt that) when we will see some new thing which will make UNIX feel dated. Now, some of you might jump and say "Oh, but UNIX already feels dated", and that would make conversation on it's own, but I think people say that more because they are bored with UNIX, or they dislike certain segments.
And what breaks my heart is general disinterest in Operating systems with young developers/students (I am student too, but I find those things to be most interesting of all university courses). I see very little people doing OS work today. I wasn't there to see how it was in 80s & 90s, but from what I've read, you had much, much more choice, but their quality was debatable. Why we always consider Operating Systems to be "solved" thing? Is it because the way Von Neumann architecture works, we tend to abstract computer as an entity in the way that gave us UNIX and that we won't be able to discover and make something different but as capable as UNIX without changing our way of thinking about what computer is and how it works? Did we got used to computers as they are, especially newer generations, taking things for granted, and just going forward with what they inherited?
Everybody thinks they can spell it, but I have never lost the dollar. Sometimes I pull out the same bet six months later and still win it.
Which makes it a messy name for a project. Though maybe Google can change the spelling by brand-name fiat, just like they did with "googol".
I get the low-latency part. But there're already OSs designed for low-latency.
The thing I really liked was that the console output was independent of the input line. You can start typing in a command, hit <help> and have the (rich, hypertext) documentation appear in the console above where you are typing in. You don't have to delete everything and type man foo like in Unix, only to have the man page disappear when you quit.
Simply in terms of usability the Genera listener craps on any Unix or Windows terminal I have used.
What I'd really like to know, what is Unix, at the core. I know POSIX defines certain standards, but what can we rip out and still call what remains Unix? If we're being really reductive can't we take it beyond the features that were present in the very first Unix for the PDP7? Is it simply the syscall interface which provides a filesystem abstraction? Do we call an OS a Unix if it only has a POSIX layer like Windows NT?
So if we could strip everything out and leave just a few pieces, and still recognize it as Unix, the use of the word approaches meaninglessness. Unixes exist without memory management or process isolation. Think of how fundamentally dissimilar an Apple Watch running iOS is compared to a PDP11. I think that versatility in the terminology itself lets us keep calling something Unix long after it's morphed into something else.
It's not hard to imagine replacing system calls with other ways of achieving the same outcome. I think fundamentally, at the lowest level, where the operating system is an interface to the core features of the processor, it is relatively invariant. For truly unique systems, we do have to look at the hardware. Unique operating systems have been tied to unique hardware, like the Xerox Alto, or the MIT CADR, whereas Unix as a generic set of functionality has made many computer architectures useful, but also reduced their variety.
How about, I don't see Unix-like systems as the end-all be-all of operating systems such that these systems will be the basis of anything in 100 years. To extend the timeframe indefinitely, is this system the one to last the ages?
Then there's stuff like Genode, which is... difficult to describe concisely, but is a capability-based OS designed for running OSes in; they wanted it to have the ability to self-host, so they added a personality for running toolchains in, and of course it's Unixy, because what else is it going to be?
https://genode.org/documentation/release-notes/11.02#Noux_-_...
So, while I agree that I'd like to see a working environment that's not a traditional Unix, I think that's a UI thing rather than an OS thing.
Basically every single mainstream OS out there has the assumption that there are files with filenames as binary/text blobs in a separate storage space from 'memory', and with that ... file descriptors, processes, threads, and sockets.
But it doesn't take much imagination to conceive of different models -- what if instead of a file system we have a relational model? Relations/relvars and tuples as fundamental storage units? What if instead of malloc/free and fopen/fclose (and mmap/msync) we have instead some unified notion of allocation/storage with hints/specifications of permanence requirements, performance requirements, type, and intended use and the OS takes care of where to put it (cache, main memory, flash, magnetic storage, network storage etc.)?
One can think of any number of possibilities. But the needs of the C-language semantics and the orthodoxy of 50 years of OS/language patterns keep us where we are.
+ one click installation of applications
+ applications are always up to date
+ applications are sandboxed
Then, since we want users to be able to tinker:
+ the source for all software installed through this mechanism is available
+ optional binary caches NixOS style so it's not slow
And while we're talking about NixOS:
+ immutable package directory so you can rollback at will
And then on to data storage, which is my favorite topic:
+ defaults to tags instead of a hierarchy for organization
+ everything is schema'd, so a file saying it's a contact entry or whatever actually has to be that thing
+ data is immutable by default, so undo and versioning can be built-in (you could still turn this off for certain tasks like video-editing where immutability isn't feasible)
I have more thoughts on data storage here if anyone's interested: https://juniorschematics.com/
+ web applications almost always have a shitty, slow, ad-infested, dumbed-down interface with bare-bones features
+ you're at the mercy of whatever company owns and runs the servers that the application is served from, if they decide to end the service or change it in a way you don't like tough luck for you
+ your privacy and control over your own data are usually forfeited
+ your data is usually trapped on the servers or difficult to extract and use independently of the web service itself
On the other hand, programming languages that are decades old are looked upon as antiquated and not fit for modern problems, so we create new languages and discard the old ones, including forgetting useful ideas those languages contained. Sometimes, we come back to some of those ideas. So a dynamic language decides that types are in fact quite useful, and a single exe file is so much simpler to distribute than endless tiny script files, and maybe speed does matter after all.
Not passing judgement, just saying that's how it is. And it is rather odd isn't it?
We use maintained operating systems that started decades ago - there are basically no good maintained options outside of Unix and Windows these days.
You need a seriously extreme number of testers to have a relatively bug-free operating system. We run proprietary RTOSes for some stuff at work and the number of weird bugs are crazy. We have to reboot every 280-some days because otherwise the machine will crash, IGMPv2 randomly stops working after a couple months - there's no v3 implementation at all, weird hacks just to make the thing boot, etc. And that's on top of the fact that their semi-official ports of modern open source tools don't work half the time and haven't been updated in years.
You really don't want to mess around with esoteric operating systems if you want any chance of having a stable useful application. OSes just do too much.
Is it possible to do the same things in C that we can in Ruby, PHP or Node? Absolutely. But can it be written in the same time frame?
While I'm sure there are HNers out there who can - or who at least claim they can ;) - let's ask ourselves if that's really broadly truthful outside of trivial example applications. I'd wager 'no'.
Those higher level languages might 'forget' something in the past and 'rediscover' it but I feel like that's kind of a very minor sub-plot in the larger story of the usefulness of their abstraction and ability to represent more powerful ideas in less lines of code.
* - read 'web'. Old and low level languages are still obviously used in a wide variety of projects and industries.
Yes, the "pure" Unix tools are awful, GNU improved on their usability a lot. But they're still a simple command that does something.
Except Autotools. Those should burn in eternal damnation.
In all seriousness, what's your preferred alternative? Seems like Autotools is a pain, but it gets the job done and is widely available. I haven't found a build system for C projects that is:
- Less complicated
- Available from default package repos so others who clone don't have to track down some esoteric package themselves
- Free software that runs standalone on a shell, not in an IDE or whatever
Autotools sucks big time, and what it does has been largely unnecessary since around the turn of the millenium [1]; but since it's used almost everywhere in infrastructure (often decades-old) software you have to deal with it.
If you pull a 927 and make a grand unified build system, you get something like CMake which sucks even more (its own build process takes longer than that of the software it's supposed to build, need to deal with C++, have fun with CMakeLists build errors and customizations, etc.).
I believe git's build system is just a bunch of (or a single) Makefile. That's what an optimal build (but not mine, unfortunately) looks like. Though, pure (POSIX) make is insufficient for anything non-trivial IMHO.
phk's famous rant on libtool:
The script takes into account differences in operating systems, without including thousands of lines of weird little leftovers from 30 years ago when you needed to check if you were actually running on a 16-bit Data General machine or whatever (I'm looking at you, autoconf)
Autotools sucks. But everything else sucks more. There's a life lesson there, somewhere.
It also has better Windows support than autotools.
;) cmake is actually exactly what I had in mind when I wrote that. Maybe I haven't used it enough, but I find it basically just trades Makefile.am everywhere for CMakeLists.txt everywhere.
Windows is OK for non-techies (being generous but there aren't that many real choices if you're e.g. Buying a computer from a store and don't know how to install an OS) but you really need a VM to do some types of work (though the Ubuntu subsystem is pretty awesome and now we have mobaxterm instead of just cmd.exe and putty).
Linux is fine for techies / power users but requires customization to get to the productivity levels that Mac gets to (IMO). Non-techies wouldn't be able to achieve the same thing or probably even install it in the first place.
You can buy a Mac in a box from a store and pay someone at the store to help you if it breaks or you don't understand how to do something. You can develop iOS apps on it. It also looks cool to people who don't know any better and people who do. Daft Punk and almost every other musician who works with computers on a stage uses Mac.
They all have their place and I run all 3 at home (Win desktop for gaming and some browsing, Linux laptop for personal programming and browsing + travel, Linux desktop for my home electronics lab bench mostly for embedded development, Mac laptop for work, FreeBSD for a NAS, MIPS Debian for router)
Sorry but OH MY GOD. After 4 years of obsessive, hours-a-day usage of this macbook, I never realised I could do any of this. Literally just ctrl-K'd in Chrome's address bar. This is just next level. THANK YOU.
Yes, but it also has a slow, not customizable animation when changing desktops, uses arbitrary keybindings you can't remap easily and generally imposes lots of choices on its users without any way to opt out from them.
I was forced to switch from a very personalized Fedora/StumpWM setup to Mac OS and it was a disaster. For the first time in decades(!) I had to pay for external programs to customize things. And even with these, there are features I simply can't disable. It's been seriously harsh. It looks like the entire platform has lost all interest in customizability but, for me, customizability is one of the basic requirements for any tool.
And the last time I came across one of those I compiled and used modern tools.
Because even 20 year old Linux versions had tab complete and a vi that worked with directional keys
I do occasionally ssh into boxes were I am a lame user without compilers installed.
(At least they have ssh and not telnet)
What you can sometimes do is pick an alternate shell or find some other editor someone 'left lying around' (even typing vim instead of vi can give you something different)
And sometimes "tab completion" works with \ or ESC or something similar, I don't remember exactly
Well I recently went into ones that only had ssh, but then files were also copied over plain FTP or NFS.
What was more amazing was people using X for accessing a terminal. You know, because that's how someone told to use it, so they just went with the flow.
This isn't windows, after all.
1 - You can put them there;
2 - You have enough quota;
3- $HOME isn't mounted as noexec;
4 - IT don't have scripts that purge $HOME from executables, which the corresponding penalties for the respective user when found.
I am not a UNIX newbie, although I favor Windows.
I know UNIX since Xenix, and used DG/UX, Aix, HP-UX, Solaris, OS X, FreeBSD and lots of GNU/Linux distributions starting with Slackware 2.0.
After a decade of using UNIX like systems, and Windows as well, while researching everything that came out of Xerox PARC, and being an Oberon user for a short while, I came to realize that Apple and Microsoft developer cultures are closer to Xerox dreams of how computing should look like, than UNIX where X Windows is just a manager of xterms.
Also I never was a big fan of C, even back on MS-DOS days, where I would rather use Turbo Pascal or Turbo C++.
I worked in a Solaris shop that had gnu coreutils and packages installed everywhere with a <g> prefix, and another place running openbsd which had the same.
gecho, gcat, gln etc;
I'm pretty sure gnu coreutils can be built on any Unix-like OS.
- base64encode it
- paste the encoded text over ssh to a file
- base64decode it
- chmod +x the decoded file
- …
- profit
- Disable execution bit for all directories for home
- If the UNIX variant allows it, jail/contain home for each user session
- Punish users or their employer if a consulting firm severely that bypass IT regulations
So I wanted to ask: where such a level of security would be required? And also, what attacks does it defend from?
/usr/bin/env $your_binary
You'll probably go insane doing it
(Linux x86 compiling to Linux ARM/PPC/etc is doable and done quite frequently)
Some of it is long obsolete. For example, Usenet/NNTP is rarely used today. And many of the specific implementation problems they mention are long-fixed on modern systems.
Some of the problems they note are still valid. Some of the challenges of dealing with filenames are absolutely still true; because filenames are sequences of bytes (NOT sequences of characters), and allow stuff like leading dash, control characters, and non-characters, you can have a lot of problems. See the stuff on page 168-171. I talked about this in https://www.dwheeler.com/essays/fixing-unix-linux-filenames.... and https://www.dwheeler.com/essays/filenames-in-shell.html
That said, there are reasons that Unix-like systems took over everything. Many of their complaints are from lack of consistency. But some loss of consistency is inevitable when you have a marketplace of many people with many ideas. Many of the other systems they remember fondly were often tightly controlled by a small number of people - they were more consistent, sure, but they were also slow to implement newer ideas. When you're running a race, the one who runs faster usually wins.
Are there any successful non-UNIX-y OSes that are worth checking out?
I may embarrass myself here, but I was under the impression that BSD, Plan 9, Solaris and HP-UX were all UNIX-y ...
Bear in mind that when this book was written, the average desktop PC was running MS-DOS, and possibly Windows 3.1 if it was new and powerful enough.
What UNIX is being compared to is the other mainframe OSes of the 1980s, from DEC's VAX/VMS to IBM's OS/360 and OS/400
http://www.cs.vu.nl//~ast/reliable-os/
Microkernels are also favored in the safety- and security-critical niches in high-assurance systems. Although niche, it's tens to hundreds of millions of dollars in activity over the past decade. Seemed worth adding as a surviving paradigm given that. One of more successful ones below.
http://www.ghs.com/products/safety_critical/integrity-do-178...
In regards to IDEs, frameworks, programming languages culture.
Very 90's, but I think this is what I was actually looking for ;) https://en.wikipedia.org/wiki/OpenVMS
The coherency of VMS (and the VAX platform) is quite amazing -
Coherent command line interfaces, API's, documentation, hardware, and software, even down to coherent part numbering made by a single company, from small workstations up to larger scale minis, and nearly transparent clustering.
I mention VAX specifically, since by the time Alpha arrived, DEC was competing in a much different environment, and was subsequently merged, etc etc etc.
IBM and other mainframe-ey OS's, though definately arcane, have some amazing facilities (parallel sysplex.. multi architecture systems that are completely redundant and hot-swappable) and capabilities since the late 60s/70s which are only now being caught upto in crude and hackish form at the present time with commmercial PC servers.
BeOS had some cool concepts.
The versioning filesystem is something I've waited for since I first used VMS (1991) and discovered such a thing existed. Though to be fair recent Windows and OSX versions have something like it, it's not the same.
It was. This is one of the reasons outside of its legendary reliability that I keep bringing it up. It's a cathedral where most things fit. There was cruft to deal with. Overall, the pieces work very well together as the teams had a coherent vision for how they wanted the system to work. It also integrates solutions to problems such as distributed locking and node failures that other systems dump on the app developers.
Not to mention I never got these testimonials or personal experiences when I started with UNIX...
[1] https://www.wherry.com/gadgets/retrocomputing/vax-simh.html
http://www.openvmshobbyist.com/news.php
You can sign up as a hobbyist here:
http://plato.ccsscorp.com/hobbyist_registration.php
someone will email you in the next day or so with a license installer and the URLs to download the software.
Also they have the Alpha version of OpenVMS available.
https://news.ycombinator.com/item?id=10957020
"Successful" was mostly social and economic factors rather than technical. The most successful in mass market are the OpenVMS variant called Windows, an OS building a GUI platform on a UNIX/Mach hybrid, UNIX OS's such as Linux, and an OS building a user-space platform on Linux. UNIX's and BSD-licensed code allowed companies to save money & increase adoption building on existing code/ecosystem that had tons of momentum. Mainframe OS's are still going pulling in huge revenues, including MCP via Unisys (Burroughs renamed post-merger). IBM i's succeeded AS/400 that succeeded modern System/38. Microkernels and mainframe VM's got reinvented as modern clouds with VM's or containers. Legacy continues even if original products mostly died out.
Yeah, that's what I'm curious about. Could you name names? :)
Things like ubiquituous scriptability of apps via Arexx (the language is awful, but you don't need to use the language much to call the APIs), heavy multi-threading throughout the OS, datatypes (new image format? drop a library in the right directory and every application that knows how to load images via datatypes can load it; same for text/documents, sound etc.), assigns (think of it a bit like $PATH, but not limited to a single variable, and enforced OS-level, so e.g. C: in AmigaOS works roughly like $PATH, but by default there's also LIBS: for libraries, T: for temporary storage, CLIPS: for the clipboard, and by convention people tend to have e.g. WORK: pointing wherever you want your project data - you can define your own, and redefine them at will, and they can refer to eachother, so e.g. your "C:" may refer to System:C and Work:C (at the same time), and either System: or Work: or both can be either partitions or labels assigned to removable media (in which case the OS may ask you to insert the right disk if you reference it - it can reference a specific disk rather than just the drive), or to another assign).
Or workspaces as an OS-level construct (Screens) that applications can open, close and manipulate, either for "private" use for just its own windows or by opening public screens that can be used to combine windows from multiple applications.
Or third party standards like XPK, which lets any application transparently support file compression - similar to datatypes you can drop in a library forany compression algorithms and all the apps gains support for it (there are several similar standards for e.g. archivers, disk images etc.).
Current mainstream OS's still feel very backwards in many ways after being used to those things.
Later, when you get a harddrive (or decide you like the app and want to continue using it), you can copy it to the harddrive (wherever you want) and add an assign "FOOAPP=MY_APPS:new/fooapp" and the application will still work just fine.
It's still something I miss.
About as close as you can get and stay relevant to the modern world is Emacs, which, while a lot of fun, I gather from those with real Lisp-M experience isn't really all that close. And it says something, I think, that the next former Lisp-M user I meet who has a bad word to say about that platform will be the first one.
In general, the book does these systems more justice than I can, and it's a fun read in general. I recommend it quite highly - in those areas it covers where I have experience of my own, I found little with which to disagree and much with which to laugh.
Also bear in mind that they were designed by programmers for programmers. They were not intended for the general public.
No. The file system did auto-versioning, so you could generally recover recent history of a file, but there was nothing that "tracked all changes everywhere".
Well, ZMacs (the editor) did have unbounded 'undo' functionality, and you could even select a function and undo changes to that particular function, even if those weren't the most recent changes to the file. Maybe that's what you have in mind.
Their UI was powerful and efficient, but not easy to learn. They were designed by programmers for programmers. Their UI assumed that you were willing to invest nontrivial time and effort learning a broad palette of specialized tools.
Their system design made some pretty different assumptions about how they were going to be used, and the environment they would be used in. For example, LispMs didn't have any kind of security or memory protection. They were wide open systems.
The big cost driver at that time was memory and peripherals like disks.
The lab I worked for had slow SUN SPARCs. The idea was that you would net boot them and they would get their software from a main server. Relatively cheap. But it turned out a bit slow and clunky. People then often used their office Macs for software development, with Macintosh Common Lisp.
Besides which, a system that was so much designed for programmers was probably never going to command a very big market.
I'd be interested to hear this expanded upon.
This process is facilitated by the ability to at any point save the state of the process for later resumption. These saved states are called "heaps" or "images" or "worlds". Start up one of them and you are more or less instantly returned to the last state you were in when the process was last running.
LispMs extended this model to the entire machine.
There are advantages and disadvantages. The advantages are legion, and they can enormously accelerate development in the hands of someone comfortable with that mode of working.
There are two main types of disadvantage. One is that, since you are interactively modifying a live, running system, if you make a mistake, the mistake becomes part of the running system. If you save the image with that mistake in it, it becomes part of the system in future sessions, too.
The second problem is that it becomes troublesome to separate your application from the scaffolding that you've used to build it. To take a very simple example, suppose you construct a few simple data structures for testing purposes. Those test structures then become part of the running system, and there is a risk that your application will inadvertently come to depend on their values, leading to obscure bugs if they change or if the application is deployed without them.
There are reasonably straightforward ways to deal with both classes of problem, and properly-designed Lisp and Smalltalk systems include tools that help solve these problems, but it's appropriate to acknowledge them as problems.
I like old-fashioned Lisp and Smalltalk systems, and I like image-based development. I prefer the programming model in which I am teaching the process to be my application, and I'm much more productive in such an environment than in the now more-mainstream, model where programming is more like building something from a blueprint than it is like teaching something to behave the way I want.
But that doesn't mean I don't acknowledge the problems of image-based development. They exist. They are solvable, but they do exist.
Actually a typical Symbolics 3600 didn't boot much longer than a SUN... my NXP1000 Lisp Machine boots in three minutes from a very large image.
Much of what we assume every OS does today was cutting edge development in 1990.
If your only other choice is assembly language, then C starts to look really good. You don't complain about weird function interfaces, because at least you have functions!
- Amiga OS / Morph OS
- Menuet OS / Kolibri OS. minimalistic and 100% written in Assembly.
Especially the chapter on NFS was a fun read. When I first set up my home server, I had my desktop lock up completely a few times when the server became unavailable, because of NFS. (Then I found out one can mount NFS shares in interruptible mode so the requests will eventually time out... but it was so annoying up to that point.)
For example, mandatory file locking. I bumped into this in a project once.
We wanted to prevent concurrent read/write access to a particular file (a serial device, actually). Unfortunately there was no simple and reliable way to do this on Linux.
The "traditional way" of doing this is via lock files: you create a file "somewhere", and other applications are supposed to check if this file exists before operating on the locked file.
But you have three problems here: 1) the location of the lock files is not standard 2) there are race conditions with checking for the existence of the lock files and creating lock files and, most critically, 3) applications can still ignore the lock file at their leisure.
There is also flock() (not mentioned in the book, IIRC, I think it was added to Linux at a later date). But it still blows because it only solves (1) and (2). You can flock() all you want, if applications don't care for it, they can still do whatever they want.
We just ended up accepting our losses, used flock() for our applications, and hoped for the best.
And before you say that all those operating systems are based on Unix; that's true but it's mostly just an implementation detail. There's no reason, for example, that Chrome OS couldn't be based on an entirely different kernel and still have the same permissions model, and most Unix-like systems don't have fine grained permissions like this out-of-the-box.
It's now also a standard on WinRT/UWP on Windows8/10.
Android was very late to the party regarding fine grained security. Google knowingly put billions of consumers at risk for a long time. And even today its security a nightmare.
https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua...
https://en.wikipedia.org/wiki/Security-evaluated_operating_s...
A lot of the lower-level criteria require features present in operating systems we all use from day to day.
Out of the box, most system with no public services running are usually decent (and that's hard to do with some systems). Beyond that it all comes down to configuration. There is no "most secure" OS. You can set them all up to be insecure or secure.
It was proven impossible to fully secure by high-assurance engineers back when INFOSEC was being invented. UNIX was much smaller back then. Project such as UCLA Secure UNIX and products such as Trusted Xenix were still unable to reach high assurance due to problems baked into the architecture and UNIX principles themselves. Even with API changes, they still had problems with covert channels. That led the inventors of INFOSEC to abandon UNIX for secure applications in favor of clean-slate, security kernels with user-mode or deprivileged layers for legacy, UNIX apps. Anything truly trustworthy runs directly on the security kernel.
re secure OS's
Probably INTEGRITY-178B or Turaya with Linux VM's for now. Maybe SourceT for network appliances. They're sold for nice sums of money to militaries, governments, and companies with nice budgets. GenodeOS is working toward a FOSS version of Nizza architecture.
http://www.ghs.com/products/safety_critical/integrity-do-178...
https://os.inf.tu-dresden.de/papers_ps/nizza.pdf
http://www.perseus-os.org/content/pages/Architecture.htm
https://secure64.com/secure-operating-system/
Two of the original, high-assurance systems are still around for OEM license from BAE (STOP) and Aesec (GEMSOS). We've learned a lot of ways to break stuff since then. Who knows what current level of assurance is. ;)
http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf
There's also language-based approaches being investigated that could be done in something more trustworthy than Java:
http://www4.cs.fau.de/Projects/JX/
Finally, there's CPU's designed to do isolation, reliability, and so on at the gate level. Rockwell-Collins uses one in their guards and crypto appliances. Sandia has a high-assurance Java CPU. Industry also sells Java CPU's for embedded that might be converted into some safe execution platform combined with something like JX. Call these building blocks for secure OS rather than the OS itself.
http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf
https://www.ajile.com/index.php?option=com_content&view=arti...
https://goo.gl/photos/gHvGwHpC3z5KxLv59
(edited link so that people don't need to login to google to see it.)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>UNIXUX: Click on the cursor.</TITLE>
<META NAME="Author" CONTENT="Don Hopkins">
<META NAME="GENERATOR" CONTENT="User-Agent: Mozilla/3.0Gold (Macintosh; I; PPC)">
</HEAD>
<BODY TEXT="#7CFE5A" BGCOLOR="#191919" LINK="#FF0000" VLINK="#FF3333" ALINK="#00FEFA">
<P><B><TT><FONT SIZE=+1>UNIX HATERS Release 2.0 (unixux)</FONT></TT></B></P>
<P><B><TT><FONT SIZE=+1>login: <BLINK><A HREF="password.html">_</A></BLINK></FONT></TT></B></P>
</BODY>
</HTML>While it is mostly long usenet rants about the _failure_ of Unix. There is some grains of truth buried in 80's-esque proto-shit-posting.
Yes, Garfinkel, et al., don't know what a "client" and "server" are.
What do you think "client" and "server" mean, and what do you think is wrong with that paragraph-length footnote (besides its length)?
Could you please try to rewrite it more accurately or in fewer words?
The X use of "client" and "server" is correct. The "remote machine"/"local machine" thing isn't.
See my other reply: https://news.ycombinator.com/item?id=13783802
Edit: Forgot to refer to you as Al. (Dang it, this is why I can't have nice jokes.) Apologies!
It makes sense when one thinks about it, but it's still strange until one gets used to it.
The X server is called a server because it is a server and X clients are clients.
It's excusable to be confused by the terminology, as in the quote, of course. Unless you claim to understand the whole "network" thing.
The second point is sadly neglected. If you read it and your principal reaction is "Unix isn't like that anymore" you've completely missed the point.
It's not really Unix, sometimes it's Macintosh with GNU tools installed but mostly it's CentOS or Debian servers where all this magic takes place.
Sure I need to have a lot of stuff in that thick head of mine to do magic, but the joy of stringing together a series of commands to solve a problem my windows using co-workers would have to spend license money to solve is just amazing.
Hating Linux is definitely right if you're looking from the perspective of universal user friendliness. But for true power users, the programmers, the scientists and the sysadmins; I can't picture life without it.
- Giving it away to universities?
- The C programming language?
What am I missing?
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
All the alternatives had lots of zeros on their price tags.
C just came along, like JavaScript on the browser.
We already had better system programming languages since Burroughs B5000 in the 60's.
http://www.unisys.co.uk/offerings/high-end-servers/clearpath...
Mt Xinu (commercially supported 4BSD for anyone with a usable source licence) was wildly popular at university labs where TCP/IP was immediately useful for local internetworking across disparate minicomputers, and the distribution included translation, bridging, tunnelling and so forth of other protocols (DECNET, AppleShare) over IP.
Additionally, their port to x86 let humble 386SX microcomputers do the work of much more expensive minicomputers, and was "legit" in a way that USG argued Bill Joy's 386BSD was not.
Notably UNIX distributions where source licencing was exceptionally expensive (or otherwise rare) did quite badly in settings where BSD -- supported or otherwise -- was usable.
Crucially, the University of California decided to support the release of 4.4 BSD-Lite, which had all the AT&T/USL proprietary code removed, both for research purposes and in the obvious knowledge that "someone" would make Lite usable by filling in the missing functionality.
"Someone" was largely BSDI, which survived USL's lawsuit; other independent Lite completions also benefitted from this victory, and FreeBSD/NetBSD/OpenBSD are descendents of one of those.
Additionally, Linux came along.
So I think you got it mostly right in the first line.
C was mostly along for the ride; a usable compiler, toolchain, and programming environment (ed/ex/vi, lint and so forth) was included in the source distributions, and the "p" in pcc was its claim to be readily portable to arbitrary architectures (which was almost true, in part because it was written in C itself). Had it been a language other than C, that probably would have become the systems programming language instead. (Indeed, UNIX was a bit odd in that the number of general languages considered standard was tiny; for example, compare the number of languages one could use on TOPS-10 (six standard) and TOPS-20, which were never intended to run on arbitary hardware).
On the consumer and small business end, there were DOS/Windows boxes, WindowsNT boxes, and Macs, of course. But OS/2 was still a thing, Win95 was around the corner, and, while on the decline by 1994, Atari and Amiga devices were still somewhat sensible options for e.g. music or gaming a few years earlier.
On the corporate end, and more saliently for this specific book, you still had plenty of mainframes and such around, and an equally rich variety of options. Some of these computers were called Lisp machines, and built around Lisp rather than Unix/C. They had started to lose traction after the onset of AI Winter:
https://en.wikipedia.org/wiki/Lisp_machine
https://en.wikipedia.org/wiki/AI_winter
The authors of the book basically are Lisp aficionados who mourn the good old days when they could get by using elegant Lisp machines instead of clunky, user hostile Unix boxes.
The book itself is an entertaining read insofar as I can remember. (My memory might be playing tricks on me though; I read it 10-15 years ago.)
The authors obviously cherry pick to maximize Unix bashing. The authors make a number of very valid points - some of which still apply today. The tone is usually playful. But then, at times, contempt with a pinch of self-importance emerges, and you're left wondering why you're bothering to continue reading a 300+ page long rant... only to realize that the points made are so obnoxiously valid (or, at least, were when I read it) that you continue.
Dennis Ritchie's anti-forward passage return the favor, too:
> Your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.
Harsh words from Dennis, RIP.
Seriously though, I think almost everyone has a pick of different books that influenced them the most and helped them to become the best developer that they could be, and while most of the time they are contained within a single set of books, it's kind of fruitless to buy books you might not find interesting with the promise of "They will make you a good developer". I have a fair amount of books I find difficult to read because of the style, etc. that I bought with that promise, and none of them improved my programming ability significantly more than a bunch of coding + an internship has.
[What I would recommend is finding authors that you like reading andor tend to get a lot from]
The architecture was layered, too, so you typically only ever used one book at a time. Doing raw graphics operations? All you need is the Xlib book. Xt/Xaw? There's a book for that. Motif? There's a book for that, too, but it wasn't in our set.
The raw X protocol was, IIRC, documented in volume 0.
[1] https://en.wikipedia.org/wiki/Ajax_(programming)#History
[2] http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Its architecture was more similar to modern web apps, with the UI running code and processing events on the client machine.
I once saw a great demo of it by its author, Stephen A. Uhler. For some reason, from then on, I always associate MGR with great big bushy moustaches.
https://media.licdn.com/mpr/mpr/shrink_150_150/p/2/000/013/3...
Both NeWS and NeXT were using Display Postscript (https://en.wikipedia.org/wiki/Display_PostScript). Do you know if NeWS was an inspiration for NeXT ?
In NeWS you could write your client applications completely in PostScript (or something compiled down to PostScript) and it had its own object-oriented, multi-threaded environment with event handling etc.
NeWS was more of a predecessor for Java than NeXT.
It's no coincidence that NeWS and Java were both designed and written by James Gosling.
It could be said that Java rose out of the ashes of NeWS.
Although I wouldn't go as far as to say that NeWS rose out of the ashes of Gosling/UniPress/EvilSoftwareHoarder Emacs and Mocklisp. But Gnu Emacs did! ;)
However, at UniPress we did develop a nice NeWS display driver for Emacs that worked efficiently over a slow network connection, providing local interactivity like text selection feedback, control panels, pie menus, multiple tabbed windows, etc.
Here's the PostScript source code of the UniPress Emacs 2.20 NeWS display driver [1], and a screen snapshot [2] of Emacs as an authoring tool for the NeWS version of the HyperTIES hypermedia system (plus a diagram of HyperTIES extensible client/server architecture).
[1] http://www.donhopkins.com/home/archive/emacs/emacs.ps.txt
http://donhopkins.com/home/archive/NeWS/pizzatool.txt
...and here's a link to a HN thread a few months ago where Don Hopkins talks about Postscript and windowing systems; lots of good links there:
https://www.yelp.com/biz/tony-and-albas-pizza-and-pasta-san-...
Also La Costeña, home of the World's Largest Burrito, is now at 235 E. Middlefield Rd. in Mountain View.
And Cho's Mandarin Dim Sum has moved to 209 1st St. in Los Altos. (The rent for his hole-in-the-wall on California Ave. in Palo Alto was too high!)
https://www.yelp.com/biz/chos-mandarin-dim-sum-los-altos
Please update your programs!
HyperNeWS could do some neat things - e.g. you could draw a shape (any shape!) in the graphical editor and paste it as the shape of a window, all without writing any code.
Edit: changed "uses" to "used" - was quite a long time ago!
NeXT's Display PostScript architecture was not concerned with networking, extensibility, providing local interactivity, or reducing client/server communication by downloading code, which is what the modern term "Ajax" refers to.
Here is one of Gosling's earlier papers about NeWS (originally called "SunDew"), published in 1985 at an Alvey Workshop, and the next year in an excellent Springer Verlag book called "Methodology of Window Management" that is now available online for free. [1]
Chapter 5: SunDew - A Distributed and Extensible Window System, by James Gosling [2]
Another interesting chapter is Warren Teitelman's "Ten Years of Window Systems - A Retrospective View". [3]
Also, the Architecture Working Group Discussion [4] and Final Report [5], and the API Task Group [6] have a treasure trove of interesting and prescient discussion between some amazing people.
[1] http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Methodology of Window Management
F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams
29 April 1985
This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme.
The Proceedings were later published by Springer-Verlag in 1986.
[2] http://www.chilton-computing.org.uk/inf/literature/books/wm/...
5. SunDew - A Distributed and Extensible Window System
James Gosling
SunDew is a distributed, extensible window system that is currently being developed at SUN. It has arisen out of an effort to step back and examine various window system issues without the usual product development constraints. It should really be viewed as speculative research into the right way to build a window system. We started out by looking at a number of window systems and clients of window systems, and came up with a set of goals. From those goals, and a little bit of inspiration, we came up with a design.
GOALS
A clean programmer interface: simple things should be simple to do, and hard things, such as changing the shape of the cursor, should not require taking pliers to the internals of the beast. There should be a smooth slope from what is needed to do easy things, up to what is needed to do hard things. This implies a conceptual organization of coordinated, independent components that can be layered. This also enables being able to improve or replace various parts of the system with minimal impact on the other components or clients.
Similarly, the program interface probably should be procedural, rather than simply exposing a data structure that the client then interrogates or modifies. This is important for portability, as well as hiding implementation details, thereby making it easier for subsequent changes or enhancements not to render existing code incompatible. [...]
DESIGN SKETCH
The work on a language called PostScript [1] by John Warnock and Charles Geschke at Adobe Systems provided a key inspiration for a path to a solution that meets these goals. PostScript is a Forth-like language, but has data types such as integers, reals, canvases, dictionaries and arrays.
Inter process communication is usually accomplished by sending messages from one process to another via some communication medium. They usually contain a stream of commands and parameters. One can view these streams of commands as a program in a very simple language. What happens if this simple language is extended to being Turing-equivalent? Now, programs do not communicate by sending messages back and forth, they communicate by sending programs which are elaborated by the receiver. This has interesting implications on data compression, performance and flexibility.
What Warnock and Geschke were trying to do was communicate with a printer. They transmit programs in the PostScript language to the printer which are elaborated by a processor in the printer, and this elaboration causes an image to appear on the page. The ability to define a function allows the extension and alteration of the capabilities of the printer.
This idea has very powerful implications within the context of window systems: it provides a graceful way to make the system much more flexible, and it provides some interesting solutions to performance and synchronization problems. SunDew contains a complete implementation of PostScript. The messages that client programs send to SunDew are really PostScript programs. [...]
[3] http://www.chilton-computing.org.uk/inf/literature/books/wm/...
4. Ten Years of Window Systems - A Retrospective View
Warren Teitelman
4.1 INTRODUCTION
Both James Gosling and I currently work for SUN and the reason for my wanting to talk before he does is that I am talking about the past and James is talking about the future. I have been connected with eight window systems as a user, or as an implementer, or by being in the same building! I have been asked to give a historical view and my talk looks at window systems over ten years and features: the Smalltalk, DLisp (Interlisp), Interlisp-D, Tajo (Mesa Development Environment), Docs (Cedar), Viewers (Cedar), SunWindows and SunDew systems.
The talk focuses on key ideas, where they came from, how they are connected and how they evolved. Firstly, I make the disclaimer that these are my personal recollections and there are bound to be some mistakes although I did spend some time talking to people on the telephone about when things did happen. [...]
[4] http://www.chilton-computing.org.uk/inf/literature/books/wm/...
[5] http://www.chilton-computing.org.uk/inf/literature/books/wm/...
19. Architecture Working Group Discussions
19.1 INTRODUCTION
The membership of the Architecture Working Group was as follows:
George Coulouris (Chairman). James Gosling. Alistair Kilgour. David Small. Dominic Sweetman. Tony Williams. Neil Wiseman.
[...] The possibility of allowing the client process to download a procedure to be executed in response to a specific class of input events was discussed, and felt to be desirable in principle. However, more work was needed to establish the practicality in general of programmable window managers. The success of Jim Gosling's SunDew project would be an indicator, but it was felt that it would be fruitful to initiate a UK investigation into this issue. John Butler pointed out in discussion that in the Microsoft MS- Windows system an input event received by a client process could be sent back to the window manager for interpretation by one of a set of translation routines. [...]
[6] http://www.chilton-computing.org.uk/inf/literature/books/wm/...
21 Application Program Interface Task group
[...] There was a strong feeling that, at this stage in their development, window managers need to be very flexible. The downloading-of-procedures idea in James Gosling's work was seen as a nice way to achieve this. In this context protection issues were seen to be important. There need to be some limits on loading arbitrary code, especially since the window manager has in some sense the status of an operating system in that it must be reliable and not crash. One idea for achieving protection was through the use of applicative languages which are by their nature side-effect free. [...]
21.4 DISCUSSION
Teitelman: Referring to point (3) in your list, can you characterize the conditions under which a window manager would refuse requests from a client? It feels so soft that the user might feel uneasy. Is the window manager surly? Is it the intention that requests are honoured most of the time, and that failure is rare?
Gosling: Yes, but failure should be handled gracefully.
Bono: I think that there are two situations which arise from the same mechanism. The first is occasional failure such as a disk crash. The program environment should be robust enough to deal with it. The other situation is where device independence is written into the system. What happens if a colour device is used to run the program today, where a black and white device was used yesterday? This may show up in the same mechanism, so you cannot say that it is rare.
Gosling: When an application makes a request, it should nearly always be satisfied. The application program can inspect the result to see if it is satisfied exactly. If it asks for pink and it doesn't get it, it should be able to find out what it did get. Only then should the application deal with the complex recovery strategy that it may need. We need some sort of strategy specification. What sort of strategy should we use to select a font or colour if there is no exact match? What feature is more important in matching a 10 point Roman font, its size or its typeface? At CMU, if you point at a thing and want 14 point Roman you may get 14 point Cyrillic, which is not very useful. On point (7), are you implying a dynamic strategy, or one determined at system configuration?
Gosling: Harold (Thimbleby) is all for downline loading this. In reality this is not usually very easy. GKS adopts a compromise - an integer is used to select a predefined procedure. As you may only have 32 bits, this does not give you many Turing machines. Something of that flavour would not be a bad idea.
Cook: Justify synchrony in point (2).
Gosling: This is mostly a matter of complexity of program. Not many languages handle asynchrony very well. If we have Cedar or Mesa then this is possible.
Teitelman: How we do it in Cedar is that the application is given the opportunity to take action. In Mesa we require that the application catches the signal and takes any action. In the absence of the application program intervening, something sensible should be done, but it may impose a little bit more of a burden on the implementer.
Gosling: In Unix software there is no synchronization around data objects. In Cedar/Mesa there are monitors which continue while the mainline code is running; there are no notions of interrupt routines.
Teitelman: This is a single address space system. We are unlikely to see this in Unix systems.
Newman: How realistic is it to design an interface using your criteria?
Gosling: Bits and pieces already appear all over the place. The CMU system deals with most of this OK, but is poor on symmetry. The SUN system is good for symmetry, but not for synchrony. It is terrible on hints, and has problems with redraw requests. There is no intrinsic reason why we can't deal with all of these though. The problem is dealing with them all at the same time.
Williams: A point that I read in the SunWindows manual was that once a client has done a 'create window' then the process will probably get a signal to redraw its windows for the first time.
Gosling: Right, but it's a case of maybe rather than will. Some programs may redraw and redraw again if multiple events aren't handled very well, and give screen flicker.
Hopgood: Do you have a view on the level of interface to the window manager?
Gosling: Clients don't want to talk to the window manager at all, but should talk to something fairly abstract. Do you want to talk about this as the window manager as well? The window manager shouldn't implement scroll bars, or buttons or dialogues, we need another name for the thing which handles the higher level operations.
One day it'll win :) Actually I think we could do NEWS in JS. Somehow I don't feel that would make you happy tho :P
https://en.wikipedia.org/wiki/NeWS
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
used PostScript code instead of JavaScript for programming.
used PostScript graphics instead of DHTML and CSS for rendering.
used PostScript data instead of XML and JSON for data representation.
For me, I've been using Linux fulltime for the last 15 years and I have never, not even once, had the need to connect to a remote X11 server. ssh has always been enough for me.
They just added another layer, flipped the words "server" and "client" around, and added more hardware.
Now you run the web browser client on top of the local window system server, through shared memory, without using the network. And both the browser and GPU are locally programmable!
And then the local web browser client accesses remote web servers over the network, instead of ever using X11's networking ability.
One way of looking at it in the X11 sense is that a remote app running in the web server acts as a client of the local window server's display and GPU hardware, by downloading JavaScript code to run in the web browser (acting as a programmable middleman near the display), and also shader code to run in the window server's GPU.
Trying to pigeonhole practices like distributed network and GPU programming into simplistic dichotomies like "client/server," or partition user interface programming into holy trinities like "model/view/controller," just oversimplifies reality and unnecessarily limits designs.
You mean client, not server.
(ducks for cover)
You mean X-Windows, not X11.
(ducks for cover)
On the other hand, typical applications (ie. games) usually expect that the channel to GPU has quite large bandwidth and no meaningful latency, which simply isn't true for any kind of network connection.
Now 'most' is a relative term, but I do not think that's true at all. There are very few applications that use OpenGL. Obviously games are an exception, but if you count in all GUIs I would say mostly target X11 (via Gnome or KDE).
To give you an example, think about desktop effects. On Windows, several applications such as Explorer makes parts of their windows semi-transparent. It's a nice simple effect that is impossible (without tons of hackery) to replicate using X11.
I don't think that this qualifies as "tons of hackery" given the fact that other contemporary UI systems with truly transparent windows implement it in same way (IIRC in pre-Vista Windows truly transparent windows are supported on the OS level but the implementation involves hacks with backing buffer and synthesized expose events).
Stupid, stupid Nvidia drivers...
I'd much rather have a real API with rich app-specific functional or event interfaces to call, and to be able to pass actual typed parameters instead just a stream of bytes, including structured data like json, s-expressions or PostScript data, or even (gasp) Turing complete programs, like PostScript code!
NeFS, as defined in 1990 in the infamous NFS3 proposal aka "Network extensible File System Protocol Specification" did just that, and it was actually a great idea too early for its time. So it went over like a lead balloon, and was never actually adopted.
NeFS should not have been framed as a successor to NFS, because it required a revolution in how programs interacted with the file system. And of course there are the security and stability implications of running downloaded code in the kernel, which hadn't been properly addressed. ;)
Take for example (shown below) the act of copying a file to a backup file in the same directory.
With traditional NFS, the server would have to send each block of the file to the client, which would then send it back to the server, which would then write it to disk. That required a lot of network traffic, as well as many context switches between user and kernel space on both the client and the server (at a time in history where they were extremely expensive).
Instead, the client could just send a simple PostScript program to the server (or call one that was loaded from a library or sent previously -- see the example below), which copied the file in the kernel of the server, without sending it over the network, or requiring any context switches on either the client or server.
That's several orders of magnitude more efficient in terms of both CPU and network usage, and just the simplest and easiest to explain example possible of what you could do.
Just imagine how much more efficient, powerful and tightly integrated together other utilities like "find" and "grep" could be, tightly woven together procedurally in the kernel instead of communicating with a stream of bytes over a pipe!
http://www.donhopkins.com/home/nfs3_0.pdf
Introduction
The Network Extensible File System protocol(NeFS) provides transparent remote access to shared file systems over networks. The NeFS protocol is designed to be machine, operating system, network architecture, and transport protocol independent. This document is the draft specification for the protocol. It will remain in draft form during a period of public review. Italicized comments in the document are intended to present the rationale behind elements of the design and to raise questions where there are doubts. Comments and suggestions on this draft specification are most welcome.
1.1 The Network File System
The Network File System (NFS™*) has become a de facto standard distributed file system. Since it was first made generally available in 1985 it has been licensed by more than 120 companies. If the NFS protocol has been so successful why does there need to be NeFS ? Because the NFS protocol has deficiencies and limitations that become more apparent and troublesome as it grows older.
1. Size limitations. The NFS version 2 protocol limits filehandles to 32 bytes, file sizes to the magnitude of a signed 32 bit integer, timestamp accuracy to 1 second. These and other limits need to be extended to cope with current and future demands.
2. Non-idempotent procedures. A significant number of the NFS procedures are not idempotent. In certain circumstances these procedures can fail unexpectedly if retried by the client. It is not always clear how the client should recover from such a failure.
3. Unix®† bias. The NFS protocol was designed and first implemented in a Unix environment. This bias is reflected in the protocol: there is no support for record-oriented files, file versions or non-Unix file attributes. This bias must be removed if NFS is to be truly machine and operating system independent.
4. No access procedure. Numerous security problems and program anomalies are attributable to the fact that clients have no facility to ask a server whether they have permission to carry out certain operations.
5. No facility to support atomic filesystem operations. For instance the POSIX O_EXCL flag makes a requirement for exclusive file creation. This cannot be guaranteed to work via the NFS protocol without the support of an auxiliary locking service. Similarly there is no way for a client to guarantee that data written to a file is appended to the current end of the file.
6. Performance. The NFS version 2 protocol provides a fixed set of operations between client and server. While a degree of client caching can significantly reduce the amount of client-server interaction, a level of interaction is required just to maintain cache consistency and there yet remain many examples of high client-server interaction that cannot be reduced by caching. The problem becomes more acute when a client’s set of filesystem operations does not map cleanly into the set of NFS procedures.
1.2 The Network Extensible File System
NeFS addresses the problems just described. Although a draft specification for a revised version of the NFS protocol has addressed many of the deficiencies of NFS version 2, it has not made non-Unix implementations easier, not does it provide opportunities for performance improvements. Indeed, the extra complexity introduced by modifications to the NFS protocol makes all implementations more difficult. A revised NFS protocol does not appear to be an attractive alternative to the existing protocol.
Although it has features in common with NFS, NeFS is a radical departure from NFS. The NFS protocol is built according to a Remote Procedure Call model (RPC) where filesystem operations are mapped across the network as remote procedure calls. The NeFS protocol abandons this model in favor of an interpretive model in which the filesystem operations become operators in an interpreted language. Clients send their requests to the server as programs to be interpreted. Execution of the request by the server’s interpreter results in the filesystem operations being invoked and results returned to the client. Using the interpretive model, filesystem operations can be defined more simply. Clients can build arbitrarily complex requests from these simple operations.
[...]
Example: Copy a File
Make a copy of file (foo) called (bar). Both files exist in the same directory dfh. The request starts by looking up the filehandle for the file to be copied and creates a filehandle for the copy. The loop operator executes a procedure that copies the file using 1K reads and writes. It maintains a running count of the number of bytes yet to be copied.
% Copy a file
%
dfh (foo) lookup /foofh exch def % get filehandle for (foo)
dfh (bar) create /barfh exch def % create filehandle for (bar)
/bytes foofh getattr /fsize get def % get size of (foo) so we know how much to copy
/offset 0 def % initialize offset for (bar)
{
/data foofh offset 1024 read def % read up to 1K from (foo)
barfh offset data write % write up to 1K to (bar)
/bytes bytes 1024 sub def % decrement byte count by 1024
bytes 0 le { exit } if % if it’s < 0 then we’re done
/offset offset 1024 add def % increment offset by 1024
}
loop
barfh getattr 1 encodereply sendreply % return the attributes of the new file to client. HWND WINAPI CreateWindowEx(
_In_ DWORD dwExStyle,
_In_opt_ LPCTSTR lpClassName,
_In_opt_ LPCTSTR lpWindowName,
_In_ DWORD dwStyle,
_In_ int x,
_In_ int y,
_In_ int nWidth,
_In_ int nHeight,
_In_opt_ HWND hWndParent,
_In_opt_ HMENU hMenu,
_In_opt_ HINSTANCE hInstance,
_In_opt_ LPVOID lpParam
);
Since we are counting arguments:
Window XCreateWindow(
Display *display,
Window parent,
int x,
int y,
unsigned int width,
unsigned int height,
unsigned int border_width,
int depth,
unsigned int class,
Visual *visual,
unsigned long valuemask,
XSetWindowAttributes *attributes
);They never had anything to do with UNIX.
Here's a video tape by Brad Myers called "All the Widgets" [1] that shows demos of widgets from way back, many of them long before Xt. (Over 175 segments, from 30 systems, from 15 companies!)
[1] https://www.youtube.com/watch?v=9qtd8Hc90Hw
All the Widgets, by Brad Myers. This was made in 1990, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then. Previously published as: Brad A. Myers. All the Widgets. 2 hour, 15 min videotape. Technical Video Program of the SIGCHI'90 conference, Seattle, WA. April 1-4, 1990. SIGGRAPH Video Review, Issue 57. ISBN 0-89791-930-0.
What kicked Xt's and Motif's ass, especially in terms of power and flexibility, as well as being clean and easy to understand, was TCL/Tk.
The reason TCL/Tk was so successful in spite of how lame TCL was as an scripting language, is that TCL was there from day one of Tk's design, not an afterthought.
As a result, there was no need for Tk to invent a bunch of half-assed kludges, and require applications to build complex Rube Goldberg devices on top of those, when Tk could simply call into TCL to do anything the scripting language interpreter could handle, including calling into the application's C code from TCL.
So there was zero overlap between what the scripting language could do, and what the toolkit needed to do. And that made the toolkit vastly simpler and more consistent, and much easier to flexibly program and modify.
Xt based toolkits like Motif [2] had to built on top of all that half assed pseudo-object-oriented crap trying to reimplement programming language level concepts like objects, components, properties, defaults, inheritance, events, handlers, delegation, layout, etc, in brittle C and macros.
[2] http://www.art.net/~hopkins/Don/unix-haters/x-windows/motif....
Motif was yet another proof of Greenspun's tenth rule of programming [3]: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
[3] https://en.wikipedia.org/wiki/Greenspun's_tenth_rule
So just start with Common Lisp, or at least something in the ballpark like TCL, PostScript, JavaScript, Lua, etc.
Lmao. That's close to what I said when I first learned it. I was griping about how complicated window creation was vs some tools I had. "The MSDN docs are awesome, though!"
The X11 model is also easier to reason about because it is clear where the layer boundaries are and what is implemented in your process as opposed in the kernel/display server and what causes some kind of IPC (eg. what happens to lParam when you send message to window with WndProc implemented in different process?).
Xlib is pretty bad but win32 is absolute bonkers. Or are you saying the opposite?
I do UI coding since Amiga 500 days and never found so borked API, with more parameters and configuration structures than Xlib, without any support for printing or proper use of fonts.
The amount of wasted hours of my life using xlsfonts....
And those bare bones widgets, yet another headache.
Windows is still worse as a web server platform than various Unix descendants (Linux and BSD) despite Microsoft's best efforts, and it's not free.
Unix has its flaws but being a "Unix hater" is just dumb.
"This book is about people who are in abusive relationships with UNIX, woven around the threads in the UNIX-HATERS mailing list."
They're not a bunch of angry outsiders, they're UNIX insiders who reject the idea of "Worse is Better." Worse is Worse, but we're stuck with it.
I don't negate that there are some technical choices that are better than others in some context, or even in some cases in every aspects. But e.g. the PC loser-ing problem has in practice hardly caused much problems (and is even in some cases a superior approach even for the userspace), and judging systems by that kind of details can easily be compared to an hypothetical crazy mechanical engineer not buying a car because of an obscur mechanical technical detail in the engine, that has been made to work perfectly well by taking into account its peculiarities, but that he dislike by principle and in an absolute way.
I'm also very aware of the enormously costly impact of some de facto industry choices. For ex: the C language and its derivative are shit and have arguably costed an absurd amount to the human kind -- compared to a technological-fiction world where safer languages would have been used. Does that mean that this is a case of "Worse is better"? Maybe, but then what would it mean? We have processors with MMU, we even have IOMMU that are becoming more and more common. Given some existing software stacks this does not need to be an intrinsically requirement -- but IMO this is vastly better. Can Worse sometimes win, and then Better also win on other subjects? What should we deduce from that then? What insight can we extract? If none, this whole categorization would be meaningless.
So in some cases, "Worse" is actually just better, the "worse" in question only being in the eyes of the opponent. Or you need to be extremely precise about the criterion you are using.
But I prefer to stick to consider all the advantages and drawbacks of what I'm talking about, the situation I want to apply it to, and avoid binary categorizations when they have no predictive value.
Anyway, I'm not gonna rehash the same old arguments with you.