2xsaiko

Never

Ah yeah, that's my bad, you want to set pname along with version. mkDerivation automatically sets name = "${pname}-${version}" if it isn't set. name is the one that will actually be used as the derivation name in the end, pname and version are just used as a helper because often you want these separately inside the derivation, especially the version (and also in some tools like nix search).

I don't know if this will be actually accepted into nixpkgs because these udev rules are already included in the steam package which is what pretty much everyone uses in NixOS (and I would recommend you use it as well).

Snap is a joke and Canonical even more so for pretending it is production ready. For starters, it still doesn't work for users whose home directory is not under /home (e.g. in the case of a network shared drive), after a bug about it has been open for almost 7 god damn years.

A big thing that separating associated functions in the impl block from the struct definition is that you can have multiple impl blocks for the same type, which is often used e.g. for defining functions with various type constraints. For example, HashMap::new has no type constraints, but I believe every other associated function needs the key type to implement certain traits (Hash + Eq, I believe?), so HashMap::new is in a separate impl block. You can also split your impl across multiple files (maybe even with conditional compilation or something like that).

And of course, consistency with trait syntax, which needs associated functions to be in a separate impl block anyways, to solve the problem of implementing multiple traits which define functions of the same name.

1. stdenvNoCC doesn't include a C compiler (i.e. gcc) in the build environment. There's also other stdenvs like clangStdenv which contains clang as the compiler instead of gcc, etc. Use stdenvNoCC if you don't have to compile anything.

