extensions choose on which site they're active and if they provide any available assets (e.g. some extensions modify CSS of the website by injecting their CSS, so that asset is public and then any website where the extension is active can call fetch("chrome-extension:///whatever/file/needed.css" if it knows the extension ID (fixed for each extension) and the file path to such asset... if the fetch result is 404, it can assume the extension is not installed, if the result is 200 it can assume the extension is installed.

This is what LinkedIn is doing... they have their own database of extension IDs and a known working file path, and they are just calling these fetches... they have been doing it for years, I've noticed it a few years back when I was developing a chrome extension which also worked with LinkedIn, but back then it was less than 100 extensions scanned, so I just assumed they want to detect specific extensions which break their site or their terms of use... now it's apparently 6000+ extensions...

A flux/redux "Store" acts as a Model -> contains all the global state and exactly decides what gets rendered. A flux/redux "Dispatcher" acts as a Controller. And React "Components" (views) get their props from the "Store" and send "events" to "dispatcher", which in turn modifies the "Store" and forces a redraw.

Of course they aren't "entirely decoupled" because the view still has to call the controller functions, but the same controller action can be called from multiple views, and you can still design the architecture from Model, through Controller (which properties can change under what conditions) and then design the Views (where the interactions can happen).

unless a security issue is reported it does feel very much the same...

Before LLMs once I was done with the design choices as you mention them - risks, constraints, technical debt, alternatives, possibilities, ... I cooked up a plan, and with that plan, I could write the code without having to think hard. Actually writing code was relaxing for me, and I feel like I need some relax between hard thinking sessions.

Nowadays we leave the code writing to LLMs because they do it way faster than a human could, but then have to think hard to check if the code LLM wrote satisfies the requirements.

Also reviewing junior developers' PRs became harder with them using LLMs. Juniors powered by AI are more ambitious and more careless. AI often suggests complicated code the juniors themselves don't understand and they just see that it works and commit it. Sometimes it suggests new library dependencies juniors wouldn't think of themselves, and of course it's the senior's role to decide whether the dependency is warranted and worthy of being included. Average PR length also increased. And juniors are working way faster with AI so we spend more time doing PR reviews.

I feel like my whole work somehow from both sides collapsed to reviewing code = from one side the code that my AI writes, from the other side the code that juniors' AI wrote, the amount of which has increased. And even though I like reviewing code, it feels like the hardest part of my profession and I liked it more when it was balanced with tasks which required less thinking...

I would expect most datacenters to use their own local recursive caching DNS servers instead of relying on 1.1.1.1 to minimize latency.

"Testing environment" sounds to me like a real network real user devices are used with (like the network used inside CloudFlare offices). That's what I would do if I was developing a DNS server anyway, other than unit tests (which obviously wouldn't catch this unless they were explicitly written for this case) and maybe integration/end-to-end tests, which might be running in Alpine Linux containers and as such using musl. If that's indeed the case, I can easily imagine how noone noticed anything was broken. First look at this line:

> Most DNS clients don’t have this issue. For example, systemd-resolved first parses the records into an ordered set:

Now think about what real end user devices are using: Windows/macOS/iOS obviously aren't using glibc and Android also has its own C library even though it's Linux-based, and they all probably fall under the "Most DNS clients don't have this issue.".

That leaves GNU/Linux, where we could reasonably expect most software to use glibc for resolving queries, so presumably anyone using Linux on their laptop would catch this right? Except most distributions started using systemd-resolved (most notable exception is Debian, but not many people use that on desktops/laptops), which is a locally-cached recursive DNS server, and as such acts as a middleman between glibc software and the network configured DNS server, so it would resolve 1.1.1.1 queries correctly, and then return the results from its cache ordered by its own ordering algorithm.

If python version changes in an uv-managed project, you don't have to do any extra step, just run "uv sync" as you normally do when you want to install updated dependencies. uv automatically detects it needs a new python, downloads it, re-creates the virtual environment with it and installs the deps all in one command.

And since it's the command which everyone does anytime a dependency update is required, no dev is gonna panic why the app is not working after we merge in some new code which requires newer python cause he missed the python update memo.

maybe you linked a different picture?

Oh and there's also RTX PRO 6000 Blackwell which is Blackwell from 2025...

Android also sucks for developers because they have the public facing numbers and then API versions which are different and not always scaling linearly (sometimes there is something like "Android 8.1" or "Android 12L" with a newer API), and as developers you always deal with the API numbers (you specify minimum API version, not the minimum "OS version" your code runs in your code), and have to map that back to version numbers the users and managers know to present it to them when you're upping the minimum requirements...

