jkrems

I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to

Did those engineers not actually read the complete tweet? Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work". Which doesn't seem like satire at all..? It just means "develop mostly reliable AI-driven refactoring tools with good guard rails". Which seems quite sensible, actually?

I mean... "as configured" can me either an allow OR a denylist. That sentence doesn't really prescribe doing it one way or the other..? You have to parse the denylisted elements because they will affect the rest of the parse, so you _have_ to remove them afterwards in the general case.

pnpm is the better comparison maybe in this context. Most of Deno's approach to security is focussed on whole program policies which doesn't do much in this context. Just like pnpm and others, they do have opt-in for install scripts though. The npm CLI is an outlier there by now.

Vendoring wouldn't really affect this at all. If anything it would keep you vulnerable for longer because your vendored copy keeps "working" after the bad package got removed upstream. There's a tiny chance that somebody would've caught the 10MB file added in review but that's already too late - the exploit happened on download, before the vendored copy got sent for review.

They didn't deploy the code. That's not how this exploit works. They _downloaded_ the code to their machine. And npm's behavior is to implicitly run arbitrary code as part of the download - including, in this case, a script to harvest credentials and propagate the worm. That part has everything to do with npm behavior and nothing to do with how much anybody reviewed 3P deps. For all we know they downloaded the new version of the affected package to review it!

Looks like it's back again!

Afaict many of these recent supply chain attacks _have_ been detected by scanners. Which ones flew under the radar for an extended period of time?

From what I can tell, even a few hours of delay for actually pulling dependencies post-publication to give security tools a chance to find it would have stopped all (?) recent attacks in their tracks.

Nothing to do with "smart", or at least that's mostly irrelevant to this observation. But it's definitely age-dependent. No matter how "smart", it's not fair to expect young children to immediately and fully pay attention to some "random" voice when other interesting things are going on at the same time.

Why the South? What about the North? Symmetric globe?

The globe isn't symmetric when it comes to these terms. They don't refer to the actual two hemispheres, split at the equator. The "south" contains the equator and the "north" ends way before the equator.

And why is the shrinking considered a misrepresentation, but the enlargement of high latitudes apparently not?

Because being overrepresented (looking bigger) is typically an advantage. Both are misrepresentations but the direction matters. Some of this is only a real problem if geographical area and population are correlated. Which, at least in broad strokes, is true here.

Could this be trivially solved client-side by the editor if it just encoded the slashes, assuming it's HTML or markdown that's stored? Replacing `/etc/hosts` with `/etc/hosts` for storage seems like an okay workaround. Potentially even doing so for anything that's added to the WAF rules automatically by syncing the rules to the editor code.

The gap between design and engineering has never been wider.

This seems like such a weird claim to make. This used to be "here's a JPEG, you may beg for the PSD". Not saying that there's no gap today but... never been wider..? Am I missing something about the typical Figma setup that makes it worse than a random JPEG export of one state of the UI?

Being spec compliant means being compliant with the entire spec, not just a "reasonable subset of the spec", picked by the author of the ponyfill/polyfill. And being secure only in the presence of normal inputs is... pretty meaningless afaict? Anything is secure if the inputs are "nice to the implementation". That isn't a typical bar for "it's secure".

Whether every use case that just wants to roundtrip BigInt through JSON _needs_ a fully spec compliant & generally secure solution is a different question. But at that point it's about picking a solution for a related use case, not about actually standing in for the upcoming browser feature.

Many (most?) traits require energy to develop and maintain. A stronger muscle will need more energy so there's always pressure to reduce it. That pressure may just be countered by pressures in other directions.

When doing so, caches SHOULD first normalize request content to remove semantically insignificant differences, thereby improving cache efficiency, by: [...]

That part sounds like it's asking for trouble. I'm curious if this will make it to the final draft. If the client mis-identifies which parts of the request body are semantically insignificant, the result would be immediate cache poisoning and fun hard-to-debug bugs.

If it's meant as a "MAY", then that seems kind of meaningless: If the client for some reason knows that one particular aspect of the request body is insignificant, it could just generate request bodies that are normalized in the first place..?

