Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)CO
Posts
0
Comments
375
Joined
5 yr. ago

  • 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.

  • Nice. Also it occurred to me that there might be a way to set that quirk through the kernel command line instead of having to compile a patched kernel. I haven't had a chance to look it up though.

    Edit: I couldn't find anything obvious. This behaviour is buried pretty deep.

  • 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 want to have a better idea for much time is spend on ‘management’; fix, extend and/or automate etc.

    Not that much really. I usually upgrade everything once a month or so. The last couple of times were smooth. I think the last problem I hit was:

    https://github.com/emacs-lsp/lsp-mode/issues/4153

    This was actually triggered by upgrading omnisharp, which started sending a new notification that lsp-mode didn't explicitly ignore.

    By the time I hit it, that issue had already been reported, so I was able to quickly work around it with a snippet in my main config. I could have also just rolled back omnisharp.

    Most problems I've had have been solved by upgrading spacemacs to latest.

  • 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 use Emacs + spacemacs in VI mode as a base for all my text editing on both Linux and windows (which is unfortunately required for work on occasion) machines.

    For dev environments I mostly use nix + direnv + direnv-mode.

    For C# I use the above plus omnisharp-roslyn + lsp-mode.

    I tinker in all sorts of languages, and they all have at least basic support in the Emacs ecosystem. The popular ones should have fully functional language servers and debugger adapters.

  • 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.

  • The game overlay stuff is all just noise, so I think it's only the last line (missing libcef.so) that's a problem. Maybe you could share the contents of the shell script, and the output of readelf -d [path to]/LifeIsStrange (i.e. the actual elf), ldd on the same elf, and see if there's a copy of libcef.so anywhere in the game files?

    I'm not sure if libcef (embedded chrome) is meant to be loaded from the steam runtime, from the game files, or from the system. My guess is it can be fixed by altering LD_LIBRARY_PATH in the game's shell script.

  • That's very much against the philosophy of Linux. At best you'd divide Linux gaming into trusted (known operating system, hypervisor, no root access), and untrusted systems.

    It's essentially what Google are trying to do with attestation, Web Environment Integrity, etc.

    Edit: there's no way to stop cheaters without also stopping software freedom in general. The best path forward might be to focus on building communities of people who enjoy playing games together.