|
Ihmemies posted:Does linux make things specifically obtuse for users? yes or rather, it doesn't do much to make things particularly easy for users at the system level. and yes, bluetooth may in fact be one of the worst examples of this.
|
#
?
Dec 19, 2022 22:57
|
|
|
|
| # ? Jun 10, 2024 16:48 |
|
|
Twerk from Home posted:What is the right way for a process limited by cgroups to figure out how much memory it has available to it before it's going to get OOMKilled? I see a CLI tool called "cgget", but I'd really like a library. That's how every Unix-like has traditionally handled it, so it seems strange to get rid of it.
|
|
#
?
Dec 19, 2022 22:57
|
|
|
BlankSystemDaemon posted:Isn't there something in the system log from the kernel, about which process got killed? yeah, oomkiller should be spitting out a giant wall of text to dmesg about what it killed and why and oomkiller typically doesn't just kill a process because it used too much memory, it has a formula it uses to determine what its allowed to kill when the system runs out of memory
|
|
#
?
Dec 19, 2022 23:04
|
|
|
Ihmemies posted:Does linux make things specifically obtuse for users? Like I'm supposed to mount a /dev/something folder to my docker so home assistant can use my USB bt dongle. You're confusing linux with docker. Docker is a poo poo program for which no brain cells were used in making. Linux is a bit better than that.
|
|
#
?
Dec 19, 2022 23:26
|
|
|
That's not fair, docker came around at a point where nothing else like it existed. No one ever gets things right on the first try. A lot of people were working on the linux features needed to support containers at that time and it was docker that brought it all together.
|
|
#
?
Dec 19, 2022 23:34
|
|
|
I've started using Podman for most of my container stuff now and it seems to work pretty nice. I'd recommend giving it a shot.
|
|
#
?
Dec 19, 2022 23:36
|
|
|
Yes, podman is a huge improvement.
|
|
#
?
Dec 19, 2022 23:37
|
|
|
BlankSystemDaemon posted:Isn't there something in the system log from the kernel, about which process got killed? After you've gotten killed there's OOMKiller logs, but I'm trying to figure out the right way to find out what memory limits my process is living in so that I don't get killed. I've got a C++ application I'm developing that performs better with more memory, but I'd like to have it figure out how much memory is available by looking at the settings of the cgroups limits its running in rather than forcing people to tell it a maximum. The Java Paketo buildpack checks these settings somehow to determine at launch time how to configure JVM memory limits, which is really nice: https://paketo.io/docs/reference/java-reference/#memory-calculator. I'm just looking for a lightweight way to figure out how much memory I can allocate before cgroups kills me.
|
|
#
?
Dec 20, 2022 03:39
|
|
|
Twerk from Home posted:What is the right way for a process limited by cgroups to figure out how much memory it has available to it before it's going to get OOMKilled? I see a CLI tool called "cgget", but I'd really like a library. It's been a while but the last time i wrangled cgroups I don't think we ever came up with a better way than reading the memory.limit_in_bytes file, so yeah probably the best bet is to check for both files and read whichever exists. I don't have access to the code anymore so I can't check if there was some more cleverness, but I don't remember any convenient way to just ask.
|
|
#
?
Dec 20, 2022 12:57
|
|
|
I'm currently in the process of updating from Mint 19.3 to Mint 20, and was noticing that I'm getting code:
|
|
#
?
Dec 21, 2022 00:07
|
|
|
It's updating the kernel, and thus the vmlinuz (compressed kernel) and initrd (initial ram disk) that applies to that update.
|
|
#
?
Dec 21, 2022 00:13
|
|
|
SadBag posted:I'm currently in the process of updating from Mint 19.3 to Mint 20, and was noticing that I'm getting I don't know if Mint does anything specific to it, but it should be regenerating the initrd if needed and adding the correct line to grub or whatever for the kernel in question.
|
|
#
?
Dec 21, 2022 00:15
|
|
|
Tesseraction posted:It's updating the kernel, and thus the vmlinuz (compressed kernel) and initrd (initial ram disk) that applies to that update. Is there a reason it doesn't seem to be doing this in version order? Because I've noticed its been hopping between versions on the last digit. ie 5.4.0-<variable version> It was 120 at one point, then 59, then 74.
|
|
#
?
Dec 21, 2022 00:24
|
|
|
My guess is it's doing it in alphanumerical order - and naďvely saying "well 1 comes before 5, which comes before 7" rather than parsing them as numbers.
|
|
#
?
Dec 21, 2022 00:29
|
|
|
Tesseraction posted:My guess is it's doing it in alphanumerical order - and naďvely saying "well 1 comes before 5, which comes before 7" rather than parsing them as numbers. I'm not seeing that. 66 then 113, 91, 104, 96, 99. Does seem to be doing it faster than before though, so maybe it's mostly over?
|
|
#
?
Dec 21, 2022 00:36
|
|
|
Could just be doing it in some parallel "start a bunch of workers and split the work between them" way, I guess? The kernel/initrd tasks don't depend on each other, so they don't have to be done in order.
|
|
#
?
Dec 21, 2022 02:05
|
|
|
Also, you might want to run 'apt autoremove' to get rid of some of the old kernels. There's basically no reason to keep more around than current and previous.
|
|
#
?
Dec 21, 2022 06:30
|
|
|
SadBag posted:I'm not seeing that. 66 then 113, 91, 104, 96, 99. Does seem to be doing it faster than before though, so maybe it's mostly over? you can easily see this behaviour with find, when copying directories with cp -rv, really any simple tool that just dumps the filesystem contents onto you as efficiently as possible: code:Phosphine posted:Also, you might want to run 'apt autoremove' to get rid of some of the old kernels. There's basically no reason to keep more around than current and previous.
|
|
#
?
Dec 21, 2022 14:22
|
|
|
Phosphine posted:Also, you might want to run 'apt autoremove' to get rid of some of the old kernels. There's basically no reason to keep more around than current and previous. Did this. The problem that got me to do the update is still rearing its head. Cinnamon was crashing on startup, when I tried starting from terminal I got some error with Clutter not being able to start or something. I removed my nvidia drivers, went into software mode, and tried installing nvidia-driver-525-open(the recommended driver) from driver manager. After rebooting I wasn't able to get to login(got a black screen with occasional cursor flash), so I rebooted again I removed the nvidia drivers again. In software mode now and looking at the driver manager. Currently running on xserver-xorg-video-nouveau, should I try going for a previous driver version, like nvidia-driver-515-open, should I try the non-open driver to see if that makes a difference, or should I do what I'm seeing here https://www.binarytides.com/install-nvidia-drivers-ubuntu-14-04/? code:SadBag fucked around with this message at 17:22 on Dec 21, 2022 |
|
#
?
Dec 21, 2022 16:56
|
|
|
unless you have some very specific reason to use nvidia-open driver, i'd highly suggest just using the proprietary version since that's actually supported on your gpu
|
|
#
?
Dec 22, 2022 01:31
|
|
|
Truga posted:unless you have some very specific reason to use nvidia-open driver, i'd highly suggest just using the proprietary version since that's actually supported on your gpu Used proprietary, seems to be working. Thanks.
|
|
#
?
Dec 22, 2022 02:29
|
|
|
Isn't nvidia-open in alpha stage? Why would any distro recommend it? nvidia-open is the "new" open source driver, right?, from nvidia. That they just opened this summer?
|
|
#
?
Dec 22, 2022 03:16
|
|
|
So apparently ostree supports rebasing using arbitrary container images. So you can create a containerfile of your preferred ostree OS (like Fedora Silverblue) make the tweaks you want to the OS in the file (setting up unfiltered flathub, replacing rpm Firefox with flatpak Firefox, setting the update frequency, etc) and rebase to this new image like you would to a docker or podman container. You'd need to deploy using a platform that offers CI/CD (like github with its "workflows") so you can set it up to periodically check for updates from the base image and rebuild the container image. Otherwise your OS won't recieve updates from upstream. Pretty neat IMO. https://github.com/ublue-os/base
|
|
#
?
Dec 24, 2022 16:04
|
|
|
Mint is at 21.3 so just curious why you are going from 19 to 20?
|
|
#
?
Dec 25, 2022 01:34
|
|
|
Rojo_Sombrero posted:Mint is at 21.3 so just curious why you are going from 19 to 20? Ironically I had previously intended to update my Mint 19 VM to 20 and hadn't gotten around to it so that post made me get around to it only to realise it's now 21.
|
|
#
?
Dec 25, 2022 02:08
|
|
|
Phosphine posted:Also, you might want to run 'apt autoremove' to get rid of some of the old kernels. There's basically no reason to keep more around than current and previous. I've already upgraded past this issue, but I wanted to ask for future reference: is there a way to put a hold on your old kernel and only update the current one? Backstory: After a kernel update when I rebooted I only had one monitor and resolution was locked to 640x480 or something stupid. Tracked it down to a video driver issue in that update and booted with my previous kernel, everything was fine. What I wanted to avoid was updating to another kernel version with the same issue and having both a current and previous kernel that were busted. I wanted to lock my working previous kernel version and only update the current one. vvv Thanks, I remember reading about holding packages in my research, but I wasn't 100% that same process applied to kernels. Takes No Damage fucked around with this message at 17:24 on Dec 25, 2022 |
|
#
?
Dec 25, 2022 02:38
|
|
|
Takes No Damage posted:I've already upgraded past this issue, but I wanted to ask for future reference: is there a way to put a hold on your old kernel and only update the current one? You can use 'apt-mark hold' to mark a package as held, preventing it from being upgraded or autoremoved. So if you hold the known working kernel, you can fearlessly update and autoremove after that and it will remain for you to boot into if it breaks. Edit: scenarios like this is also why upgrade doesn't autoremove and kernels are different packages that succeed that previous instead of being versions of the same. The suggested procedure is to upgrade, reboot, and then autoremove, so you don't end up with only a nonbooting kernel. I think (don't quote me on this/rely on it for safety) that Ubuntu internally keeps track of kernels you've booted, so even if you run autoremove immediately, it will keep the one you're currently on in addition to latest, as it hasn't confirmed that the new one works yet. Phosphine fucked around with this message at 11:31 on Dec 25, 2022 |
|
#
?
Dec 25, 2022 11:27
|
|
|
Problem: due to my brand new GPU, I need both a recent Mesa as well as LLVM 15 in order to get the acceleration working. For native apps that's fine, I just installed the RPM packages. But for flatpaks, it's not so straightforward. There is a mesa-git package and you can use the envvar FLATPAK_GL_DRIVERS to get it loaded by other flatpaks (detailed instructions here). So that part is done. But when it comes to LLVM, it seems I'm SOL. The only packages available, even in the beta flathub, are for v12 and v14, despite v15 having been officially released almost four months ago. And I did not find anywhere a way to inject a specific LLVM extension into flatpaks, like you can with mesa, so maybe it's pointless. The best I could find was this very old and very abandoned project but it's broken in non-obvious way (the LLVM git repo has migrated to a different structure). So I'm looking, if not for a solution, at least for some clues to the question: how do I get a flatpak to use LLVM 15?
|
|
#
?
Dec 28, 2022 14:49
|
|
|
I thought the whole point of flatpaks is that they are bound as a unit with their dependencies, rather than pulling in libraries from the host environment. It sounds like they made an exception for GL drivers but AIUI the right way to solve this is to rebuild the flatpak itself against LLVM 15. I haven’t done much of it, but because of that isolation flatpaks tend to be easy to build, if a bit slow. (I wonder how many more exceptions they’ll make, until flatpaks are just awkward RPMs again.)
|
|
#
?
Dec 28, 2022 15:24
|
|
|
Flatpak is idiotic for precisely the reason you have discovered.
|
|
#
?
Dec 29, 2022 00:43
|
|
|
It’s no more idiotic than static linking, which is to say taking a specific point in the trade off spectrum between “control my dependencies” and “integrate into the system”.
|
|
#
?
Dec 29, 2022 01:10
|
|
|
Is there anything like this https://getfancontrol.com/ for linux? I got fed up with windows on my desktop and decided to dip my toes into linux on the desktop again with Manjaro but I can't for the life of me find any utilities to control fan speed that have the depth this tool had - it seems like they either don't work at all or "work" but fail to expose all the sensors that the "sensors" command reports, including ones my previous configuration relied on. (also no hysteresis, no averaging sensors together, etc.) fancontrol-gui is the former, coolero is the latter.
|
|
#
?
Dec 29, 2022 01:30
|
|
|
Which distro branch of Linux are you on? There may be agnostic software but if you share your distro it's easier to tell who knows their branch enough to give a good answer.
|
|
#
?
Dec 29, 2022 03:08
|
|
|
corgski posted:Manjaro Being that it's arch-based, anything in AUR is also easily accessible.
|
|
#
?
Dec 29, 2022 03:25
|
|
|
corgski posted:Being that it's arch-based, anything in AUR is also easily accessible. Sorry I have to admit that I blanked on Manjaro because I didn't recognise it - my bad. Does this provide the functionality you're looking for? https://gitlab.com/corectrl/corectrl
|
|
#
?
Dec 29, 2022 04:20
|
|
|
Tesseraction posted:Sorry I have to admit that I blanked on Manjaro because I didn't recognise it - my bad. Does this provide the functionality you're looking for? https://gitlab.com/corectrl/corectrl corectrl is nice, but it’s about controlling the CPU and GPU parameters like clocks and power levels, and not system fan profiles. (It does say it can control the fans on AMD GPUs, but that’s all afaict.)
|
|
#
?
Dec 29, 2022 04:32
|
|
|
I'm pretty new to linux but I am slowly learning. I have Mint 20.3 Cinnamon installed on an AMD Ryzen 5 5600G machine. I replaced the motherboard and removed an Nvidia GT 1030 video card, to use onboard graphics instead. Linux is able to boot, but doesn't seem to be using an graphics drivers at all. inxi --graphics results in: code:code:code:I was hoping to not have to reinstall Linux. Is there any way to make this installation realize it's supposed to be using AMD graphics drivers now? Edit: The solution was I was using kernal 5.4 for some reason. Updated and now it's all good. counterfeitsaint fucked around with this message at 23:42 on Dec 29, 2022 |
|
#
?
Dec 29, 2022 22:49
|
|
|
Might be a bit of an obvious question but did you try code:
|
|
#
?
Dec 29, 2022 22:59
|
|
|
Tesseraction posted:Sorry I have to admit that I blanked on Manjaro because I didn't recognise it - my bad. Does this provide the functionality you're looking for? https://gitlab.com/corectrl/corectrl Unfortunately not, that's more of an overclocking tool than a fan control tool. To generalize the problem, my cooling system has more thermal mass than the bare minimum cooler that the Tctl value on Ryzen processors was designed to drive. So my system spins up the fans way too quickly for short bursts of activity that can be absorbed entirely by the cooler, as long as case temps are low. Using the app I linked on windows I was able to set up a cooling program that used a running average of the cpu die temperature along with the average case temperature (sampled from the hard disks and a couple of the motherboard sensors) to control the system fans and have a much quieter system with a lot less variance in fan speed when web browsing.
|
|
#
?
Dec 29, 2022 23:10
|
|
|
|
| # ? Jun 10, 2024 16:48 |
|
|
I'm guessing that https://wiki.archlinux.org/title/fan_speed_control was no help?
|
|
#
?
Dec 29, 2022 23:18
|
|