Nextgrid

Although you can run SIP over TLS (for signalling) and use SRTP for media (key exchange done over the aforementioned signalling channel), in practice most SIP is over unencrypted UDP and media is unencrypted RTP.

If you control both endpoints and they support it you can configure them to use encryption, but even then implementation qualities vary widely (just because you enable SIP over TLS doesn’t mean they’ll actually verify the certificates for example - giving you at best opportunistic encryption), and I bet a lot of the implementations also have bugs/vulnerabilities.

If security is needed, it is often implemented by way of running the whole thing over private links (which can be secured with IPSec or any other VPN technology). In fact that’s presumably what’s happening, but misconfigured equipment making those ENUM lookups would allow the attacker to steer the traffic away from the secure link and towards an endpoint they control over the public internet.

Product pages don't engage in cloaking or selectively serving a different a different page to the search engine crawler from the one served to the visitor. They are ranked based on the content visible on the page. If that's the best match to my search query, so be it (it probably means I am indeed searching for said product page).

Paywalled news articles rank on their full content (potentially displacing other, free sources) yet do not allow me to see it without paying. That's a bit of a problem because if I don't intend or am unable to pay I would much prefer seeing the other source which is free.

(the ice cream example is disingenuous because clearly we do not yet have the technology for ice-cream-over-HTTP. And when we do get such technology, then absolutely give me the option to block paywalled ice cream).

The "/month" is the problem - I just don't read the same paper often enough to justify a recurring subscription even at the intro price, let alone the full price it'll eventually transition to.

I would love it if I could be able to pay _once_ in one-click just like if I was purchasing a physical paper. But until this happens, I'm more than happy not paying (nor reading) paywalled online news.

The problem with paywalled news articles is that the ranking is done on the full article content, yet I am not allowed to see it. This often outranks the results I am allowed to see. Product pages don't have this problem.

Google even has/had a rule against cloaking (the practice of serving search engines a different version of the page from the one visitors get).

If you don’t intend to pay anyway, what’s the issue? This option just gives you the choice to hide paywall results.

There is a regex replacement feature. You could build a list of known paywall domains to rewrite them to your desired paywall unblocker service.

You only need to have a business entity (which, to be fair, can be yourself, although liability concerns apply) once you're about to actually enter into a contract with someone.

Merely listing prices (without an associated automated payment form which could imply a contract was en force upon successful payment) doesn't actually force you to do business with anyone. It would however 1) deter requests for unpaid work by giving them an idea of what it would cost to get what they're looking for and 2) give you an idea of the demand for said services and could give you a warm lead which you can then choose to pursue formally by getting the necessary business structure, legal/business advice, etc.

> Stripe is "just" a payments platform

Counterpoint: you can't just go to Visa/Mastercard or a merchant acquirer out there and set up an account on the same terms that Stripe can.

On the other hand, you can sign up to any LLM provider and get API access on terms that are the same or better (since I'm sure they don't appreciate having a middleman and would benefit from incentivizing direct usage) than OpenRouter gets.

> I don't understand why there isn't a special USB-C protocol to recover bios over SDU/CC pins

Not enough of these cases happen under warranty for them to bother (and out of warranty cases are either neutral, or even beneficial to them if they drive sales of new hardware).

> after a while the investors start asking where their dividends are at

By then, a new fad will come in and you can just pivot to it.

We went from "engagement" (with no concrete plans to monetize said engagement), through a brief period of "blockchain" and now finally AI.

It ain't the cause, but is definitely an enabler, because foreign talent on work visas effectively depends on their job much more so than their domestic counterparts and are thus very unlikely to push back against unreasonable demands or workload.

Don't worry, they are also working hard at destroying those products too.

Not fucking with a thing that works as desired would put a large chunk of the tech industry out of a job.

Can anyone explain the reasoning behind it? I can understand (not saying I approve) targeted opposition to specific scientific claims to favor commercial interests (climate change denial to favor oil & gas, etc), but wouldn't a general anti-science movement make the country less competitive in the long run and directly hurt industries like pharma/etc?

> unless you move to the EU or Japan

