That's not true. It is possible. It is just a lot harder and more error prone and takes way longer to do then just reinstalling.

The only things not linked to cancer are the things not yet been studied. Seems like everything at some point has been linked to cancer.

The data showed that people who ate as little as one hot dog a day when it comes to processed meats had an 11% greater risk of type 2 diabetes and a 7% increased risk of colorectal cancer than those who didn’t eat any. And drinking the equivalent of about a 12-ounce soda per day was associated with an 8% increase in type 2 diabetes risk and a 2% increased risk of ischemic heart disease.

Sounds like a correlation... someone who eats one hot dog and drinks one soda per day is probably doing a lot of unhealthy things.

It’s also important to note that the studies included in the analysis were observational, meaning that the data can only show an association between eating habits and disease –– not prove that what people ate caused the disease.

Yup, that is what it is. A correlation. So overall not really worth the effort involved IMO. Not eating any processed meats at all is not likely a big issue, but your overall diet and amount of exercise/lifestyle. I would highly suspect that even if you did eat one hotdog per day, but had a otherwise perfect diet for the rest of the day and did plenty of exercise, got good sleep and all the other things we know are good for you then these negative effects would likely becomes negligible. But who the hell is going to do that? That's the problem with these observational studies - you cannot really tease out the effect of one thing out of a whole bad lifestyle.

I hate headlines like this as it makes it sounds like you can just do thins one simple thing and get massive beneficial effects. You cannot. You need to change a whole bunch of things to see the types of reduction in risk they always talk about. Instead they always make it sounds like if you have even one hot dog YOU ARE GOING TO DIE.

Just? This is a link to the last page of the benchmarks. The other pages have other workloads on them - quite a lot of DB benchmarks though.

I have updated arch systems that had not been powered on for years before. It was fine. No issues what so ever. Arch is not some flaky distro that breaks if you look away for a minute. My main system has had had the same install for over 5 years now and I regularly forget to update it for months at a time. Again, no issues.

cargo add <dep> is a relatively new command. For a long time you had to edit the Cargo.toml file to add a new dependency. So a lot of tutorials still use that as a way of adding a dependency. And other guides often copy from the older ones. They also can describe it this way as a way to introduce the Cargo.toml structure since it is not hard to hand edit. cargo add is just a convenience after all and it is still worth understanding the Cargo.toml structure.

But yes, many people do use cargo add for simply adding deps rather than editing the toml file. Though it is not uncommon to edit it by hand either.

They can write good short bits of code. But they also often produce bad and even incorrect code. I find it more effort to read and debug its code then just writing it myself to begin with the vast majority of the time and find overall it just wastes more of my time overall.

Maybe in a couple of years they might be good enough. But it looks like their growth is starting to flatten off so it is up for debate as to if they will get there in that time.

Closed source drivers are not really the issue. But competing graphics APIs are. With the move to Wayland open graphics drivers were updated to support the GBM graphics API which if one window manager wants to support then it gains support for all graphics drivers that use that api. But nvidia created its own api, eglstreams that to support required all window managers to write extra code for. Some refused to do that or took a long time to do.which gave shoddy nvidia support.

Some did support nvidia slowly, but then nvidia also switched to support the same api as everyone else (poorly at first but I assume it has improved over the years). Nvidia have also partly released their drivers as open source which has also helped.

But it happens all the time with other languages. Especially when that language is newer or in the headlines. NodeJS/Electron was a big one a few years ago. Ruby/On Rails a while before that, have seen it for python programs and way back in the day when java was all the rage.

Personally I think it does matter and as a end user I do care to come degree. It tells you some things about the program, like how it can be install/run what deps you might need, is it going to be a memory hog or possibly full of vulnerabilities. The language affects all of these things, more so when the projects are new or niche and have not been hardened over time or been properly packaged yet.

Personally I love it when a program is written in languages like rust or go as it means I know it is going to be easy to build/install and distribute given they build into single binaries and very easy to make static. But if I see one written in nodejs with electron I am disappointed as I know it is going to be a huge package that consumes large amounts of memory. Or if there is some python package that is not already packaged by my distro I would avoid it as I hate dealing with python dependencies and its virtualenvs.

And for this case, with redox. Well redox is not an application to be used by people. It is a showcase about what can be done in the language. It is not intended for most people that hear of it to ever run it or even want to run it. Yet is very impressive what they have managed to do in it. Including having parts written for it be able to work standalone in Linux and other OSs.

Add it to his list of crimes. Though, fairly likely embezzlement is already on there.

Yes it was. Though he did use faster SSD drives rather then cheaper and slower flash drives. Which is something reasonable to do IMO. He also tested various network transfer methods to use the fastest one and transferred unique data to each drive rather then just uploading the same file over and over giving both sides a fair but also their best shot at working.

Snaps is just the latest controversial tech they haved pushed for. They have a long history of pushing for things they have created that people don't want or don't want their implementation of (like upstart or the original unity desktop env). Or pushing for stuff before it is ready (like pulseaudio).

Nothing wrong with pushing for your own tech, but they do seem to miss the mark a lot on what they want to introduce. And keep upsetting the community over it.

Only when needed. And I don't really use aliases at all for basic things like that. I don't like things like cp or mv being verbose most of the time as I don't have much use for their output and like it when commands are quite unless there is a problem as it makes it easier to see the error lines. I don't really want to be confirming every file in a recursive rm or cp or mv either - just leads to hitting y automatically and not thinking about it. I do like how zsh warns you about rm * though with the directory you are about to remove though.