Typo on my part.

Note that you can use systemctl list-timers to see all active timers including when they will next run and when they last ran. This is very useful for seeing if you have set things up correctly.

There are multiple ways to do this as well. You can do

OnCalendar=Sun 03:00
Persistent=true

To run every Sunday at 3am. And will run immediately when activated if the last time was skipped due to the system being off. Think that is the closest to your cron job.

You can also

OnCalendar=weekly
Persistent=true

If you don’t care when it will run. This is equivalent to Mon *-*-* 00:00:00.

You have picked some weird hills to die on there.

for x in list:

This is fine. Many languages now do it. The extra brackets around a for or if dont really add any clarity or make things easier or harder to read. This is the type of thing you just get used to and prefer what you are used to. You get over it quickly.

Why would you provide a way to type parameters but don’t enforce it at runtime?

This is a bit stupid, but really is legacy reasons for it. Since it didnt use to have static type declarations and wants to remain somewhat backwards compatible it needs to ignore them at runtime. But as a JS and PHP developer you should be used to this. Both do the same thing as python here with types (well, TS for JS and the many other attempts at getting types into JS). So it is weird that you are singling out python for this behavior.

Why so many different ways to declare an array-like structure? Tuples, Sets, Dicts, Lists?

DIcts are not array like here. Tuples sets and lists are all common is many languages as well. PHP is a real weird case here given everything, even arrays are effectively a dict - that is a strange language design feature. But Java is way worst for different types of array types in the language.

I’m mainly using it because of interoperability, easy to setup, i

What? I hate setting up python projects. Each one wants to use a different dependency or version manager. Yeah you might have python on most systems but they are all different versions and python is famously terrible at backwards compatibility. It seems every few versions they throw something in the breaks some existing scripts so you really need a version manager for things. Which is more complex setup and management of things. There are far too many different tools to help you with this and fetching dependencies which means if you work on lots of different projects by different people you have a hodge podge of diffing tools you need. It is a complete mess.

Personally I hate python as a language, but you have picked some minor points that IMO dont really matter or that the other languages you use also suffer from. There are far better things to pick from that are far more annoying in the language.

I get this but, for what I know (I might be wrong tho), steam doesn’t get a cut from keys sold externally so they are technically selling them at better conditions elsewhere?

It is a grey area. But I think the key point is that humble bundle at least don’t distribute the games in the same way as epic does. They typically offer steam keys which they get from steam probably with a different license or agreement with steam. Valve seems to not care that much about how the game is sold as long as you can activate it on steam. It cares more about people buying games on a competing platform cheaper then they can get a steam key for.

I know that but that’s not really steam’s fault?

Whos fault it is is irrelevant. If you have effective monopolistic power you are effectively a monopoly. If you abuse that power then that is bad. Does not really matter if you got there because you mostly do things people like or bully your way there. If you abuse the power that is still bad. And they could arguably be abusing that power against game devs by setting a fixed 30% fee with the devs not having much if any power to argue for less.

Not sure I’m understanding this but… how do you explain when we find in official retailers such as fanatical or humble same games at lower prices?

At least for humble store, they essentially sell steam keys. Which at least complicates that argument. So it is not really a different distribution channel and the product is available on steam for that price. Just not on the Steam store.

This I get, but couldn’t valve simply say: “Go to epic store if you want lower fees”?

Steam have an effective monopoly here. Even if they have that because all the other platforms are shit. So the argument for just going to another store doesn’t really help as that just causes a massive loss in the market share of who you can sell your game to. Plus if you consider the other requirements of if you sell on steam you cannot make your game cheaper via a different distribution method means that you have to eat that feeling and cannot pass it on to customers. Which does not give game Devs much power to negotiate for a lower fee at all.

There has been some noise about the state of accessibility in Linux last year. Seems that things are improving and the Devs of major DEs are taking things more seriously. From a more recent blog post on the topic:

Developers Are Rising to the Challenge

Here’s the good news: I’ve talked to developers from GNOME, KDE, and Fedora.

They get it. And they’re taking it seriously.

GNOME’s Wayland session is now stable and usable with Orca. KDE is catching up — and has a legally blind developer leading accessibility improvements. COSMIC is building Wayland from scratch with accessibility and global hotkey support in mind. For once, accessibility isn’t just a postscript. It’s in the room where design happens.

This transition is happening — but we’re not being ignored anymore.

https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-doesnt-love-me-back-post-4-wayland-is-growing-up-and-now-we-dont-have-a-choice/

The other posts in that series gives a good overview of previous things as well. Seems that author has been successful in raising awareness about the subject which hopefully will help improve things.

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.

Upgrades is any security or big fix as well. Those tend to be quite safe in point release distros. Upgrading to a new point release version is has all the same problems the rolling release had over the same period all bundle in one messy upgrade (which makes them a huge pain to deal with as they often compound). But between those, the patch upgrades tend to be quite smooth.

I would say the over a longer time period rolling release break in bigger way less often. But they tend to have more but smaller breakages that are easy to trivial to fix.

