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

Humans can do lots of things, I don't see how that's relevant. This post is about AI progress.

Many libraries now support AccessKit.

GPUI is developed alongside Zed and thus features that aren't useful for Zed are sometimes left behind.

I think there was a community fork recently that tried to tend to these concerns.

It's not a bad thing per se, but its worth mentioning.


Can certainly be a downside. Jaded / grumpy rust programmer perspective: I will take this over the typical rust pattern of OSS libs which have been made without being tested in practical applications!

Qt already has really good binding, see Pyside6 for instance. GTK similarly through introspection.

Not sure why you want to build desktop GUIs using web tech though.


Building a GUI framework in Rust comes with certain challenges.

Ralph Levien, author of druid and xilem made some good posts about it. I'll link one here.

https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g...


I personally think we'd have more success with a purely functional way of approaching GUIs. Our machines are fast enough now and we can use C++/Rust for the "inner loop" performance.

Yes, that. And also:

Rust was designed to build core mechanisms of UI, like internals of a browser.

But as a language-behind-ui it is quite suboptimal so I think the most successful UI framework for Rust most likely will use some form of DSL.

But if DSL then inevitably we are getting question: why not HTML/CSS/JS then?

Visual styles, layout, structure, UI logic like "on click here, hide stuff there and expand section over there" is what HTML/CSS/JS was designed for.

"Render therefore unto Cesar the things which are Cesar's;"


Thanks for that link. I just like the idea of creating things with Rust. Having the ability to build things for the web with Rust is a plus

Rust doesn't play well with traditional frameworks but works fairly well with Elm and immediate mode.

I think is an important point, and I don't see it mentioned in the article or the paper (though I skimmed the latter).

They are aware of what they are and how they are used. They're told to act as AI assistants. And there's theories of them being aware of their answers influencing their training.

So surely they must be able to reason that they're not literally controlling weapons of mass-destruction with their answers.


Why do people think this is the future? Anthropic has the leading model, and so they're able to hold back functionality. They do so with obvious regards to safety.

If anything a future with models of such capabilities and no safeguards would be a bleak future. But its likely what were headed in once other companies catch up.


I think it’s safe to say that many of us feel a lot less safe directly because of these policies and the inferred intentions of the company behind them. Nobody is arguing for unsafe models. We just don’t want to live in the plot of Deus Ex.

> Nobody is arguing for unsafe models

Then what are people arguing for? I see only two totally distinct options: unsafe models or someone being the arbiter of safety


I’d settle for a different someone at this point. What were you expecting me to say?

> The SDCS is only possible if keys are allowed to become infinite, or the data store is allowed to become infinite (...) This would, of course, make the idea useless.

But Pi is infinite. And thus this genius contraption will work as long as we have Moore's law on our side :)


> Since the file is 128 bits long, one would expect this place to be around the 2*128th bit.

> Calculate the number of bits to encode that value using log2(938933556), which is ~29.8

Can someone explain these two statements to me?


for > Calculate the number of bits to encode that value using log2(938933556), which is ~29.8

This is roughly same as saying: "If you rewrite 938933556 as a binary number / usize, it will need 30 bits".

Sanity check: 1101111111|0110111111|0100110100 (| delimits every 10 bigits).

> Since the file is 128 bits long, one would expect this place to be around the 2*128th bit.

This statement is a bit more subtle. As a first ord approximation, we can see pi sort of as a RNG.

If we write pi (ignore the decimal point), as a binary number, we get: 11011001111111011110010101011110001010101111101101110001001100001...

You can... kind of squint and pretend this is a random sequence of 1s and 0s.

Now, if you had a file that is 128 bits (so lots of intermingling 0s and 1s), and each next digit of pi is effectively a coin flip. Pretend 1s are heads, and 0s are tails. You basically have to get the exact 128 consecutive coin flips of the same result as your file to get your file back.

Imagine now, PI not as a number, but a sequence of experiments of flipping the coin 128 times.

  - (11011..01000)(10000...00100)....
  - ^attempt 1     ^attempt 2
You have to try, on expectation, quite a few times to win this game! Now, you could easily get lucky for sure. But on average, your chance of winning per attempt is roughly 0.5^128! So, how many times do you have to try to win this game? Something like 2^128 times - and you have to consider that each attempt uses 128 bits as well. So more like 2^135. But you don't have to start fresh in each attempt, you can see it as like this:

  - 11011................00100...
  - (       128 flips     )
  -  (  another 128        )
  -   (                     )
  -     ... so on and so on
That's where the 2^128 number came from.

Thank you!!!

np :-)

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

Search: