Yes. Decimal time almost happened in France during the revolution, but fixing all the clocks was impossible so people kept their standard clocks, so they kept the old habit...
Back when I played WoW I would occasionally run into issues with windows trying to put the game into memory compression, as opposed to basically any other process. It turned the game into a powerpoint.
You could either get freaky with process explorer, or just keep some overhead so the system wouldn't try to do that. When I asked my guildies, they told me the 'default' for gaming is 16GB now, I was on 8 at the time.
Pretty much every gamer will at some point tab out to process manager to see wtf the computer is trying to do and exactly zero of them will think to themselves "I'm so glad there is no wasted memory!"
For the 3rd paragraph, specifically: That's a fault with Windows not being clear enough with what is actually being in use, and what may be used and already there for a myriad of reasons.
>
Your approach is like buying a giant house, becoming a hoarder, and trying to throw a party.
exactly, excepting that the items they're hoarding are occasionally very useful for making their day to day activities go faster. And the hoarder has the superpower that in the blink of an eye they can discard everything that's hoarded to make room for the party.
Wait it isn't quite like a normal hoarder at all come to think of it!
The whole point is that pagecache does not cause any swap hits.
Oh my god, it's 2023 and we're still discussing this idea from 1970s.
Is that so hard to grasp? No, stuff gets evicted from the cache long before you hit the swap, which is by the way measured by page swap-out/in rate and not by how much swap space is used, which is by itself a totally useless metric.
> stuff gets evicted from the cache long before you hit the swap
No...?
I'm looking at a machine right now that has 3.7GB not swapped out and 1.2GB swapped out. Meanwhile the page cache has 26GB in it.
Swapping can happen regardless of how big your page cache is. And how much you want swap to be used depends on use case. Sometimes you want to tune it up or down. In general the system will be good about dropping cache first, but it's not a guarantee.
> measured by page swap-out/in rate and not by how much swap space is used
Eh? I mean, the data got there somewhere. The rate was nonzero at some point despite a huge page cache.
And usually when you want to specifically talk about the swap-out/in rate being too high, the term is "thrashing".
cached disk pages are not going to be swapped out, they're just freed (because these pages are already "out" in the same place swapland is)
if your cached disk pages keep getting hit and are "recent", they're going to stay in, and your old untouched working pages are going to be swapped out, to make room either for new working pages because you've just loaded new programs or data, or to make room for more disk pages to be cached because your page cache accesses are "busier" than some of your working pages.
you will swap out pages to make room for disk cache, but your cached disk pages will never be swapped out, they are just tossed (of course, after any dirty pages are written)
> The whole point is that pagecache does not cause any swap hits.
> Oh my god, it's 2023 and we're still discussing this idea from 1970s.
> Is that so hard to grasp? No, stuff gets evicted from the cache long before you hit the swap, which is by the way measured by page swap-out/in rate and not by how much swap space is used, which is by itself a totally useless metric.
Not everyone has been alive and into this stuff since the 1970s. That you and I know about this is irrelevant for the new people discovering it for the first time. There is always going to be a constant trickle in from new sources, for as long as it takes for the tech to go away. See relevant xkcd: https://xkcd.com/1053/
But it's also worth pointing out that RAM/swap/page cache isn't always as simple as page cache out, RAM in. For example, this question[1] seems to indicate that things aren't as simple as you suggest.
The page cache mechanism is very much alive. That's what we were discussing, is it not? I only lamented the fact that over 50 years the basics of how it works should have become common knowledge but did not.
As for the link you provided, I do think I can get a system in a state like that, and that isn't even untrivial. To push firefox into swap, esp if you have just 8 gigs of it is.. simple. But it is not in any way a normal state of a system. Idk how the author got it in that state.
I just got a 64GB machine. It rarely sees much use, but I did go over 32GB a few times.
Could've done away with less but I still have PTSD from all my applications crashing after I started Teams on my 16GB machine. On another note: Upgrading from i5-2500k to R7-5800X doesn't make Teams faster in any way.
I like the simplicity of passwordstore. But keepassx* are good too. I'll never trust an online solution, and probably almost never trust a browser extention.
Briefly looking at the files and code it's hard to tell whether that is still the case, but it's fair to assume Import-Export would reuse most of the machinery behind Bridge.
bridge exposes imap making it easy to download all your data using Thunderbird or another client. I don't know about "export" because imap does what I want and is supported by most providers in the same format.
For those who care about OSS and moving to Protonmail from bigcorps email, this _might_ matter, although I think that for the majority of Protonmail users (which doesn't care much about open source), it doesn't matter.
Mypyc is stable for what it supports. Mypy itself is built with it. Black is built with it. I use it in production for some things, but use Nuitka for others. That decision is mostly down to a project's dependencies, not the project's own code. The more magic a Python module has, the harder it is to build AOT.
On my debian stable, if I want this behaviour I actually have to add `--user`.
But that's not the recommended way to install pypi packages you want to use, with debian at least. This may install dependencies that will break (for your user) some debian packages depending on other versions of said dependencies. The easy way to go is `pipx install west`.
EDIT: --user is not necessary anymore. I think this does not alter the validity of the rest of my comment.
Actually, you shouldn’t need to add that flag, AFAIK it’s been the default for a while for non-root users. But both Debian and Ubuntu tend to package their Pythons to rely on .deb packages and have been somewhat inconsistent over the years.
Does it try to install packages in your system paths and fails due to lack of permissions?
You're right, --user seems the default behaviour, I did not realize that. Maybe because it's different in Fedora that I also use? Or maybe I was just plain wrong :)
Anyway, I think this does not change the fact that it's a bad idea to populate your ~/.local/lib with python libs, since it may break some python programs installed via apt for your user, or was that wrong too?
Well, I use Fedora since March (after a lot of Ubuntu) and I don't need --user. I'm on 36.
As to filling your lib with stuff, it depends. AFAICR the default is to search for things there first, because it is assumed the user environment takes precedence.
is suicide. You can be doing everything right, using venv’s, conda and all that, install one package in a user directory and blam! You just broke every Python you use because that package is installed in all your environments.
It’s a bad idea right up there with Linux distros having python2, python3, python3.1, puthon3.2, python3.3, …. They give up the ease of use of a command line application where you can tell people what to type for the mind numbing complexity of a GUI application where it takes a 1500 page book to explain how to do anything in Microsoft Word because now you can’t tell people what to type to run and install things.
It ensures you're installing into environment using your current python. Useful in case the op already has a messed up environment where default pip doesn't use default python.
It's a good habit which ensures pip runs with the same interpreter as your `python` command.
One example (but there's many): On Windows a `pip install --upgrade pip` can't work as the OS would lock the `pip` executable, while a `python -m pip install --upgrade pip` works as the OS would lock python instead.
I also encontered environments (CI runners, things like this) with `python` and pip installed, installed but no `pip` shortcut.
And for non-systemd systems like postmarketOS, there's waked that writes directly to the RTC dev node directly for the same effect. pmos also patches gnome-clocks to use waked.
That's an "interesting" solution, since exactly what waked does is already done by kernel internally if you use timerfd, without the need for any special daemon. Any app that wants to be woken up at certain time can just register a timer for that time with the kernel.
The issue is that it's not possible to create wakeup timers without root or CAP_WAKE_ALARM, hence why you need a more privileged daemon of some sort that your regular alarm clock app binary. Eg with systemd it doesn't let timer units in the user session that can wake the system, which is what is blocking gnome-clocks upstream from using systemd timer units.
But yes, I don't know why waked uses the dev node directly instead of using CLOCK_ALARM, and it's definitely possible it interferes with anything else going through the kernel using CLOCK_ALARM.
No, you're not missing anything. I should've been clearer that I was talking about gnome-clocks specifically, which wants to use systemd both so that only systemd needs the privileges rather than gnome-clocks itself and so that it can autostart gnome-clocks using the timer [1] even if gnome-clocks is down at the time (ie gnome-clocks doesn't itself need to keep the timerfd alive).
I think one reason not to use the timerfd method is that you (waked) could drop the fd if it terminates unexpectedly. There is probably a way to persist the db separately... But the device node is right there.
If waked terminates unexpectedly, it has to be told about all the registered alarms by all apps again after restarting. Apps need to be notified to provide the info again, etc. If waked would keep a database, then you have a syncing problem, between apps and waked, possibility of desynchronization. If app crashes, and doesn't remove alarms from waked, the phone will wakeup, but there will be no app to present the UI. Sounds confusing.
Automatic resource management by kernel when the app crashes or is stopped is actually quite nice. You just restart the app and setup the timers again from the stored settings. You have to store alarms persistently, in any case. You'll get event in the eventloop of the app that registered the timer, etc. Complexity of the solution is minimal. Less opportunity for bugs and failures.
it has to be told about all the registered alarms by all apps again after restarting
Is that true? Or does it just read from the rtc state? (Or leave it alone?) Also for efficiency reasons, don't you want a single wakeup being scheduled rather than potentially spaced out wakeups?
stored settings
Aka a database, right? Albeit a per-user database. What you are talking about sounds more like a service (daemon) than an app, though, from my perspective. A sort of per-user waked. That operates by holding timerfds it negotiated away from a privileged service. You can't revoke FDs anymore/yet, right? Although you can mark them cloexec and go on a killing spree.
I just want the timer to fire and be handled in the process where it's needed, regardless if the system is suspended or not completely transparently. Waked doesn't help with that. I certainly don't want a special daemon that I have to register with over a complicated protocol (d-bus) in addition to having to manage the timers in app when it can be avoided just by passing a single flag to timerfd_create which will work universally and will not depend on systemd.
Spliting alarms into a deamon and UI shell is kinda pointless unless some other app would need access to alarms. But that would be a different service than waked in any case. Waked doesn't handle timers.
