Pup Biru

right? like yeah i remember XMPP being cool n all, but all the experiences suuuuucked, not to mention (back in the day… i think its fixed now?) figuring out how the hell to get video calling working… “what extension does your client support?” is not a question a lay-person will ask: centralised systems don’t have extensions… they have “the way it’s done” and that’s it

inefficient in the sense that

• traffic go over the internet rather than internal networks which means the routing is much longer, over slower links
• not to mention that in distributed systems information frequently is duplicated many times rather than referenced on some internal system (sending out an email to 20 people duplicates that email 20 times across many providers rather than simply referencing an internal ID… you can just centralise content and send out a small notification message, but that’s generally not what people are talking about when they’re talking about modern distributed systems)
• each system can’t trust any other, so there’s a lot more processing that each node has to do in order to maintain a consistent internal state: validating and transforming raw data for itself - not usually a particularly big task, but multiplied by millions per second it adds up fast
• hardware scaling is simply not as easy either… with centralised systems you have, say, 1000 servers at 95% capacity (whatever that means): you can run them close to capacity because your traffic is generally insulated from load spikes due to volume, and generally you wouldn’t get 5% more load faster than you can scale up another server. in distributed systems (or rather smaller systems, because that’s implicit here unless you’re just running the hardware and software to duplicate the whole network, which would take more servers anyway due to the other inefficiencies and now you’re multiplying them) you need to have much more “room to breathe” to absorb load spikes
• things like spares and redundancy for outage mitigations also become more expensive: if you have 1000 servers, having a couple of hot spares (either parts or entire systems depending on system architecture and uptime requirements) isn’t that big of a deal but in a distributed system you probably need those hot spares, but all of a sudden every instance needs those hot spares somewhere (though this can be seen as a similar issue to traffic issue: spares of all kinds are just unused capacity, so the higher your ratio the more under-utilised your hardware)
• this is all without getting into the human effort of building systems… instance owners all need to manage their infrastructure which means that the mechanisms to handle things like upgrade without downtime, scaling, spam protection, bots, etc have all been built many many times

NONE of this is to say that they’re worse. in many ways the have a lot of advantages, but it’s not a clear-cut win in a lot of cases either… as with most things in life “it depends”. distributed systems are resistant to whole-network outages (at the expense of many more partial network outages), they’re resistant to censorship, they implicitly have a machine to machine interface, so the network as a whole is implicitly automatable (that might be a bad thing for things like spam, privacy, bots, etc), but people tend to generally be pro-bots and pro-3rd party apps

Having a unique password per device is best practices.

yup that’s all i’m getting at… this vacuum has unprotected access to ADB, which another user likened to root access, and i just think that in circumstances that are root-like, even physical access shouldn’t grant unprotected root

this seems needlessly combative… prevailing opinions are exactly as signal says… think differently? great! let’s do it, talk about it, see how it goes, and when the solution has scaled in the real world to what it’s competing against then you can feel superior as the one that had the vision to see it

but scaling is hard, and distributed tech is hugely inefficient

there are so many unknowns

anyone can follow a random “getting stared with web framework X” guide to make a twitter clone… making a twitter clone that handles the throughput that twitter does, that takes legitimately hard computer science (fuck twitter, but it remains both a good and common example)

heck even lemmy has huge issues with sync at its current tiny scale when there’s any reasonable latency involved… i remember only months ago when aussie.zone was getting updates days late because of a 300ms latency to EU/US and lemmys sequential handling of outboxes (afaik)

they’re not going to go after the robot vacuum when the thermostat, tablets, computers, TV, router, access point, etc are right there.

… and all of those things should be equally protected

they’re going to go for the easiest thing to extract information or escalate

since they have root they can add a password themselves!

the most absurd thing is assuming that an end-user is going do add a root password to a serial interface

i’m not saying end users shouldn’t be able to gain root somehow, simply that it shouldn’t be wide open by default… there should be some process, perhaps involving a unique password per device

doesn’t mean it can’t do damage - like fox news

hell you don’t even need a lab for a lot of bio plastics: you can produce them in your kitchen

Even 50 days is relatively fine if it’s cheap enough to replace saran wrap for food products

well we already have that

and that’s 50 days total, so those big commercial rolls of plastic wrap are much harder because they’re now perishable too: you can’t just stock a warehouse up

you’re on programming.dev so i assume you know that secrets is a generic term to cover things like your cloud account login (whatever form that may take - a password, token, api key, etc) for the robot vacuum service and you’re being intentionally obtuse

