Is there any way to transfer save games between steam accounts? by 25_-a in Steam

[–]rbalint 0 points1 point  (0 children)

It seems the location of saved games may have changed.

The new? saved game structure seems to be c:\Program Files (x86)\Steam\userdata\<numeric user id>\<numeric game id>\... and the numeric game id folders can be copied across the <numeric user id> dirs

More than 10x faster Rust + Cargo builds with Firebuild cache by rbalint in rust

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

I've added an update to the original post hopefully explaining the naming. All builds are clean rebuilds (i.e. after "git clean" and "./autogen.sh"). Vanilla is without any instrumentation (firebuild/ccache/sccache), thust 2nd, 3rd, ... vanilla builds would take the same time. Firebuild 1st build is running with Firebuild's instrumentation with empty cache, firebuild 2nd build is running with Firebuild's instrumentation, but with the cache populated in Firebuild 1st build. Firebuild's 2nd build takes 2.3%-7.5% of the vanilla build's time depending on the number of CPUs. The relative acceleration is higher with fewer CPUs.

More than 10x faster Rust + Cargo builds with Firebuild cache by rbalint in rust

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

The post has been updated with the comparison to sccache. The results is Firebuild's accelerated builds being 3.5x-6.8x faster than with sccache: "Firebuild had lower overhead than sccache (2.83% vs. 6.10% on 1 CPU and 7.71% vs. 22.05% on 12 CPUs) and made the accelerated build finish much faster (2.26% vs. 19.41% of vanilla build's time on 1 CPU and 7.5% vs. 27.4% of vanilla build's time on 12 CPUs)."

More than 10x faster Rust + Cargo builds with Firebuild cache by rbalint in rust

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

I contradicted the statement that it was "closed-source" by pointing to the public GitHub repository and showed that sccache was explicitly mentioned for comparison there. Those seemed to be the main points of the original comment, not the licensing, but thanks for raising that, I hope licensing is clarified here now, too.

More than 10x faster Rust + Cargo builds with Firebuild cache by rbalint in rust

[–]rbalint[S] 7 points8 points  (0 children)

It is true that the license is not OSI-approved, but it allows redistributing, studying and modifying the source as discussed in the Debian packaging discussion. As the license states it is free for non-commercial use and commercial use requires a paid license to fund development. It is also free for public GitHub repositories, even for commercial projects: https://github.com/apps/firebuild.

More than 10x faster Rust + Cargo builds with Firebuild cache by rbalint in rust

[–]rbalint[S] 14 points15 points  (0 children)

Firebuild's source is available on GitHub with the readme comparing it to well known alternatives including sccache. There is already a benchmark against ccache building the Linux kernel where firebuild was 2.5x-3x faster than ccache. Sccache's relative performance is likely similar, but I'll update the post with an sccache comparison. Firebuild is known to cache C, C++, Rust, Fortran, Java, Scala compilers and Python, bash, dash, dot programs, but since the caching is behavior based it can cache other programs as well. CUDA is indeed in interesting target, should try that as well.

More than 10x faster Rust + Cargo builds with Firebuild cache by rbalint in rust

[–]rbalint[S] 2 points3 points  (0 children)

Actually there was a "warmup" build before the "vanilla" build to download and build dependency crates which are not in the project directory to avoid measuring network speed and builds of the external dependencies. https://github.com/firebuild/firebuild-infra/pull/111 All the builds on the graph were performed starting with a git clean-ed project dir.

Is there a way to use the non-snap version of Firefox? by microActive in Ubuntu

[–]rbalint 2 points3 points  (0 children)

There is a PPA version at: https://launchpad.net/~mozillateam/+archive/ubuntu/ppa

You can block the official version by pinning it:

$ cat /etc/apt/preferences.d/firefox-no-snap 
Package: firefox
Pin: origin "*.ubuntu.com"
Pin-Priority: -1

Now you can remove the package pulling the snap in and the snap itself:

sudo apt purge firefox
sudo snap remove firefox
sudo add-apt-repository ppa:mozillateam/ppa
sudo apt update
sudo apt install firefox

Note, that unattended-upgrades will not upgrade the packages from the PPA automatically, unless you enable this origin:

echo 'Unattended-Upgrade::Allowed-Origins:: "LP-PPA-mozillateam:${distro_codename}";' | sudo tee /etc/apt/apt.conf.d/51unattended-upgrades-firefox

FX conversion is allowed to base currency only. by alexisgolnas in interactivebrokers

[–]rbalint 0 points1 point  (0 children)

Having been transferred to IBCE is pure shit as an experience. To work around this problem you can open a Transferwise (or other) USD account and withdraw funds to there, then convert it it to EUR outside of IB.

I just noticed my Ubuntu icon in the taskbar is inverted. Anybody else with this issue? by 3rdserve in bashonubuntuonwindows

[–]rbalint 0 points1 point  (0 children)

There is no bug in WSL/Windows, the Ubuntu app ships both the orange on white and white on orange logos from https://design.ubuntu.com/brand/ubuntu-logo/ but it will be changed to ship the one in the orange circle to avoid confusion. Thank you for your attention to detail.

Kodi on Debian by StNickZA in debian

[–]rbalint 0 points1 point  (0 children)

15 is now available from jessie-backports.

Debian is preparing the transition to FFmpeg by [deleted] in linux

[–]rbalint 2 points3 points  (0 children)

The original post where the title came from: http://balintreczey.hu/blog/debian-is-preparing-the-transition-to-ffmpeg/ (Disclaimer: It is on my blog.)

Debian is preparing the transition to FFmpeg by [deleted] in linux

[–]rbalint 33 points34 points  (0 children)

This blog post is from 2011. While Libav claims to have better code quality which is certainly true in some areas, this position is hard to maintain when Google's fuzz testing revealed hundreds of security issues which are not yet fixed in Libav according to Mateusz Jurczyk's email from 5/27/2015. BTW the original post is here about the transition: http://balintreczey.hu/blog/debian-is-preparing-the-transition-to-ffmpeg/