I mean, I don't think diamonds are considered "organic"; same for graphite. But that's where the term "organic" itself starts to break down as a category.
Because that's a silly idea. When missiles are flying over people's heads and everyone is running into bomb shelters, Israel would get approximately no benefit from nitpicking a single story, certainly not enough to justify a harassment campaign involving lots of people with cover stories. On the other hand, gamblers have a very concrete motivation and a long history of doing unhinged things to get it. There's no reason to look for depth.
I don't understand the Epstein thing. In particular, I don't know why everyone doesn't agree "Epstein had help offing himself". That's the most natural inference from the evidence I'm aware of, and also satisfies the conspiracist urge for drama. Everyone should be happy with this, but I've hardly ever heard anyone else put it forward. What am I missing?
The author doesn't understand what a leaky abstraction is:
He writes:
"And in order to understand why that’s the case, you need to start digging into the workings of the type system (hence a leaky abstraction)."
Then he proceeds to just write more Typescript without dropping down to reading the Typescript compiler source code, which is what generally happens when you have to deal with a leaky abstraction.
When you have an ORM that generates SQL, but you have to read the generated SQL for performance reasons (N+1, etc), that's a leaky abstraction. The details end up leaking through.
This doesn't work with Typescript, since Typescript types don't appear in the generated Javascript code. The type system doesn't try to hide an underlying system that could possibly leak through. The type system is a new thing that wasn't there before.
What's particularly annoying about the blog post is that the topic at hand actually has very little to do with type systems. It's primarily about compile time evaluation of code. The keys needed for map access need to be known at compile time and by threading them through an if(Math.random() < 0.5), or a keys = keys.map(x => x); the compiler would have to evaluate every possible code path symbolically to generate a type signature. After all, the code could have been keys.map(x => x + "abc") or any other arbitrary expression that can be evaluated at compile time.
The compiler doesn't really give a damn about the types here, because they are kind of irrelevant and crystalize out of the results of compile time evaluation. keys.map(x => x) and keys.map(x => x + "abc") both take a list of strings and output a list of strings. The types are exactly as you expect, but the concrete values are different.
The only way out of this with a type system would be to encode values into the type system itself, which is kind of antithetical to the idea of typing.
I know people love to talk money and costs and "value", but HN is a space for developers, not the business people. Our primary concern, as developers, is to make the product better. The business people need us to make the product better, keep the company growing, and beat out the competition. We need them to keep us from fixating on things that are useful but low priority and ensuring we keep having money. The contention between us is good, it keeps balance. It even ensures things keep getting better even if an effective monopoly forms as they still need us, the developers, to make the company continue growing (look at monopolies people aren't angry at and how they're different). And they need us more than we need them.
So I'd argue it's the responsibility of the developers, hired by GitHub, to create this feature because it makes the product better. Because that's the thing you've been hired for: to make the product better. Your concern isn't about the money, your concern is about the product. That's what you're hired for.
I'd say that this is also true from a money-and-costs-and-value perspective. Sure, all press is good press... but any number of stakeholders would agree that "we got some mindshare by proactively protecting against an emerging threat" is higher-ROI press than "Ars did a piece on how widespread this problem is, and we're mentioned in the context of our interface making the attack hard to detect."
And when the incremental cost to build a feature is low in an age of agentic AI, there should be no barrier to a member of the technical staff (and hopefully they're not divided into devs/test/PM like in decades past) putting a prototype together for this.
I agree and think it's extra important when you have specialized products. Experts are more sensitive to the little things.
Engineers and developers are especially sensitive. It's our job to find problems and fix them. I don't trust engineers that aren't a bit grumpy because it usually means they don't know what the problems are (just like when they don't dogfood). Though I'll also clarify that what distinguishes a grumpy engineer from your average redditer is that they have critiques rather than just complaints. Critique oriented is searching for solutions of problems, you can't just stop at problem identification.
> And when the incremental cost to build a feature is low in an age of agentic AI
I'm not sure that's even necessary. A very quick but still helpful patch would be to display invisible characters. Just like we often do with whitespace characters. The diff can be a bit noisier and it's the perfect place for this even if you purposefully use invisible characters in your programming environment.
Though we're also talking about an organization that couldn't merge a PR for a year that fixed a one liner. A mistake that should never have gotten through review. Seriously, who uses a while loop counter checking for equality?!? I'm still convinced they left the "bug" because it made them money
>Though we're also talking about an organization that couldn't merge a PR for a year that fixed a one liner. A mistake that should never have gotten through review. Seriously, who uses a while loop counter checking for equality?!? I'm still convinced they left the "bug" because it made them money
What is this in reference to? I tried to search for it but only found this comment. “Github while loop fix that was in review for a year”?
It was the safe_sleep function. Here's an issue on it [0]. IIRC there was an early issue, but really this is code that never should have made it in. Here's the conditional in question
SECONDS=0
while [[ $SECONDS -lt $1 ]]; do
:
done
Here's the fix... (s/!=/-lt)
while [[ $SECONDS -lt $1 ]];
It's a fallback sleep function for if you don't have the sleep command, (or read, or ping) then it'll increment SECONDS (special variable) until the time has passed because : does nothing (it will peg your CPU though).
Problem is the loop isn't computed with infinite precision. Doesn't take a genius to figure out < is infinitely better than != here and you'd be right to guess that people did in fact waste thousands of dollars getting stuck in infinite loops that were entirely unavoidable.
Here's the actual merge...[1]
At least it didn't take them months to merge this line, which should have existed from day 1 too (a very very well known pattern for writing bash scripts)[2]
Sure, but looking at this from a purely business perspective - I wonder how many customers would panic or jump ship rather than be grateful when notified of an attack. But I think it could work as an optional feature for paid accounts if it was marketed properly
At the end of the day it boils down to putting your users first.
Making the product better generally stems from acting in their interest, honing the tool you offer to provide the best possible experience, and making business decisions that respect their dignity.
Your comment talks a lot about product and I agree with it, I just mentioned this so we don't lose sight of the fact this is ultimately about people.
But I also think we've had a culture shift that's hurting our field. Where engineers are arguing about if we should implement certain features based on the monetary value (which are all fictional anyways). But that's not our job. At best, it's the job of the engineering manager to convince the business people that it has not only utility value, but monetary.
> Your concern isn't about the money, your concern is about the product. That's what you're hired for.
According to whom? Certainly not the people did the hiring.
I somewhat agree that developers should optimize for something other than pure monetary value, but it has nothing to do with the hiring relationship, just the moral duty to use what power you have to make the world better. In general, this can easily conflict with "what you're hired for."
In this case I think showing suspicious (or even all) invisible Unicode in PRs is even a monetarily valuable feature, so the moral angle is mostly moot. And I would put the primary moral burden primarily on the product management either way, since they're the ones with the most power to affect the product, potentially either ordering the right thing to be done or stopping the devs when they try to do it on their own.
> According to whom? Certainly not the people did the hiring.
Actually yes, according to them. Maybe they'll say that you should also be concerned about the money but that just makes the business people redundant now doesn't it? So is it better if I clarify and say that the product is your primary concern?
As a developer you have a de facto primary concern with the product. They hire you to... develop. They do not hire you to manage finances, they hire you to manage the product. Doing both is more the job of the engineering manager. But as a developer your expertize is in developing. I don't think this is a crazy viewpoint.
You were hired for your technical skills, not your MBA.
> In this case I think showing suspicious (or even all) invisible Unicode in PRs is even a monetarily valuable feature
I agree. Though I also think this is true for many things that improve the product.
Also note that I'm writing to my audience.
>> but HN is a space for developers, not the business people.
How I communicate with management is different, but I'm exhausted when talking to fellow developers and the first question being about monetary value. That's not the first question in our side of things. Our first question is "is this useful?" or "does this improve the product?" If the answer is "yes" then I am /okay/ talking about monetary value. If it's easy to implement and helps the product, just implement it. If it requires time and the utility is valuable then yes, it helps to formulate an argument about monetary value since management doesn't understand any other language, but between developers that is a rather crazy place to start out (unless the proposal is clearly extremely costly. But then say "I don't think you'd ever convince management" instead of "okay, but what is the 'value' of that feature?"). If I wanted to talk to business people I'd talk to the business people, not another developer...
They might say that your job is to make the product "better", and they might even think they mean it, but I think in practice you'll find that their definition of "better" as it relates to products is pretty closely related to money, and further that they are the authorities on what makes the product "better" so you should shut up and do what they say. If you want to make the product actually better, you're going to have to defy them occasionally. That's not what you were hired for, that's just being a human with principles.
To be frank, I tried to address your point with my comment about the audience.
I very much disagree that you start with money and work backwards to technical problems. I do not think this approach would make you efficient at solving problems nor at increasing profits for the business.
And I still firmly believe they need us more than we need them. At the end of the day this is why they want AI coding agents to work out but I do not think that even in the best situation we'll end up in any different of a situation than COBOL. You can make developers more efficient, but replacing them requires an entirely different set of skills.
An MBA-type, with no programming background, has a better chance getting their photos taken with their iPhone in a museum than they do replacing a developer. I'm sure there will be some successful at it, but exceptions do not define the rule.
Talking about the audience completely misses my point. I'm not saying it's good to start with money and work back. I'm saying that's what companies actually do, and furthermore that's something the "dev audience" should understand about their employers.
> I do not think this approach would make you efficient at solving problems nor at increasing profits for the business.
If optimizing for profit doesn't result in profit, it's not the fault of the goal. That company was just incompetent. However many companies are, in fact, moderately competent, and optimizing for profit works fine for them. It even has a pretty heavy overlap with optimizing for good products, so that's nice.
It's fine. We agree on the ideal outcome in this situation.
It absolutely is. They are simply spreading malware. You can't claim to be a 'dumb pipe' when your whole reason for existence is to make something people deemed 'too complex' simple enough for others to use, then you have an immediate responsibility to not only reduce complexity but to also ensure safety. Dumbing stuff down comes with a duty of care.
Probably. I would argue that showing up extremely late for an interview that you scheduled is considerably more jerk-ish.
It also wasn’t passive aggressive, or at least it wasn’t intended to be. I actually wanted to know if that was just a thing that was common in the company so I could plan accordingly.
Saying something like "Actually, I felt it was unprofessional and disrespectful to not have the interview start at the agreed-upon time" would also be direct, no? The way it's written sounds way more inflammatory.
Pointing out something that was objectively douchy isn’t “wrong”. Yes I was a little snarky, and maybe I am a “jerk”, but considering that this person was happy to just waste my time like it was nothing I do think he was entitled to a little embarrassment.
“Tit for tat” and “spite” feel like they are very strong words for what amounted to a justified smartass comment.
If I had shown up fifteen minutes late for the interview I wouldn’t have gotten an offer and the interviewer might have made a comment about it during the interview and people generally wouldn’t call them an asshole for it.
The fact that you only want to hire workers who won’t call you out when they feel like they have been disrespected is a great way to breed a team of people who resent you.
Regardless, you kind of proved what I was trying to say. Most people don’t actually want directness. The fact that when I was direct with someone you’re treating it like some mafioso retribution is telling.
In practice you can infer a lot. The payload of a TLS stream is formally indistinguishable from random data, but you can still tell on the wire that it's TLS. There aren't a lot of widely-used TLS implementations. It's been a while since I looked at the specifics, but I bet there's a lot of more specific signature data in the plain-text parts of the protocol like supported ciphers. You can make some good guesses from the metadata.
In the case of a physical interception, you can probably infer more. If you, after reading this article, spot an enemy drone that doesn't have any obvious emissions, then, well, there might only be one option for the software running on that drone, namely The Software that your enemy uses on their drones.
Anyway, it's not clear to me from the article whether the source object from the signal will necessarily be invisible. I think every transmitter still at least looks like a point source of blackbody radiation. The signal may not be detectable from thermal background radiation, but if the background itself is coming from a big obvious drone, well, you know it "exists nearby".
You do have to try, though, is the point. It's not automatic just because the output of the cipher itself is cryptographically random. And when you do try, the lack of metadata will itself be a clue as to the software generating it.
> transmitter still at least looks like a point source of blackbody radiation
The whole trick is that on average it is a source of blackbody radiation exactly like any other piece of matter next to it, same temperature. It does not produce a light or dark spot on an IR camera image. It turns hotter ("positive light") and colder ("negative light") with a very high frequency, in a controllable way.
Yes, in particular emotional trust is key. Maybe a few people can just declare their own emotional reactions away and have that stick, but you can't ask that of other people. We're still just apes. So if you want brief, clear communication, you need people to actually believe in their guts that when you tell them something they did is broken, it's not a personal attack.
> You end up with tribal knowledge to the extreme if you communicate like this.
Wait, what? How does a team habit of bluntly stating facts result in "tribal knowledge"? If anything it should be the opposite. The approach in the article has problems but I don't believe that's one of them.
reply