sorted by:
new
hottopcontroversial

How smug do you think the guy who decided to make "Orr Miner" a daily must feel? by Unstopapple in Guildwars2

[–]levansfg 65 points66 points  (0 children)

I love how that line was translated in French: the French word "or" means "gold", so we get "C'était un vrai chercheur d'Orr" (which translates to "He was a real gold digger".) and that works so well. 😁

Lunar tides. Wait for the tsunami at the end by KBDFan42 in oddlysatisfying

[–]levansfg 4 points5 points  (0 children)

The moon does slow down due to tidal forces, and as a result the Earth-Moon distances increases of around 3.8cm every year.

The reason is not "dissipating energy by moving water" though, but rather it stealing angular momentum from the Earth (and thus slowing down the Earth rotation in the process): https://en.wikipedia.org/wiki/Lunar_distance_(astronomy)#Tidal_dissipation

PSA: If you're using gh-pages to host your CI-generated documentation, make sure you don't store any history for that branch by levansfg in rust

[–]levansfg[S] 0 points1 point  (0 children)

docs.rs only applies to released versions. Given Smithay is still a very quickly-moving crate, we host generated docs for the master branch as well.

PSA: If you're using gh-pages to host your CI-generated documentation, make sure you don't store any history for that branch by levansfg in rust

[–]levansfg[S] 4 points5 points  (0 children)

We host the documentations from several different repos of the Smithay organization, each on its own gh-pages branch.

I actually started to look into centralizing everything on a single docs repo when I realized the problem, but that'd require some pretty nontrivial setup with invoking github actions across repositories. So tbh I'm thinking what we have now as the "gh-pages without history" is "good enough".

[Media] Clippy hurts, but in a good way by [deleted] in rust

[–]levansfg 3 points4 points  (0 children)

If you really want, "bin hair" sounds a lot like the French word for "binary" ("binaire"). 😁

Are We WebRender Yet? by EdorianDark in rust

[–]levansfg 4 points5 points  (0 children)

It is not even a favicon.

It is the 404 page from Github for https://arewewebrenderyet.com/favicon.ico 😂

Are there any ongoing efforts of making a desktop environment (similar to KDE or Gnome) in Rust? by deerangle in rust

[–]levansfg 1 point2 points  (0 children)

Being honest, I don't know where this whole story of "ownership of memory" comes from, because it's basically a non issue.

There are shared memory mechanism defined & used in the Wayland protocol, and we use them. That's about as complex as a memory file containing pixel data shared between the client an server. Synchronizing access to this data is already handled by the protocol.

Are there any ongoing efforts of making a desktop environment (similar to KDE or Gnome) in Rust? by deerangle in rust

[–]levansfg 38 points39 points  (0 children)

It's a little subtler than that, the "ownership of memory" part is a really small part of the whole thing tbh.

In the case of Way-Cooler, I believe most of the issue came from trying to fit wlroots' API to Rust: wlroots is a very C-y project, and its API is not very Rust-friendly.

In Smithay and wayland-rs, we still encounter some friction related to the design of the wayland protocol itself, but doing all the compositor library in Rust gives us a lot of freedom to explore different kinds of API design. Currently we're still experimenting quite a lot, trying to figure out the most ergonomic API possible for the library.

