Email support was the bain of my existence. I forgot how many misconfigured system I came across decades ago that would fill up their filesystem with logs from crons in the root mail dir. Such a stupid default setting. We have vastly better methods for monitoring systems these days then firing off an email when a cron runs.
nous
joined 2 years ago
You can also easily see when the job last ran, if it was successful and when it will next run. As well as just trigger the service if you want it to run now.
Inertia also accounts for time and popularity. The longer something has been around and popular the more inertia it has and the harder it is for something to change it. Back in 1985 things had a lot less inertia then they do today - C and C++ have been gaining it constantly for 30 years since then.
The US government does not like welfare programs because it gives money to the poor. They would rather give tax reliefs to the rich instead.
There is loads of evidence that welfare programs can save more money then they cost. But that does not funnel money to those in charge.
I find most people don't create good unit tests. They create them too small which results in them being fragile to change or near useless. They end up being a tray for future you not a love letter.
The number of times I have refactored some code and broken a whole bunch of unit tests is unreal. These types of tests are less then useless. If you cannot refactor code then what is the point in a unit test? I don't need to know that if I don't change the code under test it doesn't break... I need to know that when I change code my assumptions still hold true.
We should be testing modules as a whole using their external API (that is external to the module, not necessarily the project as a whole), not individual functions. Most people seem to call these integration tests though...
5 years is optimistic. More likely 10-20 years at least. Established languages have a lot of inertia and it takes a very long time for that to change.
Why wrap it in a function at all? Why not just put the if at the top of the file?
While true and some will do it for that reason, I bet most do it simply because the friction to forking is so low.
Some might have an intention to work on it but then don't or might start looking at it in detail then give up or get to busy or lose interest.
Others might just click it to save it for later.
And don't forget all the people that click it by accident.
It's not like it is a big investment to click the button.
Probably something to do with their main package deleting the pacman lock file so it can run a nested pacman update command... Which means two pacman instances running at the same time and nothing stopping other ones after that nested one has completed.
Or use systems timers which keep track on this information for you. Can even tell you when the job will next run and automatically captures the logs and exit status from the runs.
I have more then once gave up on pressing up, hit ctrl + c to reset only to see the command I wanted briefly flash up as I am hitting ctrl + c
view more: next ›
You cannot do that analysis with one sample. Why pick one day? That is an arbatary amount? Pick the 1 hour or minute that the CVE was released and you will find rust might be responsible for 100% of CVEs, Take a Week or year and that number drops dramatically. Pick the next day and that drops to 0%. You can select any % you want if you change what time period you are looking at.
The fact that there has been one cve in 5 years of rust in the kernel is a bigger tell. There will be more rust CVEs, and each one is going to be big news as they happen so rarely.