Maskawanian

At least with Samba you can use the "veto files" and "delete veto files" global directives to deal with those, I personally use the following for veto files:

    /._*/.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/.@__qini/.Qsync/.@upload_cache/.qsync/.qsync_sn/.@qsys/.digest/

Tearing and hidpi is why I left Linux for Windows between 2012 ans 2022. Once wayland was good enough I returned. Tearing is awful, and should be opt in (which wayland provides), not opt out.

No, that's every bit of software out there. Dynamic linking really does cause that problem even though allegedly it has security benefits as the vendor is able to patch software vulnerabilities.

NixOS actually is a bit better in this respect since most things are statically linked. The only thing is that glibc is not because it specifically requires being dynamically linked.

This issue also applies to macOS with their Dylibs and also Windows with their DLLs. So saying that this is an issue with Linux is a bit disingenuous.

Until everybody standardizes on one singular executable format that doesn't ever change, this will forever be an issue.

I know you are trying to make a point about complexity, but that is literally what NixOS allows for.

There is always the analog hole. Even HDCP can be worked around. Even if they do manage to stop all computers from doing direct bit copies, there are still old things such as Kinescopes which they used to use to broadcast television from film. There of course is a quality loss, but that's kind of irrelevant to the point.

When you benchmarked Postgres did you disable WAL for the cache table? That may minimize the difference.

That isn't the same as vendor-izing unless you are committing node_modules to your VCS, which would be insane.

Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!

Absolute lies, where I live it is one party consent. I can still record with another device on speakerphone.

No, you are putting words into my mouth. Try to argue in good faith through understanding the other party's viewpoint before responding.

I don't see much difference between killing chicks after them being born, or stopping them from being born in the first place. The only difference is in the efficiency of business operations.

If my values are that each deserves a chance at a life--whatever life it may be, I can advocate for searching for a better solution. I did not prescribe an alternative, don't pretend that I have.

EDIT: Damn, the hostile responses (Ad hominem, bad faith arguments, etc) to such a simple philosophical discussion I've been getting are unbelievable. I don't think there is much value in participating anymore. Thank you everyone for your responses.

You could not be more wrong. Kde is the last vestige of interfaces are powerful, pretty, and that don't their users like idiots.

You have your GNOME and simmilar ilk, be content with that and leave KDE alone.

Their anti-DRM stance is arguably their only compelling feature as opposed to just buying steam.

I remember the old game launcher that was called Desura?, which a lot of those third-party keys sites would sell keys for, and it's no longer around. So one of the main concerns with these online platforms is them disappearing and losing all your stuff.

Quite frankly, I am happy that GOG exists for this niche. It would be less "sabotaging" if consumers would actually vote in their own interests. However, this has been shown time and time again to never happen, sadly.

I would assert that iChat evolved into messages. There are a few more icons that could be added in that category.

Can't wait until MacOS 95 (then Mac OS XP of course). I can only imagine the discourse if this happened 25 years ago.

It is bad form to engage in victim blaming. While yes, Unity has been pretty bad for a while, lots of times there is already a lot of development work sunk into existing programs. It would oftentimes sink the business switching engines rather than finishing up the existing project.

I assume your in the Netherlands? Hoi! How is the tech industry there, does it pay decently, and how difficult is it for someone overseas to apply?

Agreed, the only thing that is certain is that they are cheating themselves.

While it can be useful to use LLMs as a tutor if you're stuck. The moment that you use it to provide a solution, you stop learning and the tool becomes a required stepping stone.

Elbows up, Canada.

Yes, it would stop somebody's key from working, and that's the entire point, because most key fobs work on rolling ciphers, and if you block one, you can reuse it. Typically the fob will allow like 10 or so presses. It depends on the model before you're forced to re pair to the car. But by jamming it and capturing what it sent, you can then use that to get into the car.

Looks very nice, however it doesn't seem to support subsonic yet, which means no Android Auto integration through Ultrasonic.

I'm going to keep watch on this, there aren't many music players with interfaces that look that nice.

There was employee communication that expressed it being odd to use a torrent client on company computers. [1]

[1] https://timesofindia.indiatimes.com/technology/tech-news/whe...

Nah, you made an absolute statement that MQTT was insecure, that was demonstrated to be incorrect. If HTTP can be made secure by relying on a secure transport, then MQTT can as well.

Additionally, MQTT does allow for authentication. I've personally set up brokers many times that will not allow anonymous connections.

Misconfiguration of services, does not constitute an error in the protocol itself.

MQTT is not inherently insecure. Much like HTTP, there is a encrypted version that runs on port 8883.

It certainly has an optimized kernel for its use case. I believe it also includes ZFS by default. I wouldn't be surprised if the Proxmox developers would prefer to upstream these defaults, but they likely would introduce regressions for the common use case that Debian optimizes for.

Ultimately, I use Proxmox as a hardware hypervisor only, so I don't mind that it uses its own kernel. Everything I run is in its own VM, with its own kernel that is setup the way I want.

You think they are, but you have to trust that this happens. And even if they are, what happens if the grid is offline and comes online while the inverter is operational, how long does it take, if it does at all, to adjust itself.

If the product doesn't explicitly state this on its packaging there is absolutely a chance for competing sine waves. If this wasn't the case, transfer switches wouldn't have been invented. The original comment I replied to is simply dangerous.

If the sine waves don't line up, you are in for a very bad time. There is a reason crossover switches exist, please never do this.

I put a lot of the blame here on Windows and its persistent refusal to implement a decent way to uninstall programs without using a vendor-provided binary/script.

While the install & uninstall process certainly be criticized. The fact remains that the uninstall script is made by Adobe. They deserve credit for all dark patterns that script contains.

Other systems have similarly opaque places where configuration can be left. Look at dot file structures, gconf, et al. on linux. As well as Preferences, extensions, input managers, Library folders on Mac.

Until we get a system that is entirely containerized, this will continue to be an issue.

We should probably keep the focus on Adobe lest we distract from their bad practices.

Google has had pretty serious privacy guards in place, where if you don't want Google to collect info on you (for advertising), they won't.

How do we know this? They may claim this, however their incentives as an advertising company would provide strong pressure against this.

Canonical is Ubuntu not Debian.

How would you be able to ensure you that? Even if say, Zoom itself wasn't recording, you can run OBS in the background.

Trust runs both ways.