juliosueiras

I ain’t changing the license for mine(so it will stay the same license)

maybe quay.io?

is more due to the fact that KF is born from the sole purpose of harassment(CWC) then move to harass more than just that one person

played maybe around 5% of it, I am mostly collecting them as modern gaming is rapidly becoming too unbearable for me(MTX, Lootboxes, the recent NFTs, etc), and I am most likely plan to just play the collection(which I collect with criteria of at least 1% of interest of playing ,so no baby games like Racing with Ryan etc) when I stop buying modern games

No, emulator primary motive is enabling longevity for the target system, since hardware get damaged over the years, CD/DVD/Cart get corrupt over the years, without it, there will be literally no way to preserve a console games and ecosystem, for example I own 805 switch physical games, but because I know Yuzu exist I don’t have to worry about if one day the cart get damaged or something

funny enough, B2+Cloudflare will still be cheaper, since Cloudflare R2 from the blog you linked is at the cost of $0.015/GB/month for stored storage, where as B2 is $0.005/GB/month for stored storage, and there is no download cost when using the B2+Cloudflare combo

I notice that none of the comment think about scenario where the engineer doesn't know how to drive or doesn't own a car

I do like how most people here sort of forgot that a decent amount of people in ops(especially in bigger enterprise company) are not programmer and at most have shell scripting experience and thats about it, telling them to "use a real programming language" is going to create some "fun" issues (atleast HCL is consistent)

Aside from the fact no show case of a phone interface

Just from the ars article alone I have extreme doubt of what the phone system(AOSP copy job) on release is the same as the code in open harmony repos

the article lose any creditability after doing a quick check and realizing that CGTN formally known as CCTV-9, so go figure

the focus of nix in the build process is the ideal of if you have three build inputs bash 4, gcc 4.8.<patch>, libc <whatever version> , and the source of the package being the same(hash-wise) , the output is very much(for most cases) going to be the same, since nix itself(even on non-nixos) uses very little of the system stuff, it won't be using the system libc, gcc, bash, ncurses, etc, it will use its own that is lock to a version down to the hash, it follow a target(with exact spec) -> output , where as Dockerfile more resemble, of a build that is output first , and not doing build very often, this is why Nix have their own CI/CD system, Hydra to allow ensure daily or even hourly safety of reproducible builds

I think one way to look at nix is that it want to act(in good way) the central source of truth for deterministic package, and one way it goes about it is by doing the step for both system level packages, and language level packages(for example, if you approach a nodejs app, you will lock both the nodejs version, the underlying openssl or other headers lib used by node-gyp, and the node_module packages itself in nix) and that is one of the main flow of nix, take a existing project/app/software, and convert it to usable nix packages, and that work even in edge cases like:

- app that is binary , so you can't build it from source, but is using dynamic libraries, then you can use autoPatchelfHook to tell nix to patch the binary to swap out the libraries to nix's version

- app that uses a lot of hard coded file system path that you would prefer not to patch them all out, then you can use buildFHSUserEnv to package/run the application/package in full FHS-compatible scenario

but the main point is that, nix is extreme in its approach, and the best approach in my opinion, is to do swapping step by step, ex:

you want to convert a existing project to nix, lets say nodejs

- you add the main deps in the default.nix (nodejs, yarn, high level utility needed to build)

- use sandBox false to allow building the app with yarn/npm in internet accessible(by default nix uses sandBox which disallow internet inside build step, which causes issue like npm install not working, etc)

- confirm working, then start using tool likes yarn2nix, other similar, and convert the packages itself to a usable set of nix packages

though I do agree that nix have the knowledge bias issue, and alot of my learning of nix involve me looking at the nixpkg sources itself and sometime even the nix's code

I think the person above is mostly pointing out about dynamic blocks , since that do allow abstracting blocks of config and also allow subtle differences