My apologies to my three readers, and to the hard working organizers from The Open Coop, for not getting around to a write-up on Open 2018 yet. One positive outcome from that event is that attendees who are working on ‘Open App Ecosystems’ of various kinds were able to compare notes, and as a result, there has been a wave of new members and activity on the OAE Loomio group. Open 2018 was a fantastic event, and I encourage anyone interested in potential collaborations between the software freedom movement and the cooperative movement to attend in 2019.

I will soon be heading to Hong Kong for another platform cooperativism conference, ‘Sowing the Seeds‘, taking place from 28-29 September at the Chinese University of Hong Kong (CUHK). This event is a collaboration between a number of cooperatives from around Asia, and the Platform Cooperativism Consortium, based at The New School at NYU (New York University). I’m also hoping to attend the cooperative hackathon taking place over two days before the conference (watch this space!).

A number of the speakers and participants at this conference were contributors to ‘Ours to Hack and Own‘, a book of essays that attempt to map out the transition from data farms that benefit corporations and investors, to digital cafes that benefits their members and workers. It’s a great book, and while I encourage you to buy a copy if you can afford to, I’m aware of at least one place you can download a gratis digital copy (see our Notable Books library).

It’s a privilege to be able to attend these events, and learn more about the fantastic work being done by cooperative organizers and free code hackers around the world. At the same time, it’s taking some effort to get my head around this new social movement, and how it relates to the pre-existing economic democracy and digital freedom movements that I’ve been involved in for decades. Expect to see more writing on this blog about both the organization and technical aspects of platform cooperatives over the next year or so. It may be that some of this writing will provide the ending I’ve been looking for to complete the story I want to tell in ‘Email At My Life‘. Again, watch this space!

Filed September 23rd, 2018 under News, open source

According to a piece on left-leaning kiwi blog site The Daily Blog, there’s more bad news looming for basic democratic rights. Both the Australian and New Zealand governments are considering passing new laws that would force people to hand over the keys to their encrypted communications. NZ already has some stupidly strict laws on “exporting” anything encryption-related from the country, and even publishing articles about it in academic journals requires special permission. A coalition of digital liberties groups, including InternetNZ and the NZ Council for Civil Liberties, has been defending the right to encrypt since at least 2016. A time when the debate over the technology was heating up around the world, thanks to the work of groups like Access Now. Back then, the Obama administration were saying that the US federal government would not be doing anything that weakened the digital security provided by encryption.

The problem is, encrypted communication is such an obscure thing for most people, and so far from their everyday concerns about paying the rent, keep dinner on the table, keeping the shop open, or whatever. There’s a risk that too many people will only understand why this matters too late, and start trying to close the stable door after the horse has bolted. So here’s a simple way to explain it.

You have a lock box in your house. In it, you might keep some cash for emergencies. You might keep important documents like your passport when you’re not travelling, or copies of your will, or a copy of your research on your family history. You might keep something harmless but embarrassing, like some saucy Polaroid photos you took with your lover, or something weird and sentimental, like a lace doily, or half a doughnut. It’s nobody else’s business what’s in that box. You have a fundamental right to keep it private. It’s a right that’s asserted in a bunch of other human rights conventions, including Article 12 of the Universal Declaration of Human Rights:

“No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.”

You don’t want anyone to see what’s in your lock box, but let’s say law enforcement officers want the key to it, because they believe it contains evidence of a crime. Traditionally, in democratic countries, the officers have to appear before a neutral third-party (like a judge) and the onus is on them to convince that person that they have a very good reason to be allowed to violate your privacy, not on you to prove that they don’t (”nothing to hide …”).

If they get permission - in the form of a judicial warrant - it only applies in this specific case, to you, to the private property they’re asking the judge for access to, in this case your lock box, and for a specific period of time. They can’t get a warrant to search anyone’s lock box. They can’t get a warrant to search anything you choose to keep private. They can’t get a warrant to violate your privacy any time they like from now on. A warrant is a temporary, specific exemption to the laws that normally protect your privacy. If law enforcement officers can just ask you for the key to your lock box, and threaten to arrest you and charge with obstruction if you say no, that’s “arbitrary interference” in your “privacy, home or correspondence”, and Article 12 says that’s something governments that respect human rights protect their people from.

An encryption key is like a digital version of the key to your lock box. Like your email or social media passphrase, it protects things you have reasons to want to keep private. In a tiny minority of cases, that might be communications about committing a crime. But in the majority of cases, they will be things you want to keep private because they are embarrassing (dick pics), or personal (love letters), or financially sensitive (online banking), or its your professional duty  (a doctor’s database of their patients’ medical records). Things that are harmless. Things that could even be harmful to people if their privacy is violated, like medical insurance companies getting access to people’s medical records, and charging higher premiums to people with unusual health problems, even though the whole point of insurance is to collect money off lots of people, so it can be paid out to those who need it.

The problem with the laws being discussed about encryption is not that they let law enforcement violate a specific person’s privacy, in specific ways, when they have good reason to think they will find evidence of a crime. The law already allows them to apply for a warrant for that. The problem is, these laws would let them search through anything that anyone chose to encrypt, any time they like. It would let them do so in secret, with no effective way for the public to hold them accountable for how they use those powers.

This is how policing works in a police state, not a democracy. Please contact your political representatives and urge them to do everything in their power to protect our privacy, by protecting our right to encrypt.

Filed September 7th, 2018 under News, security

At the end of last month, Mozilla Hacks announced a new series of “DWeb” posts on decentralized software projects, which aim to redistribute the power to host and share information on the web, and on the internet in general. Obviously it’s of great interest to Disintermedia, and this blog’s 2 readers. So far, there are articles on Scuttlebutt/ SSB, WebTorrent, and Beaker Browser (see the list at the end of the DWeb announcement article). Thanks to the fedizen - a citizen of the “fediverse” of federated social networks -  who brought this to my attention, sorry I can’t remember who it was right now.