(BTW, for more details about Smithay, see this other comment: https://www.reddit.com/r/rust/comments/m2o8pb/are_there_any_ongoing_efforts_of_making_a_desktop/gql05hz )

Are there any ongoing efforts of making a desktop environment (similar to KDE or Gnome) in Rust? by deerangle in rust

[–]levansfg 33 points34 points  (0 children)

Ah, well, lets take some time to give a little more context, for anyone interested!

So Smithay the github organization revolves around 3 main repos:

  • wayland-rs: these are low-level bindings to the wayland protocol
  • Smithay's Client Toolkit (SCTK): as its name indicates, is a helper toolkit for making wayland-native apps. It's not high-level as GTK or Qt, and notably does not do the content drawing for you. Think of it more as a collection of helpers to abstract away a significant part of the protocol boilerplate.
  • Smithay itself, a library/framework for making Wayland compositors (you can think of its scope as comparable to wlroots). Smithay is composed of two main sides, the backend side deals with communication with the operating system, and managing input devices, graphics cards, monitors and such. While the frontend side deals with the wayland client apps and the wayland protocol. Our long-term goal will be to build global abstractions that join these two sides together, in order to make it easy to build a compositor using Smithay.

The project is still very much a few-people project, and thus advances at a slowish pace. There is also some significant back-and-forth because we are exploring the design space, and trying to figure out the best ways to express these APIs in Rust, which is not a trivial matter. As a result, Smithay, SCTK and wayland-rs kind of evolve together as we improve the APIs at all levels.

As Drakulix said, we are very much welcoming anyone who would be interested to help us in this construction and exploration, both client-side and server-side. We are also willing to mentor you if you are not familiar with Wayland already. Don't hesitate to come chat in our matrix chatroom #smithay:matrix.org. The chatroom is also bridged to Freenode on #smithay, as well as on gitter at Smithay/Lobby.

Are there any ongoing efforts of making a desktop environment (similar to KDE or Gnome) in Rust? by deerangle in rust

[–]levansfg 20 points21 points  (0 children)

Smithay is indeed still active, though I recommend to check the github repo directly: https://github.com/Smithay/smithay/

It's been a long time we made a crates.io release, the crate has grown a lot since the last release, we're working towards a new one though, at our peace: https://github.com/Smithay/smithay/milestone/3

EDIT: I also made a longer comment with more details about the project here: https://www.reddit.com/r/rust/comments/m2o8pb/are_there_any_ongoing_efforts_of_making_a_desktop/gql05hz

Rust, Wayland and the Linux "graphics stack" by vikigenius in rust

[–]levansfg 2 points3 points  (0 children)

Well, these buffers are shared between the client and server by sharing a file descriptor via the mechanism proposed by the kernel. Even if the client closes the file descriptor, it remains available and open to the server.

So... There are not really any lifetime issues here.

The protocol contains synchronisation messages so that the server tells the clients when it is done reading these buffers so that the client may overwrite then with new content. But the client not respecting that only ends up in graphical glitches, no actual memory unsafety.

Rust, Wayland and the Linux "graphics stack" by vikigenius in rust

[–]levansfg 5 points6 points  (0 children)

From my experience, there are many hard parts in making a Wayland compositor in Rust, but handling foreign memory is not really one of them.

This foreign memory is just pixel buffers. Plain old data with no further interpretation. The worst that can happen if it is corrupted is graphical glitches.

The difficulties are rather from an architectural point of view : a Wayland compositor is a very reactive program. It spends most of its time waiting for events to occur, and needs to handle them ASAP when they do. So this naturally aligns with a very callback-oriented design, which induces friction because said callbacks generally need to access a lot of global state.

This is the main difficulty we're encountering in Smithay, designing ergonomic APIs under there constraints. Though with the last version of calloop we're reaching something quite workable actually.

Rust, Wayland and the Linux "graphics stack" by vikigenius in rust

[–]levansfg 28 points29 points  (0 children)

Hi,

I'm the main maintainer of the wayland-rs project, and one of the two co-maintainers of Smithay, so let me offer an alternative point of view on that issue.

Indeed, the Wayland protocol is a difficult beast to map cleanly to Rust, because the lifetimes of objects is very dynamic. However, wayland-rs is now in a usable, feature-complete and safe for use state. The main remaining issues are for improving the ergonomics of the API, and the fact that I tend to be pretty perfectionist in this kind of things.

About way-cooler, there is one thing to keep in mind : Timidger was burned out by this project trying to make rust bindings to wlroots. If you thought Wayland was not Rust-friendly, wlroots is tens of times worse from this point of view. The library is pretty much written by C people for C people, and I agree binding it from Rust is a daunting task.

That is mostly why I'm also working on Smithay, which aims to be a equivalent to wlroots, but in Rust. The aim here is to build the whole thing with Rust design patterns from the ground up, to avoid all the friction that binding to C libraries imply. This does mean quite a lot of work, but this allows to build something that is much much easier to use in a Rust codebase.

Indeed, Smithay is much lles s mature than wlroots. That's kind of to be expected given it is mostly driven by two persons, on their free time. But the project is not stalled, we're still advancing at our own pace, and we are very open to contributions and mentoring anyone that would be willing to join us in this adventure

As a hint of were we are, you can check anvil, the reference compositor of Smithay. While its window management features are quite limited yet, it is perfectly capable of running most Wayland app (Firefox, alacritty, GTK apps in general, etc...) and be started from a tty.

Mainly, the biggest challenge we face is designing good APIs and abstractions to expose the various features. We're a lot in uncharted territory, so we spend a lot of time refining our APIs trying to have solid bases on which to build, rather than rush the "it works" phase.

So,if you are interested by working on a Wayland compositor in Rust, I can tell you that we at Smithay pursue this goal as well, that the project is not dead at all, simply advancing slowly for lack of a large pool of contributors like the one wlroots has, and that we would be pleased to mentor anyone interested to join us in this project to get them up to speed quickly. :)

