←back to thread

1401 points alankay | 2 comments | | HN request time: 0s | source

This request originated via recent discussions on HN, and the forming of HARC! at YC Research. I'll be around for most of the day today (though the early evening).
Show context
di ◴[] No.11940134[source]
Hi Alan,

In "The Power of the Context" (2004) you wrote:

  ...In programming there is a wide-spread 1st order
  theory that one shouldn’t build one’s own tools,
  languages, and especially operating systems. This is
  true—an incredible amount of time and energy has gone
  down these ratholes. On the 2nd hand, if you can build
  your own tools, languages and operating systems, then
  you absolutely should because the leverage that can be
  obtained (and often the time not wasted in trying to
  fix other people’s not quite right tools) can be
  incredible.
I love this quote because it justifies a DIY attitude of experimentation and reverse engineering, etc., that generally I think we could use more of.

However, more often than not, I find the sentiment paralyzing. There's so much that one could probably learn to build themselves, but as things become more and more complex, one has to be able to make a rational tradeoff between spending the time and energy in the rathole, or not. I can't spend all day rebuilding everything I can simply because I can.

My question is: how does one decide when to DIY, and when to use what's already been built?

replies(6): >>11940184 #>>11940254 #>>11940350 #>>11940433 #>>11940618 #>>11943999 #
alankay ◴[] No.11940433[source]
This is a tough question. (And always has been in a sense, because every era has had projects where the tool building has sunk the project into a black hole.)

It really helped at Parc to work with real geniuses like Chuck Thacker and Dan Ingalls (and quite a few more). There is a very thin boundary between making the 2nd order work vs getting wiped out by the effort.

Another perspective on this is to think about "not getting caught by dependencies" -- what if there were really good independent module systems -- perhaps aided by hardware -- that allowed both worlds to work together (so one doesn't get buried under "useful patches", etc.)

One of my favorite things to watch at Parc was how well Dan Ingalls was able to bootstrap a new system out of an old one by really using what objects are good for, and especially where the new system was even much better at facilitating the next bootstrap.

I'm not a big Unix fan -- it was too late on the scene for the level of ideas that it had -- but if you take the cultural history it came from, there were several things they tried to do that were admirable -- including really having a tiny kernel and using Unix processes for all systems building (this was a very useful version of "OOP" -- you just couldn't have small objects because of the way processes were implemented). It was quite sad to see how this pretty nice mix and match approach gradually decayed into huge loads and dependencies. Part of this was that the rather good idea of parsing non-command messages in each process -- we used this in the first Smalltalk at Parc -- became much too ad hoc because there was not a strong attempt to intertwine a real language around the message structures (this very same thing happened with http -- just think of what this could have been if anyone had been noticing ...)

replies(3): >>11940805 #>>11944937 #>>11952371 #
pault ◴[] No.11940805[source]
> I'm not a big Unix fan

What is your preferred technology stack?

replies(1): >>11940846 #
astrodust ◴[] No.11940846[source]
What's a good non-UNIX open-source operating system that's useful for day-to-day work, or at least academically significant enough that it's worth diving in to?
replies(4): >>11941148 #>>11941329 #>>11941698 #>>11950724 #
nickpsecurity ◴[] No.11941329[source]
Here's a list of alternatives I put together to see some capabilities or traits UNIX lacked:

https://news.ycombinator.com/item?id=10957020

I think, usable day-to-day, I'd say you're down to Haiku, MorphOS, Genode, MINIX 3, and/or A2 Bluebottle. Haiku is a BeOS clone. MorphOS is one of last Amiga's that looks pretty awesome. Genode OS is a security-oriented, microkernel architecture that's using UNIX for bootstrapping but doesn't inherently need it. MINIX 3 similarly bootstrapping on NetBSD but adds microkernels, user-mode drivers, and self-healing functions. A2 Bluebottle is most featured version of Oberon OS in safe, GC'd language. Runs fast.

The usability of these and third party software available vary considerably. One recommendation I have across the board is to back up your data with a boot disc onto external media. Do that often. Reason being, any project with few developers + few users + bare metal is going to have issues to resolve that long-term projects will have already knocked out.

replies(1): >>11946388 #
1. MustardTiger ◴[] No.11946388[source]
Minix isn't bootstrapping on netbsd, the entire goal of the system is to be a microkernel based unix. It uses the netbsd userland because you don't need to rewrite an entire unix userland for no reason just to change kernels.
replies(1): >>11946589 #
2. nickpsecurity ◴[] No.11946589[source]
Mental slip on my part. Thanks for the correction. I stand by the example at least for the parts under NetBSD like drivers and reincarnation server. Their style is more like non-UNIX, microkernel systems of the past. Well, some precedent in HeliOS operating system but that was still detour from traditional UNIX.

https://en.wikipedia.org/wiki/Helios_os