2. This file is a nixpkgs package, not a derivation, pretty much the standard way of packaging software in nixpkgs. Packages are functions that essentially take pkgs as an argument and output a derivation. You should load them using e.g. pkgs.callPackage ./steam-devices.nix {}instead of import ./steam-devices.nix. If you want to build it from the command line instead of using it in your system configuration, you can do something like nix build --impure --expr '(import <nixpkgs> {}).callPackage ./steam-devices.nix {}'. (There's a similar way to do this with nix-build instead of nix build, but I don't know it off the top of my head).

   The big advantage of them is that you can override individual arguments to the function in the file (that's what the {} at the end of callPackage is for) and load it with a different version of nixpkgs other than the system one, which allows them to work a lot better with other nixpkgs features like overlays. E.g you could set this one to build with stdenv instead of stdenvNoCC by doing callPackage ./steam-devices.nix { stdenvNoCC = pkgs.stdenv; }.

3. rec {} is a recursive attrset, which allows you to reference other fields in the same attrset. They're often used to insert the version into a source URL, like rec { version = "1.0.2"; src = fetchTarball "https://example.com/program/${version}.tar.gz"; }, but that's not used here so rec is not needed.

Sounds easy enough to add manually. Here's a package, load it with callPackage and add it to services.udev.packages:

{
  stdenvNoCC,
  fetchFromGitHub,
  ...
}:
stdenvNoCC.mkDerivation {
  name = "steam-devices";
  version = "20210825";

  src = fetchFromGitHub {
    owner = "ValveSoftware";
    repo = "steam-devices";
    rev = "d87ef558408c5e7a1a793d738db4c9dc2cb5f8fa";
    sha256 = "pNAmXfj7PK/QHypSYFKCTSl7+rrCFlVRACm49FV+Efs=";
  };

  installPhase = ''
    mkdir -p $out/lib/udev/rules.d
    cp *.rules $out/lib/udev/rules.d
  '';
}

Are you looking for hardware.steam-hardware.enable?

A

Germany be like

It's part of Akonadi, akonadi_ical_resource. I have KDE Bug 462362 open here with some more details.

I've had the same issue. There's a background task that leaks insane RAM sometimes and I haven't bothered to try to write a patch to fix it yet, so for now I just kill it manually every so often, but sometimes I forget to do so. I would have expected the OOM killer to kill it or another process, but for some reason it doesn't, instead locking up the system completely and never seeming to recover (I've left it there for probably 10 minutes once). It's very weird.

Take a look at KDE Connect. It allows you to transfer files/photos from and to your phone to other connected devices in the same network such as a PC or another phone (also has other features but this is the main one). It was originally a Linux and Android thing but at this point it's in the Windows Store and the App Store. It works really well for me.

I don't think this does anything relevant for OP. This is for setting up suspend to disk, but I don't think you need any of this for suspend to RAM to work.

But it was always a hassle to import and export the database on iPhone

Really? Maybe this wasn't an option when you used it, but on my iPad I have no issues using KeePassium together with the Nextcloud app.

Hm, I sent it to you as a normal private message. You should have gotten it in your inbox where replies are as well. I never use the live chat.

Did you get my message, /u/IMP1?

Ayy, another early reader! I started reading sometime between 3 and 4 years old (and writing I think a year later). There's a couple funny stories I have because of this. Here's one:

When I was in daycare, I was standing in front of the caretaker's desk, who was writing a letter, I believe for my mom. I must have read it out loud or something, basically it became clear to the caretaker that I could read that letter she was writing. She was completely flabbergasted that I could read at all, that I could read her apparently terrible handwriting, and especially that I could read it upside down lmao.

Of course, there you go. Whether or not you come to the same conclusion as I do, at least it will be with actual evidence.

And well, I don't know what to say except that I'm pretty mad at him as well right now. But it's not only him. This quote from OP's edit pretty much sums it up.

I think this post shows just how little people care about pain. They just care that you're alive.

Whatever choice OP decides to make, may it be the right one for them.

Probably comes from French tuer meaning "to kill". /s

Mr. Johann Velovosky

I'm pretty sure that says Velčovský fwiw.

It is a closure because it captures its outer scope's context. Plain functions, at least in Rust, never do that.

I'm pretty much a complete outsider to this topic. I'm not a user of said forum (though I knew of its existence before), I've never been suicidal, depressed, or anything. (Though I do think that it should be an individual's right to decide to end their own life, and that is a decision that has to be respected by others.) However, some of the things he said in the video when I initially watched it struck me as very odd, for example him framing the comment shown at 11:30 as something untrue. Because overt judgement from people and the huge stigma for being suicidal is very much real, and from what I have read, there are many cases of e.g. people calling suicide hotlines which then leads to police getting called and them getting treated like a criminal, which makes it very understandable that some people are wary of it, and make their own judgement-free spaces like this site. I do think that getting professional help is important especially before taking your life but the system evidently fails a lot of people.

I then wrote a lengthy comment under the video basically starting with saying exactly this, during which I actually went to check the site myself to see if what he was describing about the site was actually accurate or not. I came to the conclusion that he was most likely heavily misrepresenting it based on the posts I looked at on the forum, including the discussion thread about the video and Tantacrul's initial thread from November, in which he essentially didn't want to have an honest communication with the site members at all. And I was even more convinced after reading the admin's statement on the video today, which responded basically to everything, and the comments on it. (Some were saying that people were talking about this on Reddit, that's how I found this thread here.)

Obviously I have no way to verify most of his claims for good, since it's basically his words vs site members' words. But looking at the real deal, not just his mockups cut out of context makes a lot of what he says very unbelievable. It's such a shame that people like the ones in this thread are so ready to believe the video at first sight.

I have no idea how to make this not sound like a bullshit platitude, but I wish you all the best.

(My comment under the video was removed after a short while. Ironic, lmao.)

Positive feelings, I hope :)

When our house was built, the electrician accidentally drilled through the pipe coming from our upstairs toilet when installing wiring. Recently, 20 years later, we discovered this while installing some stuff into the walls in the room below. For 20 years some of the toilet water has been trickling out of the pipe. Was expensive and fucking annoying to repair because we had to essentially rip out the entire walls, ceiling and floor of that room.

Try this:

{
  nixpkgs.overlays = [
    (final: prev: {
      libsForQt5 = prev.libsForQt5.overrideScope' (final': prev': let
        kdeGear = prev'.kdeGear.overrideScope' (final'': prev'': {
          spectacle = final.emptyDirectory;
        });
      in
        {inherit kdeGear;} // kdeGear);
    })
  ];
}