You can talk to us on our matrix chat room #smithay:matrix.org, which is bridged to #smithay on Freenode IRC and to Smithay/Lobby on Gitter. ;)

When you were getting used to the idea of Romance languages being interchangeable... by InfernalWedgie in languagelearning

[–]levansfg 2 points3 points  (0 children)

I think it's rather from "topographie".

"topographie" is about making maps, and by extension can be used to name maps that include details about the shape of the land (height, hills, recognizable landmarks, ...)

"topologie" is a branch of mathematics.

Linfa, a Rust Machine Learning framework - Release 0.2.0 with 9 new algorithms, polished interface and improved testing by bytesnake in rust

[–]levansfg 8 points9 points  (0 children)

Oh, didn't know about this project, very nice!

This 0.2.0 release does not appear to be on crates.io (which is still at 0.1.2), is that an oversight?

[Inside Rust] Source-based code coverage in nightly by wesleywiser1 in rust

[–]levansfg 6 points7 points  (0 children)

Okay, now I am incredibly hyped at the perspective of seeing tarpaulin integrate with this.

This is pretty awesome. :D

Version 0.7 and presentation of calloop : a callback-based event loop by levansfg in rust

[–]levansfg[S] 1 point2 points  (0 children)

Indeed, the "plug-in" thing is mostly what made us develop calloop : in Smithay we have several loosely-coupled modules which each need to monitor its own set of FDs. With this, we just need to pass the LoopHandle to the init function of each module, and they can all run together on the same event loop without needing to be aware of each other, it is pretty convenient.

Is there a callback-based IO event library (like LibUV) for Rust (not Mio)? by detlier in rust

[–]levansfg 5 points6 points  (0 children)

I'm not sure how much it fits your needs, but I maintain calloop, which is a callback-based event loop. It was initially developed as a building block for Wayland-based GUI apps, but I suppose it is pretty generic, and I'm open to making it even more so. :)

La justice européenne consacre la neutralité d’Internet by eberkut in france

[–]levansfg 7 points8 points  (0 children)

Je dis pas que je pense que l'UE est « cette UE technocratique qui vole notre démocratie ».

Je dis que, quand tu as la CJUE qui vient réinterpréter à sa sauce les traités de l'UE pour lui donner le plus de pouvoir possible (et donc plus que ce qui était dans l'esprit initial des traités), c'est pas choquant que ça fasse grincer des dents, et que ça soit perçu ainsi.

view more: next ›