Sylos

Right, and I guess this is in particular a problem that Linux/BSD distributions face, where they want to apply small patches for interoperability and the like, but still want to offer it to their users as "Rust".

As someone from the EU: Also a blocker for all these Cookie notices (and I guess also Cookies).

I've been test-driving Mozilla's experimental Fenix browser. It already supports Tracking Protection (which happens to block most ads as well) and it's in general a really nice browser, but I can't stand using it for anything that isn't basically Wikipedia, because of those annoying Cookie notices.

Half-offtopic: I find it very interesting that Rasbian sticks to LXDE. I thought that was going to slowly disappear, with LXQt having developer attention and there being no path forward towards HiDPI and well, Wayland (because neither GTK2 nor Openbox support these).

LXQt currently still uses Openbox, but you can replace it with KWin rather easily. I don't know what is then still missing to create a proper LXQt Wayland session, but it seems feasible.

I guess, one does not really need HiDPI on a Raspberry Pi, but yeah, Wayland would be nice.

There's also wlroots-rs, which provides safe Rust bindings for wlroots: https://github.com/swaywm/wlroots-rs

But yeah, you would still need the C toolchain with this.

As aasasd pointed out, it exists, but isn't part of the core distribution.

The openSUSE folks include it (Geeko) in the version that you find in their repositories, so that's why you might think that it is included by default.

This is a common error. Macroscopic "everyday" objects don't have a definite position and momentum. Macroscopic objects are quantum objects. But when the mass is big enough, the position and momentum can be defined simultaneously with an error that is so small that you can just ignore the uncertainty and approximate them as classical objects.

To put this into simpler terms:

Whenever we measure something, we need to throw something at it and then have that something rebound and hit us again. In most experiments, we throw photons and have them rebound into our eyes.

Throwing a photon against a "classical object" - a chair, a ladder, bacteria - is like throwing a tennis ball against a skyscraper. You throwing that does not have no effect at all, but it's very much negligible.

But when trying to measure quanta, you're now throwing your tennis ball at a football, or at another tennis ball. You're gonna be lucky, if it rebounds at all, instead of just pushing the object that you're trying to measure out of the way. (You also don't have any smaller balls to throw.)

That's why when you measure something in quantum physics, you only know that it has this exact value in the moment that you measure it. It's going to be pushed away because you threw something at it, so after your measurement it has a different value.

You also can't observe it over a longer period, so there's no way to know whether it was only in that moment at your measured position or a long time beforehand.

I have actually never shared my location, so no idea what features one might want for that, but this one is open-source, so relatively trustworthy: https://f-droid.org/app/ca.cmetcalfe.locationshare

Clearly, it was a revelation to him. Which is Google's fault, not his. Google should communicate clearly and visibly what data they use and for what.

From an accessibility point of view, it's also recommended to avoid links that only span over such half-sentences.

Screen reader users will often navigate your page by cycling through the links that are on the page and then they'll get only the link-text read out, not the surrounding text.

Let me put it like this: I consider it only a matter of time before a lawsuit for this completes and Facebook has to pay a multi-million dollar fine. A lawsuit against WhatsApp was filed in the night that the GDPR became active: https://noyb.eu/4complaints/

The lawsuit is not just for this matter, it's rather because users were forced to consent to the privacy policy in order to continue using the services, which is very hard to justify under the GDPR, but I presume/hope, they will also look into what WhatsApp wanted users to consent to and how they presented it (89 screens full of legalese).

In theory, there is some clause in WhatsApp's terms of service which requires every user to get that written permission from all their contacts that I joked about.

One actual thing that WhatsApp will be able to cling to, is that they do have a 'legitimate interest'. Without uploading these contacts, their service would not anymore grow at even just half the pace.

I appreciate the vigour, but it's probably easier to just use an ad blocker: https://f-droid.org/app/org.blokada.alarm

Just get a written permission from all of your contacts that you're allowed to upload their data to WhatsApp, like the rest of us clearly have.

Or make it so that no one has anything against you ever. Because people have been sued already for uploading their contacts' information to WhatsApp without permission.

I really don't want to encourage you to use WhatsApp, but one possible solution would be to use this app: https://f-droid.org/app/opencontacts.open.com.opencontacts

It's a separate store for your contacts, so that you don't have to use the Android contacts implementation where every app and their mum wants access to.

However, mind that WhatsApp is not going to be particularly user-friendly whether you do this or block access to the contacts in newer Android versions. It won't display people's names until they've chatted to you (and then only in a shitty secondary GUI), so you will often have to guess from their picture who they might be.

And worse still, there's no way to initiate a chat from within WhatsApp to someone who's not in your contacts.

Thankfully, there's an app for that nowadays, too: https://f-droid.org/app/io.github.subhamtyagi.openinwhatsapp

