

deleted by creator


deleted by creator


Talk about doing the bare minimum! That’ll show em! I literally haven’t used corporate social media since 2016. Ask big tech about how much I’m hurting their bottom line.


deleted by creator


I call bullshit. Even a grain of sand would be disastrous for that phone. You must be in management.


My best friend has has had the Samsung version of this for four different generations now. I’ve always been a hater about it but now in gen 4, there are very few issues with Samsung’s folding phones… but they still suck and are fragile as hell.
My conclusion: all folding screen phones like this are shite and Apple gets a first generation mulligan on this one. This release is as bad as any in their history and they should have seen it coming a mile away given Samsung’s myriad issues.
My rule: NEVER BUY AN OVERPRICED, GIMMICKY, FIRST-GENERATION APPLE PRODUCT.


I definitely commit a lot more to my private forgejo than codeberg account anymore despite everything I do being specifically AGPL3.


What are you gonna do? Release the dogs? Or the bees? Or the dogs with bees in their mouths so that when they bark, they shoot bees at you?


Checks gitignore: Claude
I would assign this a trust level comparable to dipping the tip of your penis into an open sewer in Calcutta while wearing a condom with small holes.
If you are not going to eat your pickles, can I have them?
edit: whoosh
I refuse to soften my tone. Typical piefed user.
Tagged as Fedposter.
“Please, Daddy government. Come own me.”
No explanation needed. You are willingly rolling out a red carpet for fascist governments. The best way to deal with a fascist is zero tolerance.
Removed by mod


Even the NOC list?!?!


Well said. I’m glad people are challenging my json characterization. I deserve the flack but perhaps it was just a sensationalist headline to get some discussion going. It worked. ;)
Thanks for the valuable anecdotal evidence. You do speak the truth. I’ve settled on the fact that the community will never agree to adopt flakes.
Personally, I have an opinionated stack that is, at this point, self documenting. I maintain a strict style where I add assertions to most things that nix won’t be able to prove conclusively with just a build and cheaper checks that I run before actually building any real derivations. As I said elsewhere, Nix feels like the revolutionary precursor to a sea change in dependency management. But it’s just that: an imperfect technology with enough great ideas for me to adopt it wholesale and use fixing and finding ways around the warts as a way to give back to this open source community.


Great question!
Here’s the set of instructions that I’d consider fairly canonical at this moment in time:
https://dev.to/jajera/using-nix-on-windows-the-right-way-14ki


deleted by creator


No problem. Thanks for being friendly.
Not RTFM territory at all! ☺️ The manual is honestly one of Nix’s weaker points.
#! nix shell nixpkgs#ripgrep nixpkgs#jq --command bash. The two ugly bits in my examples both come from a command. The commit hash is nix flake metadata github:NixOS/nixpkgs/nixos-unstable --json | jq -r .locked.rev. The sha256 for the jar I got the lazy way: put a fake hash in, run it, and Nix fails with “specified X, got Y”. Paste Y in. Everybody does it that way and though it can be considered “hacky” you only have to do that dance once when you declare or want to update it to the latest hash.For anything bigger than a script you don’t write hashes at all. You write a flake.nix that says “nixpkgs, unstable branch” and Nix generates a flake.lock with the exact commit and hashes, same idea as Cargo.lock or package-lock.json.
nixos-unstable branch. “Unstable” means the package set rolls forward, not that the packages are betas. It has whatever the latest stable Go/Rust/GHC/etc is, usually within days, and it only advances after the test suite passes. The “stable” branches (nixos-26.05 and so on) freeze versions for six months, which is what you want for a server and usually not for a dev box.A dev environment is a flake.nix in the repo root:
{
inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
outputs = { self, nixpkgs }:
let
systems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
forAllSystems = f: nixpkgs.lib.genAttrs systems (system: f nixpkgs.legacyPackages.${system});
in
{
devShells = forAllSystems (pkgs: {
default = pkgs.mkShell {
packages = [
pkgs.go
pkgs.gopls
pkgs.ripgrep
];
};
});
};
}
nix develop drops you into a shell with exactly those. First run writes flake.lock, you commit it, and everyone who clones the repo gets identical versions without having to download a bloated Docker image (instead running those dependencies natively in Nix’s sandbox). Updating is nix flake update and then commit the lock. Nothing moves until you run that, so you update when you choose to and if something breaks you git checkout flake.lock and you’re back. If you want it automated there’s a GitHub action (DeterminateSystems/update-flake-lock) that opens a PR with the bumped lock on a schedule, and Renovate handles flake.lock too.
Add direnv + nix-direnv and the shell loads on cd into the project, so you never type nix develop again. That’s the point where it stops feeling like extra work.
For personal tools like nvim and ripgrep that you want everywhere and not per project: quick way is nix profile install nixpkgs#neovim nixpkgs#ripgrep and later nix profile upgrade --all. The idiomatic way is home-manager, where your tool list and dotfiles live in one flake in a git repo and a new machine is a clone plus one command. I’d start with the profile commands and a devShell in one project, and only look at home-manager once you’re sure you like it.
One caveat: for Rust, if you need an exact toolchain version or nightly, nixpkgs only carries current stable, so people use fenix or rust-overlay as a second flake input to declare specific builds in the closure. Most other languages just have versioned attributes like pkgs.python312 or pkgs.jdk21.
deleted by creator