I’m back in the studio, and intending to resume normal transmission next week. This will start with a run-down of the talks and workshops I attended at Open 2018 in London.

In late July, I will be attending the Open 2018 conference in London, thanks to the encouragement of one of the organizers, who participates in the Open App Ecosystem (OAE) group on Loomio. If you’re going to be there, let me know, and I’ll do my best to make sure you know about any open space sessions that might interest you. Hopefully we’ll have open space time for folks interested in the OAE and the Collaborative Technology Alliance reboot to get together, as well as a session for those who orbit the Peer-to-Peer Foundation and the Commons Transition project.

I’ll be in London for a week or so before the conference, so if you’re not going to be at the conference, but you are based somewhere around the greater London area, feel free to get in touch. I love to meet up with a diverse range of people when I travel, and geek out about the potential for the net and digital technology to better serve human and environmental needs.

I’ve got a lot of blog posts in the pipeline, but this will probably be my last post until after the conference, and maybe even until I get back to the studio. I will do my best to post some live updates from the conference using my new fediverse account (thanks to the NZ Open Source Society), and possibly some kind of Etherpad or CryptPad for live note-taking.

Filed July 4th, 2018 under Uncategorized

In the late 90s and early 2000s, there was a wave of radical community servers, many of which fed into (or grew out of), the Indymedia network. Most of those veterans have sadly vanished from the web, and RiseUp, Framasoft, Comunes (OurProject), and CoActivate, are among the few still standing. As awareness grows of tech corporations like Microsoft, Apple, Google, FarceBook, and Amazon, putting their users in a digital cage, it’s great to see a whole new wave of cooperative groups coming together to replace these Web 2.0 prison canteens with ‘digital cafes’, like CommonsCloud, Disroot, and Social.coop, which I’m starting to get involved with.

A digital cafe (or ‘Open App Ecosystem‘) is a community of users and hackers providing themselves and each other with web services like social media (social networking, open publishing, or both), and sharing the costs. Since they’re doing many of the same things, rather than reinventing the wheel by writing all their software from scratch, they use a range of free code software developed by other groups. Sometimes they donate towards the financial costs of the peer production project that develops the software they use, and in other cases they have the skills and the time to contribute back to the project.

Social.coop began as group of members who set up a cooperative to share the costs of a site running Mastodon, a federated microblog server. Social.coop users can interact not only with each other, and with users on other sites running Mastodon (”instances”), but they can also interact with users on any site connected to a larger “fediverse” of federated social apps. The software makes these interactions across the fediverse possible by using common standards for exchanging data between social sites, initially using an older standard called OStatus. More recently a new standard called ActivityPub was published by the W3C (World Wide Web Consortium), the body that maintains the official standards for HTML, and everything else about how the web works under the hood. ActivityPub was the final output of W3C’s Social Working Group, which has now been replaced by the SocialCG (Social Web Incubator Community Group).

Social.coop depends on the work of all these other organizations in different ways, to keep their digital cafe running. But what’s the nature of the relationship between a cooperative running a digital cafe, and the groups maintaining the software they use? Does their sustainability depend more on making sure the project developing Mastodon has good governance? Or working on ensuring the reliability of their own servers, tweaking the software to serve member’s specific needs better, and perhaps adding new services, to help attract more members who can help reduce the costs per member?

You can’t have a cafe without a reliable electric and gas supply to the kitchen (the “back-end” of the server that users don’t see), and good mood lighting so people can feel relaxed but still see what they’re doing (UI or “User Interface“). But you don’t build a successful cooperative cafe by focusing on the internal politics of the energy utility, or the lamp shop. You focus on building your membership / customer base (users), and your collective capacity to provide them with good coffee, good service, and good food (UX or “User eXperience“).

If your energy supply becomes unreliable, you switch providers. If a coop-owned energy supplier emerges, great, switch to that. #ForkOffTogether could be that, and if people want to pitch that to them, go for it. But we can’t say for certain exactly which software they’re going to fork yet. Pleroma and Hubzilla are already options for ActivityPub server. Of these two existing, ready-to-use ActivityPub servers, I would say Hubzilla’s community probably has the closest overlap of values with social.coop. IMHO both their back-ends perform better than Mastodon’s Ruby-on-Rails engine, but other options continue to emerge (like Pylodon).

It’s the same with the lamp shop (UI). At present social.coop happens to be buying energy and lamps as a bundled package from Mastodon. But we’re not stuck with either, and we don’t have to get them from the same supplier at all. There are already a bunch of other lamp shops around, whose lamps can plug into the same power sockets (server-to-client API) that Mastodon uses. These include Pinafore (which I’m using these days and loving), and Halcyon, which is modeled directly on the look and feel of the birdsite, so fediverse sites who use that will have the minimum transition pain for refugees from there. Other lamp shops will emerge, and some of the existing shops whose lamps use different power sockets (eg Qvitter) might become compatible in the future. Hopefully, in a year or two, everyone will be using the same power sockets and plug standard (ActivityPub server-to-client API), so all lamps will work with all electric suppliers.

In a digital cafe, the energy supply is the maintenance crew’s problem (tech working group). As long as the lights stay on, the rest of the members don’t have to care about how they’re powered. The lamp situation, on the other hand, is something the members/ customers have to put up with while they drink their coffee. Decisions about which UI options social.coop offers need to be made by the membership, within the range of options that can technically work right now. Keep in mind that members can also get takeaway coffee (using a portal like pinafore.social to connect to their current instance), so they do have lighting options beyond what the tech group can set up and maintain right now.