It's definitely true that Mozilla needs funding beyond what users are willing to donate. Especially with other 'free' browsers available. But all scandals that I'm aware of were nonsense that journalists wanted to believe, in order to land the next big "the good guys are actually evil"-story.

A more privacy-friendly default search engine is clearly the elephant in the room, but their other financing strategies have been done to try to supersede that and to my knowledge did never infringe on privacy. If you feel different about one of them, please read up on it. There's been a lot of misinformation out there.

Mozilla would make themselves liable to prosecution, if they were to simply violate privacy without a very good reason, as privacy is an explicit goal of their legally-binding non-profit mission statement.

Having said that, there is a good reason why Mozilla has to compromise in terms of privacy. And that is webpage owners' interests.

Webpage owners want to track you. And they can opt to not support Firefox, if they can't track you. Which is kind of bad for Firefox and ultimately for Mozilla's mission, which is making the web a healthier place, for which they need Firefox even just as a second implementation of the web standards.

So, yes, they do have to balance out webpage owners' interests and yours. And yes, they cannot give you as privacy-friendly defaults as some of the browsers that don't have to care about webpage owners' interests. If you're a tiny Chromium fork, no one's going to block you, because mother Chrome is absolutely lovely to webpage owners.

But you should notice that Mozilla gives you the tools to fix the defaults and goes to great lengths to be privacy-friendly when webpage owners are not involved.

In my opinion, that is not really separate.

Pretty much all companies constantly whip their employees to get things done as fast as possible. And if that definition of "done" does not explicitly contain interoperability, then even the most well-intending employees will drop that sooner rather than later.

Which is the case for any side-goal. Security, code quality, documentation, tooling, test coverage etc. If you only prioritize one thing, other things will be neglected, unless you put explicit checks in place.

Which is why we have people whose job it is to manage these things. And if those managers failed to put checks in place, then we are back at either incompetence or malice of those managers.

I think, the major appeal of it is that it does everything.

Lots of "productivity"-applications are either TODO-lists or meant for note-taking or good for writing down concepts or are knowledge bases.

But you can't really separate these. Often I'll write something down and later realize that I need to do xyx for that. Or that I want to schedule a reminder for this note.

Other times I write something down just to have it written down somewhere and I won't want to see it again until months later. But if I just write it into a random .txt-file, I'll probably never see it again. With it being in the same place as my other notes, todos etc., I will actually find it again.

And other times, you might have this dumb idea for a thing. And then you add some more ideas to this idea. And before you know it, you've written down the entire concept for your next software project in your notes-application. When this happens to me with OrgMode, I really don't mind. Its plaintext-format is just as readable as MarkDown for this use-case. I might very well stick this OrgMode-file into the software repository.

Also, sometimes I will find an article to something in my software project concept and want to note it down there with a reminder to actually look at it. OrgMode allows me to do that.

Eventually this becomes a lot of information in one place, but OrgMode itself has lots of tools to organize that: tags, priorities (from A to whichever letter you like), notebooks (=different files), states (e.g. TODO, DONE, NOTE, and again whatever you like), scheduled times, deadlines, recurring tasks etc.

And then there's obviously also parsers like the one in this post. They can do whatever they want with the plaintext you have there.

Personally, I mostly use the Android-app Orgzly. It has a widget with a simple DONE-button for my TODO-usage. It can throw notifications at me. And it has a really powerful search-feature, allowing to save specific searches and for example select them as the listing to display in the widget. E.g. I only want to see notes with the state "TODO" that are scheduled within the next three days.

I will admit that it's a bit of a rabbit hole, but task/note management in general usually is and this feels better than my previous solutions.

Especially also the fact that it is just plaintext-files that I can sync and backup easily.

Servo is nowhere near production-ready and there's no reason to assume that it will be anytime soon.

Just consider that Mozilla is pretty much working full-pelt on Gecko and merely keeping up with Google. They (as well as Google) are far away from implementing all currently specified web-standards, of which more get specified all the time.

So, in order to get Servo to the level of current browser engines, they would have to have an even higher developmemt velocity, while not really being able to stop developing Gecko in the meantime either.

Maybe if the majority of components someday are shared between Gecko and Servo, they might do the final step and switch out the core completely, but even that is still far away.

Servo is specifically a research project. To explore what could be done, if one were to do things right. That they were able to isolate and share components, that even came as a surprise to Mozilla.

The trick with this material is that it pretty much reflects sound waves. On the way back, these reflected sound waves then crash into the upcoming soundwaves and they cancel each other out.

Headphones with active/acoustic noise cancelling use the same trick, except that they pick up the upcoming sound waves with a microphone and then use a speaker to generate those "reflected" soundwaves.

Actually-reflected soundwaves cannot be as strong as the upcoming soundwaves, so they're never going to fully cancel out the noise. Those generated soundwaves can.

One point is that there's most likely less latency for a soundwave to get reflected vs. picked up by a microphone and then generated by a speaker. However, to my knowledge our human senses have even more latency than both of those, so I don't think that matters.

