TrueDuality

How many of the makers of these trash SEO sites are going to voluntarily identify their content as AI generated?

The references I'd direct you to are NIST 800-53r5 controls CM-3 (Configuration Change Control) and CM-4 (Impact Analyses) along with their enhancements, require that configuration changes go through documented approval, security impact analysis, and testing before implementation. A certificate change is unfortunately consider a configuration change to the services.

Each change needs a documented approval trail. While you can get pre-approval for automated rotations as a class of changes, many auditors interpret the controls conservatively and want to see individual change tickets for each cert rotation, even routine ones.

Speaking as someone who has worked in tightly regulated environment, certificates are kind of a nasty problem and there are a couple of requirements that are in conflict for going to full automation of certificates.

- Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal)

- All infrastructure changes need to have the commands executed and contents of files inspected and approved in writing by the change control board before being applied to the environment

That explicit approval of any changes being made within the environment go against these being automated in any way shape or form. These boards usually meet monthly or ad-hoc for time-sensitive security updates and usually have very long lists of changes to review causing the agenda to constantly overflow to the next meeting.

You could probably still make it work as a priority standing agenda idea but its going to still involve manual process and review every month. I wouldn't want to manually rotate and approve certificates every month and many of these requirements have been signed into law (at least in the US).

Starting to see another round of modernization initiatives so maybe in the next few years something could be done...

Almost every one of those benefits _doesn't_ require anything else. You need one more API endpoint to exchange refresh tokens for bearer token (over a simple static API key) and you get those benefits.

The quick rundown of refresh token I'm referring to is:

1. Generate your initial refresh token for the user just like you would a random API key. You really don't need to use a JWT, but you could.

2. The client sends the refresh token to an authentication endpoint. This endpoint validates the token, expires the refresh token and any prior bearer tokens issued to it. The client gets back a new refresh token and a bearer token with an expiration window (lets call it five minutes).

3. The client uses the bearer token for all requests to your API until it expires

4. If the client wants to continue using the API, go back to step 2.

The benefits of that minimal version:

Client restriction and user behavior steering. With the bearer tokens expiring quickly, and refresh tokens being one-time use it is infeasible to share a single credential between multiple clients. With easy provisioning, this will get users to generate one credential per client.

Breach containment and blast radius reduction. If your bearer tokens leak (logs being a surprisingly high source for these), they automatically expire when left in backups or deep in the objects of your git repo. If a bearer token is compromised, it's only valid for your expiration window. If a refresh token is compromised and used, the legitimate client will be knocked offline increasing the likelihood of detection. This property also allows you to know if a leaked refresh token was used at all before it was revoked.

Audit and monitoring opportunities. Every refresh creates a logging checkpoint where you can track usage patterns, detect anomalies, and enforce policy changes. This gives you natural rate limiting and abuse detection points.

Most security frameworks (SOC 2, ISO 27001, etc.) prefer time-limited credentials as a basic security control.

Add an expiration time to refresh tokens to naturally clean up access from broken or no longer used clients. Example: Daily backup script. Refresh token's expiration window is 90 days. The backups would have to not run for 90 days before the token was an issue. If it was still needed the effort is low, just provision a new API key. After 90 days of failure you either already needed to perform maintenance on your backup system or you moved to something else without revoking the access keys.

That is a very specific form of refresh token but not the only model. You can just easily have your "API key" be that refresh token. You submit it to an authentication endpoint, get back a new refresh token and a bearer token, and invalidate the previous bearer token if it was still valid. The bearer token will naturally expire and if you're still using it, just use the refresh immediately, if its days or weeks later you can use it then.

There doesn't need to be any OIDC or third party involved to get all the benefits of them. The keys can't be used by multiple simultaneous clients, they naturally expire and rotate over time, and you can easily audit their use (primarily due to the last two principles).

There are other options that allow long-lived access with naturally rotating keys without OAuth and only a tiny amount of complexity increase that can be managed by a bash script. The refresh token/bearer token combo is pretty powerful and has MUCH stronger security properties than a bare API key.

Wow, that actually sounds pretty great

