Live data from Hacker News

Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

techcrunch.com

241–250 of 443 posts

Re: Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

#241
It's funny how Microsoft was once in court over essentially shoving browser components into UI, and now this.

I wish that the features of web engines were more compartmentalized. The "convenience" of a Thing That Does Everything will also introduce fragility and bloat (and maybe even security exposures).

For example, I would probably love to call functions to lay out some rectangles for me. I know a web engine can do that really well, and I don't even mind passing in CSS strings to describe what I want. The problem is, I don't want "Internet in a box" to come with it; I just want the layout in that case. It would also be a lot easier to identify problems and contribute solutions if there was a way to "only" do X and focus on that part of the engine to fix.

It would be awesome to be able to take those kinds of low-level details, and start really going cross-platform with them. Make a library that can finally lay out whatever the hell you want consistently across machines, that can be patched into all existing UI libraries or other tools. Make a portable text rendering and text layout system. Make a portable GL viewer. But don't tell me that each of those things only works if I create an InternetInBoxView. Instead, refactor InternetInBoxView to use those separate parts.

Re: Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

#242

Earlier quoted context omitted.

It was a failure as he said because the goal was to rewrite it for the company to do better. They failed at that. More work was done including by Mozilla. That worked but was too bloated and all-in-one. Eventually, someone trimmed it up to make Firefox and added the customization features. That succeeded. So, there was a failure, years of struggling changes, several new audiences, and another big change before it mad…

I don't disagree it was a bad idea to do the rewrite but rather the company (Netscape) was on a downward spiral regardless (it didn't help but I don't think it was the sole reason).

Definitely wasn't the sole reason, their server software generally sucked, e.g. a lot of people happily switched to Apache once it was perceived as being sufficiently trustworthy. I could see the latter happening in the 1995-6 period.

One thing I've read about the rewrite is that Netscape accuihired? (back before that was a word) a failed company, and put its failed managers in charge, who I guess were good at what really counts in the short term (looking out for themselves). An obvious corollary to the "don't do a rewrite" is "if you're going to do one, employ really good people to do it".

Re: Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

#243
post #233

Earlier quoted context omitted.

Yes, especially the MULTICS operating system was so advanced and dozens of decades ahead that we still borrow from its concepts. It had for example 16 security rings. Intel CPUs support only 4 CPU rings, and Windows e.g. uses only 2 rings (for kernel mode and user mode) (hypervisor mode uses another ring in recent iterations).

Initial software based Multics had 64 rings, and as I recall only 8 in the hardware versions. No more than 4 were needed in practice: 0 for root, 1 for mail (e.g. you could delete mail you'd sent to other people from their mailboxes if they'd not read it yet), 4 for normal users, and 5 for some stuff that e.g. allowed anyone to use, but was restricted at touching anything deeper in the system. AMD dropped rings in th…

> AMD dropped rings in their 64 bit architecture which Intel was forced to adopt, so they're becoming a historical curiosity.

Not quite. Hypervisors are operating in Ring -1, SMM is equivalent to another ring above that, and I can't find anything about AMD64 dropping Ring 1/2? Ring 0/3 at least are still in use.

Re: Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

#244

I think this is the 3rd time I've heard Thunderbird is/is going to be unmaintained and that I should avoid it, but I'm yet to see a good alternative. Claws was crashy and didn't DPI scale properly on Windows, OS X Mail had strange behavior with my IMAP server and I just wanted a consistent UI with my Windows and Linux system. My next option is webmail but there's no good IMAP webmail client that seems to be able to h…

I've moved to Mutt/OfflineIMAP on most every machine I own, and it's worked remarkably well. It's a CLI app, yes, but it outshines Thunderbird (and most other GUI clients, for that matter) in a number of ways:

- FAST. Mutt lets you process thousands of messages in short order. Mutt is directly responsible for helping me dig out of a 50k deep email hole brought on by years of GMail's approach (archive, never delete) in a few days of on-and-off cleanup.

- Plays well with others. Uses a bog standard Maildir format that anything sane can read (including Thunderbird, so migration should be easy), provides a very powerful hooking system which can do anything from verifying PGP signatures to checking your spelling before sending to displaying attachments.

- Sane defaults. Doesn't require a lot of in-depth customization to provide the basics, and the bells and whistles are hardly out of reach.

- You have a backup of your mail for free (by using OfflineIMAP)

- Not hard to learn (at least for the crowd here). If you can use Vim, you can be using Mutt at full speed in less than a week.

- Search capabilities that blow nearly every other project out of the water (regexes with some very cool niceties)[1]

- Secure by design. Mails are rendered as plaintext, HTML is decoded by piping messages through a program like w3m. Tracking bugs can't do their job, spammers can't see that you've looked at their stuff, and you're immune to whatever image decoding bugs crop up. (Though you can still view images, it's an explicit process). Also, builtin GPG support.

I followed Steve Losh's guide[2] on setting it up.

[1]: http://www.mutt.org/doc/manual/manual-4.html

[2]: http://stevelosh.com/blog/2012/10/the-homely-mutt/

Re: Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

#247

Anyone know how this impacts the e-mail functionality of Seamonkey? (I've actually started using Seamonkey again on a whim. The last couple of weeks. Somehow, browsing feels more snappy with Seamonkey than with Firefox.)

The demise of Thunderbird does not mean anything to Seamonkey, but the deprecation of XUL will make it hard to continue to develop it since the whole user interface is based on XUL. The only viable option would be to pick up maintenance for the XUL-supporting Gecko engine.

Actually, SeaMonkey largely lives on Thunderbird's maintenance of the mailnews code.

Re: Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

#248

I think this is the 3rd time I've heard Thunderbird is/is going to be unmaintained and that I should avoid it, but I'm yet to see a good alternative. Claws was crashy and didn't DPI scale properly on Windows, OS X Mail had strange behavior with my IMAP server and I just wanted a consistent UI with my Windows and Linux system. My next option is webmail but there's no good IMAP webmail client that seems to be able to h…

I'm certainly at a loss for amother decent mail client that works on OS X and with Exchange.

Re: Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

#249
post #164

Earlier quoted context omitted.

Are you so daft to think that the rust compiler is written in something other than C/C++?

The original Rust compiler was written in… OCaml. Nowadays it's self-hosting.

And OCaml is written in C.

Also, there's an awful lot of llvm involved in compiler-rt on github.

To think you can evade C on a Unix box is very wishful thinking. You can't escape C-generated bytecode in your stack. It's bound to be somewhere.

Re: Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

#250
post #155

Earlier quoted context omitted.

> maybe the cross-platform nature of HTML/CSS/JS will also be vital to future applications. There are already cross-platform toolkits that can deliver everything a browser engine can, faster and safely. Face it, "web technologies" are not winning because of any massive technological advancement, just like C++ wasn't this huge advancement over C. They just managed to achieve enough critical mass to make everything els…

> "There are already cross-platform toolkits that can deliver everything a browser engine can, faster and safely." Nothing with the reach of web technologies. The closest I can think of is Qt, but there are issues with deploying Qt apps on some platforms.

So our choices are

• Native applications that give users excellent UX and performance

• Web apps that are equally quirky and slow on every system

?

Post reply on HN