HN user

evnp

356 karma

Make things.

Posts1
Comments77
View on HN

"There will be no curiosity, no enjoyment of the process of life. All competing pleasures will be destroyed. But always— do not forget this, Winston— always there will be the intoxication of power, constantly increasing and constantly growing subtler. Always, at every moment, there will be the thrill of victory, the sensation of trampling on an enemy who is helpless. If you want a picture of the future, imagine a boot stamping on a human face— forever."

George Orwell, 1984

Love this idea and your creation of it. Unfortunately do think the parent's concerns are valid - at this moment on your site at least one person has set their name to something offensive so it shows up perpetually (under the street light). Anonymity+connectivity persists in bringing out the worst of our impulses, I guess...

Do you think names are really necessary? Or could they take some other form than text, perhaps unicode chars chosen from a selection of abstract shapes? The wonderful https://www.tunera.xyz/fonts/teranoptia/ comes to mind.

The point is that safety depends on context and intent being known - with unknown context or intent, dangerous situations will appear _some_ of the time, thus the system as a whole can "never" be fully safe.

There is no contradiction here.

I'm legitimately curious - could you elaborate on the difference? Speaking as someone who has always preferred the commit-by-commit focus of a rebase instead of all-at-once merge conflict resolution, auditing all the changes together later doesn't sound more appealing than doing things incrementally.

We had our circa-1915 house checked for asbestos before lifting it. The inspector laughed after taking a chip out of the plaster because you could clearly see horse hair protruding from every side of the chip. This is apparently unlikely to overlap with asbestos, though it comes instead with a minor (?) anthrax risk. I'll take that over the dust from drywall sanding every time though.

My issue is remembering that the square brackets come first, not the parentheses. I do like asciidoc's method: https://example.com for bare link, or https://example.com[pretty text] if alternate text is desired

Edit: It took me a re-read to fully understand your comment, I can see how square brackets might be an incremental addition. This may also help remember the syntax, thanks!

This is great! Not an emacs user (as yet) but this and org-mode's /italic/ _underline_ *bold* +strike+ feel that much closer to the oft-touted "source looks kinda like formatting” ideal of markdown. Not sure why we ended up with the mediocre version as a defacto standard.

Anything that doesn't force you to remember arbitrary ordering - square brackets first? Or parentheses? It's the textual equivalent of plugging in usb upside down.

An alternative would be to simply use square brackets for both clauses of the link.

Enjoyed the article, and the "less can be more than you think" mindset in general.

To the author - on Android Chrome I seem to inevitably load the page scrolled to the bottom, footnotes area. Scrolling up, back button, click link again has the same results - I start out seeing footnotes. Might be worth a look.

I'm interested in this. Code review, most egregiously where the "author" neglected to review the LLM output themselves, seems like a clear instance. What are some other examples?

Something that should go in a "survival guide" for devs that still prefer to code themselves.

Exactly. The problem is instead of getting a raise because "you can do more now" your colleagues will be laid off. Why pay for 3 devs when the work can be done by 1 now? And we all better hope that actually pans out in whatever legacy codebase we're dealing with.

Now the job market is flooded due to layoffs, further justifying lack of comp adjustment - add inflation, and you have "de-valuing" in direct form.

I love it too. Appears to be accomplished with this CSS, which you can tinker with by finding the :after element at the bottom of the <body> tag in browser devtools:

  body::after {
    content: "";
    position: fixed;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    background-image: linear-gradient(rgba(0, 0, 0, 0.4) 1px, transparent 1px);
    background-size: 2px 2px;
    background-repeat: repeat;
    pointer-events: none;
    z-index: 9999;
  }

Aren't the impacts perpetual if we're creating new contrails every single day?

Taken from another comment, this seems pretty clear:

Contrail cirrus may be air traffic's largest radiative forcing component, larger than all CO2 accumulated from aviation, and could triple from a 2006 baseline to 160–180 mW/m2 by 2050 without intervention.

[1] https://en.wikipedia.org/wiki/Contrail#Impacts_on_climate

The original article describes associated costs in time and fuel usage in the realm of 1% increase.

Pre-record your demos 10 months ago

It seems like you're misunderstanding what parent meant by "prerecorded" - not a screen recording, just pre-writing of commands to be executed during the demo. Would you consider it "deception" to hit up arrow a few times in a terminal during your demo to execute a command from shell history? This is effectively the same. Take a look at the linked repo, it's very clever.

This is great! Asciinema is well-made and a lot of fun, but it sadly doesn't show the recordings in motion right there in the markdown/README. Looks like vhs neatly solves that problem, appreciate the share.

Great read, fascinating piece of Canadian history.

For anyone on mobile (android/chrome at least) select "Desktop Site" under browser settings to see five historical images. They don't show up for me at all in the default mobile view.

How is .csv a niche dev-focused format? Our customers use our exports for a mix of purposes, some of them involving spreadsheet clients (not just excel) and some of them integrating with their own data pipelines. Csv conveniently works with these use cases across the board, without explanation, and is inconveniently saddled with these legacy security flaws in Excel (and probably other clients).

If xlsx works for all your use cases that's great, a much better solution that trying to sidestep these issues by lightly modifying the data. It's not an option for us, and (I'd imagine) a large contingent of export tools which can't make assumptions about downstream usage.

Appreciate your work! Your piece was pivotal in changing my mind about whether this should be considered in our purview to address.

The intention-based philosophy of all this makes a lot of sense, was eye opening, and I agree it should be the first approach. Unfortunately after considering our use cases, we quickly realized that we'd have no way of knowing how customers intend to use the csv exports they've requested - we've talked to some of them and it's a mix. We could approach things case by case but we really just want a setup which works well 99% of the time and mitigates known risk. We settled on the prefixing approach and have yet to receive any complaints about it, specifically using a space character with the mind that something unobtrusive (eg. easily strippable) but also visible, would be best - to avoid quirks stemming from something completely hidden.

Thank again for your writing and thoughts, like I said above I haven't found much else of quality on the topic.

There are a lot of these sorts of bug reports running around, to the point that Google's bug bounty program has classified them as invalid: https://bughunters.google.com/learn/invalid-reports/google-p...

I agree with the characterization ("security theater") of these bug reports. The problem is that the intentions of these reports don't make the potential risk less real, depending on the setting, and I worry that the "You're just looking for attention" reaction (a very fair one!) leads to a concerning downplaying of this issue across the web.

As a library author, I agree this very well may not be something that needs to be addressed. But as someone working in a company responsible for customers, employees, and their sensitive information, disregarding this issue disregards the reality of the tools these people will invariably use, downstream of software we _are_ responsible for. Aiming to make this downstream activity as safe as possible seems like a worthy goal.

That was my initial reaction as well – it's a vulnerability in MS software, not ours, not our problem. Unfortunately, reality quickly came to bear: our customers and employees ubiquitously use excel and other similar spreadsheet software, which exposes us and them to risk regardless where the issue lies. We're inherently vulnerable because of the environment we're operating in, by using CSV.

"don't trust customer input without stripping or escaping it" feels obvious, but I don't think it stands up to scrutiny. What exactly do you strip or escape when you're trying to prevent an unknown multitude of legacy spreadsheet clients that you don't control from mishandling data in an unknown variety of ways? How do you know you're not disrupting downstream customer data flows with your escaping? The core issue, as I understand it, stems from possible unintended formula execution – which can be prevented by prefixing certain cells with a space or some invisible character (mentioned in the linked post above). This _does_ modify customer data, but hopefully in a way that unobtrusive enough to be acceptable. All in all, it seems to be a problem without a perfect solution.