It's worth looking at the entire thread. Both Cox and Pike point out that life is just easier at work running a well-maintained, supported system (OSX) that can play nicely with other machines.
I think it's about time that "well-maintained" and "supported" stop being used as some kind of differentiating point against Linux. There are just as many, if not more, regular updates, both in terms of packages and new distribution releases, to the popular Linux distributions as there are for OSX and Windows. This is even more impressive when you take into account that any random Linux distribution comes with more software out of the box than either OSX or Windows. Both Ubuntu and Redhat provide significant lead time on their release schedules and give you access to the next release before it is official, allowing you to plan your upgrade path better. Even when a distribution is EOLed, you can find people who still offer packages and upgrades for it, and to top it off you can maintain your own upgrades if the vendor EOLs a release and your environment requires not upgrading. Linux distribution releases are not as marketing based as OSX or Windows releases and release schedules, and you don't need to wait until the official day, or be some kind of partner, to find out what's going to be in the newer versions before it is released.
When I first read this, I interpreted the parenthetical as editorial, since I didn't really see anything in the OP that called out OSX specifically in this regard. The original thread is mostly lumping all non-Plan9 stuff together as being more supported than Plan9, agreed.
I can understand going with a Mac if you want better support for the latest hardware or you need to run some commercial software like Photoshop. But if you're running a text editor and a compiler and developing unix software, what advantage is there to using a Mac over a unix box like Linux?
But of course, OS X implements many Unix constructs wrong. Renaming a file is not atomic on OS X / HFS+, for example. (UNIX certification is "did they give us money", not "does it actually work".)
Also, of course GNU/Linux is not Unix. GNU is Not Unix! (I like GNU a lot better than Unix, personally. Much more sugary. "rm foo -rf" actually works, for example.)
What's that do? Unless you change the order, I'd expect it to delete two files: foo and -rf. How does the Mac get it wrong? I don't have a Mac at hand.
GNU tools generally allow you to put your options anywhere you please, even after regular arguments. Whether or not this is a good thing is of course up for debate, but it certainly can add convenience.
Confusion can occur with some applications (possibly non-GNU ones) for which option/argument order does matter, or with those where options have different affects on later/earlier arguments depending on where they are placed.
Note that the parent didn't say the Mac gets it "wrong," just that GNU "rm foo -rf" works in the sense that it will do what he intends it to do.
Yes, my original point, which I didn't make quite clear, was that a Mac is an expensive unix box - for the price of one, you could get a higher-end machine running an OS like Linux. However since Google is probably paying for their hardware, I can see how that would be a non-issue.
The only latest hardware OSX supports is the hardware Apple sells. Even Plan 9 has better harware support than OSX.
The latest version can't even run on non-x86 boxes! My OS of choice runs on just about everything from an ARM-based smartphone all the way to a zSeries mainframe.
So what? Mac OS supports a limited range of hardware by choice, not because of any lack of software engineering skill on the part of its development team.
Not saying I agree with Apple's choice, but it is indeed their choice to make, and it appears to be working out decently well for them.
Do you think Linux developers lack software engineering skills and that's why they don't support the latest 3D card or wireless dongle while, at the same time, they support an astonishing range of devices running on all kinds of machines, from handhelds to building-sized boxes, on about a dozen processor and machine architectures?
Apple's choice is marketing-driven. There is no point in porting OSX for machines Apple won't make. It also saves them a lot of money. I never claimed Apple engineers don't know what they are doing. I only said that, as far as hardware support is concerned, OSX is no leader.
Not sure how you got that from what I said. I'm merely pointing out that hardware support and number of supported architectures isn't necessarily what everyone cares about most when deciding if an OS is "good" or not (whatever that means).
I love my IBM Thinkpad Z50 precisely for its ability to run NetBSD.
But no. My OS of choice is Ubuntu's Linux. To be honest, my choice of OS was dictated by the availability of decent package management and recent packages. This is subject to change (as I moved from Red Hat to Debian to Ubuntu).
But I won't move to a BSD until it plays well with APT.
If you want Acme or Sam, the best course is to install plan9port. It's easy and you get the most modern version of the editors. Wily is not very usable, so I recommend avoiding it. The sam that comes in the debian repository is a very old-school black and white version, which works fine, but the plan9ports version has very nice colors and fonts.
But, again, we had Plan 9. It was great and went nowhere. We had Lisp machines, Smalltalk and Oberon. All of them insanely ahead of their (and perhaps our) time and insanely cool. I can see we couldn't make anything better than Unix. What makes me ashamed is that we should be able to do it and I can't quite grasp why.
Eh, probably some variation of the "good enough" principle. It's hard to get people to switch to something better if it's "only" an evolution, not a revolution.
But that's the point. There were revolutions. Plan 9 was one. Lisp machines were another - an entire environment written in Lisp from top to bottom, as were the Smalltalk machines Xerox built. We had plenty of revolutions after Unix.
OTOH, Lisp is still going strong and regaining lots of followers. Maybe the folks at Bell Labs accidentally hit a local maximum in the OS space...
But I still think we should understand what really happened.
Forgive my ignorance - can anyone elaborate on what sorts of innovations came from Plan 9, and why it didn't overtake Unix? I'm intrigued, but I don't know anything about it.
I'm personally not all that familiar with it either, but I have read that it's a much cleaner and more modern equivalent to Unix, applying the "everything is a file" paradigm to far more. In Unix, a lot of behavior got tied into ioctl and binary sockets as the need for additional features grew. Plan 9 is far more file-oriented and textual in its interfaces, and relies more on file servers (i.e. eschewing an ftp command for an ftpfs filesystem). ESR believes that it may have died just because Unix was "good enough", which sounds reasonably plausible to me.
If someone else knows more, I would also be very interested.
Wikipedia (http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) article is a good start. Most notably the /proc filesystem which represents the state of kernel was lifted straight from Plan 9 into Linux.
As for the success of Plan 9, this quote on wikipedia sums it up -
Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.
That's a very large question, but I'll take a stab at a quick summary.
- All resources in Plan 9 are accessed through the file system. Want to get a screenshot? Read from /dev/window. Want to get access a file on a machine halfway around the world? Mount it on your file system. Want to interrogate the kernel, or change things? /proc. (this last bit has been ported to Linux and other Unixes; only greybeards tend to remember the days when ps had to be setuid root)
- (almost) all resources are textual. None of this business of sending obscure bits to ioctl; if you want your connection to be a certain baud, you open the appropriate "file" and tell it so.
- Related: none of this connect, bind, nonsense. You want network sockets? Open stuff in /net.
- There is no one single "file system", unlike in Unix. When you are running in a 9term, /dev/cons is the console. When you are typing in a different 9term, it's still reading from /dev/cons but it's a different /dev/cons. It's possible for every program on the system to have a completely different view of the filesystem (although I doubt it's really sensible). Accordingly there's no superuser; there's only "permission to access X".
- Union mount points. There's no /bin, /usr/bin, $HOME/bin, etc; everything is always in /bin. The system automatically makes /bin contain the executables that are most appropriate fro your processor; rc is always /bin/rc but on one machine it's MIPS code and on another it's x86 code.
- A resulting truly distributed system. Typical use had you logging in from a network terminal (like an X terminal) and running jobs on a CPU server mostly transparently, there's disk servers you can mount, etc. I'm not 100% sure how this part works, because I've never been able to run it in the wild.
- Plan 9 was designed with the intent of GUI stuff from the get go. There's no curses stuff, no console libraries; if you want to do that stuff, you use a GUI. But these GUIs were designed by folks who were very comfortable with using a command line, and so one ends up with huge amounts of text on screen that you interact with (the history mechanism for rc actually looks at the window buffer for the terminal it is running in, looking for prompts). There's an input language for mice, that's most obvious in acme (where cut and paste are done by mouse button chords).
- As a result of this most of userland has been worked over, probably because somebody was forced to think seriously of reimplementing the Bourne shell. rc is remarkably minimal for a login shell in this day of zsh, and seems useless in an xterm; but because in a 9term you can edit previous output and previous command lines and tell the terminal not to send input at the end of a line but instead wait for you to decide you're finished it ends up being surprisingly powerful and usable. It's hard to get this in Unix because a lot of the tricks they did with it involve accessing the textual representation of the contents of the 9term and e.g. grepping over it or the like. Plan 9 from User Space does manage it and it's a very strange experience.
- Unicode throughout, which doesn't seem like such a big deal now but was pretty significant back in 1992.
- A bunch of fascinating programs written as a general solution to specific frustrations. Modern terminal replacements sometimes highlight URLs or the like; the Plan 9 plumber would do this with anything, and was consistently implemented across the system (Button 3 in recent acmes, for example, runs the plumber and only does local search if that fails to match).
Plan 9 can be very disturbing to work with at first; everything seems incredibly primitive, and it has a very minimalist feel to it, but when you get used to the idioms it can be incredibly powerful. It's a pity they never wrote a real web browser for it, I would love to see what it would look like. The whole experience is very strange, and yet there's a certain elegance to it.
What linux breed do most of these engineers use? any ideas? Ubuntu? red hat? any ideas?
I've got a Win7 machine and the rc is about to runout. I'm going to get a new win laptop, but am thinking of setting up this old one as a linux box.
Seems to be mostly Ubuntu, but I've met quite a few Fedora, CentOS, RHEL, and other distro users from Google. There is no law about what OS engineers can use within Google, but they do have their own Ubuntu repository and such setup for distributing internally developed software and a custom Ubuntu install. Their server infrastructure, last I heard, was on an old bastardized Fedora version, but that was a couple of years ago; and it's probably not something they talk about with much specificity or frequency.
I'm a self-described operating system junkie. At home, I've got WinXP, Win7, OpenBSD, OS X, Haiku (BeOS), FreeBSD, Solaris, AIX, and a few Linux flavors running. Yes, all at once. Maybe I should try plan9 again in a VM.
Currently, my most powerful machine is my MacBook, which dual-boots OS X and Windows 7 natively. I probably use them about the same. I run a lot of things in VirtualBox, though. I almost always have an OpenBSD VM up and running, for example. My two lower-powered desktops are running Solaris 10 (Sparc) and Ubuntu Karmic for the time being, but Ubuntu is kind of in the dog house right now. I've had good luck with ArchLinux in a VM, so I may throw that on there soon.
This is superficially true but I think ignores how usable sam is. The rationalized command language, the fact that you can see what you're doing, unlimited undo even across files (even across file I/O), and the ability to go to the file in question and just type make it a much more satisfying experience to do large amounts of development with than ed is.
The difference is that we tend not to argue about sam vs. acme. For one, they both use the sam command language. Most of us (Plan 9 users) seem to use acme, but there are some long-time sam users around. There's no holy war :)
"Rob, Ken, Dave, and I use Macs as our desktop machines, but we're a bit of an exception. Most Google engineers use Linux machines, and I know of quite a few ex-Bell Labs people who are happy to be using sam or acme on those machines."
Google also has a bunch of ex-Microsofties (dream company of the 1980s) and ex-Amazonites (dream company of the 90s).
It pays to get into a dream company as soon as possible, and do cool things there, because other companies will see those cool things and give you your pick of jobs.