We're currently running ~30 Llama 3.1 models each with a different fine-tuned LoRa layer for their specific tasks. There was some initial pain as we refined the prompts but have been stable and happy for a while.

Since the Qwen3 0.6B model came out we've been training those. We can't quite compare apples-to-apples, we have a better deeper training data-set from pathological cases and exceptional cases that came out of our production environment. Those right now are looking like they're about at parity with our existing stack for quality and quite a bit faster.

I'm going to try and run through one of our training regimen with this model and see how it compares. Not quite running models this small yet, but it wouldn't surprise me if we could.

Primarily for libraries and deployment environments that aren't fully in your control which is still pretty common once you get to B2B interactions, SaaS is not something you can easily sell to certain environments. Depending on the assurance you need, you might even need to mock out the database entirely to test certain classes of database errors being recoverable or fail in a consistent state.

Even in SaaS systems, once you get large enough with a large enough test suite you'll be wanting to tier those tests starting with a lowest common denominator (sqlite) that doesn't incur network latency before getting into the serious integration tests.

Usenet is still around and still fairly active, though by volume its probably more commonly used as the originating source for anything torrented nowadays. PHP bulletin boards is a good approximation if you squint. If you imagine being on a large number of topical mailing lists all filtered into their own inboxes you wouldn't be far off.

Sure, but that also doesn't scale reasonably and is entirely a facile argument. My original comment supports organization paying this price instead of dealing with internal compliance burdens. Looking at one of the package lock files for a previous company I still occasionally contract for, there are 9400 dependencies referenced.

So in the name of promoting basic numeracy, and taking into account the realities of scale. Matching that cost for those dependencies (this is a >100 person company) would be $560k per month. That gets you minimal support, just a guarantee that you can submit issues. No guaranteed security maintenance, compliance, or governance of the project.

You can spin up a very strong developer team for forking and maintaining an internal copy of opensource projects at that cost and a lot of large companies do just that. Should they contribute those changes back? Sure if that made sense.

A lot of time in my experience that internal copy is stripped to the bones of functionality to remove the surface area of vulnerabilities if the useful piece isn't extracted into the larger body of code directly. It's less functional with major changes specific to that environment. Would the upstream accept that massive gutting? Probably not. Could the company publish their minimal version? Sure but there are costs there as well and you DO have to justify that time and cost.

Would a company in-house the support and development of a tool over $40/month? Absolutely not, for a one-off case that's probably fine. If you want to meaningfully address the compensation issue from enterprises, opensource single-project subscriptions aren't going to be the answer.

I would LOVE to see more developer incentive programs, but one-by-one options aren't scalable and most projects don't want to provide the table-stakes level of support required of any vendor they work with. It's not optional for those organizations, its law and private contracts.

Start-ups and smaller companies that are extremely cash strapped are willing to take an opensource project, compile it themselves, turn it into deployment artifacts and manage that whole lifecycle. There is a threshold where paying someone to manage and certify the lifecycle of tools is more valuable than keeping it in house.

This is pushing those enterprise customers that are just using and updating binary releases because they don't want to take on the compliance risks of first-party support to pay for official versions.

One with only manual interactions and regular context resets. I have a couple of commands I'll use regularly that have 200-500 words in them but it's almost exclusively me riding that console raw.

I'm only on the $100 Max plan and stick to the Sonnet model and I'll run into the hard usage limits after about three hours, that's been down to about two hours recently. The resets are about every four hours.

You're partially right for the case of trilateration, usually these would be placed about 10km apart with a GPS PPS clock (at least) and would be using sensors with a much faster response rate.

With triangulation you only need the clocks accurate enough to correlate the events. This will largely be determined by the rate you see events, and you only need to distinguish specific events if you want to differentiate locations of individual strikes as opposed to a storm front. For a boating case you probably only care about the location of a storm front.

Two sensors measuring angles from a couple dozen meters apart can get you a pretty precise location of storm front especially when aggregating results from multiple detections.

They do but without information from additional locations all you can get is distance and sometimes direction (dependent on specific chip / circuit). The ones with direction will probably good enough for most boating awareness situations.