The most important thing, the thing that *isn’t* a distraction, ever, is the coffee, the service, and the food. If we don’t get the UX right, it doesn’t matter how health or unhealthy the workplace is down at the energy company or the lamp shop, because we won’t keep the digital doors open long enough for their long term survival to matter. I love to geek out on organizational structures too. I get it. If that’s your thing, by all means go help the #ForkOffTogether folks become a cooperative energy supplier that social.coop can buy from (if they’re reliable suppliers). I totally endorse that.

Clear as mud? I may have over-extended the cafe metaphor somewhat, and as the old saying goes, no metaphor bears close examination. Feel free to hit me up about what I mean by this or that on the fediverse.

Filed June 12th, 2018 under open social networks, free software

Two years ago, Nadia Eghbal published a blog piece about how she hates the term “open source”, and not for the usual reasons; the way it misses the point of software freedom, emphasizing corporations’ freedoms to use the work of the free code community without reciprocity, instead of peoples’ freedoms to modify and share the software they use. Instead, her argument is that “open source”, as defined by the Open Source Initiative, is too specific and exclusive, and proposes that we start using a vaguer and more inclusive term like “public software”.

In that piece, she pulled a quote from another blog post by Mike Perham of Sidekiq, stripping it from the context of what Mike is arguing, and giving the initial impression that he is saying something totally different (and arguably incorrect). Upon reading Mike’s piece, where says …

“Open Source != Free Software”

… he clearly does not mean that open source software is not Free Software, as defined by the Free Software Definition (“libre” or “free-as-in-speech”). What he is saying is that open source software does not have to be free-of-charge (“gratis” or “free-as-in-beer”). Being gratis is not a requirement for being Free Software either:

“we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license.”

The two different meanings the word “free” has in English have always caused confusion, and this was probably the main reason the phrase “open source” took off in the Anglophone world (speakers of French and Spanish always know which meaning of “free” they’re using because they have words like libre and gratis). But the software freedom movement has always been concerned with finding ways to pay people to work on free code software. A recent example is the talk by Denver of JMP at LibrePlanet 2018 about Free Software business models.

The open source movement, on the other hand, was founded by people whose goal was to get people working on free code software paid for by corporations, entities that are highly allergic to concepts like “freedom”, “sharing”, and “cooperation”. The open source movement has been very successful with this, but with the consequence that most of that free code consists of back-end libraries under non-copyleft licenses (“MIT”, “BSD”, Apache 2.0 etc) which corporations then use to make proprietary apps for end users (including GitHub).

In his piece, what Mike recommends is licensing your code under a strong copyleft license (eg GNU AGPL), then selling exceptions to companies who don’t want to comply with the copyleft obligations of that license, like X-wiki Labs do with software like Cryptpad. Where this means a company is using and funding free code under a copyleft license, where they otherwise would have been using and funding proprietary software, this seems like good strategy. But this is more of an argument for using copyleft licenses than it is an argument for watering down or replacing the term “open source”.

If you’re looking for a more general term for collaborative work to create a common good, which is what people usually mean when they say “open source” outside of software (like Open Source Ecology, OpenStreetMap, WikiHouse, and WikiSpeed), I suggest “peer production”. If you need a term for people dumping their “IP” into an unstewarded commons, using something like CC Zero or the WTFPL, I think “public domain” does the job nicely. Perhaps there needs to be another term for things like Tesla offering free licenses for their electric car patents, because while this was a public-spirited offer, it is not “open source” by either common definition of the term (free code or peer production).

But I honestly don’t understand what purpose Nadia wants a term like “public software” to serve. How does it help anyone to fudge free code (open source/ Free Software/ FOSS/ FLOSS) together with “shared source” (you can see it but not use it), and “fair source” (basically shareware), and code placed in the public domain, and unlicensed code (which defaults to ARR copyright in the US and most jurisdictions), and arguably inappropriate use of CC licenses for code (to create proprietary freeware), as if these are all the same thing? Because whatever the motivations behind them, these approaches have very different consequences.

Filed May 30th, 2018 under Uncategorized

OpenBenches.org is an open data project that collects photos and information about memorial benches in public places.

OpenBenches photo by @sjorford (CC BY-SA) 

I learned about them today, thanks to iSpooge developer Harlan Iverson, who shared a link to OpenBenches blog piece on having their birdsite account suspended by bots and then just as mysteriously restored - minus their followers. In that piece, they felt the need to defend their use of the birdsite, saying:

“Yes, I know. We should redecentralize and put our content on Mastodon, or the BlockChain, or some other convoluted platform which has no users.”

I drafted a response to them in a GH Issue but it got long, so I’m posting it here with a TL;DR version there.

I share your sceptical view of blockchain startups whose “decentralized” software only connects with other versions of itself, but Mastodon is part of a larger network known informally as the fediverse, all inter-operating via a common standard called OStatus. The OStatus fediverse is currently made up of 6 federated apps (including GNU Social), all with multiple live instances, most of which are multi-user (although some people do self-host a single account). There’s plenty of us there to share your bench photos with.

Obviously, it’s not necessary to stop using the birdsite to start experimenting with decentralized replacements. The GNU Social server that my fediverse account is hosted on can be set up to automatically repost anything I post there to my account on the birdsite, so I can publish on both networks with the same action. There are similar bridging tools available for Mastodon, and probably for some of the other apps.

