Lemmy maintainer

  • 18 Posts
  • 93 Comments
Joined 5Y ago
cake
Cake day: Jan 17, 2020

help-circle
rss

Right I will also have to make a template with these common parts of the release announcement. Instance blocking is not implemented yet, but it uses the same federation library as Lemmy so that will be easy to add when its needed.




Ibis version 0.1.2
This release contains numerous bug fixes and minor improvements. Thanks to Kalcifer for reporting many of these. - LaTeX formatting is now supported to handle mathematics (thanks Silver-Sorbet) - The editor now has a live preview of rendered markdown - Better layout for edit history - Fixed user links in edit history - Edits are now correctly sorted by date - Removed maximum width for page - Render markdown titles smaller than page title - Disable markdown plugins for url shortening and smartquotes - Resize article edit input based on length [More details and download](https://github.com/Nutomic/ibis/releases/0.1.2)
fedilink

Ibis version 0.1.2
This release contains numerous bug fixes and minor improvements. Thanks to Kalcifer for reporting many of these. - LaTeX formatting is now supported to handle mathematics (thanks Silver-Sorbet) - The editor now has a live preview of rendered markdown - Better layout for edit history - Fixed user links in edit history - Edits are now correctly sorted by date - Removed maximum width for page - Render markdown titles smaller than page title - Disable markdown plugins for url shortening and smartquotes - Resize article edit input based on length [More details and download](https://github.com/Nutomic/ibis/releases/0.1.2)
fedilink

Want to contribute to Lemmy? Heres a list of good issues to get started
We also have documentation to setup the dev environment: https://join-lemmy.org/docs/contributors/02-local-development.html If you have questions, feel free to ask here, in the relevant issue or in [matrix](https://matrix.to/#/#lemmydev:matrix.org).
fedilink

Thats even more verbose so the second option is better.


@DemocratPostingSucks@lemm.ee @Deebster@programming.dev @al4s@feddit.org Thanks for the feedback! Personally I prefer the first option, but based on your comments I will merge the PR with the second option.


Which code style to initialize structs?
Which of these code styles do you find preferable? First option using mut with constructor in the beginning: ```rust let mut post_form = PostInsertForm::new( data.name.trim().to_string(), local_user_view.person.id, data.community_id, ); post_form.url = url.map(Into::into); post_form.body = body; post_form.alt_text = data.alt_text.clone(); post_form.nsfw = data.nsfw; post_form.language_id = language_id; ``` Second option without mut and constructor at the end: ```rust let post_form = PostInsertForm { url: url.map(Into::into), body, alt_text: data.alt_text.clone(), nsfw: data.nsfw, language_id, ..PostInsertForm::new( data.name.trim().to_string(), local_user_view.person.id, data.community_id, ) }; ``` You can see the full PR here: https://github.com/LemmyNet/lemmy/pull/5037/files
fedilink

The network is called Fediverse. I don’t see the need for a separate term, there also isn’t a “Tootiverse”.


Thanks for the support. I think the era of single, centralized sources of information will soon be in the past.

  1. This would be a project on its own, with writing import scripts, hosting an instance etc. Certainly not something I have time for, just like I’m not running a Reddit mirror for Lemmy. If you or someone else wants to set it up, go ahead!
  2. How would you detect that it’s the same article, only from having the identical title? That could fail in lots of ways.
  3. I agree about this.

Available Soon.

Dansup is well known for making grand announcements and delivering on them very late or never. I think it was more than two years ago that he announced federated groups for Pixelfed and still nothing. So I wouldn’t get my hopes up yet.



It can get a bit boring working on the same project for so many years. Having a different project gives me more motivation.



Yes articles are duplicated in the same way posts are duplicated on Mastodon or Lemmy, so they wont go away. Moderation doesnt exist so far. There is a search field in the sidebar.

The link goes directly to Ibis where I posted the announcement.


The frontend is very primitive right now, but it could definitely be made to work without JS.


That is true but most developers are still on Github, which hasn’t been affected by enshittification yet. I also have to keep using Github because of Lemmy, so I don’t want to switch back and forth between two separate platforms.

However once Gitea starts federation we definitely want to migrate Lemmy to a selfhosted instance, and probably Ibis too.


I mean the drama about it is over. We are constantly working to improve mod tools but it takes time.


Sounds good, please share the announcement in relevant places.



Right but that’s already over. And anyway Ibis was mostly finished since some weeks, just needed some minor work to push it over the finishing line.


Interesting, maybe it wanted to tell you about this project :D


Nowadays I can easily handle all Github notifications within less than an hour. After the Reddit blackout there were so many notifications that I couldnt even read all the issues, let alone respond. So I had to unsubscribe from issue notifications for some months.




Activitypub-Federation 0.5.0 released
This library is responsible for federation in Lemmy, and can also be used by other Rust projects.
fedilink

Lemmy 0.18 is ready for testing
The new major version of Lemmy is now ready, and we need your help with testing. Most importantly it uses HTTP for API requests now, which is much more efficient than websocket. Additionally Two-factor-auth is supported. There are also countless other improvements and bug fixes. You can register on any of the following servers to start testing, no approval required. You can post to your hearts content to find out if anything is broken. The test instances only federate with each other to avoid affecting production instances with spam. - [Enterprise](https://enterprise.lemmy.ml/) - [Voyager](https://voyager.lemmy.ml/) - [DS](https://ds9.lemmy.ml/) If you encounter any bugs that aren't present in 0.17, open an issue and mention in the title that it happened with a release candicate version. Over the next days we will publish new RC versions to fix bugs that will invariably pop up. Instance admins can try the new version by using Docker images `dessalines/lemmy-ui:0.18.0-rc.2` and `dessalines/lemmy:0.18.0-rc.1`. Make sure that working backups are in place. For production instances its better to wait at least some days for the major issues to be fixed.
fedilink


Announcing crate activitypub-federation 0.4.0: Major rewrite with improvements to usability and documentation
I want to announce a new version of the activitypub-federation crate. Over the last weeks I worked on major improvements to the usability and documentation. It now includes an extensive guide on getting started to implement federation from scratch, and also an example project which can directly be deployed to a server and federate with projects like Mastodon. The library takes care of basic functionality like HTTP Signatures, activity sending, and fetching data from other servers. Application developers can focus on the main logic, and treat federation as another form of API. There is no restriction to the content being federated: you can implement a microblogging platform, link aggregator, video hosting site or any other type of social media. The goal is to encapsulate all basic functionality, so that developers can easily implement federation without any prior knowledge. Using this library can help to share core Activitypub logic between different projects, so that the same code doesn’t have to be implemented and maintained separately by each project. This way improvements can benefit everyone. It also encourages the use of effective patterns to make Rust and Activitypub work together. All of this has been proven to work in Lemmy which uses this library and is the biggest Activitypub project written in Rust. https://docs.rs/activitypub_federation
fedilink

Announcing crate activitypub-federation 0.4.0: Major rewrite with improvements to usability and documentation
I want to announce a new version of the activitypub-federation crate. Over the last weeks I worked on major improvements to the usability and documentation. It now includes an extensive guide on getting started to implement federation from scratch, and also an example project which can directly be deployed to a server and federate with projects like Mastodon. The library takes care of basic functionality like HTTP Signatures, activity sending, and fetching data from other servers. Application developers can focus on the main logic, and treat federation as another form of API. There is no restriction to the content being federated: you can implement a microblogging platform, link aggregator, video hosting site or any other type of social media. The goal is to encapsulate all basic functionality, so that developers can easily implement federation without any prior knowledge. Using this library can help to share core Activitypub logic between different projects, so that the same code doesn’t have to be implemented and maintained separately by each project. This way improvements can benefit everyone. It also encourages the use of effective patterns to make Rust and Activitypub work together. All of this has been proven to work in Lemmy which uses this library and is the biggest Activitypub project written in Rust. https://docs.rs/activitypub_federation
fedilink


FEP 1b12: Group federation was finalized!
This standard document explains how group federation works in Lemmy and other projects. It can be useful to developers who want to implement a similar federation model.
fedilink


How to optimise compilation times with Rust
Between Lemmy versions v0.8.10 and v0.9.0, we did a major database rewrite, which helped to improve compilation time by around 30% (see below). In this post we are going to explain which methods were effective to speed up Rust compilation for Lemmy, and which werent. ## Compilation time comparison Here is a comparison of debug compilation times for Lemmy. All measurements were done in with Rust 1.47.0, on Manjaro Linux and an AMD Ryzen 5 2600 (6 cores, 12 threads). Results are taken as the average of 5 runs each. | | v0.8.10 | v0.9.0-rc.11| improvement| |-------------|---------|--------------|-----| | Clean build | 195s | 129s | 34% | | Incremental build | 23s | 17s | 26% | ## Build Graph The build graph and statistics can be generated with the following command, which will generate a file `cargo-timing.html`. ```bash cargo +nightly build -Ztimings ``` In our experience, it is really the most useful tool in order to speed up compilation time. There are a few ways to use it: - The table at the bottom shows which crates took longest to compile. You can try disable unused features for slow crates, or remove those dependencies entirely. If your own crates are slow, split them up (see below). - In the bar graph near the top, you can mouse over each crate to see which other crate it has to wait for in order to start compilation. You can try to remove these dependencies, or features that you don't need. ## Splitting code into workspaces This is often tricky to do, but proved to be the most effective way to speed up compilation. At the same time, it helped to better organise our code into independent parts, which will make future maintenance work easier. As a first step, it is enough to split the code into crates which depend on each other linearly, as this is relatively easy and already helps to speed up incremental builds (because only part of the project needs to be recompiled when something is changed). In case you have a particular dependency which takes very long to build, you should take all code which does *not* depend on that dependency, and move it into a separate crate. Then both of them can be built in parallel, reducing the overall build time. Later you can try to reorganise your code so that crates in your project can be compiled in parallel. You can see below how we did that in Lemmy: **Before:** ![](https://lemmy.ml/pictrs/image/gmThFkgoNn.png) **After:** ![](https://lemmy.ml/pictrs/image/Co3pfEjwn5.png) As you can see in the before screenshot, all Lemmy crates are compiled linearly, which takes longer. In the after screenshot, at least some of the database crates are compiled in parallel, which saves time on any computer with multiple CPU cores. [For more details on how to use cargo workspaces, have a look at the documentation](https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html) ## Disabling debug info This is very easy to do, as it only requires putting the following into `Cargo.toml`: ``` [profile.dev] debug = 0 ``` The effect is that debug information isn't included in the binary, which makes the binary much smaller and thus speeds up the build (especially incremental builds). We never use a debugger in our development, so changing this doesn't have any negative effect at all for us. Note that stack traces for crashes still work fine without debug info. [Here it is in the documentation](https://doc.rust-lang.org/cargo/reference/profiles.html#debug) ## Removing dependencies This only had limited success, for the most part. We weren't willing to remove or replace any of our dependencies, because then we would have to remove features, or have a lot of extra work to reimplement things ourselves. However, there is one specific dependency where we could improve compilation time by around 50 seconds. Refactoring the database allowed us to remove diesel's `64-colum-tables` feature. This was especially effective because diesel only has a single crate, and as a result is compiled on a single thread. This resulted in a period of 40 seconds where one thread would compile diesel, while all other threads were idle. There is still room for improvement here, if diesel can be split into multiple, parallel crates. [Lemmy issue with more details](https://github.com/LemmyNet/lemmy/issues/920) With actix we noticed that it includes a compression library by default, which is useless in our case because we use a reverse proxy. Thanks to @robjtede from the actix for making the necessary changes to allow removing that library. In the end the effect was limited however, because the library could be built very early and in parallel to other things, without blocking anything. It should help with compilation on devices with few CPU cores at least. [Issue in the actix-web repo](https://github.com/actix/actix-web/issues/1561) ## Other optimisations `cargo bloat` was commonly recommended in order to find large functions, and split them up. But that didn't help at all in our case, probably because our project is quite large. It might be more useful for smaller projects with less code and less dependencies. It was also suggested to reduce macro usage, but there wasn't much opportunity in our case because diesel uses a lot of macros. We removed a few `derive` statements that weren't needed, but without any noticable effect.
fedilink