sylvestre

Because Collin reported it in Ubuntu too :)

+1 ;)

While I do understand the frustration, I think the "find in page" hotkey isn't a big enough reason to change the platform. Myself, I am happy with the performances. By the way, what would you replace it with?

As others said, having more details would be helpful (or a bug report on https://bugzilla.mozilla.org/).

In general, we quickly act on obvious bugs/regressions on major websites. Often, such major issues on big websites are caused by certain add-ons or antivirus software.

and it is now fixed!

Yes

Please don't read too much into this ;) We moved from self-hosted Discourse to hosted Discourse. The transfer was initiated late from the Mozilla side (my bad) and the automatic system from Discourse kicked in.

it would be nice if you could open a bug https://bugzilla.mozilla.org/ with a screen recording and/or step to reproduce.

(I am a big user of Github on Firefox for android and I can't reproduce) thanks

Would you have more details to share? I don't experience such issues on github. Clue: do you have some unusual addons which could change the behavior of Firefox?

Feels like an excellent track record to me: https://tracker.debian.org/pkg/firefox-esr ;) And Mike is also a prolific Firefox developer.

This project isn't related to Mozilla at all.

Coucou ;)

See https://news.ycombinator.com/item?id=37836932 by a Mozilla employee

Getting closer and closer to GNU parity

Distributions are mostly patching software for (not specific for Rustc):

* Paths - distro don't need to keep path detection and can simplify it (ex: headers detections)

* Archs that upstream don't care about (ex: m86k).

* Kernel that upstream don't care about (kfreebsd)

* Some old CPU support. example: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...

* simplification of the build system (ex: skipping windows support)

* Use libraries provided by the system (ex: compiler-rt for rustc: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...). This could be forwarded upstream.

* Some minor doc changes - for example, https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de... will use the local css file and not a remote css file (for offline support)

* Cherry-pick upstream fixes before the next upstream release: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...

* etc

As you can see, these patches do not impact the quality of Rustc itself. Some could be forwarded upstream (it is a pain for packagers to maintain patches - so, we do have strong incentives to contribute upstream).

This work has been coordinated with the Rust Foundation.

I added some CI task and replayed the history to graph the evolution of the size: https://github.com/uutils/coreutils-tracking#binary-size-evo...

This will help making sure that we aren't regressing (more) ;)

I don't have data but I guess ls, cp, mv, ln, chown, chmod, sort and cut are the most popular. Overall, I don't think it is a key part of the OS regular work. Most of the servers and system are busy with services, db, browsers, etc...

https://github.com/uutils/coreutils/actions click on a CI job on main For example: https://github.com/uutils/coreutils/runs/4990891225?check_su...

The "Run GNU tests" is probably what you are looking for.

Good question!

Probably not. In general, functionalities are enabling or disabling a behavior when doing an operation. In the code, it translates most of the time by a simple if else. For example, adding new options usually looks like this PR: https://github.com/uutils/coreutils/pull/2880/files

The performance wins are usually produced by using some fancy Rust features.

yeah, see https://github.com/google/breakpad/graphs/contributors luser was contributing as Mozilla staff, Gabriele is too.

And a bunch of others folks (I counted 3 more)

Nope but snap and flatpak are provided: https://snapcraft.io/firefox https://flathub.org/apps/details/org.mozilla.firefox

Indeed, 3 months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=52821#c319

This is one of the thing that I loved starting using rg :)

Wahou; this is terrific work! It would have saved me hours of work if I had known that before! Thanks for sharing!

There is a package for nix: https://gitlab.tryp.io/nix/nixpkgs/-/tree/bodhi/pkgs/tools/m... (but not up to date)

Significantly bigger than the C version.

Rust: 73M source: https://packages.debian.org/experimental/rust-coreutils

C: 17M https://packages.debian.org/unstable/coreutils

Note that no size optimization that been done and there is a lot ways to do it in Rust https://github.com/johnthagen/min-sized-rust

In term of performance, well, it depends on the binary. For example for cp, most of the time is spending copying the files. For the factor command, some work happened to make it faster https://github.com/uutils/coreutils/commits/master/src/uu/fa... (getting closer).

Using Rust also opens some great capabilities like parallelism. But this makes sense only for complex commands. For example, doing a parallel "df" isn't super interesting (I tried it was too expensive just to start threads to do it).

Anyway, performances should be a focus but only after correctness is implemented.

Because it often finds security issues in our code: see the graph at the end of the blog post.

If opensource, this fuzzer could be used against our users...

AFAIK, Mozilla doesn't sell any software!

We will still have jobs to build Firefox with gcc and gcc is not going anywhere in general: the % of package built with clang in Debian/Ubuntu is a fraction compared to gcc.

Nathan Froyd wrote this great blog post about compiler usage: https://blog.mozilla.org/nfroyd/2018/05/29/when-implementati...

Yeah but this will probably change too.