manpacket

joined 1 year ago
[–] manpacket@lemmyrs.org 5 points 11 months ago (4 children)

You don't need a car in Singapore. Very good public transport and affordable taxis.

[–] manpacket@lemmyrs.org 29 points 11 months ago (6 children)

Canonical make it hard not to use snaps so only those who took extra steps are not using them.

[–] manpacket@lemmyrs.org 7 points 11 months ago (5 children)

Yea, not with firefox, at least not without switching to some third party repo.

[–] manpacket@lemmyrs.org 1 points 1 year ago

Uses KDE and not available to general public.

[–] manpacket@lemmyrs.org 4 points 1 year ago

If you open to do some research - you should be able to stay on Debian and use nix the package manager https://hachyderm.io/@fasterthanlime/111099224022408403

Comes with some steep learning curve, almost a learning cliff though. But once past this - it's good.

[–] manpacket@lemmyrs.org 1 points 1 year ago

That's what I'm using, but it's not a fully featured replacement.

[–] manpacket@lemmyrs.org 6 points 1 year ago (2 children)

Been using it since forever, no reasons to switch. It works. Got a bit upset at them when they killed xul/pentadactyl though.

[–] manpacket@lemmyrs.org 1 points 1 year ago

Yea, something like that. Using it on my laptop already. configuration.nix for system plus home-manager for user stuff. Will move the desktop soon-ish.

[–] manpacket@lemmyrs.org 3 points 1 year ago (2 children)

NixOS. I'm going to migrate to NixOS by then.

[–] manpacket@lemmyrs.org 4 points 1 year ago

https://github.com/nix-community/home-manager/issues/3968 - this to monitor and poke, there are also a link for a sample wrapper that might or night not help you.

[–] manpacket@lemmyrs.org 16 points 1 year ago

Don't use it - vote with your feet :)

 

cross-posted from: https://lemmyrs.org/post/144635

If you have a workspace with dependencies you probably noticed that sometimes cargo seemingly unnecessary recompile external dependencies as you switch between different members of your workspace.

This is caused by something called feature unification ([1]). Since features by design should be additive only cargo tries to avoid redundant work by using a superset of all required features. Problem comes when there are multiple crates in the workspace require external dependencies with different set of features. When you are working with the workspace as a whole - unified features include all the dependencies, when you target a single crate - unified features will include only features of that crate's dependencies.

What's worse - if you are using nix with crate2nix to manage dependencies - you'll get no feature unification at all and every dependency with each unique combination of features is considered a separate dependency so the same crate can be compiled (and linked in) multiple times - I've seen 20+ copies of a single crate.

Unless there are special requirements it is better to make sure that all the external dependencies have exact same set of features enabled across the workspace. One option is to do it by hand manually editing Cargo.toml files for individual dependencies or with inherited workspace dependencies. As with anything manual - it would be error prone.

That's where cargo-hackerman comes in. It can check if there are feature unification issues in the workspace so you can run it in CI if you want to do it manually or it can apply the smallest possible hack by itself (and remove it later).

This is not a new crate, we've been using it in production with a large workspace for over a year now.

In addition to feature unification it can help with some other compilation time things giving easy answers to questions like :

  • are there any duplicate dependencies in my workspace?
  • why is this dependency or feature on dependency is required?
  • what are all the dependencies of this crate?
  • where is the repository of this crate?

With updated bpaf documentation on https://crates.io/crates/cargo-hackerman should be always up to date and cli - a bit more user friendly

view more: next ›