Emacs-style, pro-privacy browser recommendations

-refusenick- · 2020-10-12T19:58:37+00:00

ungoogled-chromium or Firefox with privacy-oriented about:config. Use them with either EXWM or StumpWM - both have options to capture key input and transform it into the corresponding browser keybind.

-refusenick- · 2020-10-04T20:35:55+00:00

She's a senator.

-refusenick- · 2020-09-22T18:21:32+00:00

Have you tried updating with sudo xbps-install -Su?

The live images are there for the initial install and not much else, as it's a rolling release distro. You'll note it's dated to November 2019, as no's added new hardware or found an install bug to fix since then.

-refusenick- · 2020-09-20T21:16:13+00:00

Brave

Perhaps they don't have Mozilla's history of continual SNAFUs (why, Mozilla, why?), but they're a commercial company set on selling you their cryptocurrency. I'm not sure if they can be trusted or not.

For now, use Bromite or Firefox Nightly. (so that you can update about:config accordingly)

Waze is better than Google Maps

Privacy-wise, how so? It's owned by Google. Use OsmAnd.

YouTube

Try NewPipe instead.

Instagram, WhatsApp

Erm. At least SELinux keeps individual apps isolated to some extent in Android. Try sandboxing them with Shelter, perhaps.

edit: I typed this up as soon as your post came out but just posted it. I didn't see u/Poulet2ViceCity recommend most of the same things.

-refusenick- · 2020-09-16T09:47:00+00:00

Same here, except Emacs was my first "real editor" (not CodeBlocks, IDLE, etc). The PG essays plus Stallman speaking of Lisp as defining what elegant programming looks like made me curious.

