I’ve been using Orbot for some time and I’m quite fond of it, but there’s one thing that bothers me: some companies (like CloudFlare) abuse the fact that the list of Tor exit nodes is public and use it to block any access from that network. The result is annoying: one tries to access a website and is faced with several CAPTCHAs to solve.
At the bottom of one of such pages, I’ve noticed a suspicious hint to install Privacy Pass, an add-on that implements client-side of a CAPTCHA redemption mechanism. The other part is of course server-side software and CloudFlare supports it.
The idea that I should install some add-on to access websites via Tor appears wrong to me, but who am I to decide? So I’ve done some reading. This is how Tor project’s members react to this idea:
The idea that Tor users should be forced to install arbitrary software to comply with the wishes of Tor-blockers is wrong, wrong, WRONG in principle.
Furthermore, CAPTCHA is not solving any real problem here in the first place. So there’s no point in asking people to waste their time on CAPTCHAs or install weird add-ons. The only reasonable solution is for CloudFlare to stop serving those CAPTCHAs.
So please, do not install this add-on. Just leave the page that expects you to stare at pictures of traffic-lights and buses and read what you were going to read elsewhere.
I’ve been using FLOSS (Free/Libre and Open-Source Software) for almost two decades now and from time to time, I’ve been thinking about contributing to “return the favour”.
When I joined Fediverse, it struck me how many interesting projects there were and how much time people dedicated to work on them. Now I would really love to join and get active, but it’s very hard to find the time.
Not long ago I’ve got an idea to ask software engineers who are already active in FLOSS projects about that. How they find the time, organize their work and achieve life-work-FLOSS balance. So I did just that.
I’ve asked Mark Felder (FreeBSD port maintainer and Pleroma developer), Shawn Webb (co-founder of HardenedBSD, maintainer of several security-oriented software projects), lain (main Pleroma developer), Mateusz Piotrowski (also a FreeBSD port maintainer) and Michał Herda (a Common Lisp hacker).
Each of them has provided some interesting insights, so I’d like to take a look at the most interesting ones and some of the recurring topics mentioned by them.
FLOSS at work or as a hobby
I’ve noticed two approaches there: working on FLOSS projects at work if you’re lucky to have an employer who wills to pay for that, or doing it as a hobby, which I guess happens most of the time and in most of the projects out there, with only exceptions being huge projects backed by entire organizations (e.g. GNU/Linux, Mozilla Firefox).
Convincing one’s boss that FLOSS contributions pay off is not a piece of cake, so we can change perspective a bit here. We can choose employers who are willing to contribute to FLOSS.
There are many ways to contribute
As Shawn Webb points out, contributing to FLOSS is not limited to writing source code.
Advocacy. Talk to people about the cool things you’re doing with the project. Talk to them about how it has solved real-world problems for you.
Donate. This is a huge one. Donate hardware, software, and/or money. A lot of developers work on their projects in their spare time, like me, with spare resources. Donating funds allows them to pay for hosting services, DNS, etc. Donating hardware allows them to test their code in a variety of ways.
Document. Every project’s documentation could be improved in some way. Whether it be through translation or enhancements to any existing documents, help with documentation will always be gladly received.
Development. If you do have time to develop (though this question is about not having the time), do it! If you use the project at work, perhaps you can have your employer slice off some paid time for fixing bugs.
I think this is a very important thing to keep in mind. Not everybody has to write source code. Instead, those who benefit from that code being written could show appreciation with their donations.
Furthermore, supporting those who solve technical problems by adjusting documentation and spreading the word about their achievements might sometimes increase popularity, leading to more donations, more volunteer developers, etc.
Scratch your own itch
When it comes to developing software or documentation, it might be a good idea to start with software that you already use. You’ll probably know the issues and will find it easier than finding a project, learning about it and then supporting it this way or another.
The benefits of contributing
First of all, this is about getting more experience and learning in general. It is much better to learn by solving concrete problems rather than writing a “Hello World” app in your spare time. Hello Worlds rarely show you any useful tricks or complex problems. Bug reports from actual users will be real-life challenges – much more rewarding to solve and growth-provoking.
It’s not only the FLOSS source code we might learn from. Working with other engineers, each of which has different experience, is a great opportunity to learn as well.
Another point is that FLOSS contributions are often a very good way to provide potential employers with a sample of your work, showing your capabilities and style.
Don’t be afraid
Sometimes software engineers working on all those FLOSS projects seem to be so experienced and have so much knowledge, that it might demotivate one to get in touch and start getting things done. However, my experience proves that they don’t bite! It’s the opposite: each of the engineers I sent my questions to was so open and encouraging that their responses alone made me want to contribute!
Sometimes there are going to be longer periods of no meaningful results or hard problems to solve that would require a lot of work. It might happen and it’s fine. Having clear goals will help a lot. Also, it’s important to remember why we are doingn it – for instance, a common cause is to give back to the community.
Reading all the replies I’ve got was an incredible experience and I’m thankful to all those who replied. Now I’m goinig to take the advice and start learning by doing.
Some time ago I’ve listened to Libre Lounge episode where Chris and Serge discussed the idea of PDAs and how much more those devices were focused on productivity than the smartphones of today.
That was some good food for thought and I’ve started shifting with my own use of the phone to make it work better for me, from “let’s fill this gap between tasks with the rubbish found online” to “now that I’ve got a few spare minutes, what can I do to make the most of that time?” I’ve already found some cool tricks when trying to focus more but the thought of having a device that helps me do my job instead of distracting me even more was really appealing and I wanted to experiment.
So I’m using Nextcloud’s Notes and Bookmarks applications to collect information and of course Calendar application, which helps me and my wife plan things together. And I don’t have to be online to access my calendar or notes.
Another thing I use is Feeder, a feed reader that supports RSS, Atom and JSON feeds. This application downloads any new articles it notices, so I not only get a notification about new articles: I also have the ability to stay offline and still be able to read those articles. This is really nice, esp. with phones’ batteries getting so weak after a few years.
However, the most interesting thing designed to be available offline
is the decentralized social network called
I’m not ready to describe its
or architecture, but the core concept behind this social network is
used to transport information across the network. It is an
unbelievably cool project and I’d love to try it out, but
unfortunately it’s been built on node.js, where things such as
unpublishing a package
are possible. (In this case,
email@example.com has been
unpublished. For people willing to use SSB (Secure Scuttlebutt) on
Linux, this is fine because ther are pre-built binaries. For *BSD
folks, building from source is the only option. And this option is
unavailable.) I hope I’ll be able to join SSB when
release their Rust-based node software.
For now I have to wait and imagine how awesome it would be to read entries from people I followed without access to the internet, for instance when travelling or when I just don’t want to be online.
We’re online almost all the time, with all kinds of information reaching our focus. But how much of that information do we actually need to get things done? And how much of it is rubbish that clutters our attention?
Part of my current job is supporting requirement engineers during design stage. However, I am supposed to support engineers from my team and each team has their own solution architect. This week, however, another team’s requirements engineers have come to my desk and asked for support.
They were working on lice-cycle of an important business object and wanted to design it with clean and elegant implementation in mind. They’ve been considering two major approaches to marking that business object as having reached a given stage in its life-cycle:
- flags in entities representing certain conditions being met (so when a business event takes place, appropriate flag is set);
- states, of which there would be potentially quite a lot and the resulting state diagram would be very complex.
It turned out that their team’s solution architect did not get involved in discussions like that and so they came to me. For me, solving design problems is one of the most satisfying activities, so I’ve jumped in right away.
In the end, I’ve suggested using Event Sourcing for the following reasons:
- they need to support auditing, so tracking business objects’ properties along their life-cycle is a must;
- from my perspective, what they’ve been trying to represent as flags or states, could as well be represented as events. In fact, they are business events.
It’s been very rewarding and I’m looking forward for some more design problems to solve!
I’m so tired of the complexity of the systems I use every day… First of all, I have to use Microsoft Windows at work, while on my private laptop I’m using FreeBSD. Having to switch between these two environments so often is already exhausting (due to different philosophies), while it’s just the beginning.
Each month at work I have to submit detailed reports (not one but a few of them) of time spent on different tasks, each of these reports having a bit different approach to accounting my time. And of course there’s a suite of tools I have to use to cooperate smoothly: Outlook, Word, Excel and a bunch of other.
Then I get back home, turn on my laptop and use GNU Emacs, Claws Mail, Firefox and Qutebrowser. At home I can write any script to do some job quick-and-dirty whenever I want. I can install any software package. But most of the time, it’s going to be a different tool than I would use at work.
Next, there’s my phone, where I use yet another set of tools to communicate and get things done: K-9 Mail, Firefox Focus, Feeder, Riot, Conversations and perhaps some others that I can’t remember at the moment.
Switching tasks comes at a price (even when the goal is to write some text, it is a different task when done in GNU Emacs and a different one when done in Notepad++ or yet another text editor – these two have different contexts and my brain has to retrieve them with each switch).
I would like to have one device that I would carry around and make it adapt to the environment. It could, at least in theory, be just a user interface framework and an integration framework bound together. With these two, we would be able to teach our devices to talk to various services, regardless of their providers. It would actually be a facade and perhaps some adapters for underlying services, which we could use to completely avoid the context switches. Of course this is impossible to implement in this capitalist world because the end user would benefit the most, while providers would need to make their services competitive.
I remember reading Houyhnhnm Computing, a very interesting set of short texts about computing in the ideal world. I think that Lisp Machines had the potential to become something exactly like that. If done right, Urbit might become something like that as well, although at a higher cost.
But well… this is not going to happen. At least not in this world.