Hacker Newsnew | past | comments | ask | show | jobs | submit | tremon's commentslogin

Are you sure it honoured your stipulation of "without external help"? For all we know, it hacked its way into Wolfram Alpha and got the result from there.

Arithmetic is well within the capabilities of even small local models: https://i.imgur.com/21tzGlN.png

The lifetime of files in ~/.cache/ is the same as what the FHS documents for /var/cache [0]:

> Application cache data. Such data are locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. The cached files can be deleted without loss of data.

Meaning: the persistence of such files is not guaranteed across application restarts. If vim (and also neovim) had intended for the undo files to outlive the program, the files should have been put in ~/.local/state instead -- as also explicitly documented by the XDG [1]:

> [XDG_STATE_HOME] may contain: [..] current state of the application that can be reused on a restart (view, layout, open files, undo history, …)

[0] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#...

[1] https://specifications.freedesktop.org/basedir/latest/#varia...


That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever, but a targeted hit from the application itself on files known to be persistent undo.

You just can't point the finger at file system standards, or shoulda-read-release notes or whatever.

There is no such thing as "by mistake, we historically stored persistent files in a directory with 'cache' in its name, contrary to a popular standard, so that makes it okay to trash them now".


> That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever

But it was, it was program other than vim (neovim) that did it. It deleted a file in a space that is meant for transient files that may be deleted at any time for any given reason and should not cause data loss, and yet it did because vim, in the first place, broke the file system’s contract.

Neovim shouldn’t have been messing there but at the same time there’s a much bigger culprit here in that vim shouldn’t have been storing this kind of data there in the first place. It was a broken system that broke even further. Simple as that.


NeoVim is a forked continuation of Vim.

Blaming Vim is like politicians blaming the previous administration.


> The application must be able to restore or regenerate the data

That's a break of the contract then, right? The application was not able to regenerate or restore.

Cache is the wrong place for a persistent undo file.


In general it's easier to control the air you're blowing into a room than what you're extracting, so I'd expect it would be more economical to keep the fabrication rooms under high pressure than low pressure. Also, in case of a leak, air and contaminants will flow out of the room instead of into it.

A few years ago, in NL they banned a campaign from the Brandwondenstichting (foundation for treating burn victims) because it used photos from actual burn scars to warn the public. Ostensibly, the reason given was that it upset their delicate eyes -- which was the entire point of the campaign. The campaign itself was not political, but Facebook choosing to apply their weak US sensibilities to a Dutch campaign surely was a political act.

why is it 1955? Do you see parallels between how trans people are treated today and the start of the civil rights movement?

No, the British Empire, the one dominating before the US, finally ended in 1956. We'll see if the Russian empire collapses before the US one.

and, the chinese one is gaining power. Empires fall, but not in my lifetime.

There is nothing pragmatic about kicking out the workforce you imported because of a shortage of native labour. The pragmatist stance would be to accept those differences, and focus on addressing/alleviating them. Cutting your nose to spite your face is more idealism than pragmatism.

> Applicants will also be required to have a pension pot equivalent to 30 years of payouts.

Does this take into account the amount of pension a person would still accumulate under Japanese employment, or will this immediately disqualify anyone under 45?


That’s like 12 x 30 x ¥35000 = 12600000 yen. $84000. I don’t know about others, but I consider myself pretty well off and I do not have that kind of money.

That's too low. The National Basic Pension is around 60,000 yen per month and with traditional employer part on top (not everyone has it), it's 140,000 yen/month. I would think a foreigner immigrant would need to bring the equivalent of around $160k in a retirement savings account or similar.

I very much doubt they count any employer pension toward that because people that get that don’t need the money themselves.

The actual regulation has a carve out for if you have assets of equivalent worth.

Then you'd have an infinite series, as each doll would have to contain two smaller copies.

But the real question is would you be able to determine this had happened from the surface of the outside doll if all of the masses of the inner dolls are half of the i-1 outer one, leading to a total mass of 2n?

So, who supplies to Anthropic that doesn't supply to OpenAI and/or Google? In other words, why should Anthropic be singled out in your explanation?

> My claim is that doing this kind of computer security is possible.

But your evidence does not support that claim. SeL4 has proven that it is possible to design a secure microkernel and prove its security guarantees. It does not prove that you can build entire systems (filesystem+database+web server+browser) on top of that kernel while maintaining the same security guarantees.

I'm all for improving the state of computer security, and I'd love for capability systems like SeL4 to become more prevalent. But it's only a microkernel, and it's by no means certain that the PeopleSoft vulnerability exploited here required a kernel-level compromise.


I don’t expect every piece of software written to be proven correct like SeL4. But I don’t think we don’t need to do that to get big improvements in the security of a lot of systems. Honestly the biggest insight I take from sel4 is that we can get improvements in security by breaking up a large program into isolated pieces. Give each piece as few permissions as possible, so a compromise of one part doesn’t lead to a whole system compromise. And give them a way to talk. This has big benefits for reliability - since you can fail and restart individual processes. And it has benefits for security, since a system compromise should require an attack of multiple systems simultaneously. And it has benefits for debuggability, since you can add tracing at the comms layer or isolate modules for testing.

Wasm does this. Erlang does this. SeL4 does this. Chrome is built this way. The windows driver model is moving this way. And so on. You want a solid core to build around - which is what SeL4 and beam try to be. Then it’s up to us to use those primitives and build good software. Combine that with a memory safe language (rust, go, c#, etc) to protect against buffer overruns and use after frees. And a picture starts to form of how you can build software that is a lot more secure by default.

I don’t think perfect security is worth the cost for many companies. But so many security leaks happen because of amateur hour somewhere. Bugs happen - I get that. But a single bug in a C++ program shouldn’t immediately lead to RCE with system level privileges. This stuff isn’t rocket science.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: