Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla Wants To Split Off Its Thunderbird Email/Chat Client

techcrunch.com

Post reply on HN
Print view View original

301–310 of 443 posts

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

#301

Post by walterbell »

scrollaway wrote: post #255
walterbell wrote: post #185

Earlier quoted context omitted.

In that case, could the XUL dependency be removed from Thunderbird?

Unlike the original parent post I don't think this announcement anything to do with XUL. Thunderbird just doesn't have the userbase Mozilla expects it to at this point because, surprise, the people who want an email client are a small subset of the people who want a web browser. This is lost in a sea of replies now but I'm sure pissed off Mozilla is completely losing their root mantra of fighting for the free web. Pe…

It is easy to forget that freedom and creativity are not a numbers game. There are benefits to a majority when a minority is free to create. An argument could be made that the majority consumption patterns are made possible by the minority creator patterns, hence it makes economic sense to fund the minority out of majority profits.

This is one of the reasons why iPads have stalled - pro developers can't make money, for well documented reasons. The web equivalent will be the starving of open communication, thought and creativity, leading to homogeneous noise as a poor substitute for ground-breaking content.

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

#302

Post by tmalsburg2 »

I use Thunderbird's calendar and think that this is good news. Thunderbird has been in a sad state for long time. It is slow, buggy, and behaves unpredictably. I hope this will create the necessary momentum for a new project or at least a new approach to developing Thunderbird further.

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

#304

Post by newscracker »

INTPenis wrote: post #294

I'm saddened because the only thing holding me back from using Linux full time at work is the lack of a good calendar and e-mail application. Of course thunderbird is insufficient for me who rely on Microsoft Exchange at work but it could still be a contender to Evolution given the right development focus. Evolution, the number one alternative I know of today, has had shaky EWS support from day one and in Fedora 23 o…

Have you checked out Exchange EWS Provider [1], currently maintained by Ericsson? This has been around for a few years [2], and when the developer could no longer spend time on it, Ericsson took it over. The extension is not perfect, but you can get some stuff done.

Another alternative is the DavMail gateway [3], which runs as a separate (Java) program that sits between your Exchange server and Thunderbird. [I haven't used this one for years ever since the Exchange EWS provider became available]

[1]: https://github.com/Ericsson/exchangecalendar

[2]: http://www.1st-setup.nl/wordpress/poducten/exchange-ews-cale...

[3]: http://davmail.sourceforge.net

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

#306

Post by scrollaway »

ZenoArrow wrote: post #270
scrollaway wrote: post #235

Earlier quoted context omitted.

> So web apps can't have reusable components now? I'm not saying they can't, I'm saying they don't. You go ahead and try to fix that, create widget#772981 that still won't support typed-selection, or will break with large text or what not... I've seen too many of those, most of them bad, and none of them standard. So far, React is the only thing that even comes close to a sane model for a contender to UI development…

> "I'm not saying they can't, I'm saying they don't." They already do. Electron, Web Components, etc... > "Do you even have evidence that it'll be better than what we have now in other languages if it does take over?" Compare the performance of vanilla JS vs. asm.js. It is clear from what developers have stated that WebAssembly performance will exceed the performance of asm.js, the threading improvements alone should…

> They already do. Electron, Web Components, etc...

And nobody can agree on which to use. It's not standard if it's just "some set of components some people reuse". A far cry from standardization.

> Compare the performance of vanilla JS vs. asm.js.

That's not what I'm comparing. I'm comparing the performance of native toolkits vs web toolkits on asm.js. It pales in comparison, and the battery usage is through the roof. ymmv?

> So what are we looking at to replicate that?

1. Standardization of components (developer does not have to build their own scrolling system, context menu, etc) 2. Themability of components at the application level (developer can style components not to clash with the style of the application) 3. Themability of components at the platform level (user can style the application not to clash with the style of their own desktop) 4. Performance needs to shoot way, way up. Apps can't rely on a performant GPU, it's unreasonable to ask that of every device at this point in time. Some day maybe every device will come with their own high performance GPU, but eventualism cannot excuse bad coding practices and unnecessary layering.

The rest should follow. But I still don't see us getting any of those things, any time soon. These are not easy problems to solve.

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

#307

Post by nickpsecurity »

vinceguidry wrote: post #178
nickpsecurity wrote: post #159

Earlier quoted context omitted.

He's right. Mozilla, a $200-300 million a year outfit, currently maintains their software including Firefox. It's a huge C++ application. People who code XUL in their spare time, even a bunch of them, aren't likely to make a dent in keeping parity between a Firefox fork and the main release. They'd likely have trouble even porting it. So, a fork is a rough solution and will have maintenance issues for an app this siz…

I was being facetious.

Ah. You got me there haha.

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

#308

Post by snuxoll »

nickpsecurity wrote: post #171
pmelendez wrote: post #121

Earlier quoted context omitted.

>Reading up on the capabilities of early mainframes is eye-opening if you (like me) grew up on Pentiums. Close enough... I grew up on XTs, i286, i386, so on :) All of them way weaker than my phone (Not sure if that was what you were referring to). However, in terms of architecture, algorithms, programming language features... It feels like we haven't advanced too much. Actually, the opposite... we are encourage now t…

