Can google just disappear from the face of the Earth…
@xianc78 @lanodan I think before that everyone will have to quit using Goolag stuff first.
Because if you kill every single Freemason on the face of the earth without getting everyone on Linux or BSD, and the rest of the FOSS stuff first, nothing will change to be honest.
All you'll get is going from a proprietary 666 mark of the beast soystem to a free software 666 mark of the beast soystem.
Because if you kill every single Freemason on the face of the earth without getting everyone on Linux or BSD, and the rest of the FOSS stuff first, nothing will change to be honest.
All you'll get is going from a proprietary 666 mark of the beast soystem to a free software 666 mark of the beast soystem.
@lanodan @xianc78 I know.
And this is exactly what always bothered me back when I was still at the PINE64 forums.
People would buy a PinePhone to get as far away from Goolag and Fakebook as possible, and as soon as they unboxed the phone and configured it, they reach out to the forums and ask how to install WhatsApp, GayMail, JewTube, and Goolag Drive on it.
Just why the fuck did you get a PinePhone then?
And this is exactly what always bothered me back when I was still at the PINE64 forums.
People would buy a PinePhone to get as far away from Goolag and Fakebook as possible, and as soon as they unboxed the phone and configured it, they reach out to the forums and ask how to install WhatsApp, GayMail, JewTube, and Goolag Drive on it.
Just why the fuck did you get a PinePhone then?
@ryo @xianc78 Those are just idiots.
I mean more like how several software projects, even ones not made by google just copy over stuff from google monorepos (aka bundling of dependencies to screw with distros), here is some examples:
- WebKit (and probably also firefox) uses ANGLE for WebGL, has no releases, can't be easily packaged as a system library, often a source of breakages
- NodeJS, wasm-c-api, wabt, … uses chromium *internal* JS engine (V8), which can't be easily packaged as a system library
- Firedfox uses "LibWebRTC", which is yet another thing internal to chromium, which also of course comes with a copy of Google's own fork of OpenSSL (BoringSSL) and probably other "fun" things like this.
I mean more like how several software projects, even ones not made by google just copy over stuff from google monorepos (aka bundling of dependencies to screw with distros), here is some examples:
- WebKit (and probably also firefox) uses ANGLE for WebGL, has no releases, can't be easily packaged as a system library, often a source of breakages
- NodeJS, wasm-c-api, wabt, … uses chromium *internal* JS engine (V8), which can't be easily packaged as a system library
- Firedfox uses "LibWebRTC", which is yet another thing internal to chromium, which also of course comes with a copy of Google's own fork of OpenSSL (BoringSSL) and probably other "fun" things like this.
@lanodan @xianc78 NodeJS, Electron, WASM, and so on is simply a matter of not developing in it and not using anything made with it.
With the only exception of MyMonero, I have literally nothing on my ThinkPads that uses Electron.
And on my desktop I have Bisq, but that's because it's literally the only way to get fiat into crypto (I don't care about crypto to fiat at all) without the KYC bullshit.
With the only exception of MyMonero, I have literally nothing on my ThinkPads that uses Electron.
And on my desktop I have Bisq, but that's because it's literally the only way to get fiat into crypto (I don't care about crypto to fiat at all) without the KYC bullshit.
@lanodan @xianc78 Browsers on the other hand, it's just hard to mitigate that in current year.
You can use different CLI, TUI, or GUI apps to minimize your dependence on a browser where possible, and perhaps use something like Netsurf or Lynx for the remaining part as long as it doesn't depend on any of the soydevvery.
You can use different CLI, TUI, or GUI apps to minimize your dependence on a browser where possible, and perhaps use something like Netsurf or Lynx for the remaining part as long as it doesn't depend on any of the soydevvery.
@ryo @lanodan Speaking of NetSurf, I tried it with my personal website. It can't read my navbar which is the only JS part I have on there.
Yeah I know, I should probably find a better way to handle the navbar but this is the only way I know how to do it without resorting to a static-site generator (or using an iframe). But I don't think there is any reason why NetSurf still can't handle even the most basic JS. (The navbar script is just a few document.writeln() calls)
@ryo @xianc78 Well most people have literally no idea what they're doing.
It's like as put in the SUV vs. bicycle metaphor used in the [url=https://idlewords.com/talks/website_obesity.htm]The Website Obesity Crisis[/url] talk. All sorts of irrational tricks where they might as well believe the "Free Energy!" shit you see on youtube, instead of thinking carefully about the problem at hand.
It's like as put in the SUV vs. bicycle metaphor used in the [url=https://idlewords.com/talks/website_obesity.htm]The Website Obesity Crisis[/url] talk. All sorts of irrational tricks where they might as well believe the "Free Energy!" shit you see on youtube, instead of thinking carefully about the problem at hand.
@xianc78 @lanodan They can.
I even tried to make the form needed to send a reply depend on JS as a test, and a "noscript" just saying "FUCK OFF!!".
And the spambots were still able to submit comments as if nothing has changed.
Just making comments with "http" and "https" in them fail to submit was way more effective, but eventually they got around even that one.
And even if it would have worked, spambots still see the email address.
They don't care if it's in onclick or in href attributes, all they care about is that they can recognize an email address in plain text, it's then a matter of just sending spam to that email address.
I even tried to make the form needed to send a reply depend on JS as a test, and a "noscript" just saying "FUCK OFF!!".
And the spambots were still able to submit comments as if nothing has changed.
Just making comments with "http" and "https" in them fail to submit was way more effective, but eventually they got around even that one.
And even if it would have worked, spambots still see the email address.
They don't care if it's in onclick or in href attributes, all they care about is that they can recognize an email address in plain text, it's then a matter of just sending spam to that email address.
> breaking your site to avoid spam bots
Just put a spam trap, you'll likely get one for free anyway if one of your address leaks in a database (and you use per-service emails, most providers support + or . to make sub-addresses).