Waterfox VS opensnitch

> [Monday](https://github.com/WaterfoxCo/Waterfox/releases/tag/G5.1.9),

With 4GB of RAM I would recommend that you use the ESR version or some lightweight fork like Waterfox that I've been testing these days. Is really lighter and can use Firefox Sync. But it has his problems. I would prefer to go with ESR and deactivating smooth scrolling if I was you.

> I wish Unity didn't die

Hi from Unity on Ubuntu 23.04.

I am running the Unity flavour:

https://ubuntuunity.org/

It uses the latest Unity 7.7, released earlier this year:

https://gitlab.com/ubuntu-unity/unity-x/unityx

I run it on 3 or 4 machines, one of which has 2 screens and one of which has 3. Works great, scales well, handles modern Ubuntu just fine.

I use it with the Waterfox browser, which integrates natively with the Unity global menu bar, without any addons or config. I am currently on -- (hits alt-H, A) -- version 5.1.9.

https://www.waterfox.net/

Post issues on Gihtub for reporting bugs. https://github.com/WaterfoxCo/Waterfox/issues

I've made sure security updates have now been available ASAP for quite a while now. G5.1.9 released on Monday, for example. This is a day before Mozilla, but mostly because Mozilla spend a day or two doing QA.

I've been a fan of Waterfox for some time now

https://extensions.gnome.org/extension/1201/extend-panel-men...

Of course, GNOME broke it in a later release. This is why no amount of extensions are an answer: they break. Extensions do not work from one release of GNOME to another, and when they fail, the whole desktop often fails.

> Also, it’s not really Gnome’s fault that linux doesn’t have as great metadata from apps to be able to display the apps’ menubars (unity could do it).

False. Gtk exposes this; Unity didn't have stored metadata on lots of apps, it just displayed the existing controls' contents somewhere else. If you run brand new Gtk apps on Unity today, they get panel menus. This was not some clever hack.

Unity is still around:

https://unityd.org/

The distro is back again:

https://ubuntuunity.org/

Brand new apps, like Waterfox, integrate with it fine although they did not exist when it was written.

https://www.waterfox.net/

> With all due respect, that is bullshit reasoning. Selectively displaying useful things is the whole point of UIs.

I disagree.

1. I want to choose what is shown or not. In order to choose, I have to be able to see it. In other words, it needs to be there at first, and then I can choose whether I want to show it or not.

If I can't see it in the first place, then how am I to know it's there?

It's the users' choice what is shown or not. It is not up to the developer to say "they don't need to see this and I'm going to hide it away."

Any piece of software that does that is user hostile.

> Otherwise why would you roll up your window?

Again: it's my choice. I get to choose. It's my computer. They are my windows. I choose if they are shown or not.

That is the point of free software: Choice.

GNOME says it's free, but it takes choices away from me. I object to that.

> Why do you have menus in the first place that hide their content until clicked?

To save space for my document. You can't show everything all the time: that is why you leave it up to the user to choose what they show and when.

(Incidentally, this is also why in my opinion the Microsoft ribbon based fluent interface fails. It tries to show far too much all at once, and the result is that it wastes a huge amount of screen space, and is actually more difficult to hunt through for what I need when I need it.)

> That is no longer the corner, so it doesn’t benefit from this law at all.

False.

Fitt's law is about target size.

https://en.wikipedia.org/wiki/Fitts%27s_law#Implications_for...

It is not about corners. It is about edges too.

By the way I do have a clue about this stuff... for example here is a screenshot of a piece of software which I designed about a dozen years which makes use of Fitt's Law.

https://twitter.com/SimplicityComps/status/54085863397497241...

> The super key is the same as the windows, or the mac command key.

So, yes, but those environments don't suddenly change your entire screen.

> Also often called Meta.

That is a different key. Meta and super are not interchangeable.

https://en.wikipedia.org/wiki/Meta_key

https://en.wikipedia.org/wiki/Super_key_(keyboard_button)

> What’s the problem here exactly? Is alt+f4 written over the screen? Or ctrl+c? Especially that the same behavior is expected from the windows start menu.

The problem here, as I'm attempting to spell out, is that there were existing conventions for this stuff, and GNOME does not respect them.

> It’s a community for its users. You clearly don’t use it nor contribute to it either by work or financially, so it is not really fair to ask someone else to work for you specifically..

No. What I do is, I write about it for a living. I analyse this stuff, I draw comparisons, I point out weaknesses and strengths. That's my job.

In my professional capacity, the GNOME foundation invited me to its GUADEC conference about six or seven years back. I asked a lot of awkward and difficult questions, because that's my job, and I didn't get invited back.

> Literally every OS and distro suck at it.

False. For example, using most other interfaces, such as XFCE, I can treat a multiscreen desktop as one big space. I can have one panel at the far left, and one on the far right, of the entire multi-monitor desktop.

But GNOME doesn't let me do that.

Why not?

> Nonetheless, I feel you are reasoning from a very biased point

Because I disagree with you, you think that I'm biased?

Do you think that everyone who disagrees with you is biased?

Have you considered that perhaps I have opinions, and can draw upon years of knowledge and experience, and make reasoned arguments based on evidence, and that is not the same thing as being biased?

> I don’t think it is as fruitful a discussion.

So because I can counter your arguments with examples and reasoning, you don't think that it's fruitful discussion?

Personally, I think that the arguments where people can defend their points, and produce evidence to back them up, are the most fruitful kind.

opensnitch has existed for a while now. I've never used it, so I can't comment on how well it works.

https://github.com/evilsocket/opensnitch

If you prefer a GUI try https://github.com/evilsocket/opensnitch

The whole BPF verifier and development process is so botched, it's ridiculous. It's like maintainers decided to make this as hard as possible out of pettiness and "they have to use C APIs instead" or something.

- Loading an eBPF module without the CAP_BPF (and in some cases without the CAP_NET_ADMIN which you need for XDP) capabilities will generate a "unknown/invalid memory access" error which is super useless as an error message.

- In my personal opinion a bytecode format for both little endian (bpfel) and big endian (bpfeb) machines is kinda unnecessary. I mean, it's a virtual bytecode format for a reason, right!?

- Compiling eBPF via clang to the bpf bytecode format without debug symbols will make every following error message down the line utterly useless. Took me a while to figure out what "unknown scalar" really means. If you forget that "-g" flag you're totally fucked.

- Anything pointer related that eBPF verifier itself doesn't support will lead to "unknown scalar" errors which are actually out of bounds errors most of the time (e.g. have to use if pointer < size(packet) around it), which only happen in the verification process and can only be shown using the bpftool. If you miss them, good luck getting a better error message out of the kernel while loading the module.

- The bpftool maintainer is kind of unfriendly, he's telling you to read a book about the bytecode format if your code doesn't compile and you're asking about examples on how to use pointers inside a BPF codebase because it seems to enforce specific rules in terms of what kind of method (__always_static) are allowed to modify or allocate memory. There's a lot of limitations that are documented _nowhere_ on the internet, and seemingly all developers are supposed to know them by reading the bpftool codebase itself!? Who's the audience for using the bpftool then? Developers of the bpftool itself?

- The BCC tools (bpf compiler collection) are still using examples that can't compile on an up-to-date kernel. [1] If you don't have the old headers, you'll find a lot of issues that show you the specific git hash where the "bpf-helpers.h" file was still inside the kernel codebase.

- The libbpf repo contain also examples that won't compile. Especially the xdp related ones [2]

- There's also an ongoing migration of all projects (?) to xdp-tools, which seems to be redundant in terms of bpf related topics, but also has only a couple examples that somehow work [3]

- Literally the only userspace eBPF generation framework that worked outside a super outdated enterprise linux environment is the cilium ebpf project [4], but only because they're using the old "bpf-helpers.h" file that are meanwhile removed from the kernel itself. [5] They're also incomplete for things like the new "__u128" and "__bpf_helper_methods" syntax which are sometimes missing.

- The only working examples that can also be used for reference on "what's available" in terms of eBPF and kernel userspace APIs is a forked repo of the bootlin project [6] which literally taught me how to use eBPF in practice.

- All other (official?) examples show you how to make a bpf_printk call, but _none_ of them show you how to even interact with bpf maps (whose syntax changed like 5 times over the course of the last years, and 4 of them don't run through the verifier, obviously). They're also somewhat documented in the wiki of the libbpf project, without further explanation on why or what [7]. Without that bootlin repo I still would have no idea other than how to make a print inside a "kretprobe". Anything more advanced is totally undocumented.

- OpenSnitch even has a workflow that copies their own codebase inside the kernel codebase, just to make it compile - because all other ways are too redundant or too broken. Not kidding you. [8]

Note that none of any BPF related projects uses any kind of reliable version scheme, and none of those project uses anything "modern" like conan (or whatever) as a package manager. Because that would have been too easy to use, and too easy on documenting on what breaks when. /s

Overall I have to say, BPF was the worst development experience I ever had. Writing a kernel module is _easier_ than writing a BPF module, because then you have at least reliable tooling. In the BPF world, anything will and can break at any unpredictable moment. If you compare that to the experience of other development environments like say, JVM or even the JS world, where debuggers that interact with JIT compilers are the norm, well ... then you've successfully been transferred back to the PTSD moments of the 90s.

Honestly I don't know how people can use BPF and say "yeah this has been a great experience and I love it" and not realize how broken the tooling is on every damn level.

I totally recommend reading the book [9] and watching the YouTube videos of Liz Rice [10]. They're awesome, and they show you how to tackle some of the problems I mentioned. I think that without her work, BPF would have had zero chance of success.

What's missing in the BPF world is definitely better tooling, better error messages (e.g. "did you forget to do this?" or even "unexpected statement" would be sooooo much better than the current state), and an easier way to debug an eBPF program. Documentation on what's available and what is not is also necessary, because it's impossible to find out right now. If I am not allowed to use pointers or whatever, then say so in the beginning.

[1] https://github.com/iovisor/bcc

[2] https://github.com/libbpf/libbpf

[3] https://github.com/xdp-project/xdp-tools

[4] https://github.com/cilium/ebpf/

[5] https://github.com/cilium/ebpf/tree/master/examples/headers

[6] https://elixir.bootlin.com/linux/latest/source/tools/testing...

[7] https://github.com/libbpf/libbpf/wiki/Libbpf-1.0-migration-g...

[8] https://github.com/evilsocket/opensnitch/blob/master/ebpf_pr...

[9] https://isovalent.com/learning-ebpf/

[10] (e.g.) https://www.youtube.com/watch?v=L3_AOFSNKK8

Close to zero most probably. If you want something different, to block/monitor what applications access the internet, block ads, etc, try https://github.com/evilsocket/opensnitch

The last thing I built from source was a suckless utility which was nothing but a treat to play with and hack on, so I felt confident I could manage this even though the project's wiki page on compilation warned that it might fail on distro's other then debain and ubuntu. First order of business was translating the apt-get command for the dependencies into an emerge command that would install the same packages. Once that was done, I went on to the go dependencies which all seemed to install without a hitch except for the first one which gave this "build constraints eliminates all Go files" message but didn't tell me that the installation had failed otherwise. I spent a good amount of time trying to decipher this message which eventually turned into just familiarizing myself with go since I hadn't really touched it before before deciding it was fine. Then I tried to build it. It didn't work.

OpenSnitch is a clone of the popular 'LittleSnitch' firewall for Mac. The main feature is that it will tell you about every single connection your computer is doing. A bit annoying for the first few days, but not too bad once you've already allowed the apps you use regularly. I think this would have been the perfect tool for the job.

take a look at opensnitch or picosnitch