Firefox has still some clear advantages over Brave, thanks to owning their engine.

A trivial example is the battery API. It's nowadays mainly used for tracking, but is an official webstandard. Mozilla decided to fuzzy it, so it lost its usefulness for tracking. Google didn't.

And I imagine, there's hundreds of similar examples at this scale, which as an average user you'll just never hear of.

One bigger feature is Firefox's Containers. It's based on work from the Tor Browser. Which also just illustrates what this partnership sometimes brings forth. Tor Browser is going to always be there, checking the Firefox code for privacy problems, and will suggest better ways of doing things, which Mozilla can just adopt.

For Chromium, there exist in principle similar efforts, like Brave, Iridium Browser, ungoogled-chromium, but these will always fight an uphill battle against Google and obviously Google isn't going to adopt and maintain their fixes.

Are you aware of the recent WebSQL remote code execution vulnerability?

That's a pretty good reason for Mozilla's decision.

One very obvious point which somehow hasn't been named yet, is security.

If Blink has a security vulnerability, like the recent WebSQL remote code execution, then in a monoculture that means everyone has this vulnerability.

I think one part of it is that HTML(5) and CSS have become much more powerful.

In the past, if you wanted fancy animations or even just moving parts on your webpage, you needed to script that.

Heck, you needed to embed Flash for any video or the like.

Nowadays, even responsive webpages are no problem with just HTML+CSS.

Yeah, I simplified there. I remembered it being a really insignificant amount that they're limited to, and then more importantly, it's still a non-profit. If they take the money, they're just as well forced to reinvest it into their mission statement.

Oh yeah, as far as I remember, Google (and Facebook) said right away that they would not support DNT, before it became default in IE.

With most webpages shipping code from Google/Facebook, that was also already pretty bad for DNT.

They've changed the default since then, again. Here's a source for them having had it on by default and turning it off again: https://www.theregister.co.uk/2015/04/03/microsoft_reverses_...

It could have had legal bearing, if Microsoft had not turned it on by default.

Before DNT, the way consent basically worked was that companies just assumed you consented, and only if you specifically denied consent, they would have no chance to defend that in court.

With DNT, if the user turned that on themselves, they would have clearly signalled that they want this the other way around. Do Not Track me, unless I specifically give you my consent. This would have made it hard for companies to defend their behaviour in court.

With Microsoft turning it on by default, there was no way for companies to know, if the user actually wanted privacy, or if they supposedly wanted to be tracked, for whatever reason.

With the GDPR in place, you theoretically now need to get consent every time (including implicit consent, e.g. when the user asks for something to be shipped to their address, that means you can process their address). Most companies don't yet keep to it, though.

As if they thought I was 65+ years old.

I think, it was rather that they thought you were using a touchscreen...

And the second feature missing is the search highlight in the scrollbar. It's a mandatory feature for my when searching on a long page (like this one for example) to search for "firefox" and find in the scrollbar everywhere it is.

I don't see how this is mandatory, you can just use the next/previous-result buttons (F3 / Shift-F3) to go to each result, but I guess it would make it much easier to establish some context as to where you are on the page, especially after you've jumped to the next search result.

And the Mozilla Corporation is a 100% subsidiary of the non-profit Mozilla Foundation. That means their only stakeholder that they could pay out their profits to, is the Foundation, which can't take the money, because it's a non-profit. The Corporation can only really save up the money to reinvest it later.

The Mozilla Foundation's legally-binding mission statement is therefore also effectively enforced for the Corporation. The Foundation could throw out the CEO of the Corporation and in general gets to decide what happens in the Corporation, which they're legally bound to tell to follow the Foundation's mission statement, i.e. making the web a healthier place, improving privacy etc.

As a result, the only profit-motive that exists in the Corporation is that the employees want to keep their job.

The problem is that WebKit isn't really a competitor to Blink:

1) It holds this marketshare mostly because of the forced monopoly on iOS. It's not technologically particularly far ahead or even has a browser implementing it with good marketing.

2) It exists on platforms other than macOS and iOS, but it is being optimized specifically for those platforms and only there can kind of compete with the other browsers. So, if you're not on macOS/iOS, it is hardly a competitor that you could choose from.

3) Chrome's Blink engine was forked from WebKit, so they are actually very similar in a lot of ways. A Blink-WebKit-duopoly would still have many of the disadvantages of a monopoly, like security vulnerabilities being shared and certain innovations being harder, because they have the same architecture.

sneaking extensions into updates that users didn't opt for.

If you have auto-updates enabled, Mozilla, like Google, has complete control over the source code that runs on your system. Had they wanted to sneak new source code in, they would have specifically not packaged it as an extension, which made it user-visible and limited to the extension API in its capabilities, and instead just patched the Firefox code to include it. So, they were decidedly doing the opposite of sneaking it in.