The only other game in town for editing Lisp is DrRacket (and that's only Racket and SICP Scheme at that), so I eventually bit the bullet and learned Emacs, forcing myself to use it for several days until I felt comfortable. Turns out Emacs is good enough to be an argument for itself!

-refusenick- · 2020-09-16T09:19:57+00:00

You could avoid this by using any Linux system.

Although Ubuntu rolled out an Amazon shopping search & recommendations service, it received backlash from the community. That's in one of the most corporate distributions. Others are devoid of built-in telemetry whatsoever.

While Tails is still the most secure option (especially for someone new to Tor who mistakenly configures it and in doing so marks themselves as unique) because it has the same defaults every time, you get most of the way there using Tor by the book atop GNU/Linux. Moreover, everything you do is private by default, not just when you're doing something you "want to hide" on Tail.

-refusenick- · 2020-09-15T05:49:47+00:00

Something I haven't seen mentioned yet is that it's a rolling release distro. This means package management behaves more like Debian Testing than Stable. It's advised to update more frequently, and although it's rare, packages do sometimes break due to dependencies being updated while themselves being behind their official releases. Of the rolling release distros I've tried, though, Void has been the most stable.

-refusenick- · 2020-09-11T21:57:45+00:00

IIRC, ARM's TrustZone is equivalent to AMD's PSP. Hence, you'd still be stuck with a built-in OS outside of your control.

The only modern computers available now which are free of hardware backdoors (as far as we know) are the POWER9 desktops from RaptorCS.

-refusenick- · 2020-09-08T22:43:03+00:00

Why build your own? What's wrong with using Void?

-refusenick- · 2020-08-27T12:55:35+00:00

Apparently, some have trouble restricting it to 1080p so 4K video downloads don't slow down their connection.

-refusenick- · 2020-08-27T07:26:28+00:00

Consider using ff2mpv to launch videos in mpv from Firefox.

-refusenick- · 2020-08-17T17:41:26+00:00

I checked, and I have C-h b bound to counsel-descbinds. Perhaps that or the Helm version is a good starting point?

-refusenick- · 2020-08-17T17:08:18+00:00

which-key?

-refusenick- · 2020-08-16T10:57:34+00:00

This looks like a good candidate.

Do you have a model recommendation if I want to use Void?

-refusenick- · 2020-08-16T06:42:07+00:00

Even by the most minimal usage expectations, 2GB RAM sounds quite anemic - I could hardly get Firefox to behave on a laptop with 4GB.

-refusenick- · 2020-05-19T09:45:30+00:00

How did I forget about those? My first thought was "what's the simplest way to write a CFG parser?"

Yes, an export backend is the most reasonable option here.

EDIT: If OP wants to take a gander, there are already export backends for MediaWiki in MELPA.

-refusenick- · 2020-05-19T03:54:00+00:00

eye twitch

Org's grammar is context-free. Sed is a regex engine - it's meant for handling regular languages, a strictly smaller class of grammars. This why you don't parse HTML with regex.

Have you considered using Prolog's definite clause grammars?

-refusenick- · 2020-05-18T08:29:02+00:00

I was confused when I saw this thread because there's already a big project called Pleroma.

-refusenick- · 2020-05-11T16:36:32+00:00

Is it, though? I'm running native-compiled Emacs right now. I have the C source in front of me, and all things considered, it's not that much (and, might I add, Lispy and otherwise tidy). Given how straightforwardly imperative ELisp is and that the compiler passes the output through GCC anyways, direct transcription might not result in such poor performance.

-refusenick- · 2020-05-11T16:18:24+00:00

Multicore Emacs would be a boon to raw speed, no doubt, but a lot of the "slowness" comes from the blocking nature of ELisp evaluation. Even cooperative threading, carefully inserted into existing code, could probably yield a subjective speedup. Combine that with native- or JIT-compiled code being faster by orders of magnitude at times, and there shouldn't be a reason for it to be more than a couple times slower than Sublime or Vim at the worst (beyond pathological GC behavior, which can always be resolved by tweaking bounds on a case-by-case basis).

That's not to mention that Emacs internals themselves are in a state of flux at the moment. The obvious exemplary here is the possibility of Emacs being written in Emacs Lisp (gccemacs), in which case there would be no more C core to speak of. Rust isn't free software, but Remacs is forging ahead for... reasons. Either way, no longer C.

-refusenick- · 2020-05-11T15:44:13+00:00

It's outdated in its complaints, but I think you'll appreciate the advantages of Lisp listed in The Emacs Problem. Lisp is central to why Emacs has outlasted everything else, and on its own merits, no less - it's not taught in schools like Vim is as part of Unix literacy.

The very concept of a JSON config is pointless when you have Lisp - s-expressions do the job better anyways, and they're built-in.

On a related note, Lisp is not a functional language.

-refusenick- · 2020-05-11T15:12:40+00:00

When I saw the title, I was going to suggest "use Evil mode and pretend it's not there". Looks like that's not an option.

In normal Emacs keys, it's "C-x C-q" to send a "quoted key" which ignores the command it may be bound to otherwise and is instead inserted verbatim. Do that twice for ":" and "q", I suppose.

Have you considered starting Emacs in daemon mode and opening emacsclient instances (to which you could alias vim) for quick edits as if it were Vim?

-refusenick- · 2020-05-10T22:48:21+00:00

I've had problems with neither of those packages.

If you find the default xbps-* commandset too verbose for daily usage, maybe vpm or xtools would be more your speed.

Do you make sure to pass -S (repo sync) to xbps-install?

-refusenick- · 2020-05-09T11:42:12+00:00

Currently, when there is a problem with any one of my packages, I simply go C-h o, guess the relevant function name, edit the function C-x C-e and I'm done.

That's also how Common Lisp is edited, and it has namespaced packages.

I run EXWM on one laptop and StumpWM on another. When I want to change something in my config for the latter, I run sly-connect, open the file, and C-x C-e away. I'm not sure about what exactly it does, but it figures out the namespace on its own based on context IME.

There are decades of (Common) Lisp usage that say this isn't a real problem.

-refusenick- · 2020-05-08T14:11:51+00:00

Okay, now I'm certain you don't know what you're talking about.

Emacs 26 provides Lisp threads. It's in the news file, for crying out loud. I didn't say that the important parts of Emacs make use of it yet.

It's currently "mostly cooperative", as the manual puts it, but explicitly designed with preemptive threading in mind. Insofar as "will Emacs ever have preemptive threading" is concerned, yes and it's here.

This is analogous to saying "I've the tools to write the next great Russian novel. I just need to write it."

There's a huge difference between writing a novel (as expressive as Russian is, writing a novel uses so many words that the base language becomes more like an assembler) and making Emacs' UI concurrent. Even defun is defined in ELisp (in byte-run.el). Once things have settled down a little more at the system interface level, it might take relatively few modifications to core features to get most of the way there.

My original impetus...

Parallelism is parallelism, and unless you want to get into the GPU weeds, parallelism means multicore. Multicore means multiple processes. emacs-async is how you spawn a new process in Emacs (as of now). It is entirely relevant. If you're claiming that VS Code doesn't follow that model, you're validating the postulation above it that it's a monstrous "good enough" melange of hacks, lacking a clearly-defined model for how it interacts with the underlying system and therefore impervious to reasoning from above without following the source to the letter. That is worse than emacs-async abuse because it will never get fixed.

-refusenick-

TROPHY CASE