it’s a realistic attack scenario for some people - think celebrities etc, who might be being targeted… if someone knows what type of vacuum you have, it’s not “carefully take apart” - it’d take 30s, and then you have local network access which is an escalation that can lead to significantly more surveillance like security cameras, and devices with unsecured local access

just because it doesn’t apply to you doesn’t mean it doesn’t apply to anyone… unsecured or default password root access, even with physical access, is considered a security issue

yes and no… i agree with the sentiment, but with root you can extract wifi credentials and various other secrets… you shouldn’t be able to get these things even when you have physical access to the device… the root access itself isn’t the problem

+1 davinci… it’s incredible what you get in the free version, and the studio version is getting more and more worth the money in a value add way rather than a need it way

plus one of the main issues with desalination plants for fresh water is… getting rid of the sodium

i’m fairly sure it’s untrue yes but didn’t want to comment that because i don’t know for sure, and honestly it’s a little null and void because they definitely do broadcast all kinds of bluetooth stuff which is equally trackable (though i guess with all the wifi location data you can correlate someone in the store to where they live pretty much perfectly accurately where bluetooth info is less useful in that regard)

i’m 99% sure your phone scans for available wifi networks, sees one it knows and then connects, but i could see a situation where it’s 2s faster to just keep trying so for a “good user experience” some shit company decided to start doing it… but i’m pretty sure for apple pr google that’d result in a CVE

but that’s a compromise… it’s not categorically better

you can’t run a bank like you run distributed instances, for example

services have different uptime requirements… this is perhaps the first time i’ve ever heard of signal having downtime, and the second time ever that i can remember there’s been a global AWS incident like this

and not only that, but lemmy and every service you listed aren’t even close to the scale of their centralised counterparts. we just aren’t there with the knowledge for how to build these services to simply say that centralised services are always worse, less reliable, etc. twitter is the usual example of this. it seems really easy, and arguably you can build a microblogging service in about 30min, but to scale it to the size that it handles is incredibly difficult and involves a lot of computer science (not just software engineering)

i’d say that’s mostly reasonable… not to say you can’t mess around in the guts of python, but you can mess around a lot more in c

the flip side of this is that python has a lot more guard rails: it’s simply impossible to write entire classes of sometimes very dangerous and subtle bugs in python code, while in c… go for it! that’s valid operations that you may have decided to do for performance reasons (also a reasonable argument, but if you know you’re not doing this fuckery then maybe it’s better to just let software not let you do them by accident or on purpose)

right? like if white space weren’t required, how would you format your code differently? arbitrary white space all over the place? no indentation? that is some spicy garbage code

that’s pretty disingenuous though… individual lemmy instances go down or have issues regularly… they’re different, but not necessarily worse in the case of stability… robustness of the system as a whole there’s perhaps an argument in favour of distributed, but the system as a whole isn’t a particularly helpful argument when you’re trying to access your specific account

centralised services are just inherently more stable for the same type of workload because they tend to be less complex, less networking interconnectedness to cause issues, and you can focus a lot more energy building out automation and recovery than spending energy repeatedly building the same things… that energy is distributed, but again it’s still human effort: centralised systems are likely to be more stable because they’ve had significantly more work put into stability, detection, and recovery

to really hammer home this “many ways to hide”: the PDF is kinda just like a container… it contains other things like images (the patterns for example)… these patterns are probably vector graphics (made up of lines rather than pixels)… this means you can magnify them basically infinitely… and they can contain transparent lines and all sorts of things. they could easily embed that same text in the SVG image, at tiny scale (less than a pixel at 100% scale), and make it transparent… no PDF editor is going to touch the image data: it simply doesn’t really understand it to that degree - it’s an image; not a PDF after all… so that information will remain even after you’ve removed all visible/reasonable marks

this is just 1 example of practically infinite places it could be - and remember, this text is just lines in an image! it’s not like you can ctrl+f for the text necessarily… you’d have to go through every image manually and inspect every single line, and even then there are no guarantees (perhaps they encoded that information like morse code in bumps in some lines that are only barely visible at 1000% magnification)

no matter where you host, outages are going to happen… AWS really doesn’t have many… it’s just that it’s so big that everyone notices - it causes internet-wide issues

Would or is also a really good way to sniff WiFi passwords. If anybody says “Well yes, I am indeed $HOME_NETWORK_NAME” your phone just hands them the password.

okay that’s very untrue… wifi passwords aren’t really passwords; more accurately they’re pre-shared keys… they are used to generate the encryption parameters used to talk to the AP. the password is never sent over the air, and there’s a 4-way handshake