Slashdot Mirror
Mozilla 1.4 RC1
Mister.de writes "Mozilla 1.4 RC 1 is out. We've added lots of features and fixed lots of bugs since Mozilla 1.3. Help us shake it down in preparation for Mozilla 1.4 final. More information is available in the release notes. Mozilla is an open-source Web browser, designed for standards compliance, performance and portability."
Excellent. This was the only reason I kept a copy of explorer around. Now to see if it works. :)
He actually explained to us what open source is on Slashdot. Priceless. =)
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
If the next release is to be based on Firebird and Thunderbird, that is separate components instead of the suite, call the thing 2.0.
It's a huge change in the code base, it's a huge change in the user interface, just call a spade a spade and release it as 2.0.
What is the rational for calling it 1.5? That'd be more confusing, in my opinion, than letting everyone know "Hey, big changes here. Check it out."
Do everyone a favor and call the release after 1.4 2.0.
obviously no deficiencies vs. no obvious deficiencies
Some links:2 1639.html
h tml?tag=nl
"Does Netscape Deal Mean 'Game over' for Open-Source Browsers?"
http://www.newsfactor.com/perl/story/
Microsoft pays AOL 750Mil for killing Netscape. Gives 7 year license to use Microsoft Internet Explorer:
http://news.com.com/2100-1032-1011296.
Unfortunately Microsoft will change how NTLM authentication works soon because of this, and the Mozilla team will be forced to change Mozilla to meet these changes, and the process will repeat, just like with aspects concerning samba, and then I might change myself to support the ability to convey my thoughts without run-on sentences.
From the release notes: .exe files
"Launch file" after downloading has been enabled for
Isn't this taking IE emulation a bit too far!
Taking PHP to the next level: phpmole, php codedoc, php-gtk pear installer, DataObjects for php, ldap schema viewer and
I'm posting with my fresh and shiny 1.4 RC1, and I have to say that the subjective speed is increased significantly over 1.4 beta.
It feels on par with opera now...
Congrats to the mozilla team
Btw... why is RC1 announced on slashdot? wouldn't it make more sense to kick their ftp servers in the nuts when 1.4 is finalised?
Considering that people who get the release candidates use them and report bugs so that they are fixed in next releases - yes, it is necessary to anounce every release candidate.
Wow.. although there is a problem when you upgrade it from previous version, but it's quite good.
:)
:)
The feeling of bulky and heavy program is gone.
It's very fast when it is being launched and it loads HTML pages.
Well... probably Apple's decsion of choosing KHTML over Mozilla affect this thing. Before the Apple's decision, Mozilla was bulky and slow. Mozilla people may noticed their problem and don't want to lose its anti-MS user base.
You are going to love this browser.
Work with various HTML pages better than the Safari also.
I thought mozilla was a database.
I don't need no instructions to know how to rock!!!!
Please hurry and download the release candidate so the rest of us can have the final 1.4 tomorrow. Thank you for your cooperation.
Finally! A year of moderation! Ready for 2019?
Firebird is NOT exactly a fork. According to the page (OK, I've read it somewhere, old phoenix's page, I think), to make a Firebird build they get the latest CVS Mozilla and patch only the interface code. This way, if some change in RC1 is deeper than interface, then it is automagically in the next Firebird. You can see this if you go to about:config in Firebird. You'll see (should I say legacy) options for about everything in Mozilla (mail/news, composer).
Well...*mostly*. From the release notes:
"# Due to the nature of C++ compilers, libraries built with GCC will likely be incompatible with libraries built with MSVC. For example, XPCOM plugins will not work. This includes the Java plugin.
# Due to the use of MSVC-specific code in the tree and the relative immaturity of the w32api, certain functionality will not be available in the GCC build. The dependency tree for bug 203303 tracks the list of MinGW GCC-specific issues."
No Java, and other, unspecified, non-working bits. Hmm...I think I'll wait until it's a little older before I try to build on Win32.
If all the world's a stage, anyone who says they want better lighting spends far too much time in a dark theatre.
There's been a lot of discussion about how Mozilla 1.4 will the be the last version in it's current form, as Mozilla 1.5/2.0 will be based on Firebird... Keep in mind that one of the goals for 1.4 is to replace 1.0.x (currently 1.0.2) as the stable distribution version. So while future versions will have drastic changes to the GUI framework, 1.4 will live on with small fixes for those that aren't needing or wanting the very cutting edge. Just as there are many current unix and linux distributors shipping 1.0.2 today, there will be many shipping 1.4.x a year from now. As for the version number discussion, my vote is to call the next version 1.5... I think the version 2.0 title should be reserved for a refined, heavily tested version of Firebird. Much like the extensive testing that went into the current flavor of Mozilla before 1.0 was released. Maybe I just don't like version number bloat...
You're right, they're not. So I suggest that you complain to ATI that their graphics card driver is full of bugs and can lead to random crashes of applications that use graphics in a serious way. They already admit that the problem is at their end so you may as well let them know that you find it unacceptable.
For what it's worth, I'm not sure if this particular crash is actually still happening. It's been in the release notes for ages, but I don't recall many reports of it happening recentley. Maybe it's been fixed by the latest driver upgrade.
I completely concur that using 1.4 as the latest 'stable' makes sense, until the 1.5/2.0 version becomes tried and accepted as stable.
Release version numbering should follow major changes in the base code. The specifics listed thus far in this discussion reflect that this will be the case with Mozilla in it's next release (*Disclaimer* - I didn't spend time researching them myself, so I'm basing this comment on earlier comments in this discussion and understanding of Mozilla's development in general).
A classic example is Redhat, of course. With versions 6 and 7, the *.0 release was widely considered stable and tested enough for the typical end-user, but not for 'enterprise level' deployment, esp. on the server side. I have read many comments (and agree) that most businesses waited for a version *.1, *.2, or *.3 before migrating, giving the time necessary to fix any unforseen issues that didn't appear in normal testing.
I concur that a move to a version number of 2.0 is warranted when the change is made to Firebird. The 'refined, heavily tested' version cannot be made available until after the initial release (into production environments - testing will NEVER be able to account for all possible situations).
Silly me, I'll just crawl back into the server rack now. Unlike the kernel, it *is* an end-user product. The Mozilla team can go "it's just for testing" all they want, but it's not the truth. It is being deployed on Linux machines as the end-user browser.
If you remember the Mozilla 1.0 Manifesto, you'll see that one of the most important point of that release is: Personally, I would consider the separate browser and mail spin-offs as a completely unforseen development since 1.0, and that this would have been an excellent policy if they had continued on a unified tree.
However, what they are doing is changing Mozilla drastically, both in terms of structure, as well as the changes that have been made to the browser and mail components, and this is not a natural successor to the 1.4 release, rather a separate branch since 1.0 (or whenever these spin-offs started, haven't kept track).
To me, that suggest that the browser should have version 2.0. It would far more accurately describe it to the end-users you claim do not exist. Nothing would be easier than to specifically state that the XUL 1.0 API has *not* changed, and that all things working in 1.0 will continue to work perfectly in 2.0. The people that need to know (developers and whatnot) would care enough to find out that "nothing" has changed, while the people actually using Mozilla will be made aware that there's been a huge change.
Kjella
Live today, because you never know what tomorrow brings
An easy fix to the bug would be to not change filenames at all when transferring them from server to client. I know the Mozilla team really, really wants to tell a file what type of file it is based on what the server's MIME stuff says (because MIME info is never wrong, and we all know that the world would come crashing to an abrupt end if Mozilla didn't rename half the files it downloads); but I strongly feel this behavior does more harm than good in the user-friendliness department.
I'm a big boy now -- if I want a downloaded file to have a different extension, I can change it myself. Really, I can... I've been studying up on it and practicing endlessly. Seriously, though; at the very least, the user should be able to select whether or not they want Mozilla to assign file extensions based on MIME info. I don't see how one could argue against letting the user decide.
This isn't a pet peeve of mine... no.... not at all... [twitch]
Please don't discourage him. The editors could learn something from him. I'm sick of articles of the sort: "Foobar gets AutoFrotzing" where Foobar is an obscure kernel module or some video game and frotzing is something you would only have heard of if you had been following that module or video game yourself.
What's so hard about defending the claim for standards-compliance? Mozila is, by a very long shot, the most standards-compliant browser in existence. Internet Explorer has not-too-bad CSS and DOM support, but can't claim to support either as well as Mozilla does. There's also all the standards that IE doesn't even try to do right -- MathML, which is hugely important for those of us who use it, PNG, which IE only sort-of supports, XHTML, and SVG, even though it's off by default. These and many other open standards are supported natively by Mozilla, something that no other browser can claim to do (not even Opera or Konqueror/Safari).
As for performance ... Mozilla is actually very fast, in some ways. The Gecko HTML engine is one of the fastest around, and handles super-complex CSS positioning with ease. (Yes, KHTML and Opera can be faster, but this is partly because they don't support many of the more complex aspects of CSS).
Also, although the Mozilla integrated suite takes forever to start up, Firebird/Phoenix is a good deal faster, and Gecko front-ends like Epiphany for GNOME and K-Meleon for Windows start up fast enough that if you blink, you'll miss it.
And finally: "fairly" portable? C'mon, there is no other browser that's available for as many systems as Mozilla is. Ever tried to use IE or Opera on BeOS, Irix, OS/2, or OpenVMS?
Living in Perth, Australia? Come to our Slashdot Meetup