If you want to know more specifically you need to have separate sensors that have with reasonably synchronized clocks so they can trilaterate or triangulate strike locations. Those sensors probably need to be further away from each other than most boats allow for. The further away the sensors are from each other, the tighter the time synchronization between them, and the more sensors you have will determine the overall accuracy your system will be able to attain.

Bits are a bit misleading here, it would be more accurate to say "units of computation". If you're problem space operates on 32-bit integers this would be 32bits * number of steps, these papers solve for individual bits as the smallest individual unit of computation we can commonly reason about.

You'll commonly see new technologies utilized by people that have the ability to make use of that technology for their own gain. Programmers are (for the most part) the only ones that can unlock LLMs to solve very specific personal problems. There are workflow automation tools allowing non-programmers the ability to do workflows but that's only one way to utilize them and it will always be constrained by the already developed integrations and the constraints of the workflow platform.

In regards to jobs and job losses I have no idea how this is going to impact individual salaries over time in different positions, but I honestly doubt its going to do much. Language models are still pretty bad at working with large projects in a clean and effective way. Maybe that will get better, but I think this generational breakthrough of technology is slowing down a lot.

Even if they do get better, they still need direction and validation. Both of which still require some understanding of what is going on (even vibe coding works better with a skilled engineer).

I suspect there is going to be more "programmers" in the world as a result, but most of them will be producing small boutique single webpage tools and designs that are higher quality than "made by my cousin's kid" that a lot of small businesses have now. Companies > ~30 people with software engineers on staff seem to be using it as a performance enhancer rather than a work replacement tool.

There will always be shitty managers and short-sighted executives that are looking to replace their human staff with some tool, and there will be layoffs but I don't think the overall pool of jobs is going to reduce. For the same reason I don't think there is going to be significant pay adjustments but a dramatic increase in the long-tail of cheap projects that don't make much money on their own.

Can't speak for everyone, but workflows can get pretty crazy in my personal experience.

For example the last place I worked had a mono repo that contained ~80 micro services spread across three separate languages. It also contained ~200 shared libraries used by different subsets of the services. Running the entire unit-test suite took about 1.5 hours. Running the integration tests for everything took about 8 hours and the burn-in behavioral QA tests took 3-4 days. Waiting for the entire test suite to run for every PR is untenable so you start adding complexity to trim down what gets run only to what is relevant to the changes.

A PR would run the unit tests only for the services that had changes included in it. Library changes would also trigger the unit tests in any of the services that depended on them. Some sets of unit tests still required services, some didn't. We used an in-house action that mapped the files changed to relevant sets of tests to run.

When we updated a software dependency, we had a separate in-house action that would locate all the services that use that dependency and attempt to set them attempt to set them to the same value, running the subsequent tests.

Dependency caching is a big one and frankly Github's built-in cacheing is so incredibly buggy and inconsistent it can't be relied on... So third party there. It keeps going on:

- Associating bug reports to recent changes

- Ensuring PRs and issues meet your compliance obligations around change management

- Ensuring changes touching specific lines of code have specific reviewers (CODEOWNERS is not always sufficiently granular)

- Running vulnerability scans

- Running a suite of different static and lint checkers

- Building, tagging, and uploading container artifacts for testing and review

- Building and publishing documentation and initial set of release notes for editing and review

- Notifying out to slack when new releases are available

- Validating certain kinds of changes are backported to supported versions

