[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opining on "modern" development practices (was Re: Merging the “bina

From: Katherine Cox-Buday
Subject: Re: Opining on "modern" development practices (was Re: Merging the “binary” NPM importer?)
Date: Fri, 29 Oct 2021 09:54:42 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Ludovic Courtès <> writes:

> Nope!  You’ve probably noticed that the Hurd isn’t known as a lively and
> successful project, and then there are things like the Critique¹ or work
> on porting the Hurd to the L4 microkernel which, while showing the
> “right” direction research-wise, have also had IMO the effect of
> suggesting that it’s never going to be good enough.
> I think a project needs to be aware of its shortcomings, but it also
> needs achievable milestones, and it needs to refrain from elitism.
> ¹

Yes, I'm generally aware of the challenges the Hurd (and other micro kernels) 
have had taking off. I'm not clear on whether this is because monolithic 
kernels are intrinsically better (is this yet another example of worse is 
better?), or because of an organizational expression of worse is better.

I happened to be watching John Carmack speak last night. I haven't watched many 
of his talks, but he seems like a consummate pragmatist. I've always admired 
people like this because it's so opposite of my own idealistic tendencies. One 
thing he said in particular seems relevant:
"The metaverse is a honeypot trap for astronaut architects."

I.e. he was arguing against trying to build (read: architect) the metaverse 
because it's a great way to either not get anything useful done, or to get the 
wrong thing done.

I guess I've been circling around this philosophy for awhile, but I think I'm 
going to let it cross over into being my working theory of how to build useful 
software (among other things in life): worse is better, and collect as many 
forcing factors as you can, as early as you can. I wonder how I can apply this 
to Guix.

> See <>.

Thank you for the link!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]