I love your ACM Queue articles, like the one on leap seconds. The writing style reminds me of Andrew Tanenbaum and Mackenzie Ceglowski, and is a delight!
> 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?
I have customers in several countries. If one of them died and I was sent, say, a Danish death certificate, I wouldn't know how to verify/authenticate it. With ~200 countries and almost as many languages, that becomes a non-trivial issue. How do $megacorps deal with this? Is there anything a small business can learn from them in that regard?
I think that is seeing things from the wrong end, the question can ever only be "how should people deal with death?"
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.
Being against modern Israeli policies is not anti-semitism.
Calling it anti-semitism is an hypocrite and perfidious way of silencing all opposition by playing the victim card against millions of people that have died because of actual anti-semitism.
Please enlighten me how holding Jews "collectively in contempt" and "I thought anti-semitism was unfounded hatred of Jews? If you hate them because they did something awful, like implement apartheid, it is not anti-semitism, but perfectly justified critique of people who in particular should know better than that" is {checks notes} "being against modern Israeli policies not antisemitism"?
2 out of 3 quotes in your comment are not mine and it's not my place to justify them, but please don't mix them with my own personal position, thank you.
I agree that a small part of phk's comment would benefit from more cautious wording, but I stand by the fact that trying to cause a flame war by playing the antisemitism card is disgusting and I suspect you're doing it in bad faith.
Those quotes are by the man you are chiming in for to defend as 'anti-Israel' comments, so they are very pertinent to the conversation. As for the "antisemitic card", I generally find that anyone who uses phrases like that is usually the one doing so "in bad faith". HTH
The charge of "antisemitism" has been weaponized with very great effect, and is being used indiscriminantly against anybody who speaks out against Israels apartheid policies, like I did.
My experience being at the business-end of such an attack has been very educational, and has provided a lot of raw data to some people who study information warfare.
The FreeBSD projects reaction was a very good example of the efficiency of this mode of attack: By demanding immediate, as in "minutes not hours" reaction from anybody and everybody associated with the target, the attachers cause overreactions, badly throught out reactions and lots of collateral damage.
The only way to stand up against this kind of systematic and state-sponsored bullying, is to stick to your principles, and demand that everybody else does so too, no matter how scared shitless they are about the shitstorm Israel have thrown them into.
My principles are that Israel, like every other state on the planet, shall be forced to respect the human rights of every human being, not just the people they think are "Chosen" by their superstition.
That does not make me antisemitic, that makes me human.
Except you were talking about Jews collectively, not Israel.
"I thought anti-semitism was unfounded hatred of Jews? If you hate them because they did something awful, like implement apartheid, it is not anti-semitism, but perfectly justified critique of people who in particular should know better than that."
"I don't hold them collectively responsible, I hold them collectively in contempt." etc.
That's not quite right. The vast majority of Jews are Zionists. Zionism is just the belief in the right of Jews to self-determination in their ancestral homeland. Whether or not someone is a Zionist, shouldn't have any bearing on whether they deserve racism which is PHK's defence. He believes that Jews can deservedly be hated because of Israel and can be held "collectively in contempt"(his words).
The reason I find the topic fascinating is that the semantics seem to obliterate the discussion before it can really begin.
I'm assuming that from PHK's point of view, he casually used "the Jews" as a identity for "Israel". That's crass and wrong, but as another white European I'm ashamed to say that it is something that I might have also done before I was given the opportunity to learn a little more about the topic.
I'm assuming that from your point of view, the language PHK used, with the history irremediably attached to it, is presumably just such obvious anti-Semitic racism, perhaps being so similar to language that you've certainly heard several times before, that you feel compelled to call it out as such.
And so, here we are: unable to discuss the topic because the language is constructed from hand-grenades. By the time we have recognized them as such, our hands are already missing.
At the risk of getting involved in the discussion in the way I said above I did not want to, I feel I have to point out that "Holding Jews collectively responsible for actions of the state of Israel" is usually explicitly defined as anti-Semitic[1]. You do now rather seem to be missing an opportunity to clarify your views on the topic.
I fully agree that the Venn diagram is not a circle.
But given that any slight, no matter how insignificant, no matter against which part of the Venn diagram it was directed, invariably gets labeled "antisemitic", I think people like me can be excused if we express ourselves with less exacting clarity, than the people in the Venn diagram demands.
If the people in the Venn diagram think the distinctions are very important, a good place to start is to use very distinct colors.
Poul struggles with the concept that imposing certain conditionalities on whole groups of people before deciding if they are deserving of basic protections from racism is, er, racist.
That's not what's happened here. You used the word "Jew" to describe "citizens of Israel". You have to know that those two words don't mean the same thing, and the history of extrapolating accusations to all Jewish people. The distinction between the two terms is straightforward, and hardly a "hand grenade" as you suggest downthread. I'm struck that you haven't at any point simply said "I misspoke". Did you?
This whole subject is a weird tangent from the original post we're discussing, but you seem on this thread to have managed to double down on what you said in 2019. That's hard to ignore.
That is a phony argument. You blamed all Jews for Israel's actions. That was antisemitic. You don't need to wait for Israel to become better before admitting that. Many people have criticized Israel, sometimes very harshly, without needing to say things like "I hold Jews collectively in contempt". Your blog post on the matter [1] would have looked more dignified if you'd said "I was wrong" not just "I didn't express myself artfully".
Maybe a bit unrelated to the post, but I have been wanting to ask the question of why you still choose C as you language for new projects. Is it because that is what you have always used and what you know best or do you not think modern languages like go, rust, nim etc. are sufficiently better?
ps. I really hope that you can get a nerd talk about your eso project accepted, it sounds like a really interesting project.
I agree that choice of language is important, but you cannot just consider the language in isolation.
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.
Sure thing. So did you ever issue a mea culpa regarding your statements in ACM Queue [1]:
"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
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
No, and I dont think I owe anybody an apology for that.
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.
Did you know about Cache-oblivious algorithms when you wrote that essay? My sense is that you did not, otherwise you would have mentioned them in passing and noted your (arguably reasonable) objections regarding their practicality.
[p.s. I'll 'retract' /g that mea-culpa. Didn't mean it in a literal sense of "apology".]
Yes, I did know about their existence, and I had even tried to implement one of them myself, but ditched once I realized that patents would preclude its use in FOSS.
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.
Fair disclosure that I studied EE so have second hand insight into what a CS education entails, but my thoughts on the oversight that you noted are that it may be too much to expect that level of knowledge sharing in a 4 year undergrad education. I am reminded of internship and post-doc of physicians working in a hospital. I’m sure you are aware of the prevalent mindset (from blogosphere to actual working environments) that heavily discount the value of experience in a software engineer.
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.
> 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.
Pleased to see that you got the original phrase from Parkinson's Law. That book deserves a wider audience, and so does its sequel The Law and the Profits. Here's a PDF: http://sas2.elte.hu/tg/ptorv/Parkinson-s-Law.pdf
That's great, it loaded with a hideous green that made it so unreadable I suspected it would have a different color on reload. It of course did, so I refreshed three more times until it had a very comfortable pastel red background.
I'm not 100% certain what that means for the whole bikeshed discussion..
PHK is one of the few people in IT I follow. He isn't scared to write opinions without having them put through a big PR machine removing anything interesting. The spectrum of posts are also very wide indeed, from restoring old historical hardware over political ramblings to time-keeping and code.
50 comments
[ 4.6 ms ] story [ 90.6 ms ] thread[0] https://www.version2.dk/blogs/poulhenningkamp
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.
https://twitter.com/adammaanit/status/1126254013408796672?s=...
Calling it anti-semitism is an hypocrite and perfidious way of silencing all opposition by playing the victim card against millions of people that have died because of actual anti-semitism.
It's disgusting.
I agree that a small part of phk's comment would benefit from more cautious wording, but I stand by the fact that trying to cause a flame war by playing the antisemitism card is disgusting and I suspect you're doing it in bad faith.
My experience being at the business-end of such an attack has been very educational, and has provided a lot of raw data to some people who study information warfare.
The FreeBSD projects reaction was a very good example of the efficiency of this mode of attack: By demanding immediate, as in "minutes not hours" reaction from anybody and everybody associated with the target, the attachers cause overreactions, badly throught out reactions and lots of collateral damage.
The only way to stand up against this kind of systematic and state-sponsored bullying, is to stick to your principles, and demand that everybody else does so too, no matter how scared shitless they are about the shitstorm Israel have thrown them into.
My principles are that Israel, like every other state on the planet, shall be forced to respect the human rights of every human being, not just the people they think are "Chosen" by their superstition.
That does not make me antisemitic, that makes me human.
"I thought anti-semitism was unfounded hatred of Jews? If you hate them because they did something awful, like implement apartheid, it is not anti-semitism, but perfectly justified critique of people who in particular should know better than that."
"I don't hold them collectively responsible, I hold them collectively in contempt." etc.
On one side, vogon_laureate appears to want phkemp to acknowledge that he understands that the Venn diagram of Jews and Zionists is not a circle.
On the other side, phkemp would like vogon_laureate to accept that political criticism of Israel is not automatically anti-Semitic.
Both of these seem, to me, to be somewhat reasonable points that should not be hard to agree on. What prevents this?
Would it be accurate to say that you're looking for a clarification that "the Jews" and "the state of Israel" aren't synonyms?
I'm assuming that from PHK's point of view, he casually used "the Jews" as a identity for "Israel". That's crass and wrong, but as another white European I'm ashamed to say that it is something that I might have also done before I was given the opportunity to learn a little more about the topic.
I'm assuming that from your point of view, the language PHK used, with the history irremediably attached to it, is presumably just such obvious anti-Semitic racism, perhaps being so similar to language that you've certainly heard several times before, that you feel compelled to call it out as such.
And so, here we are: unable to discuss the topic because the language is constructed from hand-grenades. By the time we have recognized them as such, our hands are already missing.
At the risk of getting involved in the discussion in the way I said above I did not want to, I feel I have to point out that "Holding Jews collectively responsible for actions of the state of Israel" is usually explicitly defined as anti-Semitic[1]. You do now rather seem to be missing an opportunity to clarify your views on the topic.
[1] https://www.holocaustremembrance.com/resources/working-defin...
But given that any slight, no matter how insignificant, no matter against which part of the Venn diagram it was directed, invariably gets labeled "antisemitic", I think people like me can be excused if we express ourselves with less exacting clarity, than the people in the Venn diagram demands.
If the people in the Venn diagram think the distinctions are very important, a good place to start is to use very distinct colors.
This whole subject is a weird tangent from the original post we're discussing, but you seem on this thread to have managed to double down on what you said in 2019. That's hard to ignore.
[1] http://phk.freebsd.dk/sagas/israel/
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
http://supertech.csail.mit.edu/papers/Prokop99.pdf
[1]: https://queue.acm.org/detail.cfm?id=1814327
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.
> 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.
* https://en.wikipedia.org/wiki/Law_of_triviality
* [3] http://phk.freebsd.dk/sagas/bikeshed/
I'm not 100% certain what that means for the whole bikeshed discussion..