• 0 Posts
  • 36 Comments
Joined 4 years ago
cake
Cake day: June 24th, 2020

help-circle



  • That’s great. If you get a chance, would you be able to test this patch?

    diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
    index 297a88587031..3204bed08b3c 100644
    --- a/drivers/acpi/resource.c
    +++ b/drivers/acpi/resource.c
    @@ -484,6 +484,18 @@ static const struct dmi_system_id tongfang_gm_rg[] = {
     			DMI_MATCH(DMI_BOARD_NAME, "GMxRGxx"),
     		},
     	},
    +	{
    +		.ident = "Infinity E15-5A165-BM"
    +		.matches = {
    +			DMI_MATCH(DMI_BOARD_NAME, "GM5RG1E0009COM"),
    +		},
    +	},
    +	{
    +		.ident = "Infinity E15-5A305-1M"
    +		.matches = {
    +			DMI_MATCH(DMI_BOARD_NAME, "GM5RGEE0016COM"),
    +		},
    +	},
     	{ }
     };
     
    

    I’d like to try to get it upstream, and that seems like the sanest way to do it.

    You might need to be on linux 6.5+ for this patch to apply, and if you could verify that it’s still broken on 6.6 without the patch, that would be nice.



  • Could you do:

    Please share the output of grep -v /sys/class/dmi/id/* as a normal user (not root)

    It looks like all the patches from that thread are in linux 6.6, so your board may still need quirks added.

    Once you know the board name you try something like this:

      boot.kernelPatches = [{
          name = "acpi quirk";
          patch = pkgs.writeText "acpi.patch" ''
    diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
    index 297a88587031..655332f3a5da 100644
    --- a/drivers/acpi/resource.c
    +++ b/drivers/acpi/resource.c
    @@ -524,6 +524,12 @@ static const struct dmi_system_id pcspecialist_laptop[] = {
     			DMI_MATCH(DMI_BOARD_NAME, "GM6BG0Q"),
     		},
     	},
    +	{
    +		/* [COMPUTER DESCRIPTION] */
    +		.matches = {
    +			DMI_MATCH(DMI_BOARD_NAME, "[BOARD_NAME]"),
    +		},
    +	},
     	{ }
     };
    '';
      }];
    

    Just be careful that the indentation of the patch part doesn’t get changed.



  • I assume this is due to the amount of effort that would have been required for it to acquire some of the functionality you were expecting out of it. Am I right?

    I didn’t really understand what Emacs was at the time, I just got fed up with trying to make vim into an IDE. Out of the box, spacemacs had good language support, modal editing, and looked ‘modern’.

    What I love about Emacs now is Lisp and the package ecosystem. I have 396 packages installed, and many of them interact in quite complex ways. When I do a package upgrade it pretty much pulls the latest from the development branch of each package. Some packages haven’t been changed in 10 years, some are changed daily. It’s bleeding edge everything, and things don’t actually break that much. Lisp makes for (obviously IMO) beautiful, simple code, so most packages are a pleasure to fix, extend, or automate.

    I intend to put my teeth in GNU Guix at some point in the future.

    Me too, but I nix has served me well, so I haven’t been motivated.



  • Or is the usage of Spacemacs primarily attributable to it coming earlier to the scene?

    Yeah, pretty much just that. If was to start again now I’d consider other options, but I have no serious complaints about spacemacs. I probably would have never got into Emacs at all if I had to start with vanilla.

    Furthermore, as you’re using it in “VI mode”, would it be fair to assume that you’ve got some experience/history with Neo(Vim) as well? If so, what led you to making the switch from (Neo)Vim to Emacs?

    Yeah, I used VIM (and I still do when I’m in an unfamiliar environment), but only before neovim existed. IMO Lisp is what makes Emacs great, and vimscript is (was?) an absolute nightmare for anything complex. I don’t think lua is a bad language, but I’ll still take Lisp any day for this purpose.

    I’ve also got my concerns related to what degree the containers can be sandboxed. Do you happen to have some insights on this?

    What I described isn’t using containers. Nix just provides an environment for processes to run in, and direnv-mode ensures it’s using the right environment for a given buffer in Emacs. So for example I don’t have OmniSharp or dotnet in my user $PATH, but they are provided by the nix expression in a particular project directory. That allows lsp-mode to start OmniSharp as a language server, or I can run dotnet build using the Emacs compile command.

    You can define containers with nix and manage them with nixos-container. I do that for testing server deployments, or running sandboxed services, but I’ve never needed something that complex for a dev shell.




  • I feel like there will be a backlash to this. As a recipient, what do I get out of reading your routine confirmation email that I wouldn’t get out of reading whatever (presumably more concise) prompt you used to generate it?

    Maybe people will find better ways to use these systems, but so far most of what I’ve seen is text that is bloated without any useful information being added. I think we’ll get to a point pretty quickly where that is considered less polite and less professional.