Slashdot Mirror
Mozilla Now Even Includes The Kitchen Sink
zzxc writes "Mozillazine reports that a 'kitchen sink' easter egg has been added into Mozilla by a patch to bug 122411. It shows an ASCII art animated kitchen sink. This was prompted by people complaining about Mozilla's bloat - that 'it includes everything but the kitchen sink.' You can see this xhtml demo by going to about:kitchensink in a recent Mozilla nightly, or at mozilla.org with an older mozilla build. Please note that this is not actually included in the browser package, so it doesn't add to mozilla's bloat. Instead, about:kitchensink directs the user to the xml document on mozilla's website."
Neither does Windows, unless you count showing a blank blue screen on request as a "feature." I wish people would stop posting this as if it were somehow funny and interesting.
My guess is that this was going to be an Easter Egg, but someone somewhere along the line thought better of it.
I wonder what kind of a crappy setup you have. I have a athlon 2000+ @ 1.82 and mozilla sucks up a big fat 31 megs of RAM and 1% of my CPU in XP with 13 tabs open (12 slashdot comment pages and the sink). Sure if you load 12 pages with flashy widgets it will get worse but that's with any browser.
The page is valid XHTML. If IE can't render it, that's its problem. Most of the IE-only pages are not standards-compliant, and that's the problem.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
It's kind of hypocritical to talk about sites that just don't work in Mozilla and other browsers, and that you shouldn't support companies that make sites like that but when a site like this works only in Mozilla it's just fine
Oh what a load of troll-scented crap. This isn't a "site", it is a silly easter egg built into the program. This is not a page with actual information, it's not meant for consumption by the general public (i.e. my grandfather is not going to search on Google for "kitchen sink", find this, and be disappointed that it does not work in IE). It is a "feature" specifically for Mozilla users.
Would you complain the same way if a Mozilla skin or XUL extension didn't work with IE? Of course not. It's not meant to.
"Wow, you're like some kind of superhero able to ward off happiness and success at every turn."
-- Ryan Stiles
NTLM easily explained
m.kelley
life is like a freeway, if you don't look you could miss it.
I have no complaints about Mozilla taking up too much of either RAM or cycles.
As you point out, the cycles are no problem when it is idling. Just a possible problem when animating ascii. (I wonder of other browsers would do better at ascii animation consumption of cpu cycles?)
As for RAM, who cares? RAM is cheap and getting cheaper by the day. Just look at the things we can do with computers today while jerking off vs. the things we could do with our computers, say in 1990.
Unfortunantly, having so much capability takes RAM.
We could trade RAM for capability and go back to using Commodore 64's.
I imagine in 10 years everyone will complain that Mozilla takes up 9 Gigabytes of RAM! Why can't it be efficient like back in 2007 when it only needed 768 MB of RAM? Of course, nobody will mention what Mozilla can do in 2013 vs. today.
Could Mozilla be made to have the same capability and use less RAM? Yes, undoubtedly. What would it cost? Development effort.
I believe there is some fair tradeoff of using computer resources (cycles, RAM, disk, etc.) to shorten development effort. Use higher level languages. Higher level abstractions. Yes you can be more efficient by working at a lower level of abstraction, but the development effort is higher.
Why don't we write everything in assembly language? This used to be a huge argument between the "high level language" camp and the "assembly language only" camp. The evidence was clear. Assembly programs were smaller and faster. More efficient by every possible measurement. So why aren't we still writing programs that way? Why don't we still use GOTO instead of structured programming constructs? Why was object oriented programming introduced? Why do we even tollerate the existance of interpreted languages, and even worse, inefficient languages that use dynamic typing such as Lisp, Python, JavaScript, etc.? Don't people know that static typing allows much more efficient compilation?
My hunch is that people don't care. They value productivity more.
If you could have your new super-duper software package (Office, word processor, browser, <insert software package of choice>) released nine months sooner, but it would use 30 % more RAM, would you take it?
I'll see your senator, and I'll raise you two judges.
The patch was not checked in to the Mozilla trunk because it was vetoed by drivers@mozilla.org. It will likely never be checked in.
How about doing some tiny little bit of fact-checking? Who needs news if it's false?
Bah, ascii-renderings of people are common. You plug in an image, run it through a rednering program, and walla: You have pr0n. Tech has been around for years.
For the Trek asciiart, someone actually sat around for hours to get the ~ or the ` in the right location. A true waste of time, but I admire their effort.
"Can of worms? The can is open... the worms are everywhere."
What kind of a sad world has it become when easter eggs get announced before they've even made it into a beta? The whole point of these things used to be the treasure hunt. Do you read the walk-through before you even start playing a new game?
And followed by insisting that anyone who thinks something like that should be expected to work in the first place is a drooling half-wit...
What I'm listening to now on Pandora...
Put another way, here's another story. In the early days of the interstate highway system, there was a problem with the roadway signage where, because the signs didn't give people enough warning that an exit was coming up, drivers kept colliding with the signs, destroying them, while trying to veer off the highway at the last minute. When the project engineers were told about this, the solution they came up with was simple, elegant, and completely wrong: build a sign strong enough to withstand an impact from a car moving at highway speeds.
The lessons there should be obvious. Rather than identify what today might be called the usability problems of the signage system, they focused only on the sign device itself. Their solution didn't make the problem go away, and it probably made impacts with signs much more dangerous for people in the car. The right solution, which we have since moved to, is to come up with standards to give people more information ahead of the exits so that collisions like this are much less probably.
I think the Mozilla people are falling for the same trap. They've heard the complaints, but rather than take them to heart, they poke fun at it -- and in fact adding in code for this easter egg, even if you are downloading the xml from mozilla.org's servers, is only adding to the application's bloat. Like the splash screen example, this is itself a great sign *ahem* that the project developers aren't listening to the concerns of their users. Rather, it's just starting to seem like a colossal exercise in self-gratification.
Good thing I can use Safari :-)
DO NOT LEAVE IT IS NOT REAL