I worked at companies in Paris where it’d be considered "uncommitted" as well, if done consistently. Especially in "small" companies (let’s say fewer than than 20 people). I guess it’s a matter of company culture.
It may be 1000 comments, but including answers to comments, and answers to answers to comments and so on. Since it’s possible to fold "sub threads" of answers in which I am not interested, it becomes pretty manageable.
To read more.
I know it sounds cliché, but here is the plan: instead of setting a quantitative bar (e.g., read 20 books in 2026), I have 5-6 topics I want to explore and get reasonably knowledgeable about. That’s the goal.
> Viral traffic from Hacker News, Twitter, etc. fades quickly; One-time spikes provide no long-term value; Focus on sustainable organic growth instead
I guess it depends on the audience. Our audience is tech-savvy and like RSS feeds, and it can change everything.
You need to make one big "spike", then some people will subscribe to your RSS feed, and some of them will silently follow you and read the future articles that won’t make it to the HN front page.
Looks pretty bad... Hackers on BreachForums are claiming they did that and now have criminal records (wanted persons, victims files, ...) data, and emails from +16M people. If the files contain info on key witnesses, they are now at risk.
macOS/iOS 26.1 had some minor (but annoying) UI bugs. Some of them are still here after having upgraded to 26.2, e.g., the menu displaying wrong Bluetooth device statuses (despite the device working as expected).
The article is self-contradictory in that it acts like that key is super-important ("Operations becomes a nightmare. You now have a cryptographic secret to manage. Where does this key live? Protected by a wrapping key living in a KMS or HSM? Do you use the same key across prod, staging, and dev? If dev needs to test with prod data, does it need access to prod encryption keys? What about CI pipelines? Local developer machines?") but then also acknowledges that we're talking about an obfuscation layer of stuff which is not actually sensitive ("to hide timestamps that aren't sensitive"). Don't get me wrong, it's a definitive drawback for scaling the approach, but most applications have to manage various secrets, most of which are actually important. E.g. session signing keys, API keys etc. It's still common for applications to use signed session with RCE data formats. The language from that article, while not wrong, is much more apt for those keys.
That being said, while fine for obfuscation, it should not be used for security for this purpose, e.g. hidden/unlisted links, confirmation links and so on. Those should use actual, long-ish random keys for access, because the inability to enumerate them is a security feature.
reply