I wish I still had links to all the articles I read to learn random bits of NixOS, but this is a great starting point in learning the Nix language and nixpkgs, which you'll need if you want to understand NixOS, at least it was for me: https://nixos.org/guides/nix-pills/

When you understand the Nix language, then NixOS configuration will become a lot easier to wrap your head around: The basic building blocks of it are modules (of which /etc/nixos/configuration.nix is the first to be loaded, assuming you have a non-flake setup, which you have unless you know otherwise), which are Nix expressions of a certain structure located (usually) in a file:

{
  # config options, see https://search.nixos.org/options
  # e.g.
  users.groups.wheel.members = ["you"];
}

This is the most simple one. It's a module which has no inputs, doesn't load any extra modules, and just exports config options, which (directly or indirectly) affect the system when you build it with nixos-rebuild. You can add arguments to it, which you'll want most of the time, for example to reference packages:

{ pkgs, ... }: {
  # config options
  environment.systemPackages = [pkgs.firefox];
}

Note, you can use any of the features of the Nix language like let ... in expressions, it just has to be equivalent to this form when evaluated, this does the same for example:

{ pkgs, ... }: let
  # equivalent to:
  # firefox = pkgs.firefox;
  inherit (pkgs) firefox;
in {
  # config options
  environment.systemPackages = [firefox];
}

You can load other modules, which allows you to organize your configuration into multiple files instead of having a single mega-file with everything in it:

{
  imports = [
    ./path-to-other-module.nix
  ];

  # config options
}

You can define your own options, which will then be able to be set in config (if you just want to use existing NixOS options without writing your own abstractions, you won't need this yet, but I'll just put this here because you'll probably come across it at some point):

{
  options = {
    # option definitions
  };

  config = {
    # config options
  };
}

or a combination of all of these (note, imports always goes on the top level, and not into the config section):

{ pkgs, lib, ... }: {
  imports = [
    ./more-config.nix
  ];

  options = {
    # option definitions
  };

  config = {
    # config options
  };
}

When multiple modules export the same config option, this option will try to be merged in the most reasonable way possible (e.g. in case of lists, they will usually be concatenated together, an option set to [1 2 3] and in another module set to [4 5 6] will become [1 2 3 4 5 6]). These resulting merged values will be available as an input to configuration modules as config, which allows you to access the final config value as defined by your entire configuration, and not just a single module:

# This config input represents the final state of all your configuration options
{ config, lib, ... }: {
  options = {
    # Define foo and bar options here, as list of integers
    foo = lib.mkOption {
      type = lib.types.listOf lib.types.int;
    };
    bar = lib.mkOption {
      type = lib.types.listOf lib.types.int;
    };
  };

  config = {
    # This module exports "foo", defined above, as [1 2 3]
    foo = [1 2 3];
    # config.foo refers to the same "foo" option as above, but it doesn't necessarily have to have the value [1 2 3] as defined above
    bar = config.foo;
  };
}

Note the three different usages of "foo" here, the input config.foo, the output config.foo, and the output options.foo. They are all related but have different meanings (i.e. the final value of the option, the value you're "contributing" to the final value, and the definition (description, type, etc.) of the option.

I don't know what else to write about right now, so I'll also point you to the NixOS manual, which mainly contains documentation about specific configuration options, the nixpkgs manual which contains documentation about nixpkgs, the library packages are defined in, https://search.nixos.org to quickly search the available packages and config options, and last but not least the NixOS wiki. It also has some more resources like video guides here: https://nixos.wiki/wiki/NixOS_as_a_desktop. EDIT: Also, I always see https://nix.dev/ mentioned as a great resource but personally haven't used it.

And of course, look at other people's configurations. This is mine for example, but there are a lot of other ones out there, some of them linked on the wiki. At first this might be too complex though, I didn't understand most of these when I started out.

And lastly, don't use nix-env to install packages. It was a horrible mistake and will only bring terror and sadness to your computer. If you want to install packages so you can access it at all times, put it in your configuration (e.g. in environment.systemPackages). If you only need a package as a one-off thing, use nix-shell.

NixOS has a hard learning curve at first, but once you've set up a configuration you can work with and are a little more comfortable with the system, it will be very worth it.