Mauve 👁💜 @mauve@mastodon.mauve.moe

So…who hates those Google log-in pop-ups that are seemingly everywhere now? Wanna make them go away?

1. Get uBlock Origin (which you should have already been using):

https://github.com/gorhill/uBlock

2. Open the plugin and click the settings button.

3. Click on the “my filters” tab and paste this into the input:

||accounts.google.com/gsi/*$xhr,script,3p

That’s it! Worked flawlessly for me.

(Updated URL. Thx @IceWolf
and @emz!)

#Google #Privacy #Security #PopUps #InfoSec #BadGoogle

Most types of business exhibit linear growth. But VC will only fund exponential growth.

The result: companies that would create a lot of jobs and actually maintain their products never get funded and never start. If you must hire more to make more product, that's unacceptable linear growth.

We live in an exhausting VC hype machine because it's more profitable to repeatedly hype up and cash out of short-term exponential growth spurts than to build something real.

Paragraphs by @Mer__edith

I've come to believe there are basically two good architectures for apps: - Elm App Architecture: strict tree of state machines - Message bus: no direct parent-child relationships, everything connected via messages over one bus

It's just something that I've been playing with... Simplest version: - Components emit custom events for requests like "toggle sidebar" - Sidebar component listens on window for bubbled "toggle sidebar" events. Components don't need to know about each other, they just pub/sub custom events.

hacker: i am spying on you through your webcam

linux user: omg you got it working?

I want to defend Wayland here and explain a crucial piece that I think people are missing...

The splitting of protocols in Wayland and compositor reimplementation were to allow for new form factors. It had to sacrifice the guarantee of all desktop app functionality being present to achieve that.

The idea (as I see it) was never to have 500 desktop compositors all trying to reimplement the same thing with slight differences. Iinstead, it was for 500 different interfaces for different platforms that are compatible with the same apps (e.g. desktop, laptop, phone, car screens, AR/VR, watch). Different form factors have totally different ways of dealing with interface, but share enough common features where it makes sense to have 1 base protocol and many other ones for device/form specific features.

Problem is, while in 2008-2016 we had a ton of new experimental UIs coming out on a semi-regular basis (that was the peak of the whole convergent phone/tablet craze, smartwatches started, fancy car UI, touch tables, early AR/VR) things have quieted down. The purpose of Wayland's insane modularity hasn't been visible to most people given it's almost always complained about in a desktop contest vs X11. But X11 was literally only designed for a desktop form factor and has been refined for that 1 purpose for decades!

As an example of different form factors, Wayland lets IVI (in-vehicle infotainment) systems work way better than Xorg could have. Desktop window layouting on that platform would inherently produce massive amounts of unnecessary complexity, and the ability to direct scanout saves on power/expensive compute. Automotive Grade Linux and COVESA maintain reference interfaces for cars so companies can iterate a ton faster. Wayland gives the app compatibility and they can make the system UI work with more flexibility and ease than an X11 window manager.

Take Linux Mobile too, the compositor can reliably enforce window layout and boundaries and composition. While this could technically be done with an X window manager and compositor, doing it with Wayland guarantees reliability as the app simply doesn't have a choice or room for error. Some things like drag and drop of toolbars doesn't make much sense on mobile given how small the screens are.

There's some interfaces where X11 is basically impossible to use. In AR/VR (where i am making a Wayland compositor) the concept of a screen simply does not exist. How is an app supposed to position itself when the very concept of 3D is not part of the protocol? In Wayland I don't have to implement the protocols that don''t work (e.g. layer shell) and therefore any apps that don't need it will be compatible..

Wayland has allowed for insane levels of flexibility, things that no other display server architecture can do reasonably. Total flexibility between app and screen, direct scanout without hacks, AR/VR support, etc.

Here's some fun and useful stuff that's been done with Wayland, stuff that X11 could never reasonably do:

LG Smart TV UI: https://youtu.be/4cmYCK9PBkM
Multiple user collaboration on touch tables with arbitrary rotation: https://youtu.be/8xtjJTJAQsY
AR/VR apps running in windows and volumes at the same time, all interactable back in 2014 (eat your heart out magic leap and apple): https://github.com/evil0sheep/motorcar
Presentation slides that were themselves a Wayland compositor written in Qt and QML so therefore allowed fully interactive live demos in an integrated form factor with a very popular and easy to code UI framework: https://youtu.be/mIg1P3i2ZfI
Cosmic panels are actually Wayland compositors, meaning widgets can draw literally anything from any toolkit in any language.

Now, could Wayland devs maybe have distributed features across protocols better? Worked with app toolkit devs to ensure the protocols they made actually fit what the apps and compositors needed? Stopped bikeshedding (though imo many cases of "bikeshedding" are simply accounting for other form factors)? Absolutely!

My point here is simple: there was a reason for making it this modular, for not having a standard implementation. It wasn't just devs trying to impose some ideology, it wasn't some corporate takeover. It's good reasons that people using X11 on their desktop/laptop don't encounter. If we made something that wasn't universal, most apps wouldn't be compatible with it and therefore everything but the desktop form factor would lack apps.

Message in a bottle time again #GetFediHired (not a peep from anyone yet).

Growing desperate in search for (remote) software developer work in the #Ottawa #Montreal areas. #C C# #Erlang #Java #NodeJS #Shell #SQL #BSD #Linux #English #French and more. Very versatile, adaptable, experienced.

http://www.snert.com/resume/

Hey! If its remote, its possible to work world wide too!

🔥

🧵 ...

OpenPrinting is an essential piece of the free software system infrastructure and it needs to be kept in its good shape in which it is currently, many people appreciating my work and sometimes even telling that for them printing works better than under Windows or macOS.

Any help is appreciated, including just boosting this thread.

... 🧵

#OpenPrinting #LinuxFoundation #getfedihired

Don't trust cloud services with your creative work.

#enshittification #privacy #infosec #security #cybersecurity #writing #art

@21ffd29c411746837aa1dfface253d4403160542419833e0026ebac6518a8ff5 @seachaint - Ok.

Based on your link. Signal is safe.

The link focuses on the EncroChat hack.

First off, the EncroChat hack did not use signal.

Second, the EncroChat handsets were hacked and infected. Signal and other apps are end-to-end encrypted (meaning encryption in transit). They do not protect the endpoint from being hacked. If you open your phone and let someone read your messages, they will read your messages. Right. No app - Signal or Tox or anything else - will prevent that.

Also for the US senator thing, that was not Signal specific either. In one case, it was a group chat of Signal where one of the group members leaked the information. Which... yeah. Again, end-to-end, if you send an encrypted message to someone and they show that message, the encryption worked. Also there was another instance where a bunch of senators used a TROJAN HORSE app that was DISGUISED as Signal and was backdoored.

That's not Signal.

That's malware.

So, no, Signal is still safe and still fine to use.

Please do not spread misinformation or disinformation.