I just replied to the other person’s comment.
I just replied to the other person’s comment.
I don’t. Could you elaborate?
While Linux itself isn’t proprietary, it supports loading proprietary firmware/microcode blobs and running on proprietary hardware. Thus, part of the Linux hardware/software stack is proprietary.
I’m surprised that other people are surprised that for-profit companies constantly try to increase their profits; such companies only contribute to FOSS when that’s more profitable than the alternative. The Linux kernel, AMDGPU, Steam, etc only exist because some part of the software/hardware stack is proprietary (which becomes a more attractive product as the FOSS portion of the stack improves).
I’m definitely not justifying the “rug-pulling”, but people need to stop supporting projects with no potential for long-term profitability unless those projects can survive without any support from for-profit companies. Anything else is destined to fail.
Maybe I’m Jia Tan 😉
I’d love yearly Debian releases instead of just every 2 years.
The data block would be modified but the signature of that block can’t be recomputed without the key used to sign it
Isn’t that also true of an encrypted checksum, though? For some plaintext block q there is a checksum r, but the attacker can only see and modify the encrypted q (Q) and encrypted r (R). How any change to Q would modify q (and R to r) can’t be known without knowing the encryption key, but the attacker would need to know that in order to keep q and r consistent.
I’m not a cryptographer (so maybe this is wrong), but my understanding is that although it’s possible to modify the cipher text, how those changes modify the plaintext are very difficult (or impossible) to predict. That can still be an attack vector if the attacker knows the structure of the plaintext (or just want to break something), but since the checksum is also encrypted, the chances that both the original file and checksum could be kept consistent after cipher text modification is basically zero.
In exchange, FF uses Google search by default. So they’re also getting direct value from the deal.
I vaguely remember the advice actually being to leave it running but disconnect it from the internet. Although maybe hard disconnect the backups if you can.
…Because no one else wants to write my documentation.
There was a thread about that on c/selfhosted a few weeks ago. Created by a particular wild-cat-inspired sysadmin, I might add.
But on a more serious note, the interactions between a sysadmin and their servers (that they have enough responsibility for to be able to name) are much more intimate than the interactions between a dev and their variables. The server names also exist in a much larger namespace, so they need to be more unique.
Customers have more power than companies would like you to believe. Politely explain the situation to customer support, and ask for a refund. If they refuse, mention that you purchased a game that was promised to work for at least several months, and you haven’t received the product you paid for. Because of that, you’re considering charging back through your bank. If that doesn’t work, say you’ll charge back if they don’t refund. If that doesn’t work, actually charge back through your bank. Banks are surprisingly cool about it as long as you don’t do it too often. Of course, you need to buy the game directly (no account balance) from a credit card.
Just don’t be a jerk to the support person, because it’s almost certainly not their fault. It’s also less likely to get you what you want. They’d rather give you what you want so you go away, and you just need to give them reasons that they can relay to their supervisor if necessary.
deleted by creator
Because you’re generic and everyone’s initialized you at some point
Does anyone else prefer no MOTD? You can SSH into your server without clobbering your scroll back buffer. It makes everything feel more seamless.
Stop pinging yourself, stop pinging yourself!
Just connecting to the internet on various networks can be confusing. And they’re going to need to periodically upgrade system packages, or they’ll be vulnerable to various exploits. Even if you set up auto-upgrades, occasionally some things will need manual intervention.
Not all FOSS projects need to be profitable to survive. IOW if a project cannot survive without being profitable and it cannot be profitable long-term, then it cannot survive long-term.