> If a security vulnerability is reported by someone who is also violating the CoC, what do you do? Do you ignore it? Fix it silently?
Is this even a question? You triage and fix the vulnerability just like any other one. Are truths spoken by folks one dislikes — even for perfectly valid reasons — any less true?
The only way I can imagine this somehow applying is if someone has a habit of reporting vulnerabilities which do not exist, or of exaggerating their severity. Is crying wolf a CoC violation? If so, then I can imagine that particular sort of bad behaviour justifying some consideration before acting on a report.
> It was easier to have non-threatening debates because everyone felt more secure. When people are stressed and afraid, the debates aren’t just intellectual exercises but things that could mean the loss of real opportunities in their lives.
You’re right that people feel less secure, but that doesn’t mean that they are correct when they feel that.
By pretty much any measure, I believe that people in 2025 are far more secure than they were in 1975, 1985 or 1995.
I think that this is correct. Also, we really shouldn’t forget that Markdown is meant to generate HTML, and that HTML blocks are valid Markdown: a system which does not permit it isn’t really using Markdown.
> If you run more than one monitor with different DPI, Wayland is the only choice.
I run multiple monitors with differing physical DPIs on X11. Yeah, that means they have differing resolutions. It doesn’t bother me, and I can do all the things that I want, unlike if I were using Wayland.
Maybe someday Wayland will be a replacement for X11, but that day is not today.
This really makes me wonder if you’ve used Tcl. Quoting in Tcl is so much simpler than in e.g. bash or cmake. It’s all about know when a string will be evaluated or not.
> Type errors are very common.
In my experience, no more so than in any other dynamic language, e.g. Python or Lua.
Again in my experience, if one wants a scripting language — i.e., one used to orchestrate a number of commands — then Tcl is exactly what the doctor ordered.
> Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs.
Completely agree: the entire company should be on a common, future-proof, extensible, free platform: Emacs!
I honestly don’t understand why anyone bothers wasting effort on any other editor.
> I know, it’s strange… since 1972 everyone was thinking that we were manipulating versions, but, it turned out, surprisingly, that thinking about the changes themselves as first class solved a very important problem: the problem of merging branched code.
This is a very good point, and it really was revolutionary.
These are hilarious. Is it a meta-joke that a series of videos about over-complicated technology are only visible if one allows JavaScript and embedded Twitter posts?
It’s so much easier to destroy than to build. That applies to buildings, but it also applies to cultures and civilisations. The work of centuries — even of millennia — can be broken in decades or even years.
And what’s worse is that there’s not much one can do about it. One can preserve what one has inherited, and try to increase it, but others can knock it down much more easily.
I think there is a correct answer: use the 404 to indicate that a requested resource does not exist, and use a 200 to return a requested resource that does exist; and use URLs to represent resources.
In other words, follow the HTTP RFCs.
And never, ever, ever EVER use a 200-series status code to return an error.
> It's the difference between "There is nothing handling this route at all" and "there is something handling this route but the object isn't found."
'Nothing handling this route' has no meaning, because routes have no meaning in a hypertext application. Clients should not generally be constructing URLs by hand; they should be receiving them from the servers they communicate with.
In the example in the article, an application dealing with employees should not be constructing URLs by appending employee IDs to strings; rather, every reference to an employee in the application should be to a URL rather than an ID. So when it requests a list of employees, it receives the equivalent of {/api/v1/employees/1, /api/v1/employees/2 … /api/v1/employees/N} rather than {1, 2 … N}.
> I also very much don't like playing the "if you expose your app over HTTP you should assimilate HTTP semantics and do a fuzzy lossy map of your application to HTTP verbs and HTTP status codes."
If you are building a hypertext application, then you should build a hypertext application. It's completely possible. Off the top of my head, protocols such as ACME (used by Let's Encrypt) are good examples to follow.
Is this even a question? You triage and fix the vulnerability just like any other one. Are truths spoken by folks one dislikes — even for perfectly valid reasons — any less true?
The only way I can imagine this somehow applying is if someone has a habit of reporting vulnerabilities which do not exist, or of exaggerating their severity. Is crying wolf a CoC violation? If so, then I can imagine that particular sort of bad behaviour justifying some consideration before acting on a report.