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.

Sounds like a stuck button. Personally I would disassembly the device and have a look at the button and surrounding parts for any damage or liquid or debris at all. If there is any physical damage then an RMA or maybe replacement parts can be ordered (like you can buy replacement rubber if that feels worn at all). Otherwise I would ensure everything is clean and free of and liquids, stickiness or debris then reassemble the device. Even if nothing looked wrong I would test it again and see if the act of disassembly did something to solve the issue which it sometimes does for things.

IFixit has guides for the LCD and OLED versions and overall the steam deck is not very hard to disassemble compared to other small electronics. Though if you are unsure about this you may just want to talk to valve support first. If you accidentally damage something that could affect your ability to get an RMA.

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.

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.

The Linux directory system is a single tree from the root /. You can mount any filesystem to any directory inside it to extend it and have all writes to that location be handled by that FS. This is all irrespective of what filesystem the is present at that location in the tree. It does not matter if it is BTRFS, ext4 or anything else mounting a filesystem into the directory structure is handled by the kernel separately from the FS implementation. So, yes, you can mount any partition that contains a filesystem to /home/user no matter what you have done with / or even /home.

But, any writes to that location will be handled by the filesystem driver for that partition. So any subvolumes or anything else the main filesystem/partition has wont be available inside that directory. You can have a BTRFS filesystem mounted there from a separate partition if you want. Though a big benefit of BTRFS is the ability to use subvolumes instead of full partitions so you are not segregating the space on the disk (ie, any subvolume can use what space it requires and you wont have one running out of space because you didn't make it large enough). So if you are going for BTRFS subvolumes I would just have one main partition and use subvolumes to split up the space if you wish. Though really the only benefit to that is you can snapshot them separately and I think you can set different quotas and settings on each one.

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.

Best to not think of files as modules. Instead a rust crate is just a tree of modules with the src/main.rs or src/lib.rs being the main entry point.

Inside these files you define the module structure you want like:

mod foo {
    mod bar {}
}

This creates two modules, crate::foo and crate::foo::bar. Now, because you don't want to have all your code in main.rs/lib.rs rust lets you move the module contents to separate files. But the location of the file needs to match its location in the module structure - from the crates root (not the file it was declared in).

So when you call mod foo; from src/main.rs it will look for src/foo.rs or src/foo/mod.rs (and you can only have one of these). And the foo::bar - no matter if that is declared in src/main.rs (as above) or inside src/foo.rs or src/foo/mod.rs, it will always look for the bar module contents inside src/foo/bar.rs or src/foo/bar/mod.rs as it is nested inside the foo module - not because the file is next to the current one.

This means if you had this inside main.rs/lib.rs:

mod foo {
    mod bar {
        mod baz;
    }
}

Then it will look for the baz module contents inside src/foo/bar/baz.rs or src/foo/bar/baz/mod.rs - even though those might be the only two files you have.

There was that time where one dev broke the internet by deleting one simple NPM package.

Or the thousands of malicious packages that are removed every year?.

The node_modues dir also becomes massive as it needs to download hundreds of repos including readmes, tests, and other cruft for what is often only a few lines of code. And it used to need to download the same libraries many times for every dependency that needed to use it (not as big a problem now that they are flattened by NPM first).

The node_modules dir also breaks sometimes needing you to just delete and recreate it.

It automatically runs install scripts when you download a package (and all it's dependencies) by default which breaks a lot of packages if you disable them.

It has improved over the years and some of these are no longer issues, but they have all contributed towards people's dislike for NPM. The overall idea for having a file tell you what deps are needed and to download those deps is not a NPM exclusive idea and most if not all modern languages do the same thing. Even older languages have started to adopt similar tooling. Some share some of the issues NPM has, though others have improvements over it as well.

But these are developer tools design for developers and build systems to use. Not really ideal for end users. Especially for compiled language. But even for NPM, you don't want to be shipping a full node_modules dir to all your end users nor do you want them to have to install your language tooling every time. It be more ok for developers that are already working in the language or sysadmins deploying to a server, but for the average desktop user it is not a good experience.

Or?

That latter case likely wont be copyrightable, but the former can start to meet this criteria mentioned in the article:

An application for a work created with the help of AI can support a copyright claim if a human “selected or arranged” it in a “sufficiently creative way that the resulting work constitutes an original work of authorship,” it said.

The way I read that, the more instruction you give to the composition of the image (ie, how detailed and descriptive you are with your prompt) the better claim you would have to copyrighting the resultant work.

I think the mistake lots of people are making is that all AI generated art is the same and should all be treated the same. Which is likely not going to be the case. And Copyright rulings are mostly done on a case by case bases, unless there is significant change this will likely still hold true and so one ruling on some AI generated art might not result in the same ruling for a different piece created in a different way with different effort.

What this case shot down is the claim that AI can claim copyright on a works as an AI is not human and copyright only applies to humans. Which is the same stance courts have tend before with content created by animals.

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.