Which is precisely what I'm responding about above. 93% actually collapses much slower than 90% since the rate of reduction is based on that of all of the previous rounds, not just the current chance. E.g., this is the difference between 14 rounds before an expected failure instead of 10. An extra 4 rounds deep at the same error rate is a big step forward despite a small change in the base percentages. Add just few more percentage points again and you've more than doubled the depth.
I.e. it's precisely when you look at these chained that the difference is actually very large. It's really only the 1st turn or two of prompts where the difference seems negligable.
How are you running that math and what are you consider to be "expected failure"? If even 30% of your runs go into the garbage, that sounds horrifically unreliable, and both 7 and 10% failure rates hit those margins in less than 5 iterations.
Not to mention that the deeper your iterations, the more money burned on garbage before you realize that data in turned to garbage out turned to garbage in somewhere in the chain.
I'm taking 0.90^n and 0.93^n and seeing 0.93 does more than the initial 3% better over time, which preciesly saves you from things like spending tokens on garbage by this larger factor. You're free to pick whatever target reliabilities from that. E.g. you can maintain above 80% accuracy over 3 turns rather than 2 or 50% over 6 turns instead of 3 or you can pick another percentage point and see how the depth to expected error/expected error at depth numbers are much better than 3% and how another 3% actually doubles accuracy because this is all non-linear.
There's also the matter of "90% compared to what". If it was 90% per attempt compared to a calculator then I'd just use a calculator. If it was 90% per attempt for something I have a 10% chance of getting right per attempt then it's not really so bad. OTOH if it's 90% per attempt at keeping my car in the lane then it's obviously quite bad. I.e. there isn't one "reliable percentage" to target which is why I'm comparing the curve instead of just the most stringent things I can think of in isolation.
Completely agree that error tolerance depends on what it is that we're doing. Some things demand no errors at all, some things have a cost to attempt, some things you can't pre-evaluate for correctness if you don't already have the prerequisite knowledge and you only get one chance. Not everything is software where we can conjure 50 more end-to-end tests to ward off demons. When it's not a harmless throwaway weekend project, 7% is already a huge error rate before you ever think of feeding it back into itself.
I of course agree not everything is fine with 93%, but via the very same reasons believe a 3% error rate change is a big deal rather than a reason to dismiss the improvement: not every task has the same tolerance, but there's not many percentage points left until it'd be claiming all of them.
That's completely orthogonal to whether you can still find tasks which require more accuracy or not (except for the sole case someone claims it's 100%).
You might be thinking along the lines of the O-ring theory. Indeed long supply chains accumulate errors exponentially.
However the origins of theory explored the outcome of disastrous and irreparable outcome of space shuttle exploding, lives lost, and billion of dollars destroyed.
When LLM goes off the rails the cost is much lower, and retry is on the table. In fact our core competency shifted from writing code to creating environment where agents can retry cheaply and course correct based on feedback.
A modest increase in the number of turns it takes to reach decorehenve could make a difference between
Decoherence and reaching the a grounded checkpoint.
If failure is essentially guaranteed somewhere in that chain, success becomes impossible. You don't need to lose lives to have simply have a fruitless endeavor. And when we're talking about law, we're talking about more than a fruitless endeavor. Law also isn't software that can have tests crafted and fed back into the loop.
My last job I was notified via text message on a Saturday that I didn't need to come back into the office Monday. The USA has basically zero protections for employees.
Yep. My company, based in the US, did that to most of our US team. Being somewhere with decent employment regulation meant that they kept us and not the US guys.
Power longevity might not be the reason since in this project, having faster transition seems to be done by using less change waves, which probably uses less electricity.
The hardware owner can modify it all they want, disable SIP. For a large swath of average and non-average users that will not be modifying the closed-source OS they're running, it is obviously good.
Traditional UNIX is does not mean having an open source core you're intended to tinker with. Traditional UNIX was entirely proprietary, connected with well-defined text-based interfaces. This is entirely orthogonal to user control and manipulation of the OS.
Also worth keeping in mind that macOS is intended for use with commercial third party software that’s repeatedly been proven untrustworthy, doing things like prodding system internals and installing dodgy kernel extensions where neither is warranted.
SIP is as much defense from the likes of Adobe and Google as it is from more traditional malware.
For now SIP can be disabled (on mac, not of course on iOS that is completely closed) but I wonder for how much. It's clear that the desire of Apple is to make macOS a closed system like iOS, installing third party software outside the AppStore is more and more difficult, with Gatekeeper that asks you to enter the system settings and warn about "potential insecure stuff" each time you want to run an application downloaded from the internet not signed by Apple (yes I know that if you disable SIP you can get rid of Gatekeeper as well).
I think that piece by piece Apple wants to go into direction of making macOS just a desktop version of iOS, that is closed and impossible to modify. They will use of course security as an excuse, the practical thing is that with iOS they succeeded because they went to the market with an OS that was already closed, but making users accept that in new version downloading a software from the internet and installing it it's no longer possible takes time. But they are getting there soon to me.
The reason why that won't happen (but more and more warning prompts all the time because of this modern world...) is because macOS is a self-hosted platform.
Apple _needs_ macOS as an unlocked OS at the very least as a development platform to develop their operating systems on. Not having the self-hosting requirements allows to tighten the security model a lot.
Notably, with a Unix terminal, a huge problem for sandboxing is how to determine permissions granularly, whereas a UI flow has significantly better answers to that.
Traditional UNIX was entirely proprietary, with source you're intended to tinker with.
AT&T was forbidden by its consent decree from productizing Unix. Licensees received the source code, on an as-is basis, with no official support from AT&T.
Sure, but that just means UNIX vendors had access to the source code.
It doesn't mean end users had access to the source code.
In fact, vendors would have been prohibited from distributing AT&T source code to customers who weren't themselves AT&T licensees, just as CSRG was prohibited from distributing BSD to customers who weren't licensees before 4.4BSD-Lite.
The same goes for most other proprietary source-available products. For example, game developers can't open source Unreal Engine projects even though Unreal Engine source licenses are available to end users for free.
As jeremyjh wrote at https://news.ycombinator.com/item?id=50032733 , "A system that the hardware owner cannot modify is not really on the same wavelength as traditional UNIX.". Since traditional Unix was source-available, with the expectation that people would hack on the source, I fully agree with jeremyjh's characterization.
I think you are talking about a later era in Unix history? The early Unix licensees were educational institutions and commercial sites, not vendors or resellers.
Every one of those academic and commercial end users got the source code.
> "In 1973, AT&T released Version 5 Unix and licensed it to educational institutions, and licensed 1975's Version 6 to companies for the first time, ... Anyone could purchase a license, but the terms were very restrictive; licensees only received the source code, on an as-is basis. ... Unix was entirely unsupported by AT&T"
From the same link, "Perkin-Elmer began distributing Wollongong Unix for Interdata as Perkin-Elmer Edition 7, the first version supported by a computer company". That was in 1980.
So while yes, "Traditional UNIX was entirely proprietary" and could not be redistributed to non-licensees, it was also provided with "full user control and manipulation of the OS", and not merely "connected with well-defined text-based interfaces", quoting jdiff at https://news.ycombinator.com/item?id=50033080.
You would absolutely normally get source to the vast majority of the unix components with a unix install.
At a bare minimum, you would almost have to have source to the vast majority of the kernel because there was no kernel modules. Sysgenning for a particular system involved compiling the kernel for that set of hardware.
I'm literally working on an early sun system emulator right now, heavily assisted by the standard sec tape that came with the standard software distribution of sunos, which has plenty of AT&T code.
Sure, if by “you” you mean universities, Sun, DEC, IBM, etc.
As a non corporation end user with a sublicense from one of the above licensees (which is the apt analogy for an individual user in my opinion) you most certainly did not receive the source or have the rights to it.
I regard "traditional Unix" as the 1970s era. There were no sublicensees. You bought the source code from AT&T. That was the only option.
You then likely hacked the source code to make it work on your machine.
I can understand that others might include the commercialization of the 1980s and the Unix wars as part of "traditional Unix", but even then, my IRIX system ca. 1990 supported end-user kernel extensions, to handle new types of devices. Our imaging hardware was not "connected with well-defined text-based interfaces".
True, but we saw alignment issues also on topics that aren't part of OpenAI's business model or business conduct. Like an agent tasked with solving build failures due to failing test cases deciding to "solve" the problem by deleting the failing tests.
It's perfectly reasonable to think less of an individual who is so sheltered that they are incapable of caring for themselves. Whether it's your mother or your maid doing your laundry and cooking your meals for you.
I don't think less of a CEO just because they have an EA that takes care of stuff like phone numbers and mailing addresses for them and their business.