Special branches might trigger additional processes like running a set of upgrade and regression tests from previously deployed versions (especially if you're supporting long-term support releases).

That was a bit off the top of my head. Splitting that from a mono-repo doesn't simplify the problem unfortunately it just moves it.

Do you have an example of the logic bugs you're referring to?

I was with you until this paragraph:

> The broadest possible interpretation of this ruling is that any website that downloads any digital asset–cookies, javascript, heck maybe even HTML–onto a California resident’s computer can be sued in California, even if the website doesn’t know where the users are. If this is correct, the majority effectively would be saying: if you place a cookie on a reader’s device, you’ve done something more than passive publishing (i.e., you can passively publish without the cookie) and must accept the jurisdictional consequences.

This feels so close, but a little off my interpretation. In Collin's concurrence, he specifically calls out that the required parties "minimum-contacts" in the transaction were both in the state as part of the reason for the unambiguous jurisdiction, with Stripe being a third unexpected party to the information. To insert themselves is in effect inserting themselves into the jurisdiction as well. This paragraph:

> When a State specifically regulates the conduct of electronic systems with respect to transactions within its borders, the as-intended operation of those systems within that State is the relevant tortious conduct for minimum-contacts purposes, and that conduct is attributable to those persons who deliberately intended that such systems reach into that State and operate in that manner when they do so...

For me, this implies that third-party services not required or expected when a user interacts with a site that run scripts or set cookies for anything outside that "minimum-contacts" requirement is liable for what they do with that data, access, and what that code does.

I have the Xreal Air and it's alright. Low resolution and a bit blurry text still. It's the nature of optics right now.

It's a single virtual display by default unless you run a fairly unstable piece of software. I use it mostly on plane flights.

It feels like the tech is almost close enough to really be useful but it's just not quite there yet. It's useful but not pleasant.

While that's true, many enterprise customers are going to have MSAs with notification requirements that have contractual punishments for failure to notify of material security incidents. Those are probably what Oracle is trying to avoid.

Even with the discounts of volume pricing cloud prices are still quite inflated unless you need to inherit specific controls like the P&E ones from FedRAMP High/GovCloud. The catch there is lock-in technologies that may require to re-develop large swaths of your applications if you're heavily reliant on cloud-native tools.

Even going multi-region, hiring dedicated 24/7 data center staff, and purchasing your own hardware amortizes out pretty quickly and can you a serious competitive advantage in pricing against others. This is especially true if you are a large consumer of bandwidth.

I would bet the SpaceX investors would heavily protest taking on the level of indirect debt associated with that company (Elon's shares and the ongoing SEC payout fight there), though he may have a controlling interest in SpaceX.

Even with controlling interest it likely would result in a class-action from shareholders... But he's defanging all the federal organizations that have been keeping his double handed dealings in check and the judiciary that would oversee the cases sooo... Oligarch can do no wrong?

Always a possibility with custom runtimes, but the weights alone do not pose any form of malicious code risk. The asterisk there is allowing them to run arbitrary commands on your computer but that is ALWAYS a massive risk with these things. That risk is not from who trained the model.

I could have missed a paper but it seems very unlikely even closed door research has gotten to the stage of maliciously tuning models to surreptitiously backdoor someone's machine in a way that wouldn't be very easy to catch.

Your threat model may vary.

AMD's limitation is more of a software problem than a hardware problem at this point.

The native app that allows for MCP is only available officially on Mac's and the web interface is generally more convenient for non-technical users. Searching and interacting with the web has become a table-stakes feature and was a glaring gap in Claude.

I'm a US citizen but I'd be a lot more concerned about the EU if the US falls but not because of the expansionist talk. I do not want to see expansionism rise at all, but the leader we have right now is also a coward and a bully. He might be willing to go for a small country like Panama (and that would still be an _insane_ move) but NATO is still really strong even without the US and I don't think he'd be willing to risk anything but a sure thing.

More likely in my book is the existing wars in the EU spreading, and civil war breaking out in the US. The EU wars are already expanding, loosing stability, and generally getting more politically divisive even if US policy had a strong impact on them. Those tensions aren't new, and at least from this side of the pond it seems like the US was keeping those expansionist actors in check more than encouraging them. Things are not going well in the US politically, and I'll leave it at that.

From the economic side, if there is a US economic collapse, and its definitely not going up, the economies that are going to hurt the most are going to be those built on top of the US dollar as they have outsourced control over the fundamental tools you can use to stabilize your economy in rough times.

Look a bit farther out than the first world countries you're used to. Reliable energy, and energy to your night stand aren't available everywhere and the countries still sticking to 2G largely fall into that category. Having the flexibility to only need a charging once a month makes these devices actually usable tools.

2G due to its lower information density is also easier to receive and transmit generally allowing significantly lower density of towers and longer reliable range. In largely rural areas there aren't enough customers for companies to invest in towers for the same level of 4G coverage.