Poul-Hennings Random Outbursts
varnish-cache.org
varnish-cache.org
> Once you start working with the Varnish source code, you will notice that Varnish is not your average run of the mill application.
> That is not a coincidence.
> I have spent many years working on the FreeBSD kernel, and only rarely did I venture into userland programming, but when I had occation to do so, I invariably found that people programmed like it was still 1975.
> So when I was approached about the Varnish project I wasn’t really interested until I realized that this would be a good opportunity to try to put some of all my knowledge of how hardware and kernels work to good use, and now that we have reached alpha stage, I can say I have really enjoyed it.
> The law has been applied to software development and other activities.[2] The terms bicycle-shed effect, bike-shed effect, and bike-shedding were coined as metaphors to illuminate the law of triviality; it was popularised in the Berkeley Software Distribution community by the Danish software developer Poul-Henning Kamp in 1999[3] and has spread from there to the software industry.
I'm not 100% certain what that means for the whole bikeshed discussion..
https://queue.acm.org/listing.cfm?sort=publication_date&orde...
Feel free to ask any questions...
On http://varnish-cache.org/docs/6.6/phk/lucky.html you say
> The Internet is not there yet, people on the Internet have only just started dying, and there are not yet any automatic routines or generally perceived procedures for informing the people and communities who should know, or for tying up the loose ends, accounts, repositories and memberships on the Internet.
Has anything improved since then? How should the internet deal with death?
That's why countries have spent centuries refining how to properly document and dispose of cases of death.
But somebody needs to know where to send the official certificate of death to in the first place.
In my childhood, the death-notices in the local newspaper did the job, that's no longer the case.
If you are anything like me, you probably attended less than a handful of funerals until your fourties, and then, as part of growing "really" up, making sure the dark respectful clothes are always ready became a thing.
The problem is we built the internet before we turned 40, so we never thought about how deaths figured into it.
I still think the two most important aspects are A) Ensure access. (ie: write down crucial passwords) and B) Making sure the news gets round.
Failing A) may leave practical and economical heart-burn.
Failing B) will make the people you leave behind much more uncomfortable and sad than you would want.
And, of course: Make sure to tell people how much you appreciate them, while both you and they still are.
ps. I really hope that you can get a nerd talk about your eso project accepted, it sounds like a really interesting project.
I have spent almost four decades becoming better at writing C and I write much better programs in C than I do in any other language because of it, and if you asked me to write something very important today, I would trust the result more, if I wrote it in C, even if that were, on some objective scale, not the best language for the task.
With that said, a lot of my recent projects, I have chosen python3, which I am now, after some years of "toy-projects", starting to feel quite comfortable with.
"The past 30 or 40 years of hardware and operating-systems development seems to have only marginally impinged on the agenda in CS departments' algorithmic analysis sections, and as far as my anecdotal evidence, it has totally failed to register in the education they provide."
Cache-Oblivious Algorithms and Data Structures - Erik Demaine
http://erikdemaine.org/papers/BRICS2002/paper.pdf
Abstract:
A recent direction in the design of cache-efficient and disk- efficient algorithms and data structures is the notion of cache obliviousness, introduced by Frigo, Leiserson, Prokop, and Ramachandran in 1999. Cache-oblivious algorithms perform well on a multilevel memory hierarchy without knowing any parameters of the hierarchy, only knowing the existence of a hierarchy. Equivalently, a single cache-oblivious algorithm is efficient on all memory hierarchies simultaneously. While such results might seem impossible, a recent body of work has developed cache-oblivious algorithms and data structures that perform as well or nearly as well as standard external-memory structures which require knowledge of the cache/memory size and block transfer size. Here we describe several of these results with the intent of elucidating the techniques behind their design. Perhaps the most exciting of these results are the data structures, which form general building blocks immediately leading to several algorithmic results.
-
Cache-Oblivious Algorithms - Thesis - Harald Prokop - 1999
My main objection was that some of the algorithms praised in theoretical CS have near pessimal behaviour on actual hardware, and have had so for a quarter of a century, yet these "details of implementation" were deemed a waste of educational bandwidth.
I've had a fair bit of communication with people in boths ends of CS education about that piece, and I think by and large most agree that I have a valid point there.
But nobody wants "Algoritms %03d" to turn into "Optimizing your code for $CORPS microarchitecture %03d", and modern architectures are horribly complicated, in particular from a performance point of view, so sifting out the most representative and relevant phenomena and finding a way of presenting them in education is not easy.
On CS TA told me that they hand out my article mid-semester, and ask the students to identify algorithms in their textbook which are robust or vulnerable to actual hardware performance. I'm torn between being flattered and thinking it is a bit of a cop-out.
As far as cache-oblivious algorithms go: I'll consider them when they prove they are worth their often formidable complexity.
Yes, it would be nice to never have to think about about page-sizes or cache-line widths and all that again, but if only people with a phd in those exact algorithms (many of which are patented) can debug programs which use them, the cost/benefit tilts.
[p.s. I'll 'retract' /g that mea-culpa. Didn't mean it in a literal sense of "apology".]
But I did not think then, and still do not think now, that they are core material in bread&butter CS algorithm courses, I consider them more of a research-curiosity, so I cant say I even thought about bringing them into the article.
What are your thoughts on that?
The claimed "time ~ experience" correlation certainly exists, and in a long established discipline, like plumbing, experience is almost unquestionably a virtue.
In a young discipline, such as computers, there is a very concrete risk of confusing experience with not-moving-with-the-times, certainly on the party claiming experience.
So it is probably very much a case-by-case judgement call ?
I consider the state of affairs to be pre-industrial / arts & crafts, at best. The atelier approach did wonders for the arts in the Renaissance. I suppose F/OSS to some mild extent provides some of the same benefits.