I honestly donât understand the love for Thunderbird⊠Tried it for a few months, loved it entirely until I discovered it was fucking losing days worth of emails
Lost, as in, nowhere to be found, no search or manual browse would find them, no way of restoring them. Had to go into OWA to see the missing emails
Then apparently I found out itâs a known bug
Iâm sorry but I would trade every bell and whistle for an email client that does not fucking lose your email
It was⊠I was accessing my work email which unfortunately runs on Exchange⊠having said that, sorry, either support whatever crap MS puts or out donât⊠âlosingâ emails cannot be part of a ready-for-public email client
Now, from what I read at the time, it was not âOwl for exchangeâ's bug, it was Thunderbird. It apparently happens with other email sources as well, however you can ârepairâ your mailbox to get them back when you notice
It apparently happens with other email sources as well
I deal with a lot of mailboxes and a ton of people using Thunderbird with ridiculous amounts of emails like 50-100GB accounts and even on the few times I saw Thunderbird failing it wasnât loosing anything.
I donât trust Owl very much, the good news is that we will soon get an official and decent support for Exchange. :)
I mean we are using Exchange email accounts at work with thunderbird, would be really lol if emails just get âlostâ. But yea for sure a problem of Thunderbird. No user nor microsoft problem⊠;>
The email was right in my inbox in owa⊠I could be an ms issue although I had seen the email in Thunderbird, thatâs how I saw it first⊠Not sure how an email disappearing from my inbox is my fault
Gmail has a bad habit of losing my emails anyway. Maybe yours too if you ever used Google Inbox.
I migrated my main account to Inbox and it was honestly the best email experience Iâve had. Unfortunately, the forced migration following its collapse left my Gmail riddled with problems.
Granted, itâs not losing days worth of email. It just occasionally attempts to automatically categorize emails into categories that donât exist, removing them from my inbox and leaving them in a weird uncategorized limbo space. Once there, I have to search for them specifically before they will show up anywhere.
The worst part is, it is so inconsistent that I have no clue when to expect it. I have missed major bills this way.
I have a coworker who is also an Inbox refugee. He is the only other person Iâve met with identical Gmail issues.
Victim of the Inbox move myself⊠Same as it happens with Thunderbird, I started noticing something amiss when searching for emails I was certain I had were coming back empty
At first I thought my memory was not as good as I expected⊠But then realized what was going on
Iâm getting fed up about all those articles ârust x something: the future?â, âI rewrote <cli tool> in rust itâs now memory safeâ. I get the rust safeties and all, but that doesnât automatically make everything great, right ? You can still write shit code in any language that can RM -rf all your disk, or let security gaps here and there without intending to.
Yes security issues will remain a problem no matter what language was used. You are talking about the possibility of a logic flaw being there, whereas rust âjustâ prevents memory corruption.
Which is the more common security issue? Memory corruption by a mile. Thatâs why many are excited by the rust rewrite
So youâre right it isnât literally everything, but Iâm not sure what would be. What would make you not fed up about it?
I think Iâm more fed up with people making those quotes ârust will change everythingâ when, in fact, it will rule out many if not most memory corruption as you said. Reading your comment, I see now itâs the mentality âeverything need to be in rustâ that bothers me the most, which in fact means ârust can bring memory safetyâ and not ârust will replace everythingâ. Alas Iâm seeing it used times and times again as the latter instead of the former.
It does make stuff great. Even Microsoft is trying out Rust in their shit operating system because apparently 30% of all CVEs are related to, you guessed it, memory issues. And Rust will most likely solve them all.
Even the Linux kernel has Rust code in it now. If Rust was not of importance, why would the Linux kernel get rusty? Especially Linus Torvalds is very strict about these things.
Sure, bad code rewritten in Rust does not make it any better than it originally was.
Plus you get C-like speed with good syntax and memory safety, what more could you ask for?
I love FairEmail because of its âmillionsâ of settings and the privacy features, for an example if you press a link, youâll get a popup with options (for an example, what app you want to open the link with). And if the link contains trackers, FairEmail will remove these by default and saying âtracking parameters removedâ with yellow text in bold.
K-9 Mail feels incomplete in comparison. Have you tried FairEmail?
And when was âlast timeâ? :) I have been using F-Droid for FairEmail since I tried the email client for the first time few years ago and I have never got any issues. Just updated FairEmail while writing this comment. Works just fine :)
I donât remember why but I switched from k9 to fairemail a long time ago. I think it might have been the branding lol⊠Shallow I know but I just canât get passed the logo / name. I might give it another shot once itâs rebranded.
K-9 mail is what I originally used, but it isnât supported or being developed any more. There were some weird issues that I canât remember now that caused me to switch to FairEmail.
Having said that, I almost switched to FairEmail because K-9 lacked support for some sort of authentication measure (which I no longer need), but that wasnât because K-9 stopped development.
I donât recall it ever being a dead project. They did have a time period where you had to either join the beta on Play Store, obtain the beta on Github releases, or use F-Droid and install the beta. They were working on integrating certain things and rewrites before doing an official release.
It was a pinned issue in their issue tracker.
The whole 5.7xx series were betas, and 5.800 started the official releases again
Rust is wildly fast. Learning that it is being used for a program is good to know if you care about speed. If you read the article, it even addresses your exact critiques:
Moreover, Rust has demonstrated superior performance compared to JavaScript add-ons, resulting in a quicker and more responsive Thunderbird. Furthermore, the integration of Rust into Thunderbird will be facilitated by the fact that it is already utilized in Firefox, enabling Thunderbird to leverage existing infrastructure for testing and continuous integration.
So not only with thunderbird be faster because Rust is faster than JavaScript, but it eliminates 3rd party addons by being native which also further increases speed. Lastly, development time for new features and improvements is faster because they can now use using the mature tooling that Mozilla has for Rust.
Not the person you wrote to, but TB has native code in C++, so I donât really think the speed will change. The official website also doesnât advertise speed improvements. It argued that Rust is (almost) as fast as the current native C++ part in TB, and thatâs about it.
The improvement here is switching from interpreted to compiled. It could have been C, Zig, Odin, or even C++ (but thank Satan it isnât C++)
Iâm not sure I understand why people like Rust over C, although I donât have that much experience in enterprise coding. Iâm generally distrustful of languages without a standardized specification, and I donât really like that Rust has been added to the Linux Kernel. Torvalds giving in to public opinion isnât something I thought Iâd live to seeâŠ
I get the segmentation fault thing, but to be blunt, that sounds like a skill issue more than an actual computer science problem.
Maybe if things were less rushed and quality control was regarded more highly, we wouldnât have such insanities as an email client (or an anything client) written in JavaScript in the first place.
Rust is likely going to suffer the same problem as JS, where people indirectly include 6,000 crates and end up with 30 critical CVEs in their email client that they canât even fix because the affected crate was abandoned 5 years agoâŠ
Obviously itâs a skill issue but donât you ever make mistakes? If Rust prevents some bugs and makes you more productive, what is not to like? Itâs a new language and takes time to learn but the benefits seem to outweigh the downsides now and certainly in the long run (compared to C at least).
Maybe Torvalds didnât give in to public opinion but made an informed choice?
The crates are a bit of a problem and I think Rust is a bit overhyped for high-level problems (it still requires manual memory management after all) but those are not principal roadblockers, especially in the kernel.
Itâs not âthe segmentation fault thingâ. Itâs that C allows you to shoot yourself in the foot in many various ways, part of which will immediately show itself in the form of a segfault, part of which may show itself in the form of a segfault minutes, days, or years later depending on how the users use the software, and part of which will not show itself in the form of a segfault ever but make the program unstable in other ways.
Yeah, sure, you can say that itâs âa skill issueâ, but maybe thatâs not the attitude of the year if you want more contributors in the project, which is a useful goal if you donât want itâs developer community to die out or otherwise disintegrate.
where people indirectly include 6,000 crates and
Thatâs why the maintainers shouldnât allow anyone to just add any new dependencies without a proper consideration. I donât think this is an unsolvable problem.
I admit to not knowing how running an open source project goes, but wanting more contributors seems like the wrong metric compared to better contributors.
I understand the pitfalls of C are not limited to segmentation faults, but I suspect it would be more productive to fix C by including some of Rustâs better ideas than to throw it away, as seems to be the current trend.
I donât think Rust is wholly bad, to be clear, but it seems over-engineered to me, and the fact its useful new features donât even completely work (see rust-cve) isnât very encouraging.
I would recommend listening to Jonathan Blowâs opinion on Rust, which I tend to agree with. I personally think Iâm just going to stick with C until Rust either becomes the standard, or I retire and let the next generation worry about that.
including some of Rustâs better ideas than to throw it away
The problem is that you canât just tack Rustâs ideas onto an existing language. Generics, traits, lifetimes, borrowing, sum types, and match are key Rust features, but took considerable design time before Rust even reached 1.0. They interlock to produce a pleasant development experience. You canât just attached them to C and call it a day.
I donât think Rust is wholly bad, to be clear, but it seems over-engineered to me, and the fact its useful new features donât even completely work (see rust-cve) isnât very encouraging.
Most of the CVEâs listed there are in unsafe code in the standard library. At some point, some code is going to have to have to implement the tricky cases. In C, this code is common place, ready for any coder to run into problems. In Rust, these are bizarre edge cases that most people would never trigger.
I havenât heard Jonathan Blowâs take yet, but one thing a person pointed out is that he tends to prefer a style that uses a lot of shared state. Rust explicitly discourages that style, considering it a source of bugs.
I encourage you to give Rust a try. It never hurts to have another language in your arsenal. Who knows, you might even find it fun.
I donât have much experience in C, but Iâm not sure if bringing Rustâs ideas over to C would help.
As I understand, a lot of problems come from either that arrays are actually just pointers and if you donât enforce itâs length for yourself then no one will, and in practice they span the entire area of process memory dorwards and backwards too. Or from that you free memory at the wrong time, or you never do that at all.
You canât make mistakes with the first thing in Rust because the compiler takes note of the arrayâs length, and you just canât abuse it as it wonât compile then. The second is a nonissue too, as memory management is automatic (kind of).
Fixing C sounds to me like patching up a sieve. That language was designed with those features in mind that make it error prone, and changing them would result in a different language. You would have to change your program anyway, and that probably wouldnât be a small renovation. Also, you often canât afford to not use pointers, because thatâs how you pass things by reference in C, and besides passing by reference being important for performance reasons (to avoid copies) thatâs the only option if so you have is a pointer to something, and when itâs stored in the heap.
This âskills issueâ thing just sounds so stupid in my ears. I am sick of reading it.
So, I am choosing a language that I hope will ensure fast, secure, and sophisticated code for my project. It has to do this for code I write, my team writes, and all future maintainers and contributors will write as well. If I choose a language that makes it easy to write unstable, fragile, and insecure code then âthe skills issueâ applies more to my lack of capability as an architect than it does the coders that come after me.
Stop saying, âwell ya, it is super easy to make these mistakes in this language but that would never happen if you are as awesome as I amâ and thinking that sounds like an intelligent argument for your language choice. There are better options. Consider them.
Why do you want sophisticated code ? That word seems out of place from the other two to me.
Rust doesnât introduce the same problems as C, but it sure does introduce a lot of other problems in making code overly complicated. Lifetimes and async are both leaky abstractions (and donât even work as advertised, as rust-cve recently demonstrated), macros can hide control flowâŠ
C is unsafe, sure, but also doesnât pretend to be safe. C is also stupid simple, and thatâs a good thing : you canât just slap ArcMutexes around, because by the time you know how to code them yourself you also know why you shouldnât do that.
I hope Rust can reach a point where its safety model can be formally proven, and we have a formal specification and a stable ABI so we donât have to hard-compile every crate into the binary.
But I personally expect something with some of Rustâs ideas, but cleaned up, to do that instead. Actually, I wouldnât be surprised if C itself ends up absorbing some of Rustâs core ideas in an upcoming standard.
Iâm not sure I understand why people like Rust over C, although I donât have that much experience in enterprise coding.
Iâd actually say that Rust is more popular in open-source projects. The reason people like it is because itâs WAY safer than C or C++ while being literally just as fast if not faster. Iâm still in the process of learning it though so I canât speak to your other points.
It is worth mentioning that the White House recommends Rust over C/C++ due to its very notable safety advantage over classic languages.
Somehow it sounds quite weird that the white house has such a recommendation. NIST, or the NSA? That would be easier to understand because they deal with code and algorithms but the white house?
I wrote a simple commandline program in Rust to read mailbox file from Thunderbird and to output count of unread mails. The speed is insanity! Measuring the execution time with command time CMD outputs execution time of total 0m0,001s! While also providing all the features and checks from Rust (plus Clippy with pedantic options enabled), so I am confident it is not a buggy mess. I would need at least 10 years of professional experience in C to have this feeling of confidence.
Why does every mention of Rust have to spawn these comments?
The story right after this one for me is how KeepassXC is porting to Qt6. I bet nobody has knee-jerk responded to that story bitching about the fact that they mentioned Qt. It is just the anti-Rust zealots that do this.
This article talks about the problems they were trying to solve, the tools they chose, and how those tools solve those problems. What is wrong with that?
Are you offering up informed commentary countering why you would have made different choices and why?
You do not need to attack every mention of a technology just because it threatens your historical preferences.
people who like fast apps should care because like 99% of current software developers are building electron apps instead of giving us something that actually lets your high end computer behave like a high end computer.
the only modern chat application that doesnât run electron today is Telegram.
the only cloud note taking app that doesnât run electron is âŠuh. doesnât even exist.
the onlyâŠ
i canât even think of something i use that was released after 2016 on my computer that doesnât run at a crawl because of electron. fuck electron.
using cinnamon. and yeah base software is largely fine. but non-base productivity apps are largely built in electron. cinnamon even offers a webapp tool so in some cases i can at least avoid it.
Maybe, but I find it kinda frustrating that they invested a lot of time in the direct opposite way. Thunderbird had Qt/GTK support in version 102. In the next release, they forced their own theme and moved some elements while removing Qt and GTK support with the nonsensical justification of "we'd have to hardcode every single possible color permutation that the user could theme" when you get the colors from a function. They then locked the threads about this. I assume they did some internal refactoring, but still, it feels frustrating. 102 115
(note that the new UI can be customizable to have the inbox be single-row and the mail content be on the bottom)
(also 115 is 102's next release, thunderbird updates the major version number to whatever firefox's is at the time of release)
I want to, but none work properly. KMail is broken on NixOS, Evolution doesnât work well with KDE, and Thunderbird was just a broken mess last time I used it a few years ago when I was distro-hopping. Email is really not that important to me anymore either. Check it on the shitter or before bed and thatâs it.
There was also a problem with it no syncing calendars or something. Canât remember which issue I had there. Maybe itâs all fixed now since Qt6, but thatâs to be released in the next stable version I think.
Huh, I havenât encountered any of these (adding address book works for me too, the last comment on that post seems to have a solution if it doesnât for you) and Iâve used KMail on NixOS for probably about as long as that first issue existed. Weird.
Not at all, given weâre running probably significantly different configurations. With the same configuration weâd get the same results, and NixOS never claimed to eliminate what is essentially packaging bugs related to runtime dependencies. KDE stuff (and especially anything Akonadi-related) right now needs a lot of plugin path environment variable mess to work with NixOSâs file structure because it loads a bunch of stuff at runtime from other packages, which can break in strange ways like this if you donât add a specific package to your system packages for example, itâs definitely not ideal the way it is right now but itâs also pretty hard to get right.
I saw the work k900 and other contributors put into KDE and Qt stuff. Itâs admirable. Iâm not saying itâs their fault things are the way they are.
That is clearly talking about build-time dependencies and the build process given the context (maybe the word âworkâ here is misleading though, also because some packages donât even have parts that can âworkâ or ânot workâ like wallpaper packages). It is impossible to automatically ensure all runtime dependencies are met, because that would require analyzing what the program actually does. I can write you any number of Nix packages that will only run on my computer (simplest case is because they load a file from a path from my user directory or something), but the thing that Nix ensures is that you can reproduce the package contents on your system as well.
That said, in a lot of cases, nixpkgs does actually (manually) patch runtime dependencies to use store paths which sets up that dependency relation, but with KDE PIM stuff this would lead to dependency cycles if done the typical way, for example KMail depends on Akonadi to build, but Akonadi loads plugin files from KMail when it is installed. This is not something you can do, so to resolve that cycle, you need another package which depends on both and links them together so they can see each other at runtime. Right now the entire NixOS configuration (or rather, whatever the environment.systemPackages option affects) assumes the role of this third package, but it would be nice if was done in in a more self-contained way, so that you could also reasonably use this stuff outside of NixOS.
NixOS is just another attempt at changing the way fundamental things are done so one day they can introduce some orchestration / repository / xyz payed solution. Yet another step in the commoditization of software development.
I donât yet⊠but a few months ago nobody believed they could take on a sponsorship from Anduril. Nor that they would enact a somewhat vague policy guide pushing the ideia that the community is all that matters and that all further important decisions will be community driven without actually specifically defining âwhoâ is the community.
I only recently start using it after also being a browser email user all my life.
Kinda wondering what took me so long Thunderbird is great! donât have to relearn questionable Ui between different email providers or re-login to check two mailboxes on the same provider.
Only annoying thing is not supporting ProtonMail out of the box.
That annoying thing is more on Protonmail though and I donât mean that as a negative, just more difficult to connect when the provider wants to keep things secure.
just more difficult to connect when the provider wants to keep things secure.
Proton couldâve just implemented everything they did with IMAP/SMTP on Thunderbird + OpenPGP with the same level of security, but they decided not to. Yes, their solution is convenient but also close to everything else.
Only annoying thing is not supporting ProtonMail out of the box.
Thatâs Protons fault, theyâre the ones that decided to ignore all the open and standard e-mail, contacts and calendar protocols out there and built their custom-everything stack to keep you vendor-locked into their interfaces.
How many email accounts do you have? It might be a huge factor. I have about 7 accounts I need to check regularly and I cannot imagine doing it manually for each. I can see it working for one or maybe two though.
Web interfaces are so much worse than local apps IMO. And that doesnât just include email, I always choose a local app over anything that runs in my browser.
Your phoneâs email app is a client, but I digress⊠I hate using the browser to access emails. I use many different email accounts with multiple email providers to compartmentalize my emails and avoid spam. I used Thunderbird for years before switching to Geary and now back to Thunderbird.
I have several mails for different projects. Also private + university mail. Then I have my Google mail that I exclusively use for everything related to android/app store.
Checking all those mail accounts at once, managing folders/filters and signatures is all way easier with a desktop mail client.
Some years ago I was like you. I only needed to read mail and I have to admit that a desktop client is not really necessary in that case.
As a Thunderbird user and Rust fan, I approve this integration. However I want to mention that Thunderbird is good as it is and actually donât think new features are needed. Only compatibility with other software or protocols could be better (which the Rust integration aims to improve). And to be honest, a way to disable some of the feature bloat would be preferable too, as I donât use lot of the additional stuff (but I make use of the RSS Feed reader).
I didnât know JMAP either. Apparently the authors found the complexity and stagnation of IMAP as well as inability to integrate with basic groupware such as CalDAV caused free e-mail clients to be dropped in favor of proprietary systems. Seems like a fair assessment and if JMAP solves that Iâd be very pleased.
Please correct me if Iâm wrong, but doesnât this allow one to represent virtually any resource as a mail inbox/outbox with access through a generic mail app?
Iâm working with a specialized healthcare company right now, and this looks like a way to represent patient treatments data as an intuitive timeline of messages. With a local offline cache in case of outages. Security of local workstations is a weak point of course, but when is it notâŠ
Yes, but that is always possible with most protocols, including imap.
Take a look a FUSE and you will see all the creative things people have done with filesystems. Or DNS, lots of fun things have been done with that also.
Yes it was shocking to learn about the file format. I reverse engineered the stuff that I need to know and its a complex mess of noodle soup (later found a description of it, but its not fully documented by Mozilla either). I am surprised that Thunderbird still uses this ancient and inefficient format.
Evolution is a good client that I used for a long time. But I switched to Thunderbird after their recent UI overhaul and I have to say it feels way more thought out and robust than evolution.