Less chance of an update breaking things. Lots of small and frequent updates, instead of rare and large update packs/stacks.

I would say a rolling distro update has a higher chance of it breaking something. Each one might bring in a new major version of something that has breaking changes in it. But that breakage is typically easier to fix and less of a problem.

Point release distros tend to bundle up all their breakages between major versions so breaks loads of things at once. And that IMO can be more of a hassle then dealing with them one at a time as they come out.

I tended to find I needed to reinstall point release distros instead of upgrading them as it was less hassle. Which is still more disruptive then fixing small issues over time as the crop up.

It has an LTS kernel. Not a separate version. This does not make everything LTS. This is very different from LTS distros.

It is not just about your pc hardware. I much prefer running the latest software on it as I regularly use features from tools added in the last version of something. I would hate to have to wait 6 months to a year to be able to use new features that make my life easier. That might not be every bit of software I use but enough core things that I would notice.

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.

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.

I was not trying to brush away the differences for GPL 2 vs 3. My point was just that I don’t think a more permissive license on Coreutils would have caused every company to want to steal the code, get everyone using it and force out the GPLed version. But a more restrictive license (say one that infects other binaries on the system) would have meant fewer companies using it and thus fewer distros and everyone else using it.

But for other projects the balance is different and a more permissive license would cause issues. There are some projects that even the GPLv2 or even v3 is too permissive for.

sudo is not GPL3. It is not even GPL2. It is an old license that is just as permissive as the MIT license. It has never had any big problems with that being the case. I don’t think that coreutils being GPL has really done anything to force companies to contribute back to it. It is mostly fixed in its function and does not really have much room for companies taking and modifying it to a point where others will favor the closed version over the open on. And what it provides is fairly trivial functions overall that if someone did want to take part of it then it is not terribly hard to rewrite it from scratch.

GNU Coreutils is not the only implementation of those POSIX features - just the most popular one. FreeBSD has its own, there is busybox, the rust ports and loads of other rewrites of the same functionality to various degrees. None of that really matters though as they dont really add much if any value to what coreutils provides as there is just not that much more value to add to these utilities now.

And it is not like the GPL license of coreutils affects other binaries on the system. So if you dont need to modify it and it does not infect other things there is little point in trying to take it over or use an alternative.

MacOS does not use a later version because they cannot. But also they don’t care enough to even try to maintain their own.

GPL is important on other larger/more complex bits of software. But on coreutils/sudo IMO it does not matter nearly as much as people think it does.

Core Android and ChromOS don’t need to be FOSS because they use the GPL. You can use the Linux kernel without having to make everything that runs on it GPL as well. Things that run on the kernel are not derivative works of the kernel. These projects are FOSS because google at the time thought it would give them an advantage to make the FOSS.

If you add too many restrictions to a license it does not force companies to give their stuff away for free, it just means they wont use your project which can drastically stunt the growth of your project. If Linux had a more restrictive license to start with all that would of happened is no one would have heard of it today as companies would have created something else that they can use.

There is no one size fits all safest option. Details matter and each project needs to read the licenses and decide on which suits their needs best.

MIT is probably the safest option for a company creating a library wrapping their service where there is no real value in others taking that code. Or for simpler libraries that are fairly easy to reproduce so the need to steal the code is low. Or you just don’t care what others do with the code.

GPL is probably safest for some hobbies that does not care about companies and just wants everyone that is using their project to not bake it into a product they distribute. But also means companies likely wont want to use your project if it is a library.

LGPL might be a good option for library code if you want other companies to use and contribute back to some complex library you are using that is hard to reproduce in isolation.

Other licenses are needed if you want to prevent other hosted services from using your project without contributing back.

Different licenses exist for different reasons and it all depends on what you want for your project.

I don’t think there is a good license for that. The ones MongoDB used turned the open source community against them. But that is not really my point. I just mean that some projects using MIT won’t suddenly mean every company will start stealing and closing that software. Some things like coreutils and sudo just don’t have the commercial value to make that worth the effort. So there is no real need to worry about these two projects IMO. Other projects are a different story altogether though. Each project needs to make its own decision on what licence best suits it. The GPL is not the one and only license that is worth using.

Coreutils has little commercial value to take can create a proprietary fork of. There is little value that can be added to it to make it worthwhile. The same is for sudo - which has had a permissive licence from the start. In all that time no one has cared enough to fork it for profit.

Not saying that is true of every project. But at the same time even GPL software has issues with large companies profiting off it and not contributing back. Since unless you are distributing binaries the GPL does not force you to do anything really. See mongodb and their move to even more restrictive licences.

The GPL is not the only thing that stops companies from taking open software. Nor does it fully protect against that.

Not does everything need to be GPL. It makes sense for some projects and less sense for others. Especially libraries as that basically forces no company from using them for anything. Which is also not what you want from a library.

You can profit from GPL software. The only restriction is if you distribute it you also need to distribute modifications under the GPL.

GPL also does nothing for software as a service since it is never distributed.

GPL even explicitly allows selling GPL software. This is effectively what redhat do. They just need to distribute the source to those that they sell it to.