Referring to architecture, algorithms, language features, etc obviously. They were all better on many machines from 1960's-1980's. Market kept rejecting anything that wasn't backward compatible with existing garbage and had max performance per dollar. So, dumb CPU's, COBOL, and C it is. :) Gave examples of what features old ones had in the essay below with the first link mentioning the specific systems for further in…

The modern equivalent to System/38, IBM's POWER hardware running IBM i still has the same benefits. I actually really like the concept and the way the ILE runtime works, but it's too bad that much of the platform is stuck with legacy design decisions and hasn't been modernized.

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

#309

Post by jacquesm »

vocatus_gate wrote: post #261
gist wrote: post #152

Earlier quoted context omitted.

"which is not shared by many" I agree with your opinion and am one of those that shares that thought as well. "If the quality of desk top software in the 80's and the 90's" Exactly. And it couldn't be as bad back in the day when things had to be good simply because you didn't want to have to update by floppy (or even CD) a bunch of software with issues. The focus on quality isn't there. It isn't there because of the…

A large part of the instability and security problems are also because software is so, so SO much more complex these days. There is just a lot more to consider when writing code than there used to be. So it's not necessarily that it's moving too fast, it could also just be from increased complexity.

We actually make it more complex. That's self-fulfilling prophesy, software is more complex because we choose it to be so. It does not have to be so. Feature wise we could do just about what we can do today, maybe a bit less eye candy but rock solid if we chose to walk a different path.

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

#310

Post by nickpsecurity »

pcwalton wrote: post #287
nickpsecurity wrote: post #162

Earlier quoted context omitted.

What bothers me about being older is my first browser was Internet Explorer, then I got to play with MOSAIC's slow arse in school, then used Opera/Mozilla, and so on. Got to see where it came from. And the new stuff, especially Firefox, is coming full circle in how friggin' slow they run to serve the lowest common denominator of web pages. It's annoying. I miss Web 1.0. Add just a bit of dynamic functionality plus br…

> And the new stuff, especially Firefox, is coming full circle in how friggin' slow they run to serve the lowest common denominator of web pages. It should be easy to find performance numbers showing how Firefox 42 renders old, pre-CSS pages slower than, say, Netscape 4, then. Netscape 4 didn't have a JIT, didn't use hardware accelerated layers, trapped into kernel mode for GDI calls, didn't use accelerated SIMD for…

Notice my references to Web 1.0, 2.0, etc? That means my comment was talking about not just the browsers but the sites designed for them. The combination of the two have made web sites really slow that could be designed to load up instantly. Instead, they load up as slowly as some sites did on my old Pentium 2 running Opera, etc. You'd think they'd be significantly faster with all the Moore's law iterations and browser improvements. Modern sites make sure that doesn't happen, though.

And I never mentioned Netscape: it was called Netscrape then and hackers despised it. I used Opera and IE mainly.

Post reply on HN