One needs to read OP's blog post in the context of his other posts from the last couple months (many of which have been discussed here on HN in one way or another), where he does discuss the science.
5,853 karma · joined September 17, 2010
One needs to read OP's blog post in the context of his other posts from the last couple months (many of which have been discussed here on HN in one way or another), where he does discuss the science.
I talked to another guy with the same degree in the same field and he was concerned.
As OP said elsewhere[0, 1]:
> Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”
In other words (IIUC): Some problems (here: scaling fault tolerance) seem to be easier than others.
[0]: https://scottaaronson.blog/?p=9665#comment-2029013
[1]: See also https://news.ycombinator.com/item?id=47959531 for a very similar quote.
Won't this lead to premature abstraction and application of design patterns everywhere? I mean, sure, of course you should do separation of concerns, keep your business domain layer clean of persistence/network/UI/… concerns etc. But your domain layer will still be very much tied to your product. There is no way around that.
> The pattern is clear.
> In our case, the agent didn't just fail safety. It explained, in writing, exactly which safety rules it ignored.
> This isn't a story about one bad agent or one bad API. It's about an entire industry building AI-agent integrations into production infrastructure faster than it's building the safety architecture to make those integrations safe.
Sigh.
Yes, the pattern is very clear. If the author spent less time writing the article than it would take me to read it, why should I even bother?
The agent deleting their prod database is a direct result of this careless "let me just quickly…" attitude.
> The primary feature of statecharts is that states can be organized in a hierarchy: A statechart is a state machine where each state in the state machine may define its own subordinate state machines, called substates. Those states can again define substates.
Just yesterday I was thinking about a related attack vector on AI agents: Many harnesses "sandbox" (at the application level) file reads/writes and shell commands by checking whether a given path has been whitelisted. However, I bet there are cases where the agent could simply create a symlink to somewhere else and thus trick the "sandbox" into thinking the agent is authorized?
s/has the ability to/is meant to
Then again, I don't think your statement is entirely correct: It assumes you've given the agent the permission to edit his source autonomously, which would normally seem unusual for an agent that's just supposed to connect to the browser.While I understand the security concerns, too, wouldn't this be solved by including a `trust` command like in direnv and mise? (I.e. have the user review the hooks before executing them for the first time.)
Out of interest, what sandboxing solution do you use?
Could you rephrase that / elaborate on that? Isn't Tailscale's selling point precisely that they do identity-based networking?
EDIT: Never mind, now I see the sibling comment to which you also responded – I should have reloaded the page. Let's continue there!
> Satellites at the GPS altitude travel at the speed of about 2.4 mi/s relative to Earth, which slows the clock down, but they’re also in weaker gravity which causes the clock to run faster. The latter effect is stronger which in total results in a gain of around 4.4647 × 10−10 seconds per second, or around 38 microseconds a day.
> Unfortunately, this is where many sources make a mistake with their interpretation of that result. It’s often erroneously claimed that if GPS didn’t correct for these relativistic effects by slowing down the clocks on satellites, the system would increase its error by around 7.2 mi per day as this is the distance that light travels in those 38 microseconds.
> Those assertions are not true. If relativistic effects weren’t accounted for and we let the clocks on satellites drift, the pseudoranges would indeed increase by that amount every day. However, as we’ve seen, an incorrect clock offset doesn’t prevent us from calculating the correct position.
(Nevertheless there are of course relativistic effects to account for, which Ciechanow proceeds to mention and which are explained in more detail in the other link I shared here: https://news.ycombinator.com/item?id=47861535 )
If people will no longer contribute to the source code directly, this means fewer people will be familiar with the code, meaning that:
- The bus factor becomes more significant. (Yes, this could partly be addressed by LLMs. But if the single maintainer disappears, this will still cause disruption until someone else takes over/forks the project.)
- Fewer people eye-ball the code for security issues (and for malicious changes by the maintainer). This, too, could be addressed by LLMs but are we all going to set up agents in the future that review all our 3rd-party dependencies' code?
> We're keeping the SKU stack simpler and just having a single display option that has touch. You can disable touch in your OS though if you don't want to use it.
The reason I asked was mostly that, in my experience, touch displays tend to be glossier / less matte than non-touch ones.
Seconding this question, though I would also be very interested in learning whether they're planning a 14" version.
https://www.spiegel.de/panorama/bildung/baden-wuerttemberg-s...
This doesn't seem to be entirely up-to-date: http://github.github.com/gh-stack
I don't think this is correct. In my experience no one buys Figma because of Dev Mode only. Dev Mode just makes it easier/faster to go from an existing design to working code. So it is/was a means to increase Figma's moat, not to get new customers or users. (Devs already needed access to Figma before the introduction of Dev Mode.)
This is a very interesting point, especially in light of another article discussed here a couple days ago[0] about why Switzerland has 25 Gbit/s internet and why the US and Germany don't. One of the main points of the article was that the fiber optics infrastructure is (or should be treated as) a natural monopoly:
> The rational solution is to build the infrastructure once, as a shared, neutral asset, and let different companies compete to provide the service over that infrastructure. That’s how water works. That’s how electricity works in most places. And in Switzerland, that’s how fiber optic internet works.
[0]: https://news.ycombinator.com/item?id=47652400
EDIT: Turns out the Japanese railway infrastructure is not truly owned by the railway companies but instead leased from a government-owned institution, see https://news.ycombinator.com/item?id=47773556 and https://news.ycombinator.com/item?id=47766873