Not only that, but the "entitlement" (Apple lingo for code-signature flag that grants capabilities) needed to publish a browser effectively requires to be an established company, ensuring hobbyists can't really get there with an open-source project even though the sources of Firefox are available and could technically be ported.

This is not a true uBlock Origin. It's a best effort attempt at converting UBO rules to Apple's declarative blocking framework, but is nowhere near as capable as actual UBO.

> directory structure, interface design, general state management,

These are currently problematic due to context length. You should have working memory of the whole codebase layout to decide on a sane architecture, identify opportunities for deduplication/consolidation, etc.

Not taking either side here - but surely a lot of cosmological phenomena couldn't be testable/verifiable at the time they were theorized either?

(thinking of black holes for example - they were theorized way before we had observations. And presumably a lot of particle physics can similarly be theorized before we built the technology to experimentally verify them)

> adherence to preestablished acceptance criteria

I was talking more about end-to-end feature/product development process from the perspective of the business, and not merely the "writing code" part. Things like figuring out what to build, what code to write (which remains - just that now you are writing a prompt instead of writing the code directly), design, customer support, regulatory compliance/etc.

From this perspective I believe that even if AI does actually automate away software development, we will find out that on average it was never actually the bottleneck nor a significant cost of the product lifecycle. Thus I'm not in a hurry to go all-in on AI just because I don't see old-school human-powered SW dev at being the bottleneck, at least not on the products/projects I work on (large software products with established customer bases).

In a lot of cases I find that the what to build is the biggest bottleneck - and in fact the relative slowness and occasional pushback (because they have skin in the game - see below) of conventional human-powered SW dev forces the stakeholder to think really well about what they want and gives them time to refine that idea. If I were to give them a hypothetical "SW dev in a minute" magic wand it would result in a lot of ill-defined & incoherent features being thrown at the wall which will quickly overwhelm support, destroy their reputation with customers (or worse, regulators) and become a perpetual maintenance burden slowing down any further development to a standstill (whether human or agentic). So I don't do that for my own sanity, even though that magic wand already exists and it's called Claude Code.

This is not to say I find AI completely useless - I see plenty of opportunities for AI to help out with non-product-related tasks - housekeeping that doesn't introduce/change any functionality and would normally rot in the backlog forever are good candidates, assuming I have good end-to-end tests and a full isolated environment where the agent can drive the whole product to QA its own work as to not create additional review burden (otherwise, I would have to review and QA it myself which is often as much effort as just doing the work myself).

> you don't usually have the time to pour over code when you manage multiple engineers either

One thing that I get with humans but not agents is skin in the game and self-preservation. A human writing code will write in such a way as to minimize future work to himself next time there's an outage, support ticket or likely change request and 2) will retain memory of what he wrote so that he will be able to address that support ticket or outage much quicker than a human having to effectively reverse-engineer the code to figure it out. From that perspective, agentic development didn't save time, it merely shifted it from the development phase to when the first support ticket or problem arises (the former can be scheduled and budgeted in, the latter is worse as it arises at unexpected times, derailing whatever else is happening).

(this obviously only works in environments where engineers are encouraged to own things end-to-end. I know some places treat their human engineers as a dumb one-shot ticket->code translator and discourage thinking or taking responsibility beyond that. These are the same places that wonder why they're not able to make any progress because they're stuck endlessly fire-fighting the crap such a degenerate process produces)

> With juniors [...] output needs to constantly be critically evaluated

This raises a scary catch-22. How are the juniors meant to evaluate the output without the expertise they'd only gain by being "in the trenches" for 10+ years? LLMs only help to a point - as they can be convinced of anything depending on prompting or persuasion (I've had Claude adamantly claim things that were wrong which I only picked up on because of actual experience. Similarly, I can easily steer it off the correct path with just a couple suggestions).

The problem of upskilling engineers is not new - billions have been thrown at the problem in the form of bootcamps/etc and yet there's still no good replacement for actual experience doing things and getting burnt in the process. I'm worried that deference to AI will mean a sea of perpetual juniors (but with senior responsibility and blast radius) and the jobs market for actually skilled & experienced talent drying up even more.

