Sandboxing is a mitigation but a very limited one. The library itself can contain a malicious payload -- rust code most often ends up as native code executed on the host.
I think we may need to enter a world where there are fewer, heavily audited, libraries and dependency depth is limited. Allowing unvetted dependencies to be installed by default is not a good way forward. App stores have a similar problem and I think a lot of lessons have been learned there that can be applied.
That world can’t exist unfortunately, because the minute someone wants a feature that isn’t in your core libraries, you just create a new library and we’re back to now.
Yes, or the compile time equivalents. Rust’s safety gets you most of the way there. We just need a capability model in the language, a more limited std and a way to ban untrusted 3rd party libraries from using unsafe code without explicit permission. I dream of a world where a function with the signature of add(u32, u32) -> u32 can’t burn my house down and steal my wife.
Functions should only have access to their arguments. Nothing more. We need to end ambient authority.
Are you sure about that? My understanding is that Haskell programs generally run much more slowly than their C counterparts because of all of Haskell’s magic. Like lazy evaluation and memoisation and however Haskell manages memory.
Rust certainly borrows from Haskell. Like all good languages. But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks.
SeL4 was first written in Haskell and proven correct in Haskell. Then, with a great many years of effort, ported to C and proven correct there. If Haskell were a viable systems language, I suspect the kernel would not have been converted to C.
Yes, I'm sure about that. I said that it is a systems language, not that it is as fast as C! I don't mind if your terminology excludes Haskell from being a systems language, as long as it also excludes Go. They are both managed, garbage collected, fast languages.
> Like lazy evaluation and memoisation
Yes, that causes performance impact. If you don't want the performance impact then don't write code that uses those behaviors. Sure, that rules out large parts of the ecosystem, but I said Haskell was a systems language not that its ecosystem was generally suitable for systems programming.
> however Haskell manages memory
No, Haskell's memory manager is world class, with two (at least) tunable garbage collectors.
> But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks
Nor am I!
> If Haskell were a viable systems language, I suspect the kernel would not have been converted to C.
I suspect they converted it to C because you can't write a kernel in a managed language with a garbage collector.
The pelican has looked very same-y across all frontier models, same color bike, same camera angle, etc. I suspect this challenge is already too embedded in the training data to be a good signal when it succeeds, and maybe even when it fails in pathological ways mirroring existing AI pelicans on the internet.
SVG generation is a good test because it's extremely easy to subjectively assess with visual reasoning where humans are strong. However, pelican on a bike specifically may be overused at this point.
Variations of this comment have been posted for over a year. The pelican has now morphed into part of HN culture rather than a legitimate benchmark, but it's still valuable as a meme.
As often happens with random oddball things which become traditions in web communities, the replies asking what it is or complaining about it, begin to gain their own humor value.
Almost all Musk related negative news gets [flagged] and never hits the the front page, so there is still a silent base on the other "team" apparently.
It's ridiculous to call this tulips, in the sense of a speculative asset whose price depends on resale. A more similar recent example is the dotcom boom and bust based on building internet infrastructure, or the 2008 crash which was based on cyclical infrastructure overinvestment. These crashes were characterized by demand growth not keeping up with investment because the target markets were tapped out. Not clear when we'll get there with AI. The consumer market seems saturated on chatbots but we're not even close to saturated for b2b or self driving for example. And this discounts other new technological offerings which may unlock larger consumer markets (products where people are willing to pay $100 a month instead of 10 or 20)
All that said the dotcom boom is extremely analogous and that crash was quite bad.
dotcom was maybe 100B a year focused on the US and mostly VCs. AI is perhaps 250B global VC (with more than half of ALL VCs concentrated in one sector) and another 800B+ from non-VC. These numbers are basically a guess but structurally we are set up for something much, much worse.
But unlike the dot com boom, demand for tokens has not let up and there is increasing demand. I don’t know where it falls, certainly companies don’t get or right and they either over or under build. With the current demand rate changes it’s hard to understand why you would stop building today.
Demands for tokens exists yes. On one side you have huge demand for the infinitely subsidized tokens so that people can post a "unique" illustration when posting on social media, along with the text itself even.
On the other end we have professionals happy to pay a subscription for heavier use, to build something in the hope to sell it.
I figured I don't believe in value when my dad explained to me his mate fired his team once he realised he could just pay 20 bucks for his Gemini account and run his business. I asked, do you call this value add? He said it must be, since he can produce the same output with no staff.
There is a confusion between profiting from a circumstance and value creation.
You create value if, say, you cure a disease. That it takes you an army of staff or extract maximum profit from it is just a feasibility formula.
That you make the cure more affordable is value creation.
That you cure the same disease but increase your profit doesn't create any value, except to yourself, for a while
Maybe you don't, but it's fairly obvious that a lot of things are changing and things are moving.
Maybe your dad's mate didn't have to expand on his business, good for him. Other business are expanding because they now can.
Will the positive overweigh the negative? Not necessarily, but to go "it's tulip" is the kind of argument so devoid of nuance that we shouldn't be discussing so on HN.
The overwhelming demand for token would not coming from people wanting a unique illustration - it would be from professional usage. In fact, I'm not even sure who is subsidized. The $20 subscription surely isn't being used fully across all members of that subscription.
I think the discrepancy here is that almost all these crashes would not have resulted in an insurance claim, e.g. backing into a pole at 1 mph -- this is not enough damage to report for an average driver.
That said, really bad numbers for an autonomous system which is supposed to be way better than humans.
It depends on what part of the car is crumpled, dented, scratched, or misaligned and what your deductible is. It doesn’t take much body work to hit $250, $500, or even $2000.
A hyperbolic curve doesn't have an underlying meaning modeling a process beyond being a curve which goes vertical at a chosen point. It's a bad curve to fit to a process. Exponentials make sense to model a compounding or self-improving process.
I read TFA. They found a best fit to a hyperbola. Great. One more data point will break the fit. Because it's not modeling a process, it's assigning an arbitrary zero point. Bad model.
This is an excellent example to illustrate an S-curve. There is a certain amount of energy in a photon. It cannot be emitted with less energy. There is 100% efficiency barrier that cannot be surpassed no matter how smart you are.
Sure, but the technology lifetimes and adoption rates have compressed exponentially despite that.
Efficiency is not the only relevant metric, there's also cost, flexibility, lifetime/durability, CRI, etc...
For example, OLEDs are (literally) flexible, but burn out faster then LEDs and are less efficient.
As another example, the light sources for televisions have undergone nearly annual changes! They started with CFL backlights, then side-illumination with white LEDs, then blue light with quantum dots, OLED panels, backlights as controllable grids of LEDs, mini-LED, micro-LED, RGB micro-LED, etc...
We're up to something like 10K dimming zones with the latest TCL panels and 100K is just around the corner.
If you want to light an indoor room to be as bright as the outdoors on a sunny day, you're going to need a lot of heavy, expensive equipment that produces a lot of waste heat (LEDs produce way less than incandescent, but still a significant amount). It's also not going to be a full continuous spectrum of light the way that sunlight is.
I think we can stop building new streetlights at the moment we have full daylight illumination on the visible spectrum 24x7 in urban areas. We’ll probably settle for much less and be happy with that.
If we need more light, we can deploy more power generators.
I think the mistake here is that there is a certain rate of progress where humanity can no longer even collectively process the progress and it is equivalent to infinite progress. This point is the singularity and requires non-human driven progress. We may or may not reach that point but full automation is a requirement to reach it. We may hit a hard wall and devolve to an s-curve, hit a maximum linear progress rate, hit a progress rate bounded by population growth and human capability growth (a much slower exponential), or pass the 1/epsilon slope point where we throw up our hands (singularity). Or have a dark age where progress goes negative. Time will tell.
I think we are on the cusp of it and that growing sense of chaos and acceleration and fear and at the same time gravitational attraction towards it is the beginning.
I think we may need to enter a world where there are fewer, heavily audited, libraries and dependency depth is limited. Allowing unvetted dependencies to be installed by default is not a good way forward. App stores have a similar problem and I think a lot of lessons have been learned there that can be applied.