If you don’t want to set up a separate microblog app on your server at all, you can use IndieWeb protocols to enable your existing openbenches.org website to inter-operate as a first-class citizen of the social web. This can connect you with the rest of the IndieWeb right away, and eventually with the fediverse using BridgyFeb (note: this is about a year old and still experimental). W3C recently made ActivityPub an official web standard for social networking, and all the fediverse apps either have implementation rolled out (eg Mastodon), or are working on it, and the same is true for a growing list of other apps (including BridgyFeb).

It’s hard to get an accurate population census of the fediverse vs. the birdsite. Even if you could find out the total number of accounts on all fediverse instances, it’s hard to know how many of these are test accounts set up by one user to try out the UX of the different apps (I have several). You can get user numbers for the birdsite, but it’s hard to know how many of these are bots or sock puppets, rather than unique human users.

Anecdotally, I’ve never had more than about 200 followers on the birdsite, while I’m humbled to have about 600 people following my current fediverse account. So, a large total number of users on a platform doesn’t guarantee greater engagement for any given feed published there. But it does contribute to the network effect that leaves users like yourselves feeling trapped there, despite the user maltreatment you experienced. Someone once convinced you to use the birdsite because they were already there, despite not knowing anyone else who was. You could be that person or project in the fediverse for your social network.

Filed May 8th, 2018 under open social networks

Update 2018-10-01: it just occurred to me that I could be missing out on potential donations by deleting emails from PayPal (which I presume to be spam), and emails offering me money (which I presume to be variants on 419 fraud). If you’ve ever tried to donate to Disintermedia, please reach out via the fediverse (where scam messages haven’t appeared yet), and let me know, so we can figure out if the money left your account, and where it went.

——–

A couple of years back, I decided to see if I could actually get funded by the communities who I created Disintermedia to inform and support. I started gathering information about different ways people could pay me over the internet, and adding it to a page called Help Disintermedia, which was initially created to publicly thank services like CoActivate that help us in non-monetary ways. First, I experimented with setting up the software to receive BitCoins, and put up a wallet address (is that right?), and over the next year that was followed by a link to a Patreon page, and then a Liberapay page. These “micro-patronage” sites allow people to give small, regular amounts, and in theory, like newspaper subscriptions, many people’s small payments can add up. I’m embarrassed to admit that so far, these efforts have been a dismal failure.

For a start, the BitCoin address I published was: 19KER7hfqXhZnHnnJ3VcGRr2w3i1v6e44e

But I have no idea now where this directs BitCoins to, or if anyone actually donated any, how to retrieve them. I just haven’t had the time to do all the reading required to fully understand how to use BitCoin; how to back up my wallet, how to accept payments to the same wallet from multiple devices, whether I can do this using the same address, so many questions! The same is even more true for other crypto-tokens (FairCoin, FreiCoin, SolarCoin, NameCoin, FileCoin etc). If you can help me get to grips with any of this, especially if you are keen to donate to Disintermedia  please feel free to contact me.

I’m also considering figuring out how to use Brave, Minds, SteemIt, Earn.io, and a bunch of other new systems that claim to offer ways of paying creators who contribute to the weaving of the free web. But seriously, figuring out which of these are honest, and viable, is a high-stakes research project in and of itself. With real money involved, there’s no kind of software more attractive to bad actors, idealistic incompetents, and venture capitalists. They all take time to set up and learn to use well, and you can’t get any benefit out of them without giving them real personal details and banking information. On top of that, there’s a risk involved in implicitly endorsing them if they end up being dodgy.

I’ve thought about experimenting with the newly relaunched Flattr 2.0, since unlike most micro-patronage sites, it’s pretty set-and-forget. Creators can get paid through it without needing to constantly self-promote (”click here to subscribe!”). There have been some hard questions asked about the privacy implications of the Flattr browser extension, but the developers do sound like they take privacy seriously, and it’s encouraging that all their apps are free code (not sure about the javascript on the site itself though). Another critical question is about how much money creators can realistically get out in payments. Even if they took 50% of whatever Flattr payout I got, that’s still potentially more than I’d get by not using it at all, but the new fees scheme for Flattr does seem to take a lot of bites out of my sandwich before I get to eat it.

Really, if the developers of any of these community funding platforms really think they are viable, they should be eating their own dogfood, and funding themselves using their own platform. Gratipay did this (RIP), and Liberapay still do, which is why I tried them first. Any platform skimming their users’ donations with fees, or heaven forbid, sucking up to venture capitalists, isn’t showing much confidence in their own funding platform. After all, you don’t see GitHub developing the code for GitHub on another code forge (they might have a backup there but that’s different).

For example, Ko-fi fund themselves using their own platform, instead of taking fees. I can’t find any source code though, and their use of a proprietary mail missile called SendGrid to send out emails isn’t encouraging. Ko-fi is designed to give the original Flattr model another go; buttons creators can stick on their web page, that users can click to “buy me a coffee”.

A Flattr developer posting on HackerNews claimed that model failed, because:

  • a) people using the web don’t want to click buttons (?!?)
  • b) publishers didn’t want another private company’s branded buttons all over their site

None of this seems to affect PaylPal / Stripe or social media buttons. I suspect it was more like:

  • a) people are used to having to enter their credit card details (or deal with PayPal shudder) when they click a donate button, which is a painful and scary user experience
  • b) when Flattr launched you couldn’t get paid anything without first setting up a monthly contribution to Flattr so most people didn’t bother (that’s why I didn’t), and nobody wanted buttons all over their site promoting a thing that smelt like a pointless ponzi scheme
  • c) Flattr funded themselves by skimming off 10% every time credit moved across their platform, and as mentioned above, Flattr 2.0 has even more ways to charge everyone.