> bespoke personal apps and tooling, development tools, I'm working on games, libraries, various kinds of research, you name it.

Absolutely, same here. But building goodies for yourself is different from building them for paying customers. The latter brings a certain expectation of stability and support. In fact this is why even pre-LLM, there is a huge gap between being able to program and being able to launch a product, and why many programmers' pet projects never made it to the latter.

> Clients are going to accept less stable but more ambitious demos.

Demos? Sure. But generally speaking they're paying you for the actual implementation and subsequent support and maintenance of it. Salespeople being able to bang out a demo with a few prompts without engineering involvement could also mean more cases of them selling an impossible feature (that human-powered engineering could've warned them about).

Depends how "trivial" is the fix. Are they going to get the workshop to pull out the telematics module?

Otherwise the car is still connected and very likely broadcasting telemetry anyway (and the "account" part is handled entirely on the backend). Refusing to set up or use the app is merely a placebo.

> which is much more comforting to the average passenger

Indeed I wonder how much of aviation-related security theatre is more for the perception of safety than any measurable safety improvements.

> there have been so few pilot suicide cases

I'm not sure it's conclusively possible to attribute this to regulations without a "control case" of a different profession lacking such regulations and that has a higher rate of murder-suicide-by-vehicle. It could just be that the low rates are because there just aren't that many suicidal people willing to kill innocent bystanders in the process.

To be clear I'm not arguing for less regulations as I'm not qualified and don't have all the facts, but bringing up a counterpoint that the current regulations might cause people to conceal their mental health troubles until they escalate (and the current low - but non-zero - rates of incidents are in spite of the regulations rather than because).

> wake up to more progress

I wonder how that progress is being measured. Lines of code or counts of PRs? Sure... but I thought the matter of measuring productivity by lines of code was already well-understood as being misguided.

I'm having trouble reconciling all that supposed productivity with the real world where software isn't getting better, delivered faster, or becoming cheaper - unlike virtually all breakthroughs in industrialization (printing press, weaving loom, etc) which led to a quick increase in at least one of such factors.

I'm not denying that AI helps with and excels at parts of the software development lifecycle, but from my experience those parts overall contribute to a small increase in output or merely shift the work elsewhere (where it may just not be part of whatever measurement is being used).

I'm starting to think there is no AI bandwagon per-se - instead the bandwagon most people associate with AI-assisted development is more a bandwagon of sloppy code and low standards - which irresponsible use of AI enables but isn't a prerequisite for (outsourcing sweatshops have been practicing it long before the dawn of LLMs).

Until such a time where rent/paying for housing is no longer a thing and we have a good social safety net, it will just mean pilots will keep their mental health problems under wraps to avoid losing their jobs and becoming homeless.

I wonder of such regulations are in fact counterproductive if it means people don't seek out help when they can and let the problem escalate instead (since you presumably don't go from healthy to murder-suicidal in one day, and early intervention could resolve the problem).

That's selective enforcement though. It's only "assault" because it was done against a cop. It's "just being a dick" when done against anyone else.

The danger of constant surveillance is that a lot more of these "being a dick" incidents will be prosecuted when politically convenient (because equal, fair prosecution of all incidents would not happen as that would quickly cause the law to be changed, preventing its future use selective enforcement).

With the low pay and ever-worsening working conditions, I'd be more worried about oversights/negligence than intentional sabotage (which sometimes happens all the way at manufacturing stage - see the Boeing door incident).

Unfortunately, that is unlikely to get media coverage because the solution would be to respect and pay workers more, a severe crime in a late-stage capitalistic society.

A huge part of the security of Macs is that the security domain is a single chip. Hard to do with an airplane which is inherently a physically-distributed system.

Doesn't this already require to be "on the other side of the airtight hatchway", or am I missing something?

The Marshal.load docs explicitly have a warning that you should not pass it untrusted data: https://docs.ruby-lang.org/en/master/Marshal.html#module-mar...

Traffic monitoring for a fast food chain is dubious at best even in the unencrypted days, but basically useless since the advent of HTTPS and TLS everywhere.