This feels absolutely insane for today's standards. And not just in the gaming world. Somehow with all the advancement of libraries, frameworks, coding tools, and even AI these days, development speeds seem so much slower and it seems like too much time is spent on eye candy, monetization and dark patterns and too few times on things people actually like to see - that's what made us buy games and software in the old days.

(But also in the gaming world, especially the past few years when almost no game studio develops its own engine, assets don't look more detailed than what was used 3 years ago, stories seem hastily written and it feels like 80% of developer's time is spent on making cosmetic items for purchase which often cost more than the base game price)

Also somehow we spend lots of times researching UX and developing tutorials (remember when software had the "?" button next to the close button and no software "tutorials" were needed?) and yet all the games and software are harder to learn than what we had in the 90s and 00s.

This is a very misleading sentence. HBO Max has been available in 14/27 EU countries since 2022, and by now it's available in 22/27 EU countries, 4 of the remaining ones are covered by Sky, with which they signed an exclusive distribution agreement valid until 2025 back in 2019 - even before HBO Max was launched in the USA.

This is the vulnerable workflow in question: https://github.com/PostHog/posthog/blob/c60544bc1c07deecf336...

> Why are actions configured per branch?

This workflow uses `pull_request_target` targeting where the actions are configured by the branch you're merging PR into, which should be safe - attacker can't modify the YML actions are running.

> Why do workflows have such strong permissions?

What permissions are workflow run with is irrelevant here, because the workflow runs the JS script with a custom access token instead of the permissions associated with the GH actions runner by default.

> Why is security almost impossible to achieve instead of being the default?

The default for `pull_request_target` is to checkout the branch you're trying to merge into (which again should be safe as it doesn't contain attacker's files), but this workflow explicitly checks out the attacker's branch on line 22.

And that's not excusable - every feature should have its maintainer who should know that a large framework update like Liquid Glass can break basically anything and should re-test the app under every scenario they could think of (and as "the maintainer" they should know all the scenarios) and push to fix any found bugs...

Also a company as big as Apple should eat its own dogfood and force their employees to use the beta versions to find as many bugs as they could... If every Apple employee used the beta version on their own personal computer before release I can't realistically imagine how the "Electron app slowing down Tahoe" issue wouldn't be discovered before global release...

Tutorials (at least the good ones) give you some knowledge - the tutorial often explains why they do what they do and how they do it, but don't give you any skill, you just follow what other people do, you don't learn how to build stuff on your own.

Vibe coding on the other hand gives you some skill - how to build stuff with AI, but don't give you necessary coding knowledge - the AI does all the decisions for you and doesn't explain why it did what it did, or how it did it, it just does it for you.

"I can't do anything without Cursor's help" is not really the problem. The problem is that vibe coders create some stuff and they don't understand how that stuff works. And I believe this is much bigger problem than knowing how stuff works but not knowing how to use it.

Learning doesn't need to be "uncomfortable". Learning needs to be "challenging". There is a difference. The suggested approach here vaguely reminds me of the "you must first learn how to code in a notepad before using an IDE" approach.

While the real takeaway should be "you must first learn how to learn, before properly learning something". To learn something properly, you need 2 things: To know what to learn, and to know when you've learned it. To know what to learn you need a curriculum - this obviously depends on your specialization for coders, and can be more crude or more detailed, but you still need something to follow so that you can track your progress. "When you've learned it" for coders is when you can explain what some code does to a colleague and answer questions about said code. It doesn't matter if you wrote it, or someone else wrote it, or an AI wrote it. Understanding code you didn't write is even more important than understanding your own code.

For example:

- When multiple people respond to the same email, the email "thread" branches out into a tree. If the tree branches out multiple times, keeping track of all the replies gets messy.

- While most clients can show you the thread/tree structure of an email chain, it only works if you've been on every email in the chain. If you get CC'd later, you'll just see a single email and navigating that is messy.

- Also if you get CC'd later, you can't access any attachments from the chain.

- You can link to a Slack/Teams conversation and as long as it's in a public channel, anyone with the link can get in on it (for example you have a conversation about a proposed feature which then turns into a task -> you describe the task simply and link "more info in this slack convo"), you can't do that with Emails (well I guess you could export a .eml file, but it has the same issue as getting CC'd later)

- When a thread no longer interests you, you can mute it in Slack/Teams. You can't realistically do that with emails, as most people will just hit "reply all"

- But also sometimes people will hit "reply" instead of "reply all" by a mistake and a message doesn't get delivered to everyone in the thread.