If you have a personal blog at wordpress.name.tld or a self-hosted gitlab instance at gitlab.name.tld, that is technically violating trademark rules.
I don't think it is strictly enforced though because there aren't any services ( that I know of at least ) that have gathered more popularity ( with misdirection in their domain names ) than the original services.
#TIL you can't have 'gitlab', 'wordpress' or 'ghost' in top-level domain names because they are protected trademarks.
- GitLab : https://about.gitlab.com/handbook/marketing/growth-marketing/brand-and-digital-design/brand-guidelines/#trademark
- WordPress : http://wordpressfoundation.org/trademark-policy/
- Ghost : https://ghost.org/trademark/ > Automatic Restriction.
Don't be shy with DNS TTLs.
If you have settled your services on one or more IP addresses, push the TTL up. 12-24 hours are no problem. You mitigate almost all service outages from your DNS providers by that.
Main thing you have to keep in mind is that if you want to move a service around, you can either move the IP address with your service or should to lower the TTL at least 12 hours before moving the service.
@DesCoutinho @praveen 2. Free Software is accountable and without accountability and the option to run a service on our own (a.k.a self-hosting which allows decentralization), we can't simply ensure privacy protection. Closed and centralized services like Facebook, Whatsapp, Twitter, etc. pose a huge threat to our privacy as well as free speech. That's the price we've to pay for our 'convenience' in using their free-of-cost 'services'.
@DesCoutinho This is the simplified version (copied from gnu.org): “Free software” means software that respects users' freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software. Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.
If you have any doubts, I'll try to answer them according to my knowledge.
@DesCoutinho Free radicals, nice pun! 😄
BTW software freedom isn't that complex to understand neither it requires knowledge of software engineering. It's basically about four freedoms: Freedom to run the software for any purpose, freedom to study how the software works, freedom to share the software with anyone, freedom to share the modified version of the software.
'Free' in Free Software stands for Freedom!
For more details: http://www.gnu.org/philosophy/free-sw.html
"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say."
— Edward Snowden
Similarly, the argument that you don't care about software freedom because you don't know coding can be considered as same. It's like arguing that you don't care about the food you eat because you don't know cooking!
It's important to think about trust and reliability transitively. For example, if you choose to use GitLab, you have to also acknowledge that you're choosing CloudFlare and Google Cloud Platform. CloudFlare is having problems today, therefore GitLab is having problems today. Shouldn't come as a surprise.
Full disclosure for sr.ht: you are transitively relying on Twilio to wake me up during off-hours if something goes wrong. Other than that, there are no third-party infrastructure dependencies on sr.ht like CloudFlare which could trigger issues; we colocate all of our servers and manage our own network. And that also leave us in a position to address any problems ourselves, without having to twiddle our thumbs and wait for a third-party to figure their shit out.
By the way, thanks to the help of @nathand I was able to reproduce the issue earlier today.
I can official say that one shouldn't use the implementation of canarymail for OpenPGP, because it's unaware of how to select the right key. They not only are unable to select the encryption sub key, but also ignore expiry dates and key revocation, making it an actual danger.
We need to defeat this bizzare cognative dissonance people face when they have to re-evaluate the place email holds in their mind. It's not some useless relic of the last generation to cast off in the course of chasing the shiny new.
- Built with open standards
- Fault tolerant
- Enjoys a wide variety of open-source clients & servers
- Has widely available implementations for almost every programming language
- Already being used for software development at scales greater than GitHub-style development has ever dreamed of
Screw that noise. Set aside your preconceptions and look at email for what it is. The things that make you "yuck" about email are more related to the bastardization of email *software* by corporate interests like Google and Microsoft, and have next to nothing to do with email itself.
@nolan I think any effort towards killing electron with fire is a good thing. In the mobile space the vast majority of apps seem to be little more than custom containers for web content made to deliberately circumvent security, privacy and user control. Electron seems almost deliberately designed to bring that evil practise to the desktop.
My main concern is that the big G seems to be the only significant player in desktop PWA and they shouldn't be trusted with setting standards by themselves.
@dch Sure, you can also use Lynx to browse the web, your terminal to send emails, etc. Healthy limits. 🙂
The other thing to be aware of is that browsers are smart about reducing bloat in tabs. They suspend/throttle background tabs, share memory wherever possible (e.g. across same-origins), etc. I'd still rather have 10 webapps open in 10 browser tabs than 10 Electron apps.
Some people prefer the Electron versions of apps because they like being able to press Alt-Tab instead of having to pin a browser tab. Or they like that it's better integrated into the system notifications. For me, this is a bad reason to compromise so much security (and performance as well – you're running a whole extra instance of Chromium).
With an Electron app, you're basically running a custom-made browser where the authors have to be trusted to get two aspects of security right – the web dev part, and the browser dev part.
If a website is insecure, worst case scenario (most of the time) is that an attacker can get access to that site's data. If an Electron app is insecure, worst case scenario is that the attacker gets full system access to do whatever they want. That's terrifying.
"Remote Code Execution in Slack desktop apps" https://hackerone.com/reports/783877
This is why I refuse to use Slack, Discord, etc. in their native app versions – only in the browser. Browsers have gotten pretty good at sandboxing and auto-updating. Historically, Electron apps have demonstrated themselves to be good at neither.
Nerd | Tech Freak | Linux Geek | Terminal Freak | Open source lover | Free Software zealot | DevSecOps | Privacy Enthusiast
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!