It understands \n
if I recall correctly. You can also write regular bash, use templating tools, etc. Just use the nativeBuildInputs
parameter if you need a binary that isn't provided by stdenv.
Oinks
Another alternative approach would be to add a duplicate desktop file, but to write it declaratively using Home Manager:
# in home.nix
home.file.".local/share/applications/firefox.desktop".source =
pkgs.runCommand "firefox-desktop" { } ''
cp "${pkgs.firefox}/share/applications/firefox.desktop" "$out"
substituteInPlace "$out" \
--replace-fail "Terminal=false" "Terminal=true"
'';
# - or -
home.file.".local/share/applications/firefox.desktop".text = ''
[Desktop Entry]
Name=Firefox
Icon=firefox
Exec=firefox --name firefox %U
'';
It would be possible to DIY this with user activation scripts, but I don't really see a value in doing that over the symlinkJoin
.
Since the desktop files come directly from a package you'll need to change the package you're installing. This works best if you use the postPatch
phase of symlinkJoin
:
pkgs.symlinkJoin {
inherit (pkgs.firefox) pname version;
paths = [ pkgs.firefox ];
postPatch = ''
# String replacement example - will run the app in a terminal
substituteInPlace "$out/share/applications/firefox.desktop" \
--replace-fail "Terminal=false" "Terminal=true"
'';
}
The reason for using symlinkJoin
here is that it creates a package with the same outputs as the original Firefox, but with this bash script having run. You can use this like any other package:
let
firefox' = <...>
in
{
environment.systemPackages = [ firefox' ];
# - or -
programs.firefox.package = firefox';
}
Note that symlinkJoin
has special handling for postPatch
, but ignores all other stdenv phases, so you need to do everything in one bash script. You can use all the parameters for runCommand
though, such as buildInputs
and nativeBuildInputs
- e.g. for compiling sass in a wrapper derivation.
In some cases it's useful to also inherit meta
or passthru
because it's used in some nixpkgs/nixos sanity checks, but it's usually not required.
Another approach would be to use overrideAttrs
, which will also work but will cause Nix to rebuild the package from scratch. This might be fine or even desired in some cases, but you probably don't want to do that in this case.
Many people who don't know what they're talking about in this thread. No, used memory does not include cached memory. You can confirm this trivially by running free -m
and adding up the numbers (used + cached + free = total). Used memory can not be reclaimed until the process holding it frees it or dies. Not all cached memory can be reclaimed either, which is why the kernel reports an estimate of available memory. That's the number that really matters, because aside from some edges cases that's the number that determines whether you're out of memory or not.
Anyway the fact that you can't run Linux with 16GB is weird and indicates that some software you are using has a RAM leak (a Firefox extension perhaps?). Firefox will use memory if it's there but it's designed to cope with low memory as well, it just unloads tabs quicker so you have to reload often. There are also extensions that make tab unloading more aggressive, maybe that would help - especially if there's memory pressure from other processes too.
To be fair showing the overview on startup makes perfect sense on vanilla gnome, it's only dumb if you install one of the two specific extensions that partly replace it.
Try launching Steam from the terminal so you have a chance at seeing an actual error message, at least for the crashing games.
It might be the kernel as the other comment says since the 9070 is pretty new. If it works without issues on something like Fedora or OpenSUSE TW then that was probably the issue.
Running poweroff
is one of the correct ways on anything Systemd (details). If that doesn't work then something is broken.
If you haven't done so already try looking into the journal. sudo journalctl -b -1 -e
will take you to the end of the log for the last boot.
I am very sorry to remind everyone about the existence of Visual Basic, but it has:
- VbCrLf
- VbNewLine
- ControlChars.CrLf
- ControlChars.NewLine
- Environment.NewLine
- Chr(13) & Chr(10)
And I know what you're asking: Yes, of course all of them have subtly different behavior, and some of them only work in VB.NET and not in classic VB or VBA.
The only thing you can rely on is that "\r\n" doesn't work.
GUIs do have advantages in things like discoverability. Honestly the 1983s Apple Lisa nailed this with the idea of having clickable menus annotated with keyboard shortcuts, so users could do the same thing faster next time. For some reason we stopped doing this (especially in web apps), but that's a reason to make better GUIs, not to RETVRN to the feature set of a VT100.
I don't know why we have to go on nonsensical diatribes about "UNIX wizards" though when we're fundamentally talking about a handful of minor UI improvements to things that already exist.
It depends a lot on which specific GPU you have and whether it's a laptop.
New-ish GPU in a desktop with the monitor plugged directly into the GPU? Easy to get working, literally a checkbox on most distros.
1000 series GPU or older in a laptop and you need reasonable battery life and/or some "advanced" features like DP Alt-Mode? Good luck.
Edit: Also, no Wayland until very recently. Possibly never, depending on the age of the GPU.
It's wild how on the orange website I can read entirely sensible discussions about tricky Bash semantics or whatever, while people in a parallel thread are seriously arguing the Trump admin's repressions are dwarfed by... whatever "repressions" they think happened during Covid. And I don't even click on the threads about disabilities (especially autism) anymore because it's so predictably sad.
The mentioned performance governor runs the CPU permanently at maximum frequency, which is obviously bad on battery powered devices and on devices with lacking thermal headroom. I think it might cause problems in virtualized environments as well but I'm not sure about that.