I’ve set up a Ko-Fi account, just to try it out. Is it really going to help to add yet another layer of management between me, PayPal, the bank, and the person trying to give me money? I’m sceptical about whether it was worth the time, or the indignity of having to deal with PayPal or some other toll collector on the information superhighway (again, shudder). Frankly, I’m not convinced that Ko-Fi is an improvement on just having a button for PayPal or Stripe, although it is nice to not have their garish corporate branding all over an activist website. But hey, prove me wrong, buy me a coffee!

Buy Me a Coffee at ko-fi.com

I suspect that for the contribute button thing to really take off, it needs to become a neutral web standard, so the buttons are all over the web, they always look the same, and its a standard icon on them, not one company’s logo. The person clicking them can set up a payment system that gets activated when they click the contribute button, and website creators can decide which payment gateway processes the money when they get clicked. I’m hoping GNU Taler takes off, and we can eventually use that. If anyone reading this is involved in a credit union, or cooperatively owned bank, who might be willing to get involved in a pilot scheme, I encourage you to contact the Taler team.

For now, if anyone can recommend any other sites for collecting one-off donations for struggling web writers, that would be much appreciated. If you want to donate, and you don’t mind the banking system knowing it, please contact me, and I can give you bank account details privately.

Filed April 19th, 2018 under free culture, independent media, News, open source

In 2016, I included a graph from Layer 3 Networking blog, in a rant about the tendency to put on weight over time that I’ve seen in even the most lightweight GNU-Linux DE (Desktop Environment). The blog piece I took that graph from gave a detailed run-down of the lightweight DE ecosystem, as it stood in 2013, which still serves as the most thorough introduction I’ve found on the subject.

Being 5 years old now, the graph can’t be treated as a true indication of how much RAM more recent versions of these DEs might use. But it does offer an idea of just how different free code DEs are out there, some screenshots of what some of the lighter ones look like installed, and roughly how much RAM a wide range of them use relative to each other. It also gives the exact methods used to make the RAM use comparisons between DEs, which is important to whether their results are a fair comparison, and another reason I still consider this a useful guide despite being five years old.

Obviously, being 2013 data, some of the DEs mentioned are now superseded or defunct (eg E17, Unity), or merged (LXDE and Razor-QT are now LXQT), and other newer ones aren’t mentioned (Artemis, Moksha, Pantheon, Yunity, Zorin etc). Based on the numbers from the graph there, I’d say in 2013 you could break DEs down into 3 categories (RAM use numbers assume a freshly booted system running no extra user apps):

  • Small (0-20MB): TinyWM, 9wm, miwm, wm2, dwm, Ratpoison, olvwm, TWM, xmonad/mobar, JWM, i3, Blackbox, Sawfish, IceWM, PekWM, Openbox, Window Maker, awesome, FVWM, Fluxbox, Mutter
  • Medium (20-100MB): E17, LXDE, KWin, Mate, Trinity, XFCE, Cinnamon
  • Bloated (>100MB): Razor-QT, GNOME 3, Unity, KDE

The DEs I describe as bloated are clearly targeted at providing every imaginable widget and performance boost, for users with fairly new hardware, or middle-aged hardware that’s been upgraded or is unusually powerful. Unless you are a business with deep pockets, or someone else who upgrades your computer every couple of years so you can always run the newest software, I suggest avoiding the bloated category. That is, if you don’t want to end up switching to a lighter DE in a couple of years, as the hardware requirements of the bloated DEs continue to creep up towards the latest hardware.

Cinammon, a fork of GNOME 2 developed for the Mint distro, offers everything the average user needs from a desktop experience, while using significantly less RAM than older and more common DEs like KDE Plasma or GNOME 3. Mate, Mint’s lightweight DE, uses even less RAM, while still providing a familiar point-and-click desktop, with the bells and whistles familiar to Windows users who have used any version of Windows from 95 to 7. I’m typing this on an Acer Aspire One that’s nearly 10 years old, and the Mate desktop in the about-to-be-released Trisquel 8 runs fine, although I have improved the performance by doubling the RAM to 2GB and, more importantly, replacing the internal drive with an SSD (Solid State Drive). I can’t emphasize enough what a big difference the SSD makes.

If you still want to be using your computer in ten years time, especially if you bought a netbook or some other unusually under-powered PC like I did, I strongly recommend getting familiar with the pros and cons of the DEs in the small category. If I just want to play a game, I use Openbox, and I really notice how much better the heavier games run without all the extra desktop bells and whistles taking up resources. I intend to get into a habit of logging into Openbox whenever I plan to work on a long piece of writing, or anything else that doesn’t really require flipping back and forth between apps.

In summary, I can’t tell you which DE is right for you, and just to confuse you even more, the same DE can use a different amount of resources depending on which GNU-Linux distro you’re running it on, and even whether or not it’s the default DE for that distro. But it’s definitely worth doing some reading, and choosing one that not only does what you want right now, but will keep doing it for as long as you don’t want to have to switch to keep your computer usable.

Filed April 16th, 2018 under Uncategorized

Update 2018-05-23: I just read a highly misleading piece on The Atlantic called ‘Email Hackers are Winning‘, discussing a recent crack called ‘Efail” that proves encrypted email can be cracked, and claiming that Efail:

“showed that encrypted (and therefore private and secure) email is not only hard to do, but might be impossible in any practical way, because of what email is at its core”

Ummm … no. For the Efail crack to work, the receiver of the malicious email has to have HTML mail turned on in their email app. If HTML mail is turned off, Efail … well … fails. The core of email - the email protocols - have nothing to do with it. The author, security blogger Quinn Norton, who really ought to know better, also claims that the fundamentals of email have remain unchanged since the 1970s. Since that was before HTML was invented, if that was true, Efail wouldn’t work at all. Indeed, the email protocols are constantly being improved through standards work at the IETF (Internet Engineer Task Force). However, despite the weird fairy tale Quinn wraps around the story of Efail, it is yet another very good reason for activists not to use HTML mail.

