The canonical documentation is https://www.kernel.org/doc/Documentation/filesystems/proc.rst (ctrl-f oom) but if you search a bit you’ll find various guides that might be easier to digest.

https://www.baeldung.com/linux/memory-overcommitment-oom-killer looks like an informative recent article on the subject, and reminds me that my knowledge is a bit outdated. (TIL about the choom(1) command which was added to util-linux in 2018 as an alternative to manipulating things in /proc directly…)

https://dev.to/rrampage/surviving-the-linux-oom-killer-2ki9 from 2018 might also be worth reading.

How to make your adjustments persist for a given desktop application is left as an exercise to the reader :)

I’m not sure what this comic is trying to say but in my recent experience a single misbehaving website can still consume all available swap at which point Linux will sometimes completely lock up for many minutes before the out-of-memory killer decides what to kill - and then sometimes it still kills the desktop environment instead of the browser.

(I do know how to use oom_adj; I’m talking about the default configuration on popular desktop distros.)

I think it depends which side of the debate one is on?

$ systemd-analyze calendar tomorrow
Failed to parse calendar specification 'tomorrow': Invalid argument
Hint: this expression is a valid timestamp. Use 'systemd-analyze timestamp "tomorrow"' instead?
$ systemd-analyze timestamp tuesday
Failed to parse "tuesday": Invalid argument
Hint: this expression is a valid calendar specification. Use 'systemd-analyze calendar "tuesday"' instead?

ಠ_ಠ

$ for day in Mon Tue Wed Thu Fri Sat Sun; do TZ=UTC systemd-analyze calendar "$day 02-29"|tail -2; done
    Next elapse: Mon 2044-02-29 00:00:00 UTC
       From now: 19 years 4 months left
    Next elapse: Tue 2028-02-29 00:00:00 UTC
       From now: 3 years 4 months left
    Next elapse: Wed 2040-02-29 00:00:00 UTC
       From now: 15 years 4 months left
    Next elapse: Thu 2052-02-29 00:00:00 UTC
       From now: 27 years 4 months left
    Next elapse: Fri 2036-02-29 00:00:00 UTC
       From now: 11 years 4 months left
    Next elapse: Sat 2048-02-29 00:00:00 UTC
       From now: 23 years 4 months left
    Next elapse: Sun 2032-02-29 00:00:00 UTC
       From now: 7 years 4 months left

(It checks out.)

Surprisingly its calendar specification parser actually allows for 31 days in every month:

$ TZ=UTC systemd-analyze calendar '02-29' && echo OK || echo not OK
  Original form: 02-29
Normalized form: *-02-29 00:00:00
    Next elapse: Tue 2028-02-29 00:00:00 UTC
       From now: 3 years 4 months left
OK
$ TZ=UTC systemd-analyze calendar '02-30' && echo OK || echo not OK
  Original form: 02-30
Normalized form: *-02-30 00:00:00
    Next elapse: never           
OK
$ TZ=UTC systemd-analyze calendar '02-31' && echo OK || echo not OK
  Original form: 02-31
Normalized form: *-02-31 00:00:00
    Next elapse: never           
OK
$ TZ=UTC systemd-analyze calendar '02-32' && echo OK || echo not OK
Failed to parse calendar specification '02-32': Invalid argument
not OK

Copy left is very much not communist. Get out of here with that tankie rhetoric

i don’t actually think copyleft is communist per se, but i dig that you’re somehow mad about my joke - the intended butt of which was people who (typically disparagingly) insist that it is 😂

yep, since it’s under a “copyleft” (communist) software license that’s how it has to be.

Formally.

Ads?! in Ubuntu? Never! They were simply “integrating online scope results into the home lens of the dash” 🤡

(that is an actual quote from the sentence immediately following “We’re not putting ads in Ubuntu” in Mark Shuttleworth’s blog post responding to the entirely predictable backlash after they did this, twelve years ago…)

What a confused image.

1. TiVo complied with the GPLv2 and distributed source code for their modifications to Linux. What they did not do was distribute the cryptographic keys which would allow TiVo customers to run modified versions it on their TiVo devices. This is what motivated the so-called anti-tivoization clause in GPLv3 (the “Installation Information” part of Section 6. Conveying Non-Source Forms.).
2. Linux remains GPLv2, so, everyone today still has the right to do the same thing TiVo did (shipping it in a product with a locked bootloader).
3. Distributing Linux (or any GPLv2 software) with a threat of violence against recipients who exercise some of the rights granted by the license, as is depicted in this post, would be a violation section 6 of GPLv2 (“You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.”).

adding all compiled file types including .pyc to .gitignore would fix it

But in this case they didn’t accidentally put the token in git; the place where they forgot to put *.pyc was .dockerignore.

At my workplace, we use the string @nocommit to designate code that shouldn’t be checked in

That approach seems useful but it wouldn’t have prevented the PyPI incident OP links to: the access token was temporarily entered in a .py python source file, but it was not committed to git. The leak was via .pyc compiled python files which made it into a published docker build.

Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve

I somehow first read “Redhat” as “Reddit” in this sentence, and so was briefly thinking that perhaps this bad idea originated there 😂

python -c 'print((61966753*385408813*916167677<<2).to_bytes(11).decode())'

$ python
>>> b"Hello World".hex()
'48656c6c6f20576f726c64'
>>> 0x48656c6c6f20576f726c64
87521618088882533792115812
$ factor 87521618088882533792115812
87521618088882533792115812: 2 2 61966753 385408813 916167677

(probably the most downvoted post i’ve made yet on lemmy 😂)

Mattermost isn’t e2ee, but if the server is run by someone competent and they’re allowed to see everything anyway (eg it’s all group chat, and they’re in all the groups) then e2ee isn’t as important as it would be otherwise as it is only protecting against the server being compromised (a scenario which, if you’re using web-based solutions which do have e2ee, also leads to circumvention of it).

If you’re OK with not having e2ee, I would recommend Zulip over Mattermost. Mattermost is nice too though.

edit: oops, i see you also want DMs… Mattermost and Zulip both have them, but without e2ee. 😢

I could write a book about problems with Matrix, but if you want something relatively easy and full featured with (optional, and non-forward-secret) e2ee then it is probably your best bet today.

That installs and or updates roots flatpaks

Which is what flatpak will always do unless provided with the --user flag.

By default it operates in system-wide mode, which is different from “root’s”.

flatpak list and sudo flatpak list will both show you what is installed system wide, and flatpak list --user will show you your user’s, and sudo flatpak list --user will show you the root user’s flatpaks installed in per-user mode (of which there are typically none).

Only with --user (I think)? Root can also update the “system installation” flatpaks, which are presumably what OP needed a password for.

next time you can use su or sudo

Ente doesn’t seem to require a CLA.

It turns out, they do have a CLA (with full copyright assignment 😢).

They’d need to implement something like SRP.

Update: I contacted the developers to bring my comment to their attention and it turns out they have already implemented SRP to address this problem (but they haven’t updated their architecture document about it yet).