Wouldn't it be faster to swap to vram if you are sitting there with 8gigs of it unused than swapping to ssd and burning its write cycles, assuming you absolutely need swap
Moved from cronie to systemd timers because they are resilient to system startup times. My backup strategy is to create a borg archive entry every day at a fixed time. With cronie the system needs to be running at the scheduled time, but systemd timer tolerates this and runs the service as soons as the system is available.
Cronie has a mechanism for this, called "anacron", which is called hourly by cron (on my system, /etc/cron.hourly/0anacron), and performs all the /etc/cron.{daily,weekly,monthly} tasks, no matter if the earliest possible schedule was missed (and with a configurable random delay). You can modify /etc/anacrontab to create custom schedules.
To do this at the user level, you can add something like "@hourly anacron -t /path/to/anacrontab -S /path/to/spooldir" to the user's crontab, though I've never tried this.
Many cron implementations have a similar mechanism.
This isn't the same as with systemd timer because timer lets you specify when you want to run your service exactly and will fallback to running when the system comes online. With @hourly I lose this control and multiple machines could potentially trigger backups at the same time, hogging the physical hard drives and the network.
> fallback to running when the system comes online.
That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.
I prefer the deterministic behavior of cron, the script will run when it is specified to run, as you said earlier, as long as the system is running; and as I stated in a separate comment, it will run @reboot if I need it to run then.
> With @hourly I lose this control and multiple machines could potentially trigger backups at the same time
Then don't use @hourly, use staggered times, it's very easy.
> That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.
This isn't what happens. If you leave it offline for days it'll only trigger the service only a single time.
I interpreted it more like "I have these 500 different cronjobs all spread out across $unit_of_time. If the system is down for longer than $unit_of_time and then comes back, does all 500 jobs start running instantly (since they missed their previous deadline)?"
Just to be clear, this isn't default systemd timer behaviour, you need to opt in by setting Persistent=true. If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool because at that scale you'd surely need better observability
You could implement this with a gitlab instance in a separate system, like two VMs in proxmox or two physical machines, and a shell executor running in them. Gitlab CI has a nice feature to limit concurrency by using resource groups. Say you have 500 jobs spread through the day and the system stays offline for a while, when it comes online it'll start processing the jobs, but will only run a single one at a time. You get visibility, logs, queue monitoring and an API to query data.
> If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool
Eh sometimes, but you can get pretty far with one of two approaches:
1. Careful use of Requires= and Wants= to group your scripts into chains of jobs, which achieves fixed parallel (though at 100s of jobs, I hope you're generating those unit files with a tool like Puppet or https://github.com/karlicoss/dron or something and not doing this by hand).
2. Even better, just use a lockfile. `ExecStart="flock -F $TMPDIR/mylock <command>"` is pretty hard to beat. Use -F so as not to confuse KillMode and resource accounting and you're golden. Just don't use flock(1) timeouts; let systemd handle that. Heck, if you have that many cron jobs, you should be doing this even if you don't use systemd; otherwise job latency changes can cause reboot-style thundering herds out of the blue.
If you have 100 different jobs that were supposed to run over the past week, but didn't because offline, when you restart, they they all flood the system on start.
100 jobs all running at different times throughout the week is a very different load than them all falling back and running at the same time on system boot.
> That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.
There are two options to fix it;
Disable persist so no catching up on missing scripts. Set OnBoot=5m so it gets ran 5 minutes after boot, so your script (say backup) is ran on boot first, then every time on schedule
Enable persist but just add sleep in ExecStartPre - very "cron" way but there is just no in-systemd option to enable "catch up" script to be delayed
Sadly no option to "run catch-up timers with delay" at least yet
> Then don't use @hourly, use staggered times, it's very easy.
Not in cron. In systemd it's just RandomizedOffsetSec=30m and it is "stable" - same host with same job will always have same delay so on multiple hosts it is spread nicely. There is also non-stable version
No, just different cron schedules. If I just reboot a machine the job doesn't get triggered, only if I start a machine after the cron schedule should have been triggered. To be fair, if I start two machines in these conditions this will happen too, but such situation is much more manageable than rebooting too machines in a short period of time.
> With cronie the system needs to be running at the scheduled time, but systemd timer tolerates this and runs the service as soons as the system is available.
It would be nice to know the limits of this tech, like how does it tolerate head gears and garments like headphones or hoodies, beanies and glasses, long hard, different skin colour and facial features or even background contrast.
To me they are much better than browser/electron/native gui because they are light on resources, very predictable, portable and honestly they get the job done. I used k8s Lens and it gave the impression of being efficient because of the high density of information, but I haven't felt like I downgraded when I moved to k9s, and now I can manage my clusters, develop their charts using neovim and browse the web without getting dangerously close to filling 16GB of ram. Before with Lens, Pycharm and a browser that would swallow the ram whole and spit its decaying bones to the swap unreasonably often.
On k8s/devops tooling: I'm building tuis.nvim [1] — Docker and Kubernetes management as Neovim buffer TUIs, built on morph.nvim [2], a react-like UI framework for Neovim. Stay in the editor (if you already use Neovim, of course) instead of switching to k9s, works over SSH, same Vim keybindings you already use. Also has plugins for Bitwarden, process management, and file exploration.
To me particularly, leaving editor isn't a hassle because kitty makes it seamless. Neovim, k9s, zsh shell, agents, it feels like it's just a single IDE, and I believe that specialized tools are simpler and more robust to maintain instead of adding functionality that wasn't intended for neovim. Don't get me wrong, neovim is sufficiently flexible for this, it's just that I had too much agro with neovim extensions that I just prefer native tools.
That is a valid point of view. For me, however, I have found a huge productivity boost being able to stay in Neovim for extended periods of time. That's not to say that my way is the only right way, but the more I'm able to accomplish in Neovim, the less friction I personally experience.
I know this is just a speculative comment, but the list of GitHub issues is eerily familiar. These problems read a lot like the types of mistakes and assumptions unattended agents will make that corrode codebases.
I had the Surface 3 and it was a good product, really good for note taking in college, quite revolutionary I'd say, to use the same device for the notes and for MATLAB and the likes. It was terrible in terms of maintenance but I think they fixed it in later iterations. The surface 3 had a glued screen that would crack 99 out of 100 times and there was no other way to access components in it. It survived for about 10 years which I think is fair. Shame that such an interesting product is developed by a completely untrustworthy company.
Why in general? Because if you don't read the article, you run a strong risk of reacting to things that the article didn't actually say. See OP for a good example.
Why this OP specifically? Because he is strongly reacting to the article's claim that "Ai is not the default" ... which is not stated or implied by the article he's replying to.
The article is a useful bulletin that DDG has a "no AI" function, previously accessible via a URL and now through extensions as well. OP is acting like DDG is claiming to be an anti-AI company, based on nothing stated in the article.
It's just that people have different understanding of the world and assuming something is self evident is dangerous. For instance the problem here is the apparent disconnection between the comment and the article, but maybe it's just that the connection isn't evident to you.
Take this response to a comment of mine for instance https://news.ycombinator.com/item?id=48144461. I've read the article and someone thought I didn't because he didn't see the connection I saw and acted all righteously, almost as this threads OP.
So in order to avoid embarrassing yourself online it's always nice to first give people the benefit of the doubt and then avoid being sneaky and clever when communication what you want.
I don't owe the benefit of the doubt to a comment that says "this is just marketing" and "are people this stupid?". If OP is going to make dismissive, vitriolic comments like that, he should probably make sure that the article is actually saying anything like what he claims.
In an ideal world guidelines should be suggestions for those willing to make the best of the course and improve as a person and professional. However a degree has real world value and repercussions, so enabling someone incompetent to do a dangerous job can put innocent lives in jeopardy. It's tough, but I hope in time we learn how to live with this new tech.
This is ridiculous. What if instead of LLMs the author made it so that you get your project erased if you used NVidia? And meanwhile it doesn't make a dent in the actually damaging practices the model providers are conducting.
Protesting is important and should happen. The idea is that it'll make people's lives difficult so they pressure leaders and companies to change their practices. Believing that this will happen and by public outcry companies like Meta, Anthropic and OpenAI will change their ways is delusional.
The cat is out of the box. If you want to make a difference in the world either join these companies and change things from within or you open your own company that'll push a viable ethical model. That and vote better for more ethical leaders. What we see in the world is partly because we have olygarchs in power. Anything else is childish behaviour and the authors should think hard about growing up as adults.
I am reminded of the Sway tiling window manager. When I tried it, years ago, on NVIDIA cards it refused to start unless you passed a "--my-next-gpu-wont-be-nvidia" flag. I remember that even then that seemed pretty childish (particularly for something like a WM). Apparently they eventually renamed it to the more neutral "--unsupported-gpu".
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
reply