——————————

I wrote a couple of blog pieces last year about how horrified I am when I find activist groups and other social change organizations helping surveillance capitalism tools like NationBuilder and MailChimp to track their supporters. In the MailChimp piece, I also took the opportunity to gripe about people sending HTML pages as emails. At the risk of sounding like the 1990s internet equivalent of people who moan about how nobody sends paper letters anymore, I just wanted to share a few resources about just how dodgy HTML mail can be.

To set the scene, here’s what I said in the MailChimp piece:

While we’re on the subject of mass email, the “service” that seems to make MailChimp so attractive is that is uses HTML to add a bunch of trackers to the email sent through its servers. Putting aside the ethics of enabling companies to use email to track people we like, I strongly discourage people from sending HTML by email.

Email is designed as a text-only medium, and works better this way. HTML email massively increases the amount of space email takes up in someone’s inbox, how much of their data allowance is used looking at it, and how much of the total resources of the internet are used by email that may not even be wanted or seen. HTML email also creates vectors for viruses and malware to spread through email, vectors which do not exist in plain text email.

If you want to show someone a page of HTML, it’s better to put that on a website, and include a link to it in a plain text email. That way people can read the email anytime, then look at the linked web pages when they are using fast, un-metered internet. This is also helpful to people still using dial-up connections, or slow rural broadband.

But hey what do I know? I’m just a guy who researches user-respecting software and writes a tech blog. I practically live in my Mum’s basement. How about we consults some experts?

Let’s start with George Dillon, a performance artists and web designer. Now we all know how much web designers love HTML, and George has been building his own websites since the late 90s. But his article on using HTML for email lists seven reasons why HTML mail is “evil”, or at least unhelpful and unnecessary, covering many of the points I touched on but in more detail. OK, it hasn’t been updated in about ten years, and some of the specifics may seen out-of-date (HTML mail exploits are the least of your worries if you’re still using Windows XP), but you’d be amazed how many people still use dial-up connections to access the net. As I forgot to mention in the MailChimp piece, many of the same issues that apply to dial-up also apply to people using mobile devices to read their email, on metered net connections they pay through the nose for.

Next, let’s pay a visit to tech writer M. E. Kabay, who wrote a 2004 piece about the growing use of HTML in email, for NetworkWorld.com, describing a number of specific security holes made possible by HTML mail, and dismissing it as a pointless source of …

“unwanted, mislabeled links, Web bugs, harmful active content, and outright worms and viruses”.

 Kabay sums up the piece with this advice:

“I urge everyone to send plain text instead of HTML as the default format for outgoing e-mail. If you need to send a message with features beyond text, you can always create a word-processing document and send that.”

Now I know what you’re thinking. Like me, these articles are showing their age. I mean, 2004 was more than a decade ago. Surely all these security problems have been solved by now, right? Nope. Here’s the conclusion of an article published on The Conversation in 2017, written with input from security researcher Robert Graham:

“Security-conscious users must demand that their email providers offer a plain-text option. Unfortunately, such options are few and far between, but they are a key to stemming the webmail insecurity epidemic. Mail providers that refuse to do so should be avoided, just like back alleys that are bad places to conduct business.”

The title of the piece is ‘The only safe email is text-only email‘. Need I quote further?

Finally, there’s StackExchange, a Q&A website where anyone can ask a question, and the answers from the communities of experts there get upvoted, and downvoted, and commented on, and edited, until only the best answers are left standing. A question about the security risks of creating a webmail that allows HTML mail was asked in the software engineering department, and my favourite quote from among the answers given is this one by one Michael Shaw, which pretty much sums it all up:

“Start allowing anything beyond presentational [HTML] tags and you are making assumptions that you know more about how these tags can be misused than the mal-ware writers. And believe me, that is a brave claim for anyone to make.”

Asked a question on the internet, actually got a useful answer.jpg