So you don't use a spam filter in your inbox? You just subscribe to more emails that you _do_ want to drown out the spam? It's easy to say "just counter with more speech!" but it's harder to see how that works at the scale of a global network with nation state actors, bots, and extreme imbalances of power (100 people dogpiling onto 1 person).

Apart from the "it just explained the already ordered groups in the question" problem, it didn't even explain one of the groups correctly. "Something about coat(ing) and food" is not the correct explanation, it's missing a lateral logic step there to go from food-related to a separate meaning.

If you have a static frontend bundle, isn't that just SSG (static site generation)? And if you can generate the site at build time, what's the fundamental difference between any of the non-web component SSG solutions and a web component SSG solution? Sure, you can pretend like there will be "no build step". But only if you're fine with "no proper cache headers" (and a long tail of other things). So in practice - hopefully there _will_ be a build step anyhow.

The dataset seems pretty unreliable. For example this page claims both that "Kai" isn't a name used in German: https://mixedname.com/name/kai. But then half of the "celebrities named Kai" are... German.

I wonder what the source for the names is. Kai is #289 in at least one list of the most popular names given to German kids in 2022: https://www.beliebte-vornamen.de/jahrgang/j2022/top-500-2022. So I'm surprised that it wouldn't show up in a list of >1000 "German" names.

Congrats on 1.0!

And that article says:

Perl regexes have become a de facto standard, having a rich and powerful set of atomic expressions.

That's a question of policy, not of repo structure. A monorepo can still have certain parts of the repo protected by access control. One repo doesn't mean "all files share one read permission".

What they said was:

in the neighborhood of the difference between the fair current market value (~20B$?) and the purchase price (~44B$).

The difference is 24B$ which is implied to be the upper bound. 10-15 is in the range 0..24.

Because people generally have elevated rights when it concerns themselves? E.g. I have the right not to be touched and it will (generally) outrank your right to touch me.

Until very recently it was a thing in all browsers, with a variety of lower bounds depending on which browser. It was meant to prevent accidental busy-loops when developers forgot the set the time parameter IIRC.

I think you misread that paragraph. It refers to situations like this: "You selected that you want to jointly apply with another individual. Do *they* live in the same household as you?" Yes, you could also write out "the other individual" every time. The guideline doesn't prevent that. But it says not to use "he" or "she" (or "he/she") to refer to the other individual.

It's actually not related to strict mode. HTML comments work fine in strict mode as well as sloppy mode in scripts. The difference here is that modules are a different file format / syntax and they fundamentally don't include parts of the syntax that was supported in the older script file format (and vice versa: they allow syntax like top-level await that wasn't/isn't valid in the script file format).

Important footnote: Unless you are in an JavaScript module file. They work in scripts only. E.g. the following is a syntax error in a module but a valid script:

    <!-- ok if it's a script only
    --> console.log("ok");

If food or drink consumption was the primary purpose of going out, there'd be no reason to coordinate and meet. If a group of people meets for food, they don't meet for food. They meet for each other. They meet to enjoy each others company, the mood, and good discussions. The price of food and drinks for the group is meant to facilitate these things. For the group.

That's not paying for other people's alcohol consumption. It's paying a fair share of the expenses that were involved to create this particular communal experience. Which also means that if somebody is budget constrained, the group may want to keep that in mind - no matter what they order. I've been routinely in groups where somebody with budget constraint paid less. Not because they ate or drink less. But because the group decided that it was their fair share, based on the group's perception of fairness.

I meant in publicly available "box office" figures and all that. Box office earnings alone usually cover all the expenses already, many times over.

Maybe it covers the expenses for the studio but it's not necessarily sufficient for all artists involved in the creation. Movie tickets (and/or other short term revenue streams) would have to be more expensive if artists (actors, writers, directors, ...) wouldn't be able to get a cut of streaming- and other secondary exhibition revenue for a while after release.

I don't know why you're being downvoted.

I can answer why _I_ downvoted the comment. It was this part:

[...] it's really surprising to me how many eagerly lap up the angle Apple is pushing without much reflection, even on HN. Like the good old Apple hype days.

You can make a point without implying that anybody who doesn't agree with you is incompetent (the "Apple hype" meme is really stale).