- Put the gear in neutral (This prevents the car from trying to move when you turn the engine on)
- Press the clutch and the break fully (Same as above, also some cars won't turn on unless you fully press the clutch)
- Turn engine on
- Remove hand break
- Put car in first (or reverse)
- Slowly release the clutch until you feel the car is stable (this is not needed if the street is not inclined, or is inclined in the direction you want to go)
- Release the break
- Slowly release the clutch while slowly pressing the accelerator
Nibodhika
This will be almost impossible. The short answer is that those pictures might be 95% similar but their binary data might be 100% different.
Long answer:
Images are essentially a long list of pixels, each pixel is 3 numbers for Red, Green and Blue (and optionally Alpha if you're dealing with a transparent image, but you're talking pictures so I'll ignore that). This is a simple but very stupid way to store the data of an image, because it's very likely that the image will use the same color in multiple places, so you can instead list all of the colors a image uses, and then represent the pixels as the number in that list, this makes images occupy a LOT less space. Some formats add to that, because your eye can't see the difference between two very close colors, they group all colors that are similar into one only color, making their list of colors used on the image WAY smaller, thus having the entire image be a LOT more compressed (but you might noticed we lost information in this step). Because of this it's possible that one image choose color X in position Y, while the other choose Z in position W, the binaries are now completely different, but an image comparison tool can tell you that color X and Z are similar enough to be the same, and they account for a given percentage of the image depending on the amount minimum of the values Y and W. But outside of image software, nothing else knows that these two completely different binaries are the same. If you hadn't loss data by compressing get images in the first place you could theoretically use data from different images to compress (but the results wouldn't be great, since even uncompressed images won't be as similar as you think), but images can be compressed a LOT more by losing unimportant data so the tradeoffs are not worth it, which is why JPEG is so ubiquitous nowadays.
All of that being said, a compression algorithm specifically designed for images could take advantage of this, but no general purpose compression can, and it's unlikely someone went to the trouble of building a compression for this specific case, when each image is already compressed there's little to be gained by writing something that takes colors from multiple images in consideration, needing to decide if an image is similar enough to be bundled in together with that group or not, etc. This is an interesting question, and I wouldn't br surprised to know that Google has one such algorithm to store all images you snap together that it can already know will be sequential. But for home NAS I think it's unlikely you'll find something.
Besides all of this, storage is cheap, just buy an extra disk and move over some files there, that's likely to be your best way forward anyways.
I didn't understood your criticism, what are they unwilling to release? What are they claiming all of? Why would ownership rules cause an OOM?
Sharing stack memory is a bad practice in C as well btw.
I just got to work and plugged my surface pro into my external monitor. It didn't switch inputs immediately, and I thought "Linux would have done that". But would it?
Nope. My laptop for example doesn't automatically use an output when plugged in, but that doesn't bother me because I know other DEs would do that, and it's my choice of having a minimal window manager that causes that.
And this goes into your next point, because I know that this comes from decisions I made, I'm okay with that. I also know I could probably fix it somehow, even if just by running a script in the background that checks if an output is plugged and tries to use it.
And for me that's the big difference. As a general rule when things break or don't work are not the fault of Linux as a general, but of a specific piece of the stack, and more often than not it's because that piece was backwards engineered without any help from the manufacturers of the hardware it's meant to be controlling, so I can be very tolerant of these errors since the bad guys here are the third-party who's refusing to make their things work on Linux. But even things that don't work as I want to, I can make them do so, and that's a huge change in viewpoint.
In other words, on Windows I used to be of the thought of things you can do, and things you can't, with time I noticed that in Linux this thought shifted, to the point that the only question I ever ask myself is: "HOW do I do this?". This implies that there are no impossible things in Linux, which is obviously false, but I would argue that the correct way to think about this is "things that are impossible on Linux, for now", and that's a huge difference, because Linux is always evolving and getting better and better, things you thought are impossible now might be trivial in a few months or years whenever someone with the knowledge to fix it gets bothered with it.
First of all you're missing the point.
Drivers are automatic during setup.
That still means third-party drivers, so it's still not a Windows win but rather a "windows is so ubiquitous that Logitech (or whoever) was forced to release a driver for it", which is what the comment you're replying was talking about.
Secondly, bullshit. In my 20 years using Linux I have never, ever, plugged in a mouse that didn't get immediately recognized and worked as expected. What mouse do you have? You said Logitech, which model? The only thing that I ever needed specialized software on a Logitech mouse was to configure extra buttons or to pair it to a different dongle (both stuffs that also need specialized software only provided by Logitech on Windows)
Data in Bitcoin is undeletable, it's impossible for any law to force anything from being deleted on Bitcoin. Then the same exceptions that apply there would apply to Lemmy since the technology is similar in the relevant aspects (besides deletion being theoretically possible on Lemmy).
As for Meta, the problem is that the data they're sharing is not public. Meta is not getting fined for sharing things you posted on your publicly, since they share those regardless by virtue of them existing and being publicly available, they're fined for sharing things you put privately or data derived from non publicly available sources such as how you interact with Meta.
Any information that a user willingly makes public can be processed in any way, even if it includes identifiable medical information (which is the biggest no-no of GDPR). It even has a specific point about it in 9.2.e
processing relates to personal data which are manifestly made public by the data subject;
Essentially saying you can process anything that was made public by the person. GDPR is to protect people from companies doing shady things, not to prevent people from themselves. Because EVERYTHING is public in Lemmy, all data in it has been manifestly made public by the person who created it.
Yup, you can buy the official dock or really any usb-C dock. Resolution can be set, so you can even do 4k on it if the tv supports it and the deck can handle it for that game
Still, the archival nature of decentralized communities is one of the primary objectives of the technology. It's arguably the defining feature of any decentralized thing that no one controls everything so things are meant to stay "forever". Otherwise Bitcoin would be completely ilegal since there's no way to delete information there.
What do you do if someone in the US refuses to delete and maybe gives you that argument about freedom of expression? That's right. You pay damages to your user because you screwed it up.
Not really, again, the text of the law states that if the information has been made public the company must inform whoever they made the data public to:
Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data.
AFAIK Lemmy federated deletions, whether an instance acts on it or not is another matter.
But GDPR doesn't work like you think, let me give you an example, say you sent an email from provider A to someone on provider B, then you decide to delete that email account, the email you sent will still be in provider B, even if company A deletes all of your information that email is still there and won't get deleted. This is fine with GDPR, otherwise no email provider could operate here. Same goes for other federated or decentralized technologies.
But it is a replacement for a console like I told the person I replied to.
Sorry, forgot about answering here. Although the name is General data it is about personal data. I was going to reply with point by point why it either doesn't apply to Lemmy or it follows GDPR, but I think it might be easier to answer directly your point about right to be forgotten.
First of all Lemmy allows you to delete your posts and user so it complies with it, but even if it didn't GEPR has this to say:
Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:
Paragraphs 1 and 2 are the right to be forgotten
for exercising the right of freedom of expression and information;
Which one could argue is public forum primary use
for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing;
Which again one could argue is part of the purpose of Lemmy as well.
Those are the usual problems in Linux, they can be summed up by "Third party companies don't support Linux", and they are especially annoying because with time you learn that there's no reason that thing shouldn't work, other than because the company either purposefully figures out if you're running Linux and crashes the program (e g. DRM, anti-cheat, etc) or because they created their own closed proprietary protocol and refuse to share the public API for it so it needs to be reverse engineered.
Nope, it's a terrible one. Everyone will be constantly looking for new jobs. And would do the bate minimum to not get fired, that's the contract you're signing, bare minimum pay for bare minimum work.
Regardless of what you do, it's likely that you'll need multiple times the amount of employees to get shit done, because one dedicated employee is worth several doing bare minimum, depending on the job some works simply won't happen because no one gets paid enough to do them.
Besides that you'll suffer brain drain, i.e. anyone good enough will leave you, and they won't accept a raise to stay because if someone offered them double their salary and you tried to match it they would immediately see the bullshit you'd put them through and know that the only way to get a better pay again would be to get a new offer from someplace else.
Anyone bad enough that other companies don't want would be stuck with you, but there's a reason other companies don't want them.
You wouldn't be able to pull any new talent, you'd get stuck just getting people no one else wants because they're the only ones willing to work for that low.