Filed April 12th, 2018 under security
Next Page »
  • Annual Events

  • Digital Freedom Foundation
  • LibrePlanet
  • Aotearoa

  • Aotearoa Indymedia
  • BallaNZ
  • Creative Commons Aotearoa/ NZ
  • Creative Freedom Foundation
  • DigitalNZ
  • Enspiral
  • Fair Deal Coalition
  • GreenStage
  • InternetNZ
  • Island Bay World Service
  • Living Economies
  • Localise
  • Loomio
  • Matrix FM
  • Nicky Hagar
  • No Right Turn
  • NZ Council for Civil Liberties
  • NZ Makers
  • NZ Makers Map
  • NZ Māori Internet Society
  • NZ Open Source Awards
  • NZCommons
  • OASIS
  • Open Government Ninjas of NZ
  • Open Source Society of NZ
  • Open Standards NZ
  • Open Ur Eyes
  • Pacific Media Centre
  • Permaculture in NZ
  • PledgeMe
  • Radio Chomsky
  • Regulation
  • Scoop
  • Tech Liberty
  • Timebank Aotearoa
  • Transition Towns Aotearoa/ NZ
  • Uncensored Magazine
  • Waatea News
  • Waikato Linux Users Group
  • What If
  • Wiki NZ
  • Zenbu
  • archives

  • ArchiveTeam
  • Critical Commons
  • Ibiblio
  • Internet Archive Community Software Collection
  • Open Archives Initiative
  • Blogroll

  • Abject
  • Access Now
  • Ars Technica
  • Autonomo.us
  • BadScience
  • Banjo - RoboBlog
  • Boing Boing
  • Born out of Binary
  • Centre for Media and Democracy
  • Choke Point Project
  • Copyrighteous
  • Create Digital Music
  • Creative Commons International
  • Cryptogon
  • Digital Standards Organisations
  • Disinfo
  • E-Democracy
  • Electronic Privacy Information Center
  • Ever Vigilant
  • Freedom Box Foundation
  • Freedom of the Press Foundation
  • Gaming On Linux
  • Global Indymedia
  • Gondwanaland (Mike Linksvayer)
  • Institute for the Future of the Book
  • Institute of Network Cultures
  • Internet Governance Project
  • InternetNZ
  • Island Bay World Service
  • Iterating Towards Openness
  • Knowledge Ecology International
  • LinkedListCorruption
  • Linuxed - Exploring Linux Distros
  • Localise
  • Moved by Freedom - Powered By Standards
  • Nanowares
  • New Zealand Māori Internet Society
  • Nicky Hagar
  • No Right Turn
  • NZ Council for Civil Liberties
  • NZCommons
  • O'Reilly Radar
  • OASIS
  • OERu Technology Blog
  • Open Educational Resources Foundation
  • Open Knowledge Foundation
  • Open Rights Group
  • Open Social Web
  • Open Source Conscious Intelligence Network
  • Open Source Food
  • Open Stand
  • Open Ur Eyes
  • OpenCollective
  • OpenDotDotDot
  • OpenSource.com
  • Permaculture in NZ
  • Plumi
  • Public Interest Journalism Foundation
  • Punk Rock Permaculture
  • Question Copyright
  • Replicant (OS)
  • Rob Meyers
  • Schneier on Security
  • Scoop
  • Shareable
  • Slashdot
  • Software Freedom Law Centre
  • Software in the Public Interest
  • SourceMap
  • Sustento Institute
  • Tech Liberty
  • TechRights
  • The Tin Hat
  • Tinkering Down Under
  • TorrentFreak
  • TransitionMovement
  • Translation Project
  • Trisquel GNU/ Linux
  • United Diversity
  • Waatea News
  • We Speak for Freedom
  • Why Your Boss is Programmed To Be a Dictator
  • code bank

  • Allura
  • BitBucket
  • FusionForge
  • GITHub
  • GITLab
  • Gogs
  • Internet Archive Community Software Collection
  • LaunchPad
  • NotABug
  • Savannah
  • Software Freedom Conservancy
  • Software Heritage
  • Sourceforge
  • community economics

  • Commons Transition
  • Fruit Tree Planting Foundation
  • In Our Back Yards
  • Institute for Local Self-Reliance
  • Libre-Living
  • Living Economies
  • Sensorica
  • Sustainable Economy Law Centre
  • Timebank Aotearoa
  • TransitionMovement
  • cooperative

  • Loomio
  • Snowdrift Coop
  • crowdfunding

  • ArtistShare
  • BountySource
  • Causes
  • CauseVox
  • Crowdfunder
  • Crowdjustice
  • Crowdrise
  • Crowdsupply
  • Flattr
  • Fundit.buzz
  • GiveaLittle
  • Goteo
  • In Our Back Yards
  • KickStarter
  • KissKissBankBank
  • Mighty Cause
  • OpenGift
  • Patreon
  • PledgeMe
  • PledgeMusic
  • Pozible
  • Snowdrift Coop
  • StartSomeGood
  • Taproot Foundation
  • The Working World
  • Tidelift
  • Events

  • IndieWebCamp
  • free code

  • April
  • Black Duck Open Hub
  • DistroWatch
  • Ever Vigilant
  • F-Droid
  • Free Software Directory (GNU FDL 1.3 or later)
  • Free Software Support Network
  • Free Software Support Network
  • Free Your Android
  • FreshCode
  • Gogs
  • Gun.io
  • Internet Archive Community Software Collection
  • LILA
  • LinuxTracker
  • NotABug
  • OERu Technology Blog
  • Peers Community
  • Plumi
  • PublicLab
  • Replicant (OS)
  • Software Heritage
  • Urchn Studios
  • Free Media

  • Communes Collective
  • Copyrighteous
  • Create Digital Music
  • Definition of Free Cultural Works
  • Dyne Foundation
  • FLOSSManuals
  • Free Culture Foundation
  • Ibiblio
  • Librivox
  • LILA
  • Open Video Conference
  • Show Me Do
  • Translation Project
  • Urchn Studios
  • WikiLeaks
  • freelancing

  • BountySource
  • Gun.io
  • independent media

  • Aotearoa Indymedia
  • BallaNZ
  • EngageMedia
  • Freedom of the Press Foundation
  • LILA
  • Matrix FM
  • Pacific Media Centre
  • Public Interest Journalism Foundation
  • Radio Chomsky
  • Radio Heritage Foundation
  • Uncensored Magazine
  • Waatea News
  • libre gaming

  • Gaming On Linux
  • Makers

  • GreenStage
  • Libre-Living
  • Mediamatic
  • NZ Makers
  • NZ Makers Map
  • Open ROV
  • Renewable PCs
  • Rob Meyers
  • Sensorica
  • maps

  • GeoForAll
  • GeoNames
  • Green Map System
  • Map Tools
  • Open Geospatial Foundation
  • Open Street Map
  • open governance

  • Crowdfunding
  • D-Cent
  • Deep Democracy Institute International
  • E-Democracy
  • Fight for the Future
  • Holacracy
  • Internet Governance Project
  • Kettering Foundation
  • Knowledge Sharing Toolkit (CC-BY-SA 3.0)
  • Open Government Ninjas of NZ
  • Open Policy Network
  • Open Space World (CC-BY-SA 2.5)
  • Open Stand
  • Open Standards NZ
  • Participedia
  • Sunlight Foundation
  • Transition Towns Aotearoa/ NZ
  • What If
  • WikiLeaks
  • open hardware

  • H-Node
  • Makey Makey
  • Meeblip Open Source Bass Synth
  • Open Hardware Summit
  • Open ROV
  • Open Source Hardware Association
  • Orgs

  • Access Now
  • Apache Foundation
  • April
  • Autistici/Inventati
  • Collaborative Knowledge Foundation
  • Commons Transition
  • Communes Collective
  • Computer Professionals for Social Responsibility
  • Creative Commons Aotearoa/ NZ
  • Creative Freedom Foundation
  • Critical Commons
  • D-Cent
  • Deep Democracy Institute International
  • Digital Due Process coalition
  • Digital Freedom Foundation
  • Digital Standards Organisations
  • DigitalNZ
  • Dyne Foundation
  • E-Democracy
  • Electronic Frontiers Foundation
  • Electronic Privacy Information Center
  • Fair Tracing Project
  • Fight for the Future
  • Foundation for Peer-to-Peer Alternatives
  • Free Culture Foundation
  • Free Network Foundation
  • Free Software Foundation
  • Free Software Support Network
  • Free Software Support Network
  • Freedom of the Press Foundation
  • Guifi
  • Ibiblio
  • Identity Commons
  • Institute for Local Self-Reliance
  • Internet Engineering Taskforce
  • Internet Governance Project
  • ISA Commons
  • Kettering Foundation
  • LEAP Encryption Access Project
  • LILA
  • Living Economies
  • Loomio
  • May First/ People Link
  • Mediamatic
  • NZ Māori Internet Society
  • NZ Open Source Awards
  • Open Architecture Network
  • Open Archives Initiative
  • Open Geospatial Foundation
  • Open Policy Network
  • Open Source Hardware Association
  • Open Source Society of NZ
  • Open Web Foundation
  • OpenADR Alliance
  • OpenCorporates
  • OpenHatch
  • Participatory Culture Foundation
  • Peers Community
  • Permaculture in NZ
  • Privacy International
  • Public Citizen
  • Public Interest Journalism Foundation
  • Public Knowledge
  • Public Patent Foundation
  • Question Copyright
  • Radio Heritage Foundation
  • ReDecentralize
  • Reform Government Surveillance
  • Regulation
  • Rhizome
  • RiseUp
  • Science Commons
  • Software Carpentry Foundation
  • Software Freedom Conservancy
  • Sunlight Foundation
  • Sustainable Economy Law Centre
  • Taproot Foundation
  • Transition Towns Aotearoa/ NZ
  • Waikato Linux Users Group
  • Wiki NZ
  • World Wide Web Consortium (WC3)
  • Xiph.org
  • XMPP Standards Foundation
  • Peer2Peer

  • BitCoin
  • FreeCoin
  • Permaculture

  • Appropedia (CC-BY-SA 3.0)
  • Fruit Tree Planting Foundation
  • Future Scenarios
  • OrganicDesign
  • Permaculture in NZ
  • TransitionMovement
  • We Speak for Freedom
  • Privacy

  • Access Now
  • Digital Due Process coalition
  • Ever Vigilant
  • Fight for the Future
  • International Principles on the Application of Human Rights to Communications Surveillance
  • LEAP Encryption Access Project
  • OASIS
  • Privacy International
  • Reform Government Surveillance
  • What If
  • protocols and licensing

  • Definition of Free Cultural Works
  • Digital Standards Organisations
  • Greenlots
  • ISA Commons
  • Open Archives Initiative
  • Open Stand
  • Open Standards NZ
  • Open Web Foundation
  • OpenADR Alliance
  • Regular Events

  • Libre Graphics Meeting
  • Open Hardware Summit
  • science and datasets

  • AllTrials
  • Collaborative Knowledge Foundation
  • DigitalNZ
  • Fair Tracing Project
  • ISA Commons
  • Open Geospatial Foundation
  • Open Hand Project
  • SourceMap
  • Wiki NZ
  • Zooniverse
  • Tools

  • Autistici/Inventati
  • BitCoin
  • Black Duck Open Hub
  • CoActivate
  • Crowdfunding
  • DistroWatch
  • Dyne Foundation
  • F-Droid
  • FLOSSManuals
  • Fork the Cookbook
  • FreeCoin
  • GITHub
  • GNU Operating System
  • GreenStage
  • H-Node
  • How To Escape the GoogleMax Panopticon
  • Knowledge Sharing Toolkit (CC-BY-SA 3.0)
  • LEAP Encryption Access Project
  • LinuxTracker
  • Loomio
  • Map Tools
  • May First/ People Link
  • Meeblip Open Source Bass Synth
  • Monolith
  • Open Hand Project
  • Open Source Ecology
  • Open Space World (CC-BY-SA 2.5)
  • Open Street Map
  • OpenCorporates
  • OpenMailBox
  • Participatory Culture Foundation
  • Plumi
  • Renewable PCs
  • Replicant (OS)
  • RiseUp
  • Savannah
  • Show Me Do
  • Sourceforge
  • SourceMap
  • TransforMap
  • Translation Project
  • Web Platform
  • Zenbu
  • Transition

  • Green Map System
  • Health After Oil
  • Localise
  • OrganicDesign
  • Wiki

  • Appropedia (CC-BY-SA 3.0)
  • Foundation for Peer-to-Peer Alternatives
  • Instructables
  • LibrePlanet
  • Open (Government) NZ
  • Participedia
  • SourceWatch
  • WikiEducator
  • wireless mesh

  • Guifi
  • workplace democracy

  • Enspiral
  • The Working World