wusspuss

no profile record

comments

vor 4 Jahrendiscuss

Well, given how all mainstream desktop programs are getting huge buttons these days...

vor 4 Jahrendiscuss

>Because it predates them?

I know, point is Android could've been something like regular linux + flatpak, that's it. If "security" were so important to them they could just invent flatpak without reinventing the rest of the system.

>Also, flatpaks/etc don’t provide nearly the same level of security that android does.

1. There's an order of magnitude less effort being spent on them. They're like RedHat's side gig or something. So not exactly a fair comparison.

2. Who are you kidding praising Android's security? A couple of years after purchase that thing stops getting security updates anyway.

>A fundamental part of Android security is that it is user-controllable at runtime even, giving the user more liberty.

1. Initially it wouldn't allow you to reject an app's permission. You could only see what an app is allowed

2. Who are you kidding calling Android user-controllable? The thing doesn't even give you root access. Also all apps are mostly proprietary and can just refuse to work if you don't give them what they want.

vor 4 Jahrendiscuss

>Display hardware for mobile SoCs often had no or poor x11 drivers during the early days of Android.

How is creating an entirely new SurfaceFlinger a solution to the lack of x11 drivers, logically? There could no drivers for SurfaceFlinger either, if it didn't even exist yet.

>x11 drivers are not easy to write,

I can't believe that's harder than redoing what X11 does from the ground up.

>Limited capability mobile devices really don't need to run a distributed systems protocol that outputs to screens as a side effect, regardless of how cool distributed systems are.

I don't see what the word "limited" has to do with anything here since system requirements of Android are greater than that of the desktop GNU/Linux. When a keyboard app eats away a hundred MBs, any overhead introduced by X11 is outright negligible.

And then even if X11 was so unsuitable that they just HAD to reinvent something, they could've done what Wayland is doing - reinvent it but that's it, don't reinvent the rest of the system, and keep it compatible with the existing ecosystem.

vor 4 Jahrendiscuss

