Rucadi

And doesn't forbid you from using their platform for free if you sell the keys by yourself and you can also decide to publish your game to other stores...

I'll be honest, I just want something that I can develop on (linux is the easiest by far) and that's not annoying (Nixos is the best at that).

I don't even use any advanced config, just bare-minimum config for the system, enough (project-specific things handled by nix).

I also got the same feeling from that, in fact, I would go as far as to say that nixpkgs and nix-commands integration with git works quite well and is not an issue.

So the phrase the article says "Package managers keep falling for this. And it keeps not working out" I feel that's untrue.

The most issue I have with this really is "flakes" integration where the whole recipe folder is copied into the store (which doesn't happen with non-flakes commands), but that's a tooling problem not an intrinsic problem of using git

The best part of statement expressions is that a return there returns from the function itself, not from the statement expr.

I use that with with macros to return akins to std::expected, while maintaining the code in the happy-path like with exceptions.

This is also somewhat common in c++ with immediate-invoked lambdas

it makes function declarations/instantiations much more grep-able.

auto has a good perk, it prevents uninitialized values (Which is a source of bugs).

For example:

auto a;

will always fail to compile not matter what flags.

int a;

is valid.

Also it prevents implicit type conversions, what you get as type on auto is the type you put at the right.

That's good.

This will end up with people creating their pages in top of godot engine to avoid html scrapping hahaha

To be honest I don't know what to say, you can use nix in many ways, and you don't even require to know the language.

The easiest entry-point is to just use it like a package manager, you install nix (which is just a command...) and then you have available the whole set of packages which are searchable from here: https://search.nixos.org/packages

nix-shell is just to download&add programs temporary to your PATH.

I don't feel that this is harder than something like "sudo apt install -y xxxxx" but for sure more robust and portable, and doesn't require sudo.

If at some point you want to learn the language in order to create configurations or packaging software, it may require to check a lot more documentation and examples, but for this I think it's pretty straightforward and is not harder than any other package manager like aptitude, homebrew or pacman.

If you really need a portable binary that uses shared libraries I would recommend building it with nix, you get all the dependencies including dynamic linker and glibc.

Nix allows you to do this with any language and required dependency: https://wiki.nixos.org/wiki/Nix-shell_shebang

If the source is known, it is not less bad that downloading a program and running it

yes just use brige networking instead of nat

cpu 100% and shitty integration.

Smite used to do that, but long time since I played it.

Location: Barcelona/Spain

Remote: Preferred

Willing to relocate: No

Technologies: C++(up to 23), Nix, Linux Namespaces / Docker, Python, CUDA, FPGA development(xilinx) with a little bit of linux driver development, verilog, reverse engineering, Rust-curious... In general I touch a lot of stuff and learn fast :)!

Résumé/CV: https://rucadi.eu/cv.html

Email: rubencanodiaz[<at>]gmail.com

The most success I had so far on doing a project where I had to work with binary data parsing is Deku in rust, I would give this a try if I have the opportunity

I compiled/ported the mario64 port to the LG TV quite easily, so I would say that LGTV is the best for that.

Totally, the only ""freedom"" that they have is the free development program... But they can cancel your account at any time if they wish for "abusing" it, and you even have to refresh apps every week.

I've been struggling with this topic a lot, I feel the slowness everyday and productivity loss of having slow computers, 30m for something that could take 10 times less... it's horrible.

Cool project!

I'm kinda of the opinion that the real option to handle dotfiles is to override/overlay the package itself with the dotfiles, patching if necessary in order to make it look to the dotfile inside the store, so you can copy the closure of *your* whole app to any machine even if they don't use/can't use nix tho.

Until zed doesn't work on windows (publicly) unfortunately can't use it in my working computer

I personally find a lot more relevant the part about "Enabling cross-compilation ", which in my opinion is important and a win.

The same about exported symbols and being able to compile to wasm easily.

I created a library "cpp-match" that tries to bring the "?" operator into C++, however it uses a gnu-specific feature (https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html), I did support msvc falling-back to using exceptions for the short-circuit mechanism.

However it seems like C++ wants to only provide this kind of pattern via monadic operations.

And why not by private entities receiving donations of people that care about preservation?

Personally I've found great success using NIX as a programmable config file, and outputting json to be read by the application.

Lldb and rr (midas) have vscode extensions

you could try to statically link them if the package support it, it does so by using musl

nix build github:NixOS/nixpkgs#pkgsStatic.git

return the pacakge as:

ls -lah git

-r-xr-xr-x 1 rucadi rucadi 5.1M Jan 1 1970 git

ldd git

$ not a dynamic executable

So you don't really need to really grow the container

I don't see much difference between a native app and web app, in the end is what the developer decided to do with that.

See autocad for web for example, is kinda the same. Or Photopea, photoshop's clone.

buffer is also a candidate :)