That wouldn’t surprise me at all - particularly as at V1.0 of a rewrite. Achieving compatibility with a former look may be something that is only arrived at over time i.e. incrementally over the next 3 years.
I still look forward to
an adaptable and extremely customizable user interface
Within limits that should keep everybody happy - but it is an objective over 3 years.
In principle, this is a good thing i.e. Thunderbird will still work on the desktop/laptop but it will work better than it currently does on a touchscreen tablet and better than it currently does on a smartphone. (They also observe that they want to make Thunderbird fully compatible with current accessibility technology, which was probably not such a requirement, or even a possibility, back in the stone age when Thunderbird started.)
I’m pretty confident that Rome won’t be built in a day.
I’m not disagreeing with that claim but where specifically did they say that?
It is perhaps implied by “extremely customizable”.
I probably gleaned that from a separate blog post of theirs; in the comments, Jason Evangelho replied to a commenter’s concerns (“…I hope it can be made to look as much like the current version as possible…”) with this:
Jason Evangelho wrote on July 13, 2023 at 18:08
You’ll be relieved to know that 115 still mostly defaults to the layout and presentation you’re used to from version 102. It takes a few toggles and changes to get the “Supernova” look. And we did this because we understand some of our users have been used to that general paradigm for the last 20 years.
We also have no plans to retire the “legacy” views, although the defaults may change in the future.
EDIT: Fixed the link, which was not for the blog post I mentioned.
A very good thing, I would say.
Rust, like Go is a memory safe language (unlike C, java) An enormous progress - so many bugs due to memory unsafe programming languages like C (which the entire Linux ecosystem is built on)
It remains to be seen what they mean by “implementing”? Which part of TB would be rusted? Obviously not the entire code - this would be herculean work. And the problem here, is that if you have some part of the Rust code that depends on any C library - well, nothing is memory safe anymore…
At the risk of starting a my-programming-language-is-better-than-yours war … to the best of my knowledge, Java is memory safe. (There is no “free” at all in Java - so there are no use-after-free errors, no double-free errors - and all memory is type safe - and all array accesses are checked … . So large classes of programming errors are simply not possible, as compared with languages like C.)
If you look more at the report it seems like what they mean is: They have changed Thunderbird so that Rust code can be integrated within Thunderbird and they did that in order to have safe support for Microsoft Exchange-related protocols. But I don’t really know the details (and Exchange support is not needed by me).
Also, I should note that Kotlin (a Java alternative that is used by many/most Android devs) is also memory-safe. Here is the cloc decomposition for K9-Mail / Thunderbird-android from GitHub - thunderbird/thunderbird-android: K-9 Mail – Open Source Email App for Android . You’ll note that in terms of actual code (Kotlin and Java), the project is written in memory safe languages.
My understanding is that if you want to write an app to run under Android then it must be memory safe because it must fall under an even broader kind of safety i.e. that it respects the restraints of its environment and cannot escape from the environment - which would be much harder to enforce if the programming language is not memory safe. (It is the same under iOS but the approved or encouraged programming languages are, I think, different ones.)
Maybe. Certainly Java and/or Kotlin are preferred. That said, applications are allowed to have native C/C++ libraries … which weakens/defeats the memory-safe advantages (Add C and C++ code to your project | Android Studio | Android Developers). I think the main aspect of application safety in regard to memory is enforced by the OS ( https://source.android.com/docs/security/features ) — each app is run under a unique UID and is effectively isolated with resource availability managed via SELinux MACs …
My bad here, I guess!
Some intox from Tamago unikernels on USB Armory devices, which I love and use for different security purposes. I picked up from these guys that Go was memory safe and java, C# and Python were not. But I didn’t check those assertions…
I made the list into a wiki post, so others may choose to maintain it if they want to. Past this point, I am likely to self-host my own email server in spite of its various challenges, but I will strive to reduce its maintenance as much as possible while prioritizing security and privacy.
Just FYI, a new version (128) just came out with a lot of development. See: Thunderbird 128 Released With UI Changes + More - OMG! Ubuntu or see release notes: “[Thunderbird 128] ushers in significant improvements to Thunderbird’s code, stability, overall user experience, and the speed at which we can deliver new features to you,” the team say of this release."