LineageOS is still buggy as hell (AFAIK it doesn't even make "stable" versions anymore since 2016 or so, just nightlies), still takes more resources than GNU/Linux, still doesn't support any good software from the desktop.

But yeah it can give you updates for a few more years after you purchase your phone if you're lucky. Still laughable compared to DECADES old pcs getting updates.

vor 4 Jahrendiscuss

>Debian already fails to put your laptop to sleep half of the time when you close the lid and you expect it to work well with your phone that you send to sleep every other minute?

Debian isn't made by a trillion-dollar company. Very few resources are allocated to testing it, worse yet, there's Redhat always breaking things ever since Gnome went to shit in 2011, which affects pretty much all DEs to some degree.

>Because half the GUI toolkits on Linux are either absolute pieces of shit (GTK lol) or simply not enough.

Last time I checked even GTK manages to NOT fuck up its widgets when resizing the window without requiring the developer to go through all the bullshit of LiveData and then a couple of years later also some new bullshit like Flow or whatever, until Google comes up with something yet more over-complicated.

Then there's also Qt which has even been ported to Android.

vor 4 Jahrendiscuss

>Just to add, because your rant is really not constructive and dismissive of a whole platform: android likely has more apps than desktop linux, plenty of them in better shape as well. Why on Earth would they be buggier, when they do in fact see more users?

What exactly is "in better shape" on Android? Why is there not a single file manager whose functionality even approaches that of say Caja or Dolphin, but which also doesn't have ads built-in? Why is multi-window some novel experimental afterthought when it's been done properly for DECADES now several times over?

>Android project back-ported countless battery optimizations to the kernel

I do wonder if just NOT making it a platform for spyware always running in the background (google services but also pretty much everything else, install Autostarts and see) would be more effecient...

>which would easily have 6-8+ hours of battery life on Android, yet it burns like fire in 2 hours with one gnu/linux-based mobile os.

Most reviews say quite the opposite, especially about screen off mode.

vor 4 Jahrendiscuss

>Android’s biggest contribution/change is the security model — the old UNIX one is simply way too crude, so instead android runs each application as a new, dynamically created user so that UNIX permissions actually get used properly, to a degree.

That doesn't justify any of the other Android's "traits". It's also not clear why that couldn't be done as part of regular gnu/linux, as it is being done now with Wayland + flatpak/firejail/anything that introduces that sort of security model WITHOUT destroying the entire ecosystem. That would actually seem easier as that'd involve much less reinventing.

vor 4 Jahrendiscuss

All of those requirements, 'user centered design' among them, to show a picture in the slowest way possible, ever, and to abuse the user by forcing them to download megabytes of malicious code to see that goddamn picture. The most outrageous part is that people actually get paid well for this.

You can't get paid to cut the web cancer out, but lots of people get paid and paid well to help grow said cancer.

This creates no value, this benefits no one.

Economy as a whole is not that much better than the popularly despised NFTs - entire companies and industries are first and foremost something to bet on, and what's behind them is hardly of importance - be it megabytes of bullshit code or a poorly drawn picture. Jobs are created the same way those monkey pictures are drawn - and the salary of a worker is affected by the importance of his work in hardly a greater part than the price of an NFT is determined by how well it is drawn.

vor 4 Jahrendiscuss

What metadata do you believe it is giving out?.. And how it could possibly even be comparable to what an android espionage device gives out by itself in the first place

vor 4 Jahrendiscuss

Literally half the OP article along with half the comments here explain how XML is a problem, how it is not equivalent to any other serialization format, etc. IMO the funniest example is stanza ids. That problem wouldn't exist even if they just used said XML in a remotely sane manner. But they really wanted to go all in on it. It's the XML mindset, the need to complicate things.

vor 4 Jahrendiscuss

It is not a long solved problem if it takes a demo to prove. If it were long solved it'd be self evident. This argument wouldn't exist to begin with.

A demo is worthless if experience doesn't prove it in the long run. And I have the latter, and it doesn't prove. Yes, I know it's probably me, or more likely my friends doing something wrong. One of them restricted Conversations from running in the background for example, non-techies do all sorts of silly stuff. But then again, it shouldn't break with non-techies either. Nothing breaks with them aside from XMPP. Not even WhatsApp which is based on XMPP afaik

vor 4 Jahrendiscuss

>But it has far to go before reaching XMPP's levels of achievement - millions of XMPP-connected users via Google Talk, and popular products such as WhatsApp and Zoom built on top of it. That many of these aren't, or are no longer, interested in interoperability or federation is not a protocol problem, and I don't see Matrix solving that.

But these aren't the protocol's achievements either. These people have so much money they could make IRC popular.

vor 4 Jahrendiscuss

How much worse than XMPP is Matrix in this regard? On XMPP your and your interlocutor's server can see who you talk to

vor 4 Jahrendiscuss

It's not the lack of namespaces that causes people to reinvent them. Using or not using namespaces is a choice you take. With XMPP it's 100% dictated by the XML mindset. There is NO reason for

  <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls>

to specify urn:ietf:params:xml:ns:xmpp-tls other than formalism/a yearn for bloat. There would never be a name collision without this ns and it convenes no useful info.

There's no reason for acks to specify urn:xmpp:sm:3 each time. Yes, here it at least specifies the version, but that's already negotiated when enabling acks anyway.

There's no reason why <query xmlns='urn:xmpp:mam:2' .../> can't be <mam_query .../>.

Namespaces are a choice, sometimes (e.g. in programming languages) reasonable, sometimes (in a serialization format for passing small texts around) not so much.

It is dictated by a mindset, the XML mindset in case of XMPP, and in the case you bring up apparently by the Java mindset, not to say there's much of a difference between the two

vor 4 Jahrendiscuss

>No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear.

Maybe judge not by reading protocol description but by trying and using said protocol, like, chatting with people a lot? With the latter approach you'll notice a very handy feature of Matrix - not losing messages.

vor 4 Jahrendiscuss

>For messaging purposes, it is absolutely identical to JSON in this regard.

There's no "JSON mindset" to produce anything comparable to this crime against bandwidth and code brevity:

  <stream:stream from="draugr.de" id="{ID}" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">

Being sent on every connection for no reason, thrice (!)

>Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML.

Even XMPP, with XML, could do just fine without namespaces. The only place where namespaces are the differentiating factor in practice is <query/>'s and <x/>'s. Couldn't they just be be called <mam_query/> or whatnot? Oh, and namespaces specify the version. Like for ack's they specify the version 3 every time. But it's something that has to be (and is) clarified when enabling said acks anyway.

vor 4 Jahrendiscuss

>So with that said, I'm very interested in hearing any details you can provide about how to silently lose messages in modern XMPP. Clients involved, steps to reproduce, etc. Then we can produce actionable bug reports.

Conversations, draugr.de, can't really say much on steps to reproduce - it worked reliably and then it didn't just yesterday, ironically just as I tried to send the article to a friend to check out.

If I understand the two generals' problem correctly, there always is a way to silently lose messages, with any protocol, it's just that some approaches to not doing that are more reliable than others

vor 4 Jahrendiscuss

>It would be just as easy to write a post like this about JSON,

JSON has no namespaces, even without taking that into account it's already less verbose, it maps nicely into lists and dicts, I don't know a single JSON parser that can leak the user's IP even as an option, let alone by default (not saying there aren't any at all, just no popular ones), doing a binary version of XMPP based on JSON would take as much as switching over to bencode instead of whatever the unsupported hell EXI is. So no, you can't really write a post like this about JSON. Even if you do, it's not gonna be XML that will be proposed as a better solution.

One thing where XML beats JSON is markup. But with XMPP's unholy approach to markup, it's actually JSON that beats XML.

vor 4 Jahrendiscuss

>I personally like the simple delivery model of XMPP

The moment you ask for reliability it stops being simple. Stream Management + Stanza Ids isn't simple, and it shows - XMPP is the only thing I use today where it occasionally happens that a message isn't delivered and I'm not even notified about it.

On a side note I don't believe that this can't be fixed. Maybe if we had end clients checking directly with each other what's been delivered and what hasn't, like actual humans end up doing anyway, I believe it'd be more reliable. Besides instead of relying on the c2s-s2s-s2c cooperation chain to work, it'd rely on just c2c cooperation, giving much fewer variations to test. Just to clarify I'm not talking about a p2p connection but rather e.g. checking the number of stanzas not with the server, but with the interlocutor's client, through the normal XMPP means, like <iq/>s maybe

vor 4 Jahrendiscuss

Not losing messages is pretty key too. But yeah, given enough marketing you can pull anything off. WhatsApp basically doesn't support multi device to this day and is more popular than either (free) XMPP or Matrix could ever hope to be. There's a web version but it only works if your phone is connected. So I guess the phone acts as a server then? Does that mean they found it easier to set it up like that than to make xmpp (which WhatsApp is said to be based on) reliable with multiple devices?