Well, given how all mainstream desktop programs are getting huge buttons these days...
133 karma · joined January 25, 2022
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.
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.
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.
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.
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.
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.
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.
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
But these aren't the protocol's achievements either. These people have so much money they could make IRC popular.
<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls>
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
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.
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">
>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.
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
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.
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
Getting you to click on ads does not take that. The only point in the list that makes money is spying I mean "analytics and tracking" but that doesn't take dozens of megabytes of js diarrhea and a thousand frameworks calculating DOM diffs and whatnot
You can't.
That's the law of software. Good components tend to be easily replaceable, bad components do not. Thus overtime as software evolves it ends up made of mostly or only bad components.
All owned by the same company. I'd agree about it being revolutionary if it was on some distributed p2p network like freenet, torrent, ipfs etc. But to call some company doing things in a slightly different manner a new era? Come on
Well that's what I am talking about. Hardware resources allow devs to be lazy, to not optimize.
But snprintf(buffer, 25, "%d item(s)") is easier than learning and setting up whatever library it is you want to pick, and thus is the lazy solution. You don't need to think about optimization to pick it. On the contrary you'd need some good reason to not pick it.
Growing hardware resources can explain the growing popularity of higher level, interpreted languages for example - they take resources and save time.
But it can't explain e.g. twitter, and that's what my question is all about. It would actually be the lazy solution to make the frontend in pure html. Yet they chose whatever unholy mess it is they chose. It took them more time and resources to build AND it takes more computer resources. So it's like anti-optimization - but it still takes dev time. And I can't wrap my head around it, why would they do this?
You'd think it works like this: you may trade features and dev time for optimizations. But they trade dev time for the opposite of optimizations, and essentially no features.
It's like if they paid a street sweeper to make streets messy. And they didn't just pay this one guy to run around the whole city throwing garbage around - they hired teams of guys to meticulously lay out litter in the streets. Nobody asked for that litter, it achieved nothing, didn't even profit the people doing it. But they spend tons of money on paying those guys, training them, team building, organizing scrum meetings...
Unfortunately there are no phones without malware in the form of at the very least android on the market, you can't even remove the malware.
And reddit's and twitter's programs, including those written in js, are malware too. I was just wondering why do they over-engineer malware that much
Not that android's not over-engineered though
Mind sharing some?
>Why do twitter and Reddit use perceived anti-patterns instead of good UX
I'm by far not talking about UX alone.
Quite the contrary I find it almost insulting to have to spend time on this.
I'd like to see an Office Space remake where the main character's job isn't the 2000 switch but building a bloated frontend with React.js + Vue.js + Soy.js with blockchain, machine learning, dependency injection, inversion of control and scrum+agile as well as the revolutionary framework buzzword.js weighing just under a 100 megs.
Is it even really about trackers? Even with adblocker on purging 50% of the page, these things are still slow.