Posts by Crypto Monad 741 publicly visible posts • joined 14 Dec 2017
It's an interesting read, but I can see several weaknesses in their arguments.
1. Every business starts to write their own software instead of spending $500K/yr on SaaS fees. However, the Anthropics and OpenAI's of this world who make this possible will be looking to capture a substantial portion of that $500K. You replace SaaS with AIaaS, and the more you're hooked, the more they'll take. Also, when your AI-software breaks, or screws up a high value transaction, there is no accountability - you are on your own to support the resulting mess. (Or you need AI to do that for you too). Liability is the brake against in-sourcing; it's one of the reasons people have been outsourcing.
2. AI agents will act purely in the interests of consumers, and hence destroy the sellers. Why would they? Surely the purveyors of the AI agents will make them act in their own interests, in the same way as Google results are skewed by advertising: the agents will send customers to the seller that makes the agent the most commission, not the one that offers the best deal to the consumer. After all, the consumers are unlikely to pay for the agents, any more than they pay for search.
3. Visa and Mastercard will fail because blockchain is cheaper. There's nothing about blockchain which makes transactions fundamentally cheap: indeed, quite the opposite. All that Visa and Mastercard do is to record transactions in a database. It's possible that more challengers will spring up, in the way that Paypal, Wise and so on have already done. But much of that 1-3% credit card transaction fee goes on fulfilling legal requirements, consumer protection, covering bad debts and so on. You can in any case do bank-to-bank transactions essentially for free today already.
The problem is laziness.
"git pull" is almost free, bandwidth-wise; to update a local copy of a respository, it only fetches the differences from your local copy.
The problem is these people are building CI/CD pipelines which start from fresh state and do a "git clone" from scratch, every time. Not only are they fetching the latest version of everything, if they omit to do a "shallow" clone then they're also fetching the entire version history.
The solution is simple:
1. Keep your own git copy of the code you use, and refresh it via "git pull" periodically.
2. Point your CI/CD at your local git copy. Clone it as many times as you like, nobody is affected.
IMO there's no need for a pricing model. As the article says, the offenders are the big hyperscalers; they easily have the resources to do (1) and (2). In principle then, the solution is simply to block out the big consumers who keep cloning over and over again.
However, this still requires users to register, and there's a risk of some people using throw-away registrations as a way to work around the blocks.
> "DSG acknowledges that it, as an organization, could make the link between the card data and real individuals, but says the attackers could not."
And by Curry's logic: if they had also lost your National Insurance Number, your date of birth, your telephone number, your E-mail address, or your shoe size, none of that would be personal information either.
It's not lack of decent programmers, it's risk-aversion.
Google scares them by saying "if your app runs on a rooted phone, then the app can be compromised and made to fake transactions". So the banks respond by intentionally making their apps detect rooted phones, and refusing to run on them.
I think this is only possible because there are existing standards documenting the C language in reasonably formal detail - and many existing test suites which (I expect) would be re-used.
Using vibe coding for some vaguely defined task like "build a business automation system" is likely to be much harder. SAP need not worry just yet.
-O3 being dangerous strikes me as somewhat absurd. If the compiler is building code that does not implement the as-written source's functionality, then it's not acting as a C compiler. Instead, it's acting as a nearly-but-not-quite C compiler that goes wrong in exciting and arcane ways.
It doesn't "go wrong". It transforms your code so that it does the same thing but faster. That's unless:
(1) you're doing something which has "undefined" behaviour in the C spec (which is quite a lot). In those cases, the compiler can make the code behave more or less however it likes. But then, the behaviour is undefined with or without optimization.
Some examples: https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-In-Action/
(2) you're doing something which depends on timing, which is the case here. The C spec has nothing to say about timing of the generated assembly language, and as long as it gets the same results according to the spec, it can shuffle things around.
Note that this is not limited to gcc. Clang can give equally surprising behaviours:
https://research.swtch.com/ub
To reiterate, this is *not* a bug in the compiler. If anything, it's a bug in the language which explicitly permits your code to be transformed in ways you don't expect.
> Since Google sees more than 49% of its users connecting via IPv6, and that doesn't include China, it's more of a success than a failure.
The Internet has split into two.
There's a TV broadcast network: Google, Apple, Netflix, Spotify, Facebook. These sites account for a large propertion of total traffic by volume. These install CDN nodes very close to the customers - often inside the ISP networks. For them, Internet is just "last mile" content delivery; they often have their own private links between data centres. And these are the sites which have deployed IPv6.
Then there's the rest of the Internet: where you find banks and shops and restaurants and other businesses. Most of this part does *not* run IPv6.
So it's not surprising that Google see a substantial proportion of IPv6: it reflects that a sizeable proportion of Youtube watchers have dual stack at home (usually without realising it). But offices, hotels, enterprises ... not so much.
"And that notional committee made one more critical choice: IPv6 was not backward-compatible with IPv4, meaning users had to choose one or the other – or decide to run both in parallel.
For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements."
That's not the reason at all. The reason IPv6 is not used is because IPv6 was designed to *replace* the Internet, instead of *extend* it. And the Internet had already become too important to replace.
Network builders don't have a choice between IPv6 and IPv4. They have a choice between (IPv6+IPv4) or (IPv4 only), since IPv4 is where the majority of Internet content is. Even if it were the minority, you'd still want to reach it. A customer who can't connect to their bank will report this as "My Internet connection is not working".
In which case, the choice is obvious: (IPv4 only) is simpler, more reliable, easier to debug and maintain, and therefore cheaper, than (IPv6+IPv4).
It *is* kind-of possible to build an IPv6-only network today and have it talk to the Internet, but you need a NAT64 gateway, and you need clients which are able to use it: macOS/iOS/Android can, but Windows still can't (*), and Linux can't without a load of hacks. Also, you still need an IPv4 address on the outside of your NAT64, which means you still need IPv4 somewhere in your network. In that case, you might as well run NAT44 instead.
IPv6 also changed things that didn't need changing, like replacing ARP with NDP, and trying to replace DHCP with SLAAC (but ultimately being forced to run both side by side); these are minor annoyances that turn people off IPv6. But fundamentally it's a business issue: do you want to run one network or two? If you want to connect to the Internet, you need IPv4, but you don't need IPv6.
Finally, don't claim that you need IPv6 to access IPv6-only websites, because they won't exist, apart from <tt>loopsofzen</tt> and a few cat feeders. Eyeballs equal money, and any site that wants eyeballs must be accessible from IPv4 clients. Fortunately, this is easy and cheap, because CDNs can host an unlimited number of sites on the same pool of IPv4 addresses. And even if you had to pay for a real IPv4 address for your website, this would still be far cheaper than the millions companies are paying for a cool-sounding domain name.
Aside: I am a techie. I do run dual-stack at home. I like having direct access to my VMs from outside, if I happen to be on an IPv6-capable network. But I can understand why the vast majority of enterprises in particular are not bothering with IPv6; dual-stack is significant cost for zero return, and single-stack IPv6 does not work for many important use cases.
(*) Unless you spoof DNS with DNS64, and that doesn't work in all cases.
There's a nice touch from Google. One of the AI mode settings is:
AI Entrypoint Disabled on User Input
Hide the Omnibox entrypoint for AI Mode while user is typing. – Mac, Windows, Linux, ChromeOS
And the choices are "Default", "Enabled" or "Disabled".
So: if I want to disable the AI Entrypoint on User Input, do I need to set "AI Entrypoint Disabled" to "Enabled"?
Around 1994, an 80836 machine with 2 MiB of RAM could happily run Windows 3.11 (a.k.a. Windows for Workgroups), and Linux kernel 1.2.13 would run well on a similarly spec'd machine.
The smallest Linux these days, something like OpenWrt or ddwrt, is unlikely to work with anything less than 64MiB of RAM.
The only reference for what this code is *supposed* to do is the code itself. Therefore, the best that can be achieved automatically is to faithfully reproduce all the existing bugs - which may require writing very tortuous Rust code to achieve.
OTOH, if the objective is to write idiomatic and safe Rust, then how will the AI tell the difference between a bug, where behaviour has to be changed to match intent (such as removing a security flaw), and a feature (i.e. some aspect of behaviour which consumers depend on, and cannot be simplified away)?
I won't be buying any crowdfunded communication device again.
I bought one of the early Planet Computers "Gemini" devices, with a built-in keyboard (funded via Indiegogo). After a single upgrade to Android 8.1 a few months after initial release, they abandoned all further software updates. As a result, it rapidly became useless for things like NHS, banking apps etc.
Bizarrely, they are still selling trying to flog the remaining few units. The wifi-only version at least appears to be still in stock.
My guess is: he's one of the refuseniks who has decided not to attach a credit card to his Apple account, which is why he needs gift cards to pay for things like iCloud.
Apple have made it very hard these days *not* to attach a credit card to your account, and perhaps they now flag such non-compliant behaviour as deviant or malicious. We're Apple: you must trust us with direct access to your financial instruments. And if you don't, tough luck: we'll lock you out of the whole ecosystem.
Keycloak is now a CNCF project, and as far as I can see, is released under the Apache2 licence which is one of the least restrictive open source licences. What are you saying they're doing to stifle commercial use?
Hashicorp is a different matter, they've gone to BSL.
AWS has a service called Amazon DocumentDB, which is a MongoDB-compatible storage system.
As far as I can tell, this and the Microsoft documentdb postgresql extension referred to in this article are completely different things - which gives much scope for confusion, and/or potential trademark litigation.
> virt-manager excels at transparently managing remote hypervisors over the network
FWIW, incus is very good at that too - for both containers and VMs.
The incus daemon needs to run on Linux, or in a Linux VM on other platforms (e.g. see colima), but the client is native across multiple platforms. You just add your Linux incus servers as "remotes". And if you like, running "incus webui" gives you a web interface, via a secure tunnel.
The problem with fingerprint security is that you leave a copy of it on every object you pick up or touch, so its worse that leaving your password on a sticky note.
The difference is that passwords can be used remotely, whereas fingerprints only have local significance to a device where they have been enrolled, and can only be used by *physically* presenting something that looks like your finger to that device. In other words, fingerprint readers don't accept images of fingerprints sent over the Internet.
Of course, the risks of secret keys unlocked by fingerprints, versus regular passwords, depends on your threat model - but IMO, in almost all cases, passwords suck way more.
If you're paranoid, you can require a fingerprint *and* a PIN or password to unlock your secret keys. Just don't let anybody watch you type your PIN.
So just how do you change your fingerprints once their data is compromised?
You don't need to change your fingerprint, because the fingerprint isn't being used as a key.
The crypto keys are generated and stored inside a "trusted" secure enclave. The secure enclave does all the crypto operations, like signing and decrypting things, without allowing the keys out.
Presenting a fingerprint to a fingerprint reader is just a way to authorize the secure enclave to perform its actions, when it sees a fingerprint which matches a previously registered one. You could just as well require a PIN to be entered. To avoid brute-forcing the PIN, the enclave will usually enforce increasing delays between attempts, and (for the truly paranoid) the key material is destroyed after too many failures.
Now, if the secure enclave is compromised (as the article says is possible), then it's not your fingerprint or PIN that's compromised - it's the secret key material inside the enclave, and the data which is protected by those keys. Which is the actual valuable thing. Note that it doesn't help the attacker attack any *other* system which is also authorized by your fingerprint.
Of course, "gummy bear" style attacks are still a thing, and they're still a weakness of fingerprint-based systems. Like all security systems, there's a tradeoff between convenience and risk. But that's not the risk being discussed here.
Unless they've changed the main Virtualbox download to bundle the Extension Pack - which as far as I can see, they haven't - then this doesn't make any difference to the status quo.
The rule always was: download *only* Virtualbox (which is GPL). Don't touch the Extension Pack with a bargepole.
Ergo a colliding pair in the 50 - 100 SM range will result in in one of 100 - 200 SM range. We keep observing collisions. Nothing forbidden about any of that.
Sure. But if these collisions are frequent wouldn't we expect to see a continuous distribution of black hole masses: some in 100-200, a bit less in 200-400, less again in 400-800 etc?
In that case, both parties can generate random numbers independently, exchange them, and then XOR them to get the final result.
If there's a risk that one party sees the results of the other before committing to their random numbers, then exchange hashes first (and verify them after exchanging the actual random numbers).
Anyone know why BT don't offer symmetric?
1. So that they can continue to offer "Unlimited" bandwidth packages.
In the download direction, there's only so much bandwidth you can consume: sooner or later you need to watch those videos, or play those games you downloaded. Faster speed mostly means downloading the same amount in a shorter time.
But in the upload direction, there are a minority of people who abuse the network by filling the pipe 24x7, whether that be by hosting bittorrent or by doing full backups of their server every 10 minutes to the cloud. If you apply a transfer limit or FUP, even something huge like 10TB per month, everyone will complain loudly. By keeping the upload speed low, you put a lid on the problem.
Remember that BT/OR are mainly concerned about the 95% of people who just watch Netflix and download games, not the 5% who process 8K video at home and upload it.
2. So that they can allow altnets some of the customers.
If BT/OR were to squeeze altnets completely out of the market, this would be considered anti-competitive, and lead to increased regulation. The altnets have only two selling points: they are cheaper (since they can cherry-pick where to build and are unregulated); and they offer faster uploads. BT/OR is happy to hand off the least profitable, most bandwidth-hungry 5% of customers to altnets in order to show "the market is working".
3. To protect their highly profitable leased line market. Leased lines are still a better grade of service, but for many users, a contended PON symmetric service would be a perfectly acceptable replacement.
I think the vast majority of people that compare DC costs to cloud costs are comparing, say, a single rack (or less) or a COLO situation. When you have a full row, it's a lot less clear cut in terms of price.
If you have heavy-duty compute needs that require a full row of racks in a data centre - that is, they are actually doing real work and not just sitting there idle most of the time - then this is the case that can work out *much* cheaper than cloud.
Say you are using AWS c5.metal (96vCPU, 192GiB RAM, $4.08 per hour): it only takes a few months before you've covered the cost of buying an equivalent server. Even if you got a 50% discount by taking, say, a 1 year reservation, you've still covered the cost in less than a year; after that you're just paying for the colo. And that's before looking at things like data egress pricing, which is the main gouging point.
There's also been a lot of crying wolf recently, like the one which claimed to be "unauthenticated RCE against all GNU/Linux systems" and then turned out to be just CUPS. Or the vague announcement of "probably the worst curl security flaw in a long time" which also turned out to be specific to SOCKS5.
Which is why (a) some skepticism is valid, and (b) the personal reputation of the reporter matters more than anything.
I might be missing something, but as far as I can tell, so far Trump has only *talked* about such tariffs, he has not implemented them. This has caused everyone to scramble around to ramp up their US-based production as quickly as possible - which is what he wanted.
In the same way, he has *talked* about invading Greenland, which has caused everyone in a mad panic to spend more on defence in that area - which was what he wanted. There was no need to actually invade.
The Columbians tried to call his bluff, but in that particular instance it was so one-sided in the US's favour that they didn't have a chance. There is plenty of non-Columbian coffee on the market.
i.e. versioning + object lock, configured with a fixed minimum retention, say 3 months. Then if anyone deletes or overwrites your object, you have 3 months to retrieve the previous version.
Mind you: if an attacker has somehow gained the ability to re-encrypt files in your bucket, then they could instead do it a million times and bankrupt you in AWS storage fees.
They sound like Microsoft.....
Except Microsoft has a large opt-in beta programme. Developer previews of Windows have been in the hands of users for months. They don't just suddenly release a new OS overnight and expect the whole world to upgrade to it simultaneously.
> But I think for anyone thinking of using these cores in a commercial product, the license fee isn't the major cost.
Indeed. The processor cost is X, and some part of it is silicon and some is IP.
At least, that's true as long as the license fee remains flat for a given part. If ARM starts demanding a percentage of the sale price of the *final product*, as has been mooted, then suddenly the equation changes.
It doesn't require that much fuel to give in to gravity
Actually, in the absence of an atmosphere for drag, it requires rather a lot.
Just getting Parker from the Earth into an elliptical orbit around the Sun took a lot of manoeuvering: seven flybys of Venus over more than 6 years, to bleed off enough momentum.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2026
