Recent submissions

Comment · 3 days ago
I really like this idea of 300 lines (asm) vs ~1M lines (C) which was possible by really understanding what you are doing and limiting to the core feature you need. In this case you had 'the luxury' of this being low level code. What I fear for is all (application) the code that runs on top of frameworks/run-times/interpreters (in reference to the recent PHP drama). We can harden our application code as much as we like, but if the underlying code is not safe we have an issue - this combined with you remark on attackers being in the advantage versus defenders. At this time the only way that I see to protect this is by using some kind of (virtual) private network. What are your ideas on this?
Comment · 2 months ago
Yep.

And, the following made me smile. Not just the em-dash.

Prompt: can you please verify that your proposals do not increase the complexity of the design and are really needed?

Response:

No—the earlier proposals were not all justified. The review found avoidable complexity and I revised Questions 62–66 accordingly:

Comment · 1 year ago
Yep. It's the auditing part that is broken. As a (dangerous) workaround use --no-audit
Comment · 1 year ago
Thanks for sharing. Good to know. I Was considering using it for that purpose.
Comment · 4 years ago
I would not go multiple Availability Zone within the same Infra/Cloud provider...
Comment · 5 years ago
Love the idea! Yes there are challenges (ref: 'Embrace and extend') but there is a very clear value: both for end users (that ultimately drive value) and for paying companies (startups or other) that have have great new products but have to deal with a market in which 'the current generation' of products are used.

From a different angle (that you're probably already considering :-): What about SaaS companies that also want to give customers a smooth way out if they are not satisfied. I can imagine that there is value in having some sort of 'seal' that makes it clear that: yes you can get out of here if our product is not what you want it to be.

Final note: I just hope that we’re not going to end up in a situation where we need to do a “ReCaptcha” again after logging in because some SaaS, x, is wary of scrapes….

Good luck!

Comment · 5 years ago
Comment · 5 years ago
Ha Ha. Thats’s even worse than the ‘C Hashtag’ that an HR dude was rambling on about.
Comment · 5 years ago
A little anecdote/legend from the Philips Research Labs (Nat. Lab.):

When the team demonstrated the first CD they drilled some holes in them, and showed: "Look how robust, they even work when they are this damaged" (paraphrased).

In reality the locations of these holes were chosen very precisely. Not sure if this is true, but this is a story that my colleagues told me in the 90's...

Rest In Peace Lou Ottens.

Comment · 5 years ago
Ken Shirriff, your blog is just awesome.

What a wealth of material you have on righto.com!

Blown away.

Comment · 5 years ago
I gave the reporting a try, and I like the flow in the demo (which is for a Public repo); easy to use.

For a private repo, I would probably also want people to be able to leave anonymous replies (to get 'as much feedback as possible'), but that's just my n=1 opinion.

Good luck.

Comment · 5 years ago
Hi,

Congratulations with your launch.

Question: must an end user (web site visitor) do a (Github or other) login? Or can they simply leave a comment?

Comment · 5 years ago
Yep, feedback is valuable. And the earlier the more valuable (it's like NPV...).

I love coding so much, and find it really hard to express ideas in natural language, so that in the end documentation... doesn't happen as much as it should.

What I find that really helps is the following:

1. Write down architecture specs (with interface specs etc), before coding. Not bloated, but really minimalistic. 2. Review these ideas with peers. 3. Happy coding and refine the docs.

Comment · 5 years ago
ASCII? UTF-8? UTF-16? ... ...

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton