0xbadcafebee
They cannot follow the Uber model because of scale. You could keep getting tens/hundreds of millions from investors, back when there was lots of cash floating around. But you can't keep getting hundreds of billions of dollars. There are only so many dollars. The world is tapped out of private capital. That's why they want an IPO - so retirement and pension funds are forced to buy their shit stock, and feed them more money. But again there is only so many dollars.
Anyway it does not matter. Subscriptions are the most effective way to extract wealth from customers. This has been established so clearly that every business in America now has a subscription. Your fridge, TV, car, hell even car washes, now have subscriptions. Not because they didn't make money from you before, but because it's the ideal way to make even more money off you. There is no reason not to use subscriptions. No AI company in their right mind would end them.
The question of how much value you get from the subscription is different. They have already adjusted both price and rate limit a dozen times. They will keep adjusting it... but the subscriptions are here to stay.
Like Netflix, Comcast, T-Mobile, etc, etc. There are millions of subscription services in the world. They all "subsidize" higher-usage users with plans for lower-usage users using a fixed price plan and rate limit. The profit comes from lots of users who don't hit their cap. The higher priced plans are actually more profitable.
This is called a tiered usage-based subscription business model.
Chinese models are being banned, will continue to be banned by USG. Even the Chinese govt is restricting external access to models now. It starts with banning Govt access to International AI, but will continue to consumer and business access.
No formal testing means no formal education which means a lack of important detail. You know how you learn the details on the job? By screwing up the job. You gonna let Eddie The Trainee Surgeon work on your brain after leaving a medical school with no grades?
Don't believe the crazy lies that AI can replace your job. AI can't replace anyone's job, because it lies, cheats, hallucinates, can't learn from its mistakes, and can't be held liable.
Example: If you want to learn to do something with your hands, it normally needs to be taught in person, so you can try to do it, fail, the teacher tells you what you did wrong, shows you how, you do it again and it works. But this can now almost entirely be done with AI. A YouTube video shows you how. You practice it on camera. An AI watches the video, tells you where you went wrong, and shows you specific clips to improve. You do it again until you get it right.
The piece of paper you get from a University doesn't need to come from "A University". Any organization that can give you a test in person can see whether you do the thing right or not and give you a certification if you do.
So really all we need now is an AI Khan Academy and independent testing/certification.
Is somebody on HN saying you should *always* do X?
-> Yes
-> Is somebody on HN saying you should *never* do X?
-> Yes
-> You should _sometimes_ do X.What's embarrassing is how many people are clueless about where AI is going. The tech sector is one giant echo chamber, so it thinks whatever it makes will be a miracle cure. Everyone outside the echo chamber has no idea what it is/how it works, so they're just hoping it's the miracle cure the echo chamber keeps saying it is.
In reality, AI is just a minor improvement in productivity that doesn't solve hard problems. It does what we could already do before, a little faster & cheaper, without determinism/trust. It's a bigger, faster truck, but somebody still has to drive it, find a place to park it, spend more on gas, etc. It may be able to "think", but it won't replace humans until it can accept liability.
I recommend Drone.io or WoodpeckerCI for hosting your own CI. It's a very good design; very simple, easy to run, easy to use, integrates with most systems you'd want to, abstracts away components rather than tightly integrating them, and you don't need to be a programmer to use it. So basically the opposite of Dagger.
This is not a server-side issue (unless for some weird reason you're using Brotli decoding in your http request processing), it's client-side.
Thank you Paul for the write-up (https://opensourcemalware.com/blog/node2shell-affects-python)
How will it do that without a model that's good at security? You gonna have humans manually secure the millions of lines of new AI-generated code, in addition to the existing code? Suddenly people will start doing the job they haven't been doing up to now? Not only are we not capable of auditing all the code, it would take decades to finish, and new code will be coming out at the same time. We can't catch up by hand.
The only way to fight this fire is with fire. We need AI hacking tools to find our security holes quickly and patch them. Otherwise we're just churning out more insecure software, and the only people who can defend against it are the governments who don't want to patch the holes (because they want to be able to exploit them). Without open tools, we all lose.
Security has been an afterthought for most of the past 30-40 years, and there are virtually no regulations requiring security, audits, or inspections before releasing software.
Now that attacks are cheap and easy, the only way to prevent these constant compromises will be to secure things before releasing them - not an afterthought, but a prerequisite. If we do finally as a society demand this, then the compromises will go away, because we won't release any new versions of software without securing it first.
This depends on having open weights with strong security scanning. If nations keep banning powerful open weight models "because they're dangerous", those nations' companies will be at more risk, because they won't have the tools to secure their own software. Countries with more permissive models will allow their own businesses to secure their stacks earlier, more people will use those businesses, they will thrive. The invisible hand of the market will choose whoever can improve first, not whoever bans things first.
Other weird facts about OSes: a filesystem is a database, the Linux kernel is a monolithic program, "hidden" dot-files were a Unix bug that got carried forward, deleting a file doesn't remove the file from your machine, virtual memory is a lie, your computer can't run multiple programs at once (it's just running one at a time real fast), in 12 years most systems will crash due to one number getting too big, you technically never need to reboot because you can launch a different version of Linux while already running Linux, you can freeze a program to a file and then later resume running that same program in the same state (but nobody uses it), files aren't actually stored in directories, there's a maximum number of files (and size of file) on most filesystems (which you can use to lock up a machine, despite file quotas existing and nobody using them), you can lock up most systems by forking too many times / using too much RAM / accessing disk too much, there's a default number of open files and/or TCP ports which is artificially low and you can use to again lock up a machine, pipes are just two file descriptors connected to one memory buffer, an IP address is just one long number split up into bytes, etc.
The author is only seeing 10% as small-change, but my version has 80% as small-change. This is due to Terraform forcing you to be intentional about the borders of functional software. There is a minimum-viable-deployable component in Terraform called a Resource: you can add more resources to your module (increasing the scope), but you can't get any smaller than one resource. So it's relatively easy to define what makes a module functional, and reason about how big it gets, before deciding to break the module up. (Technically you can -target specific parts of a single resource but it's quite frowned upon)
Compare to traditional software design, where there is no absolute minimum functionality. You can make "minimum functional software" as huge or as tiny as you want. Different people design their software different ways (often unintentionally) resulting in low cohesion and a very large scope of changes required for minimum function. If you want smaller changes, you have to intentionally design your software for it.
It's factual because there's tons of evidence. Psychology, sociology, anthropology, political science, economics... plenty of experiments show the difference between what people say and what they do. We claim to be angels but we behave like apes in hats. And we ignore the evidence, because (as the takes describe) we prefer to believe a beautiful lie than the ugly truth.
Almost every system on the internet has some local code you can chain to gain root, or a way to put some in place. It gets worse when it affects legacy systems, because they're the bastard stepchild of security. RCE on a box that hasn't been patched since Obama's first term is what little blackhats' dreams are made of. And developers are way too lazy to intentionally design their apps into different privilege domains to protect against chaining. Unless your app runs chroot() (is my neckbeard showing?) or in a container with nothing but a Go binary, somebody can LFI it.
A crack in the door is plenty of space to get a crowbar in (especially with interpreted languages).
So, it's like... software development? 90% of bugs come from unintended consequences of changes after the fact. There's a couple decades of design lessons people had to learn to keep this number low. The agents don't follow those lessons.
Good programmers rely on structure and reinforcement to prevent themselves from introducing bugs. Today that structure is a combination of software frameworks, SDLC gates, and system design patterns. For example, most any Python programmer can reliably churn out a Django app as a Microservice and be fairly sure it won't be that hard to make, or result in tons of unexpected bugs. The reason isn't that it's some perfect software design. It's that prescribed methods in themselves are bumper lanes, keeping you on track. A few of you may remember what programming was like before popular open source frameworks, or maybe you've worked on proprietary big-iron mega-projects. Left entirely to one's own devices, programmers can make a mess of things. Give them a formal structure and suddenly there's less to go wrong.
I wouldn't sit around waiting for models to become uber-programmers. Instead I'd treat 'em like humans, and enforce the structures we know have better results. You can try to impose good design as skills (https://github.com/ciembor/agent-rules-books) but the model will still do things its own way. That's why coding harnesses need to intervene and explicitly enforce the structure/framework/bumper lanes. Basically we need 1,000 different Pi extensions that will intervene as the agent codes in order to enforce the correct design. Otherwise we will forever be chasing some "perfect coding rlhf", and still the model will blunder into corners.
1. CT does not do anything if a state actor demands a CA in its borders generate a cert without publishing to the CT logs (or a three-letter-agency doing this illicitly). They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees.
2. Browsers won't check for SCTs in certs if they come from a private CA. you can MITM any domain through ZScaler all day long and nobody will notice
3. Wildcard certs make it easy to make/renew a cert that looks normal but hides requests on new/different hosts
4. Non-Browsers do not validate SCTs