My attention span for text editor configuration decreased drastically after I finished school. For better or worse, being a professional means making the correct trade off when time, money, and productivity are at stake.
In the modern era, there are sufficiently many practical editors and IDE's with major economic investment behind making them highly functional out of the box. I simply cannot justify spending copious amounts of time configuring a text editor when there's sufficiently good and productive options out there.
As long as you know your tools and can achieve everything it doesn't matter which tool you choose.
I tend to mentor a lot of newbies and they often use VSCode, but since they are newbies they don't know how to do basic things like search (and replace) and I can't help them since I've only used vim. I have tried to give VSCode a go couple times to get more familiar with it, but I run into same issue as you - I simply can't justify in my head the time and effort to familiarize myself with the editor, figure out what settings to use and which addons to add.
Yeah, I don't get the "use Vim for everything" approach unless you're just doing it because you find the customization and configuration fun. I usually use VS Code for quick editing and full IDEs for real work with big projects.
Modal editing is awesome though. I use modified Vim keybinds for everything, even web browsing.
I only took a brief look, but I like the premise. The service seems far from something I would trust with handling my email. I still trust Fastmail (for reference). But I strongly welcome more alternatives to Gmail and services which prioritize user privacy. The attempt at monetization strikes me as extremely premature, given the competition. But I hope to see more.
> The service seems far from something I would trust with handling my email.
I think that's entirely fair. This is a pretty new project, and trust is built over time.
> The attempt at monetization strikes me as extremely premature, given the competition.
Free email services leave a bit of a sour taste in my mouth, since you're not the customer. I'd also have to put more work into stuff like adding hard caps to prevent abuse, but my thinking so far is that email really isn't something you should fuss over storage caps on.
It might be ultimately necessary to attract people (although Fastmail doesn't have a free tier), but I'll get there when I get there. I'm content to take it slow for now.
> Free email services leave a bit of a sour taste in my mouth, since you're not the customer. I'd also have to put more work into stuff like adding hard caps to prevent abuse, but my thinking so far is that email really isn't something you should fuss over storage caps on.
Thank you! I love being able to just pay a (modest) fee and not have to worry (as much) about perverse incentives. It fixes or minimizes so many problems.
The problem is the level of trust. I don't trust Google, as an advertising company with a side business of technology, to keep its paws off of user data even in "anonymous" form. That's not malice; it's just temptation. There's way too much to gain, from Google's perspective, and comparatively little to lose by not keeping that wafer-thin wall intact.
FastMail, et al, alternatively aren't primarily engaged in the advertising business so they'd see a very small return from violating that trust and massive losses, so the gain/loss relationship is inverted.
What scares me most about gmail is the fear that one day an algorithm will decide I'm doing something wrong and terminate my account and no prospect of appealing the decision.
Do you think that Google would intentionally violate their contracts with various huge companies (Broadcom, BBVA, Colgate-Palmolive, etc) gain a little bit more advertising revenue? If nothing else the personal lawsuits for securities fraud against executives would be a huge deterrent.
I strongly doubt that they would, but it should be noted that them doing so would be extremely difficult to prove, and even harder to identify in the first place.
I see no reason why Google would treat various huge companies the same as my one person setup even if we all nominally use the same product (and anyway I'm pretty sure Broadcom et al. haven't signed up using the same web interface I would use).
Google, Amazon, Microsoft and all the other major SaaS providers certainly have strict controls to prevent misuse of customer data. Pretty much all companies end up signing up for products the same way, at least with the companies I've worked for.
You are vastly overestimating how much that information is worth to Google. Their average revenue per user is a pittance compared to the $5 per user per month you’re paying as a GSuite customer. They’re strongly incentivised to make sure your data isn’t misused in any way. It’s not worth jeopardising hundreds of millions in future revenue to show slightly more relevant ads to a handful of folks.
The strongest endorsement I’ve seen for GSuite is that even direct competitors to Google have no issues using it. They trust Google with their data that much.
"We won't release any data without the required legal authorisation from an Australian court. As an Australian company, we do not respond to US court orders." [1]
(Note: The parent comment claimed that ProtonMail paid "millions" in ransom. It appears to have been edited to say "thousands" now.)
I am not affiliated with ProtonMail, but the answer is no. ProtonMail has paid a ransom exactly once, back in 2015 when it was just launched and suffered a DDOS attack that caused a lot of collateral damage to third parties, who pressured ProtonMail to pay the ransom.
ProtonMail has since committed to "never pay another ransom" and invested in advanced DDOS mitigation capabilities, including by becoming its own ISP.
Thanks for sharing, this looks neat and useful! The pagemarks are an interesting concept. It would be cool if the top progress bar above the document showed, not cumulative progress, but the progress as it maps to the areas marked on the document, which aren't necessarily contiguous. Kinda like the progress bar you have for a torrent as non-contiguous chunks are downloaded. This provides spatial information about what parts of the document have been read.
Based on the phrasing of the title, I half expected the "wheel" to be that belonging to a Tesla that somehow managed to remain engaged on autopilot for a week... would have been impressive.
That said, what's to stop a situation like that from arising as autonomous vehicles become more sophisticated?
Fastmail has worked well for me with custom domains. It's nice being able to create custom aliases for when an address is publicly visible e.g. GitHub so I know through what funnel emails are coming from.
Like others have said, the Android app is not worth installing unless you're okay with limited and, in some cases, poor functionality.
I suppose you can set it up with the Gmail or Outlook Android apps? I've never tried, as this defeats the purpose of not having those companies as your email provider :)
- IMAP Idle support: e-mails appear instantly, configurable on a by-folder basis.
- Mature and stable: it's been around forever, updates are infrequent, it just works.
- Free software: apache license
- No fanciness: it is very traditional-email oriented. The only "fancy" feature is a unified inbox (showing mails from all your folders), and it can be turned off.
If your e-mail is "complicated" you'll have to spend a bit of time setting everything up. For instance, my server classifies e-mail as it arrives, and I setup different synchronization schedules and notification preferences for different folders. Best time investment of my life.
I use K-9 Mail too, and while I think it's great (fast and customizable) I think it could use some gestures or more in general a UI revamp to reflect the fact we are not using Ice Cream Sandwich anymore :)
Co signed on Aquamail - the original author was very receptive to feature requests and fixing bugs (It was nice when he eventually added scheduled outgoing emails). The software has since been acquired but developement appears to be continuing.
Other clients that caught my eye also were Bluemail or Nine, depending on the need.
I've been using Aquamail on my tablet for years, it's a nice mail app and they continue to support is. I use it on my tablet for the swipe feature especially.
On my smartphone I'm using MailDroid Pro. Like Aquamail, I'm using it for several years now, steady updates and good support. The reason I use MailDroid on my smartphone is the anti-spam plug-in (they charge extra for that though).
I use AquaMail as well, it's one of the few apps I pay for. I paid so I could attach more inboxes though the limit is quite relaxed. The only fancy feature they've added really is a unified mailbox, other than that it's the only android mail client I've used for the past 4-5 years now. I'm a big fan!
You can funnel mail with Gmail, too using extensions. Although some online forms incorrectly reject this. Looks like this: notmyaddress+github@gmail.com
The article shines light on three separate failures on Netflix's part:
1. Canonicalize email addresses
Whether or not dots or +asdf is considered okay, an email address used for identification needs to be canonicalized in order to avoid duplicate sign-ups.
2. Never leak information through sign-up forms
A login attempt either succeeds or fails. That is all the user should know. Telling the user if the attempted email address exists or does not exist is a privacy breach and a security breach as demonstrated in this article.
3. Never assume ownership of an email address until it is verified
Some services verify email addresses at some point in the user flow, some never verify, and few verify at the right point. The best sign-up flow I've seen is Slack where setting a password is part of the email verification flow and a user cannot set a password and own the account until they have verified the email address.
Thus, sending transactional emails beyond verify your email or reset your password before the email address has been verified opens one up to security breaches as in the case of Netflix.
1. Netflix shouldn't have to care about the internal implementation of Gmail addresses. It's perfectly fine to treat ab@service.com and a.b@service.com as separate accounts.
2. If you attempt to sign up for Netflix with an email address which already exists in their system and they tell you that, it isn't a security or privacy breach. There is absolutely no other way to handle the situation.
Agree with the third one though. A "click here to activate" email absolutely needs to be standard in every sign-up flow.
By canonicalization I'm not saying any arbitrary practice by Gmail or any other email provider should be considered as standard. I haven't looked at the RFC in some time, but I don't believe the use of plus suffixes is standard either. Nonetheless, I believe plus suffixes are more commonplace, generally permitted, and serve a reasonable purpose. For instance, sending email to a user using their email address as provided is a good practice in order to preserve a plus suffix which may aid the user in organizing their email. At the same time, canonicalizing email addresses in a sensible way, e.g. stripping plus suffixes, can be an aid for preventing unintentional, duplicate sign-ups. Just consider a sign-up form on the homepage of a website. It's not uncommon for people to enter their email and password into that form by mistake thinking they're signing in. Additionally, if the website compares canonical email addresses when checking login credentials, then a user who signed up with an email address containing a plus suffix can sign in using their base email. These two situations combined could lead to the accidental creation of a duplicate account if canonical email addresses are not compared during registration. There are some trade offs with this strategy, but as long as the canonicalization is implemented reasonably, I see it as an aid to the user. Note that reasonably doesn't necessarily mean stripping dots.
As for the second point, I consider it a privacy breach if a service publicly associates my email address with their service without my consent. Sign-up forms do this when giving different responses when an email address is registered vs not registered.
As for how to handle it, if a user signs up with a new email address, you send them an email to verify their email address and instruct them to check their email. Similarly, if a user attempts to sign up with an already registered email address, you send them an email letting them know they already have an account and instruct them to check their email, which will provide them with a link to login.
In the latter case, if they enter the correct password, you can just directly tell the user they already have an account, as they've proven their identity.
The problem with your canonicalization idea is that it doesn't work in all cases. Yes, it might work with gmail addresses, but there's no way that you can assume that "david+x@example.com" and "david+y@example.com" are actually the same mailbox. If you so assume that, then you've just broken you websites for users where that isn't the case.
Why would you broadly assume an incorrect rule? Email address parsers correctly implement canonicalization rules that consider the domain e.g. gmail. It doesn't require any extra work as a developer and the logic is hidden behind the abstraction. But certainly, you shouldn't go implementing arbitrary rules that aren't reasonably applicable.
> Whether or not dots or +asdf is considered okay, an email address used for identification needs to be canonicalized in order to avoid duplicate sign-ups.
Since it isn't a standard or norm, how would that work? These are gmail exclusive features, and other services have other unique features.
Many reasons. Primarily because of security and control of my information. Secondly because services like these tend to be short-lived and unreliable, if i host it myself i can trust it's there when i need it. And i hadn't considered the uploading time issue mentioned in a previous comment, but that is actually a very good point that self-hosting would solve as well.
I also just want to see the code because i think it's cool
>I also just want to see the code because i think it's cool
This is not "the" code but here's a script. I can't take credit for it... I don't remember but I probably cobbled it together by taking stack overflow code and making it more friendly. First, you need ffmpeg (ymmv.. this assumes macOS, for others installing ffmpeg is also possible but left as an exercise for the reader):
$ brew install ffmpeg
Then:
[edit: fixed some typos]
#!/bin/bash
export OLD_IFS=$IFS
export IFS=''
mkdir -p converted
for a in *.{webm,mkv,ts}
do
ffmpeg -i "$a" -c:v libx264 -preset slow -crf 20 -c:a libvo_aacenc -b:a 128k "$a.mp4"
if [[ $? == 0 ]]; then
mv "$a.mp4" converted
fi
done
export IFS=$OLD_IFS
Save as convert-to-mp4.sh then run it in a directory containing files of undesirable types like .webm
Not saying this is perfect. Take it as a proof of concept. And there's no web UI, nor would I want one. Suggestions for tweaks welcome.
Yeah, the primary benefit I see is if one fully audits the code and any future updates. Otherwise, self-hosting doesn't confer much in the way of guarantees for security or privacy.
For me, often, it's just a bandwidth issue. If a colleague has a 12 GB movie they'd like to transmute, a local app might be a possibility, but an hour long upload followed by a 20 minute long download won't be.
The creator mentions in another post that the service does indeed upload the data to a server for processing. But, in general, it being a web app doesn't mean it uploads your data any more than a locally run application might. A web app can just as well do the processing in the browser without it ever leaving your machine.
On what are you basing these expectations? Uploading means transmitting data to a third party. One could write a CLI that does just that. One could also write a web app where the processing takes place in the browser and the data never leaves the machine.
The difference is the web app runs within the browser sandbox while the CLI executes with user permissions.
Not op, but for myself, not having any way of knowing if the service reads or retains any information from my files (outside of the core purpose) would limit the amount of data I would be willing to put through the service.
In the modern era, there are sufficiently many practical editors and IDE's with major economic investment behind making them highly functional out of the box. I simply cannot justify spending copious amounts of time configuring a text editor when there's sufficiently good and productive options out there.
Looks like the last edit I published to my Vim config was 5 years ago https://github.com/fvgs/.vim
But hey, maybe I'll find some "lazy" time to give LazyVim a go and give VSCode a break.