If you want to add AJAX to the magic collection of buzzwords supported by your Web site (and who can resist the siren call of the latest buzzword?), then you have two major options: purchase a proprietary package or experiment with open source libraries.
Or just write the ten lines needed to do XMLHttpRequest calls yourself (there, that's the AJAX part taken care of), and for all other effects write your own functions just like always (copy/paste from your personal library and adapt), so you don't have to deal with bloat, nine out of every ten functions being unneeded, and far too many levels of abstraction and generalization, and have the benefit of actually being able to quickly debug the script when you encounter a problem!
The only organizations where these toolkits might be useful are the really really large ones where there's a team that can dig into the framework and basically "make it their own". Everything smaller, using occasional contractors to maintain the code, benefit far and far more from simplicity, readability and maintainability than from dubious-quality top-heavy frameworks with lack of code-level documentation and thousand and one edgecase-bugs. (Spoken like someone who's had to trace such bugs in the mess of prototype and scriptaculo.us; I've only _looked_ at Dojo, Rico, Yahoo and Zimbra (and not at all at the other two), but my impressions were that what they made up in better code quality, they lost in bloat.)
I think it's safe to say that your average consumer doesn't have any idea who these people are. But your average techie probably does, and they (we) are the ones who'll be set thinking because of it, and even if it doesn't convince us, we in turn will probably help turn the theme of open data into enough of an issue to finally be picked up by the media and consumers.
Over the years, people's data has become much more important than it used to be. In the past, you wrote a few documents in Wordstar, and later one you sent the occasional email to the three other geeks you knew who had internet access. But nowadays, everyone is living and storing a very significant part of their lives on their computers, and their data includes such things as all the photos they take, all the emails they've exchanged with their girlfriends, all the music they listen to, and the only videos of their children's first steps they'll ever have. Owning your own data reliably - being able to take it with you from system to system freely and without hassle - is becoming much and much more important, and people are now starting to recognize this.
I'll give you most points you made, but the fact that you have to do any reverse-engineering at all is a much bigger hurdle than you think. It's just wrong that it requires someone like jwz asking for the meaning of the flags field, and an anonymous benefactor (aka, almost certainly an Apple employee who knows he'd get in trouble if he revealed this information under his own name) to give a person full access to his own data.
It's much more likely for a proprietary and undocumented format like this to become unsupported. Without a good specification, all the subtle and inherent and assumed bugs that other bits and pieces start to rely on become one enormous hell to reverse-engineer. Just ask some of the WHATWG or Mozilla or Opera people who're currently trying to write specifications to make some IE-extensions like XMLHttpRequest or offsetParent work interoperably and completely sane for all edge-cases. (And those are the simple and relatively well understood extensions.)
But anyone, for you this personally isn't (recognized as?) a big enough issue (yet?) to switch to Linux. (To be honest, it isn't for me either.) But for some people, who many believe to be at the forefront of wherever it is we're going, it finally is a big enough issue, and I'm glad to see that more people are willing to consider their point of view. Awareness is half the battle won.
Who cares? Well, someverysmartpeople do. (Of those, Tim Bray himself switching as well.)
Whether you personally know or respect Mark, Tim and Cory, they're being looked to by a huge amount of others for guidance. This isn't a lightly made switch - "oh you know, I have a spare box lying around and I'm going to see how this shiny new OS works out, and then next week I'll go and play with Gentoo, and I've always been meaning to give Solaris a try as well". This is people with a tremendous amount of experience and knowledge, having spent their whole life on Macs, deciding that enough is enough, that the bough has broken, and that they care more about their data than about anything else. They all have a huge following, and their thoughts will reverberate.
Most people who will actually read their thoughts (rather than going for the knee-jerk "no, it's Monday so apple is good!" slashdot reaction that I've seen far too many posters here resort to) will probably be set thinking because of it. And everyone will make up their own minds, and most people will probably decide not to switch, for reasons that for them will be very valid. But you can sure as hell bet that the importance of open data formats and lack of DRM will become more of a talking point in the months to come, and that if Apple doesn't heed this warning, more and more people will come to the same conclusions as Mark, Time and Cory have.
(If you want to get the whole story, I'd read the following articles in this order:
1992, eh? These people have been active users and developers on Macs since respectively 1983 and 1984.
They have indeed come to the Mac. And now they've gone from it, and you might just want to listen up and find out why.
No, I don't care. The validator is a mechanical tool. It's inherently flawed, understanding nothing of semantics, easily tricked into validating things which never should validate, and in a number of cases throwing incorrect warnings and errors. Having your website validate is a first step. A guideline to doing things the right way. It's not completely necessary. The <canvas> element (as specified by the WHATWG, and implemented by Opera, Mozilla/Firefox/SeaMonkey and Safari (I'm reasonably certain)) will cause errors to be thrown, yet one can imagine cases where its use is already perfectly acceptable. (Just as long as you don't use it on a client website, or at least not without full understanding of the implications by the people there of using something which can change out from under them at any moment, and their responsibility to track those changes.)
Yes, I care. I'm a professional web developer. Of course my website validates, besides also being completely accessible and being as semantically meaningful as it can possibly be. It's just a little showcase of my technical expertise. And yes, I care, as in: if you as a fledging web developer come to me on IRC or on some mailinglist for help with your website, you'd better be damned certain that your website validates before bothering with me, as I'm not going to spend any time on what would otherwise almost certainly turn out to be a problem caused by your invalid code.
Those two points made: wow, what's with the harping on ACID 2? Yes, it's a nice test to spur browser makers on to come closer to being perfectly interoperable, but it tests a pretty arbitrary range of rendering bugs, and all browsers save for IE are pretty much interoperale on it at this point. (Firefox only on the reflow branch, to be sure, but that's set to land Real Soon Now, and as has been explained often, ACID 2 came at the worst possible time in the Mozilla development cycle.
Don't use phpbb, vbulletin or whichever other forum software everyone uses. Don't name your registration page "register.php" or something similarly easy to guess. Don't give your username and password fields name and id attributes of "username" and "password". Etc, etc. There is no security in obscurity, but there sure as hell is lots of convenience and freedom from automated harassment.
The rewards for writing scripts that can handle the subscription process for all the big software packages are simply too large. Yes, these software packages will now start up the arms race, same as has happened with weblogs and email and referer spammers (does anyone else have the feeling we've won that last one, btw?). You can try and follow along and update your forum software every other day. But it's much more convenient to simply duck under the radar. Chances are no spammer is going to bother figuring out how to register at your custom-built/modified forum.
I'm a reader. I like books. You know, the physical objects. I like the way they fit into my hands, I like the way they smell, I like the way I can stack them, I like the way in which having many of them leads to having quite an impressive looking library, where I can walk past the shelves and relive memories and randomly pick one up and leaf through the pages and remember.
I like the ways they don't use electricity, I like the way I can read them in bath without worrying, I like the way I can fall asleep with them, I like the way I don't have to worry about them being stolen, and above all I like the way they will last me forever. I expect that, barring a catastrophe like a major fire, 99% of the books I own will outlive me, and will remain readable during and beyond my lifetime.
eBooks... *shakes his head* there's just no way they could ever come close. There _already_ are eBook formats that were introduced just a few years ago which currently are currently pretty much unreadable. There are already eBook services which have gone out of business (and good riddance too!), causing their early adopting customers no end of trouble if they ever want to switch devices or re-authenticate and all that other DRM crap. There is every indication that not a single current format or implementation of eBooks will outlast the next decade.
There is no way I'm going to be tricked into having to continuously upgrade my entire library to "the next format" like music and video had/have going.
There are times I would like an electronic copy of a book. These times are 1) when I'm travelling for a long time, having spots of 10 minutes here or there to read (an eBook device here would save space over carrying multiple books, and because of the short amount of time, my eyes probably won't complain too much about the screen), but mostly 2) when I quickly want to look up a quote or specific scene, and so will want the ability to _search_ the electronic text.
Unfortunately, from what I've seen, the interface for the latter is usually severely lacking. The one strength eBooks have, and they cripple it with DRM... *shakes his head*
Give me plain text - completely free of DRM - eBooks, which I can grep through and which cost at most 10% of the real-world paperback version, and I'll probably buy my entire library in that format, just for searching and for having a "backup". (Yes, I know I could download such of usenet or p2p programs right now - but that's just too much effort.)
That's pretty much the only scenario in which I could ever see myself adopting eBooks though, and really, it'd be only as a supplement to real-world books.
Whenever I use a third-party framework (for web development, both server-side and client-side), I spend half my bug-fixing time looking through the framework's code. It's frigging annoying! I don't know if my code's just that advanced, or if I have that much bad luck picking frameworks, but I always seem to be hitting the limitations of any frameworks I use.
Nowadays, the first thing I do upon downloading a framework is to open a couple of its files and look at the coding style, see if I can figure out what's going on. If I can't make it out on a glance, if it's badly documented, or if their curly brackets look at me from the wrong position... I ditch it. It's not worth the effort. I'm far more effective just re-inventing the wheel on my own for the small parts of the framework that I'd otherwise use. And at least that way I know the code will do precisely and exactly what I need, rather than being a general-purpose tool-building factory factory factory.
Ben, those numbers are NOT per tab. The bfcache is global; there are never more than 8 pages total in bfcache (and you need to have 1GB of RAM for this to happen). Most users have 3 or 5 pages in bfcache at any given time.
The point of bug 292965 was that the pref should be global, not per-tab. Is that not working correctly?
(Boris and David are back-end developers; they have much more working knowledge of this than Ben does.)
Also, there are actual memory leaks in Firefox. See this weblog post about progress on that. However, as that weblog post says as well, most excessive memory usage that people are seeing is entirely due to faulty extensions.
Re:For those of us who don't follow mozilla.org...
on
SeaMonkey 1.0 Released
·
· Score: 1
What differentiates SeaMonkey from Mozilla?
SeaMonkey is the successor to Mozilla. SeaMonkey 1.0 is what would've been known as Mozilla 1.8, if it wasn't for the Mozilla Foundation scrapping it and focussing on Firefox instead.
However, I am disappointed that there seems to still be no support for "live bookmarks" (RSS feeds in bookmark form). That is the killer feature that made me switch from the Mozilla suite to Firefox. Are there any plans to implement this handy functionality in Seamonkey?
The bug for this is bug 240393 (copy paste link, as/. referers are blocked) and doesn't have any activity. If a developer who cares about this steps up to the plate, it could be in soon, but otherwise I wouldn't expect it for a while.
However, turning the mailnews client into a feedreader, similar to Thunderbird (both using Myk Melez's ForumZilla extension as a starting point) is being worked on in bug 255834 (idem), and is targetted for SeaMonkey 1.1, to be released late this year. It would've been in SeaMonkey 1.0, but unfortunately the lead Thunderbird dev didn't want this code to be shared, so extra effort had to be spent to fork it between the SeaMonkey and Thunderbird trees.
Re:For those of us who don't follow mozilla.org...
on
SeaMonkey 1.0 Released
·
· Score: 5, Informative
So, is it Firefox and Thunderbird thrown together in one executable? Or is it something more or less.
It's both more and less. It has a different approach to what such a program should be. Firefox and Thunderbird operate on the principle that it needs to be usable by the proverbial grandmother, and make a lot of sacrifices to get there. Features that are considered "bloat" or confusing are cut rigorously, the user interface gets lots of polishing, and everything that isn't considered essential for basic operation is delegated to the status of extension (which leads to a number of problems). Because of this, Firefox and Thunderbird are supremely usable products, which I'll heartily recommend to any computer novice.
SeaMonkey on the other hand continues the tradition of the Mozilla Suite, which cared less about appearing clunky and confusing, and is far more customizable and ultimately usable for power users, web developers and other geeks. The SeaMonkey people understand that people can have ways to browse which aren't intuitively obvious to grandmothers, but which are ultimately more efficient, and that enabling this is a great good.
As a result SeaMonkey has a number of features that aren't present (by default or at all) in Firefox/Thunderbird, ranging from roaming profiles, to the dom inspector and javascript debugger, to tighter integration between the email program and the browser to far more preferences exposed and easily editable. On the other hand, Firefox has more money behind it, and so has been developing rapidly in some areas, resulting in a large gap in SeaMonkey in an area such as extension management (of course, extensions aren't as necessary for effectively using SeaMonkey, but it's still a big gap).
So, to answer your three questions:
Compatability with Thunder/Fire themes and extensions.
Partly, depending on the specifics of the extension, and the effort its developer went to. I answered this question more fully here.
Does it share the same security holes, or will it have its own;)
It will mostly have the same (as most security problems are in the backend), but a few less in the frontend, as SeaMonkey has tighter review requirements than Firefox does. (I can think of one big security problem in the last year that was related to extension management which was only present in Firefox, not in Mozilla/SeaMonkey.)
Will it be udated as often as Thunder/Fire?
Yes, that is the goal, give or take a few weeks and some point releases. A SeaMonkey 1.1 release should come around the time of Firefox 2.0, and a SeaMonkey 1.5 for whenever Firefox 3.0 happens. (They'll be matches fairly closely in time, as both depend on the same branches and heavily tested stable code.)
In the current SeaMonkey release there is no component called "Composer". Where is it?
Assuming an install that includes mailnews, it's the third icon in the bottom left (otherwise the second), also accessible through the menu bar: Window -> Composer, or by hitting ctrl-4, or ctrl-e to edit the current page.
but I didn't know if the Sea Monkey guys had tried to improve on the old codebase though...that was my question;)
Ah, ok. In that case, yes, there've undoubtedly been a number of fixes to the editor code since 1.7 (which is what NVu started of with). I'm seeing "+3703/3280) Lines changed" in the/editor directory in the rough timeperiod between the two branches (April 2004 to September 2005) and 56 bugs marked as fixed for the same timeperiod in the editor component. (Not linking, as slashdot referers are blocked.) Of course that code is shared with the email composer and Midas (the rich text editor), but there still should be some improvements.
Some do, some don't. It mostly depends on how much effort the extension developer put into his work. A lot of basic extensions should be completely compatible between the two programs, with only needing to use a different installation system, and most of those will indeed have versions for both. A lot of other extensions depend on Firefox specific UI / code, and probably won't (if they even make sense at all in the SeaMonkey/Mozilla world), unless the developer cared, or got lots of requests from people to make the extension compatible. You can browse the Mozilla/SeaMonkey extensions at addons to see what's there.
So how does the Sea Monkey web editor compare to Nvu? If it's better, that'll really suck having to download a whole suite just for that one component.
It isn't better, as it's the basis on which NVu has been built (missing lots of features, but with the same basics). NVu's main developer has committed to donating back all the new code to the main Mozilla tree before releasing another version of NVu, and as far as I know, that's currently in the process of happening (although slowly, as it's a lot of code to be reviewed, and not many people capable of doing so).
SeaMonkey 1.5 should contain the results of this work, so basically a WYSIWYG editor nearly identical to current NVu.
Atom is "an XML-based document format that describes lists of related information known as "feeds""... with the primary use case of "the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents", as specified in RFC 4287. And it's supported by... well, pretty much everything out there.
If you read the RFC, you will also see that Atom is superbly well-specified. Back in the Atom 0.3 days, I implemented both an RSS feed and an Atom feed, and ever since I've stuck to implementing solely Atom feeds, as information about RSS is scattered everywhere, and you need to specify, for example, half a dozen mutually-incompatible and differently-formatted date elements just to be certain that the correct date of an entry is understood everywhere. And that's the easy part.
Not in itself all that meaningful, perhaps (other than that the average has now reached over 20% for Europe worldwide), but when you see the changes through previous editions:
...you get a pretty decent idea of the growth. (Anyone want to turn that into an animated gif?)
For the record, here's their map of the world, showing ~15.88% in the USA, and 18.60% in Australia. And finally, the difference between percentages during the weekend and during the week appears to be 0.05% (if I interpret that graph correctly)
Virtually all extensions which worked with Mozilla will work with SeaMonkey. It's always possible for an extension to use unfrozen interfaces or rely on bugs and for things to just stop working due to changes - there's been near enough a year and a half of development time since the 1.7 branch was created after all - but the expectation is that extension authors for who this is the case will update their extensions to work with SeaMonkey again, just like they would've done for Mozilla.
Of course there's also a large group of extensions which are Firefox only; the extension installation mechanism is different, and extensions for SeaMonkey/Mozilla have the responsibility to provide their own uninstaller (not that many do), but that's really a choice that extension authors make - who they want to support - and the only thing you could do about that is ask them directly if they will provide a version for SeaMonkey, or to take their code and do it yourself.
I thought the exact same thing. Luckily I'm using a Mozilla product (SeaMonkey in my case, Firefox is too stiffling for me), so I could open the trusty Dom-Inspector and graft some CSS to fix this for myself.
In the chrome/ directory of your profile, create a textfile called userContent.css (or open it if it already exists) and paste the following lines in there:
@-moz-document domain("maps.google.com") { body > #page > #map { margin-left: 0 !important; margin-right: 20.4em !important; } body > #page > #panel { left: auto !important; right: 0 !important; } }
@-moz-document domain("local.google.com") { body > #page > #map { margin-left: 0 !important; margin-right: 20.4em !important; } body > #page > #panel { left: auto !important; right: 0 !important; } }
Save, restart Mozilla/Firefox/SeaMonkey, and observe the sidebar on the right, where it belongs.:)
Note that this won't work in 1.7 branch build such as Firefox 1.0.x - only in the SeaMonkey alpha, Firefox 1.5 betas, old Mozilla 1.8 alphas or nightly builds.
Slashdot Mirror
Or just write the ten lines needed to do XMLHttpRequest calls yourself (there, that's the AJAX part taken care of), and for all other effects write your own functions just like always (copy/paste from your personal library and adapt), so you don't have to deal with bloat, nine out of every ten functions being unneeded, and far too many levels of abstraction and generalization, and have the benefit of actually being able to quickly debug the script when you encounter a problem!
The only organizations where these toolkits might be useful are the really really large ones where there's a team that can dig into the framework and basically "make it their own". Everything smaller, using occasional contractors to maintain the code, benefit far and far more from simplicity, readability and maintainability than from dubious-quality top-heavy frameworks with lack of code-level documentation and thousand and one edgecase-bugs. (Spoken like someone who's had to trace such bugs in the mess of prototype and scriptaculo.us; I've only _looked_ at Dojo, Rico, Yahoo and Zimbra (and not at all at the other two), but my impressions were that what they made up in better code quality, they lost in bloat.)
It is: "presenting itself as a legitimate existing extension called numberedlinks".
The McAfee characteristics page (2nd tab - stupid that that isn't directly linkable) also says:
Thanks. :)
I think it's safe to say that your average consumer doesn't have any idea who these people are. But your average techie probably does, and they (we) are the ones who'll be set thinking because of it, and even if it doesn't convince us, we in turn will probably help turn the theme of open data into enough of an issue to finally be picked up by the media and consumers.
Very well put.
Over the years, people's data has become much more important than it used to be. In the past, you wrote a few documents in Wordstar, and later one you sent the occasional email to the three other geeks you knew who had internet access. But nowadays, everyone is living and storing a very significant part of their lives on their computers, and their data includes such things as all the photos they take, all the emails they've exchanged with their girlfriends, all the music they listen to, and the only videos of their children's first steps they'll ever have. Owning your own data reliably - being able to take it with you from system to system freely and without hassle - is becoming much and much more important, and people are now starting to recognize this.
I'll give you most points you made, but the fact that you have to do any reverse-engineering at all is a much bigger hurdle than you think. It's just wrong that it requires someone like jwz asking for the meaning of the flags field, and an anonymous benefactor (aka, almost certainly an Apple employee who knows he'd get in trouble if he revealed this information under his own name) to give a person full access to his own data.
It's much more likely for a proprietary and undocumented format like this to become unsupported. Without a good specification, all the subtle and inherent and assumed bugs that other bits and pieces start to rely on become one enormous hell to reverse-engineer. Just ask some of the WHATWG or Mozilla or Opera people who're currently trying to write specifications to make some IE-extensions like XMLHttpRequest or offsetParent work interoperably and completely sane for all edge-cases. (And those are the simple and relatively well understood extensions.)
But anyone, for you this personally isn't (recognized as?) a big enough issue (yet?) to switch to Linux. (To be honest, it isn't for me either.) But for some people, who many believe to be at the forefront of wherever it is we're going, it finally is a big enough issue, and I'm glad to see that more people are willing to consider their point of view. Awareness is half the battle won.
Who cares? Well, some very smart people do. (Of those, Tim Bray himself switching as well.)
Whether you personally know or respect Mark, Tim and Cory, they're being looked to by a huge amount of others for guidance. This isn't a lightly made switch - "oh you know, I have a spare box lying around and I'm going to see how this shiny new OS works out, and then next week I'll go and play with Gentoo, and I've always been meaning to give Solaris a try as well". This is people with a tremendous amount of experience and knowledge, having spent their whole life on Macs, deciding that enough is enough, that the bough has broken, and that they care more about their data than about anything else. They all have a huge following, and their thoughts will reverberate.
Most people who will actually read their thoughts (rather than going for the knee-jerk "no, it's Monday so apple is good!" slashdot reaction that I've seen far too many posters here resort to) will probably be set thinking because of it. And everyone will make up their own minds, and most people will probably decide not to switch, for reasons that for them will be very valid. But you can sure as hell bet that the importance of open data formats and lack of DRM will become more of a talking point in the months to come, and that if Apple doesn't heed this warning, more and more people will come to the same conclusions as Mark, Time and Cory have.
(If you want to get the whole story, I'd read the following articles in this order:
1992, eh? These people have been active users and developers on Macs since respectively 1983 and 1984.
They have indeed come to the Mac. And now they've gone from it, and you might just want to listen up and find out why.
No, I don't care. The validator is a mechanical tool. It's inherently flawed, understanding nothing of semantics, easily tricked into validating things which never should validate, and in a number of cases throwing incorrect warnings and errors. Having your website validate is a first step. A guideline to doing things the right way. It's not completely necessary. The <canvas> element (as specified by the WHATWG, and implemented by Opera, Mozilla/Firefox/SeaMonkey and Safari (I'm reasonably certain)) will cause errors to be thrown, yet one can imagine cases where its use is already perfectly acceptable. (Just as long as you don't use it on a client website, or at least not without full understanding of the implications by the people there of using something which can change out from under them at any moment, and their responsibility to track those changes.)
Yes, I care. I'm a professional web developer. Of course my website validates, besides also being completely accessible and being as semantically meaningful as it can possibly be. It's just a little showcase of my technical expertise. And yes, I care, as in: if you as a fledging web developer come to me on IRC or on some mailinglist for help with your website, you'd better be damned certain that your website validates before bothering with me, as I'm not going to spend any time on what would otherwise almost certainly turn out to be a problem caused by your invalid code.
Those two points made: wow, what's with the harping on ACID 2? Yes, it's a nice test to spur browser makers on to come closer to being perfectly interoperable, but it tests a pretty arbitrary range of rendering bugs, and all browsers save for IE are pretty much interoperale on it at this point. (Firefox only on the reflow branch, to be sure, but that's set to land Real Soon Now, and as has been explained often, ACID 2 came at the worst possible time in the Mozilla development cycle.
Don't use phpbb, vbulletin or whichever other forum software everyone uses. Don't name your registration page "register.php" or something similarly easy to guess. Don't give your username and password fields name and id attributes of "username" and "password". Etc, etc. There is no security in obscurity, but there sure as hell is lots of convenience and freedom from automated harassment.
The rewards for writing scripts that can handle the subscription process for all the big software packages are simply too large. Yes, these software packages will now start up the arms race, same as has happened with weblogs and email and referer spammers (does anyone else have the feeling we've won that last one, btw?). You can try and follow along and update your forum software every other day. But it's much more convenient to simply duck under the radar. Chances are no spammer is going to bother figuring out how to register at your custom-built/modified forum.
I'm a reader. I like books. You know, the physical objects. I like the way they fit into my hands, I like the way they smell, I like the way I can stack them, I like the way in which having many of them leads to having quite an impressive looking library, where I can walk past the shelves and relive memories and randomly pick one up and leaf through the pages and remember. I like the ways they don't use electricity, I like the way I can read them in bath without worrying, I like the way I can fall asleep with them, I like the way I don't have to worry about them being stolen, and above all I like the way they will last me forever. I expect that, barring a catastrophe like a major fire, 99% of the books I own will outlive me, and will remain readable during and beyond my lifetime. eBooks... *shakes his head* there's just no way they could ever come close. There _already_ are eBook formats that were introduced just a few years ago which currently are currently pretty much unreadable. There are already eBook services which have gone out of business (and good riddance too!), causing their early adopting customers no end of trouble if they ever want to switch devices or re-authenticate and all that other DRM crap. There is every indication that not a single current format or implementation of eBooks will outlast the next decade. There is no way I'm going to be tricked into having to continuously upgrade my entire library to "the next format" like music and video had/have going. There are times I would like an electronic copy of a book. These times are 1) when I'm travelling for a long time, having spots of 10 minutes here or there to read (an eBook device here would save space over carrying multiple books, and because of the short amount of time, my eyes probably won't complain too much about the screen), but mostly 2) when I quickly want to look up a quote or specific scene, and so will want the ability to _search_ the electronic text. Unfortunately, from what I've seen, the interface for the latter is usually severely lacking. The one strength eBooks have, and they cripple it with DRM... *shakes his head* Give me plain text - completely free of DRM - eBooks, which I can grep through and which cost at most 10% of the real-world paperback version, and I'll probably buy my entire library in that format, just for searching and for having a "backup". (Yes, I know I could download such of usenet or p2p programs right now - but that's just too much effort.) That's pretty much the only scenario in which I could ever see myself adopting eBooks though, and really, it'd be only as a supplement to real-world books.
Whenever I use a third-party framework (for web development, both server-side and client-side), I spend half my bug-fixing time looking through the framework's code. It's frigging annoying! I don't know if my code's just that advanced, or if I have that much bad luck picking frameworks, but I always seem to be hitting the limitations of any frameworks I use.
Nowadays, the first thing I do upon downloading a framework is to open a couple of its files and look at the coding style, see if I can figure out what's going on. If I can't make it out on a glance, if it's badly documented, or if their curly brackets look at me from the wrong position... I ditch it. It's not worth the effort. I'm far more effective just re-inventing the wheel on my own for the small parts of the framework that I'd otherwise use. And at least that way I know the code will do precisely and exactly what I need, rather than being a general-purpose tool-building factory factory factory.
Ben was mistaken, it's cached globally.
See this comment by Boriz Zbarsky:
and this comment by David Baron:
(Boris and David are back-end developers; they have much more working knowledge of this than Ben does.)
Also, there are actual memory leaks in Firefox. See this weblog post about progress on that. However, as that weblog post says as well, most excessive memory usage that people are seeing is entirely due to faulty extensions.
The bug for this is bug 240393 (copy paste link, as /. referers are blocked) and doesn't have any activity. If a developer who cares about this steps up to the plate, it could be in soon, but otherwise I wouldn't expect it for a while.
However, turning the mailnews client into a feedreader, similar to Thunderbird (both using Myk Melez's ForumZilla extension as a starting point) is being worked on in bug 255834 (idem), and is targetted for SeaMonkey 1.1, to be released late this year. It would've been in SeaMonkey 1.0, but unfortunately the lead Thunderbird dev didn't want this code to be shared, so extra effort had to be spent to fork it between the SeaMonkey and Thunderbird trees.
It's both more and less. It has a different approach to what such a program should be. Firefox and Thunderbird operate on the principle that it needs to be usable by the proverbial grandmother, and make a lot of sacrifices to get there. Features that are considered "bloat" or confusing are cut rigorously, the user interface gets lots of polishing, and everything that isn't considered essential for basic operation is delegated to the status of extension (which leads to a number of problems). Because of this, Firefox and Thunderbird are supremely usable products, which I'll heartily recommend to any computer novice.
SeaMonkey on the other hand continues the tradition of the Mozilla Suite, which cared less about appearing clunky and confusing, and is far more customizable and ultimately usable for power users, web developers and other geeks. The SeaMonkey people understand that people can have ways to browse which aren't intuitively obvious to grandmothers, but which are ultimately more efficient, and that enabling this is a great good.
As a result SeaMonkey has a number of features that aren't present (by default or at all) in Firefox/Thunderbird, ranging from roaming profiles, to the dom inspector and javascript debugger, to tighter integration between the email program and the browser to far more preferences exposed and easily editable. On the other hand, Firefox has more money behind it, and so has been developing rapidly in some areas, resulting in a large gap in SeaMonkey in an area such as extension management (of course, extensions aren't as necessary for effectively using SeaMonkey, but it's still a big gap).
So, to answer your three questions:
Partly, depending on the specifics of the extension, and the effort its developer went to. I answered this question more fully here.
It will mostly have the same (as most security problems are in the backend), but a few less in the frontend, as SeaMonkey has tighter review requirements than Firefox does. (I can think of one big security problem in the last year that was related to extension management which was only present in Firefox, not in Mozilla/SeaMonkey.)
Yes, that is the goal, give or take a few weeks and some point releases. A SeaMonkey 1.1 release should come around the time of Firefox 2.0, and a SeaMonkey 1.5 for whenever Firefox 3.0 happens. (They'll be matches fairly closely in time, as both depend on the same branches and heavily tested stable code.)
SeaMonkey 1.5 should contain the results of this work, so basically a WYSIWYG editor nearly identical to current NVu.
Atom is "an XML-based document format that describes lists of related information known as "feeds"" ... with the primary use case of "the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents", as specified in RFC 4287. And it's supported by... well, pretty much everything out there.
If you read the RFC, you will also see that Atom is superbly well-specified. Back in the Atom 0.3 days, I implemented both an RSS feed and an Atom feed, and ever since I've stuck to implementing solely Atom feeds, as information about RSS is scattered everywhere, and you need to specify, for example, half a dozen mutually-incompatible and differently-formatted date elements just to be certain that the correct date of an entry is understood everywhere. And that's the easy part.
Percentages all over Europe (in french, but the pretty pictures speak for themselves).
Not in itself all that meaningful, perhaps (other than that the average has now reached over 20% for Europe worldwide), but when you see the changes through previous editions:
...you get a pretty decent idea of the growth. (Anyone want to turn that into an animated gif?)
For the record, here's their map of the world, showing ~15.88% in the USA, and 18.60% in Australia. And finally, the difference between percentages during the weekend and during the week appears to be 0.05% (if I interpret that graph correctly)
Virtually all extensions which worked with Mozilla will work with SeaMonkey. It's always possible for an extension to use unfrozen interfaces or rely on bugs and for things to just stop working due to changes - there's been near enough a year and a half of development time since the 1.7 branch was created after all - but the expectation is that extension authors for who this is the case will update their extensions to work with SeaMonkey again, just like they would've done for Mozilla.
Of course there's also a large group of extensions which are Firefox only; the extension installation mechanism is different, and extensions for SeaMonkey/Mozilla have the responsibility to provide their own uninstaller (not that many do), but that's really a choice that extension authors make - who they want to support - and the only thing you could do about that is ask them directly if they will provide a version for SeaMonkey, or to take their code and do it yourself.
And although this really shouldn't be necessary on /. - here are instructions for finding your profile.
I thought the exact same thing. Luckily I'm using a Mozilla product (SeaMonkey in my case, Firefox is too stiffling for me), so I could open the trusty Dom-Inspector and graft some CSS to fix this for myself.
In the chrome/ directory of your profile, create a textfile called userContent.css (or open it if it already exists) and paste the following lines in there:
Save, restart Mozilla/Firefox/SeaMonkey, and observe the sidebar on the right, where it belongs. :)
Note that this won't work in 1.7 branch build such as Firefox 1.0.x - only in the SeaMonkey alpha, Firefox 1.5 betas, old Mozilla 1.8 alphas or nightly builds.
err...
s/although this might come after Mozilla 1.7.11 or thereabouts/although this might come after Mozilla 1.11 or thereabouts/.