It’s mostly better, but not in every way. It has a lot of useful features, at a performance cost sometimes. A cost that historically wasn’t a problem with spinning hard drives and relatively slow SATA SSDs but will show up more on really fast NVMes.
The snapshots, it has to keep track of what’s been modified. Depending on the block size, an update of just a couple bytes can end up as a few 4k write because it’s Copy-on-Write and it has to update a journal and it has to update the block list of the file. But at the same time, copying a 50GB file is instantaneous on btrfs because of the same CoW feature. Most people find the snapshots more useful than eeking out every last bit of performance out of your drive.
Even ZFS, often considered to be the gold standard of filesystems, is actually kinda slow. But its purpose isn’t to be the fastest, its purpose is throwing an array of 200 drives at it and trusting it to protect you even against some media degradation and random bit flips in your storage with regular scrubs.
Precisely. It’s not just “it works”, it’s third-party hardware that Canonical tests, certifies and commits to support as fully compatible. They’ll do the work to make sure everything works perfectly, not just when upstream gets around to it. They’ll patch whatever is necessary to make it work. The use case is “we bought 500 laptops from Dell and we’re getting a support contract from Canonical that Ubuntu will run flawlessly on it for the next 5 years minimum”.
Otherwise, most Linux OEMs just focus on first party support for their own hardware. They all support at least one distro where they ensure their hardware runs. Some may or may not also have enterprise support where they commit to supporting the hardware for X years, but for an end user, it just doesn’t matter. As a user, if an update breaks your WiFi, you revert and it’s okay. If you have 500 laptops and an update breaks WiFi, you want someone to be responsible for fixing it and producing a Root Cause Analysis to justify the downtime, lost business and whatnot.
What Bluetooth controllers are you using? Is the Linux/Windows machine the same machine?
Not all bluetooth cheaps are equal. My phone will do Bluetooth all the way at the end of my back yard, but my desktop’s Bluetooth doesn’t even reliably reach the next room over.
I doubt it’s the headset, unless it’s defective and you need a replacement, those are pretty well regarded. I have a cheaper model and it’s been a flawless experience for years.
and then it will reach out to other instances to grab content from every external community that at least one local user has subscribed to
It’s the other way around. The local user subscribes to the community on the remote instance, which causes the remote instance to then push you every action that occurs on that community as it happens. The pull method is only used once and doesn’t bring in comments, it’s meant as a preview for when a remote community is used for the first time.
And this is why their content won’t make it to your instance: it expects the other instance to send it to you, but they’re refusing to. Similarly, they won’t accept content from your instance, even though it’s trying to.
Local and remote communities are pretty similar internally, federation happens as a separate process in a queue system.
This leads to this:
you can still subscribe to subs on defederated instances, it’s just the interactions that don’t get passed back and forth.
It still leads to unsolvable problems like, what is expected when two instances federate content with eachother? What if you use a web app to use a third party instance and it spits out unsanitized data?
If you assume it’s part of the API contract, then an evil instance can send you unescaped content and you got an exploit. If you escape it you’ll double escape it from well behaved instances. This applies to apps too: now if Voyager for example starts expecting pre-sanitized data from the API, and it makes an API call to an evil instance that doesn’t? Bam, you’ve got yourself potential XSS. There’s nothing they can do to prevent it. Either it’s inherently unsafe, or safe but will double-escape.
You end up making more vulnerabilities through edge cases than you solve by doing that. Now all an attacker needs to do is find a way to trick you into thinking they have sanitized data when it’s not.
The only safe transport for user data is raw. You can never assume any user/remote input is pre-sanitized. Apps, even web ones, shouldn’t assume the data is sanitized, they should sanitize it themselves because only then you can guarantee that it will come out correctly, and safely.
This would only work if you own both the server and the UI that serves it. It immediately falls apart when you don’t control the entire pipeline from submission to display, and on the fediverse with third party clients and apps and instances, you inherently can’t trust anything.
Because then you need to take care everywhere to decode it as needed and also make sure you never double-encode it.
For example, do other servers receive it pre-encoded? What if the remote instance doesn’t do that, how do you ensure what other instances send you is already encoded correctly? Do you just encode whatever you receive, at risk of double encoding it? And generally, what about use cases where you don’t need it, like mobile apps?
Data should be transformed where it needs it, otherwise you always add risks of messing it up, which is exactly what we’re seeing. That encoding is reversible, but then it’s hard to know how many times it may have been encoded. For example, if I type & which is already an entity, do you detect that and decode it even though I never intended to because I’m posting an HTML snippet?
Right now it’s so broken that if you edit a post, you get an editor… with escaped HTML entities. What happens if you save your post after that? It’s double encoded! Now everyone and every app has to make sure to decode HTML entities and it leads to more bugs.
There is exactly one place where it needs to encode, and that’s in web clients, more precisely, when it’s being displayed as HTML. That’s where it should be encoded. Mobile apps don’t care they don’t even render HTML to begin with. Bots and most things using the API don’t care. They shouldn’t have to care because it may be rendered as HTML somewhere. It just creates more bugs and more work for pretty much everyone involved. It sucks.
Now we have an even worse problem is that we don’t know what post is encoded which way, so once 0.19 rolls out and there’s version mismatches it’s going to be a shitshow and may very well lead to another XSS incident.
I think 0.19 is reverting that behaviour, because it was indeed a certified bad idea.
I think the idea was to attempt to bulletproof potentially crappy clients especially after the XSS incident, but the problem is it’s simply not even always rendered in a web context which makes the processing kind of a pain.
Wouldn’t surprise me if it becomes double and triple encoded too at times because of the federation. Do you encode again or trust that the remote sent you urlencoded data already?
Best format is the original format and transform as late as possible, ideally in clients where there’s awareness of what characters are special. It is in web, not so much in an Android or terminal app.
I don’t think the Lemmy devs are particularly experienced web developers in general. There’s been a fair amount of dubious API design decisions like passing auth as a GET parameter… Thankfully they also fixed that one in 0.19.
There will be loss in the process so you should go a little above. You also need to account for the efficiency curve of your power supply: is it best efficient at 80% load? 90% load? Can it handle 120% momentarily in case of a spike?
CV power supplies are the standard: constant voltage. It outputs say 12V, and trips when overcurrent. A CC supply would limit current to say, 20A. It does so by dynamically adjusting the voltage output to match that target. That’s a lot less common and usually used for battery charging or testing/troubleshooting. So, I guess, don’t plug it on a battery charger.
It should come with specs as to what input it can take. Follow the recommendations. If it says DC give it DC unless you’re absolutely sure of the circuit in there. The presence of a rectifier and caps doesn’t tell you much given it’s an amplifier, it could be part of the amp circuit for the MOSFETs and not its power supply.
My instance exists for me and my friends to use. It’s not meant to attract anybody, it’s meant to serve me.
It costs me nothing and I’m permanently in control of my data, and it’ll live however long I want it to live, it updates when I decide I want to update it, if I want features I can just patch them in. When I make a PR, it goes on my instance first to try it out properly. I can post 10GB files from my instance if I want to, I’m the one that will pay for the bandwidth in the end.
I bet if you look at the profile of the admin of those “abandoned” instances, you’ll find they’re active on Lemmy. They just have their own private instance just for themselves.
Doesn’t matter if lemmy.world or lemmy.ml or beehaw.org goes down: I still got all the content and they’ll eventually federate out when they come back up.
First step would probably be to decouple healthcare from being company, so people realize how expensive their health plans are and how much they pay for stuff most people don't end up needing. Pretty sure for most people it's more expensive than their single yearly checkup would be out of pocket.
Then, make state-wide and state-owned insurance plans that are capped in profits, so the rates have to match the true cost of things.
Let it simmer for a bit, get people to get used to the idea that the government provided service is actually good and cheaper for once.
Then make it mandatory for every state resident to be covered by it.
The big problem with universal healthcare in the US is the strong individualistic mindset, those that go "but I don't want to pay for other people's hospital bills". Ease all those people that think they'll suddenly be paying way more to subsidize other people's health care into realizing it ends up cheaper because the costs are amortized over way more people. It needs to be spun up as a benefit to them, they're getting a better deal on their health insurance. Because they simply don't care about other people's problems.
One thing that struck me living in the US is just how much distrust there is for anything government operated, even though it's usually the companies they love so much that nickel and dime them. Although seeing how the politics are going right now, I kind of understand that sentiment. And pretty much every company does try to squeeze you out of your money, which makes people want to screw the companies over. Land of the fees.
Apart from Debian, I guess Alpine. It's quite popular in containers for its small size. Even Arch will be much bigger in that case because the packages are much less granular and install development libraries and headers for about everything.
So, it'll still take a little while before it settles down, but I've seen other people in the admin chat do the same thing and it eventually recovered.
As for the subscriptions, part of the problem is the remote instance thinks you're already subscribed. I think if you unsubscribe and resubscribe it may go through, but you may also just need to use a new account name.