No, awesomebar must stay. I use it daily and it is one of THE best features of Firefox 3. The old bar was too dumb and it annoyed me to no end that I can't even do a substring search in the title of the pages I visited.
If you think supporting older platforms is as simple as "test for an API at runtime, check for a possible error or null pointer, and then decide what to execute" then you've never written any serious desktop software with lots of users.
You are talking about browser security updates while running on unpatched versions of Windows? That's like complaining that your door manufacturer won't make doors for your house while all the windows in your house can be opened and don't have any locks.
Yes, nowadays. 6 years ago good virtualization software was scarces.
Now, fast forward 6 years later. The once-in-4-months guy who asks about Windows 9x has now become once-in-a-year. And you still think it's worth it to spend effort on supporting Windows 9x, at the cost of fixing bugs and optimizing the software?
It isn't about just API changes, it's about behavior changes as well. Bug fixes change the behavior subtly, and if you are relying on the absence of certain bugs, then you're screwed if you didn't test your software on earlier versions of Windows.
"No. Fundamentally, what is a web browser? It's a program that sends out tcp/ip packets, waits for the response, and displays stuff on screen."
You'd be surprised how many things can go wrong, even if it's just "a program that sends out tcp/ip packets, waits for the response, and displays stuff on screen". - What if you rely on the fact that you can draw a line in your window, from a positive coordinate to a negative coordinate? And what if older versions of Windows had a bug that causes the entire screen to become corrupted? Oops, should have tested that. - What if you implemented code in the installer which registers Firefox in Windows Firewall, but forgot to write fallback code for when Windows Firewall is not available? Oops, should have tested that. - You could say "just develop on older versions of Windows!" What if you develop for XP-SP0, and rely on the fact that Windows's Unicode engine converts invalid data into "?". What if this later turns out to be unspecified behavior, and they got rid of that in order to optimize some things in Windows, and now the invalid data makes the entire program crash? Oops, should have tested that on newer Windows versions!
All of these are made up scenarios, but they *could* be true. The biggest software that I'm developing right now is a web application deployment platform built on top of Apache, and you'd be surprised how many corner cases there are that I have to consider. Fixing something on one version of Apache can break older versions, and fixing something on older versions can break things on newer versions.
You are seriously underestimating how much effort it takes to test software and how easily things can break.
"It also decreases the compatibility with the systems your userbase use. Smart move!"
If dropping support for 0.5% of by user base decreases 30% of my testing effort, which I then can allocate into fixing bugs and making things better for the other 99.5% of the user base, then yes it actually is a smart move.
"I really wonder how many of the legal and illegal XP users combined actually have SP3. Yes the illegal XP users are a legitimate userbase, because they are a big part of the reason that the OS got adopted so successfully."
There's no obligation to support people who break the law.
"So Moz is only going to support the current shipping service pack for XP and Vista. Why? Is Firefox doing anything (better question SHOULD it be) low level enough for the current version to matter?"
Yes, bug fixes in the operating system. If you write code then you'd have to test your code on all supported versions of Windows to make sure that there's no weird Windows bug which breaks your code. The more OS versions you support, the more testing you have to do. All the effort spent on testing $ANCIENT_VERSION_OF_WINDOWS could have been spent on fixing bugs in the application or optimizing things. Furthermore, older OS versions typically have less users. It doesn't take a genius to see that at some point you'd reach the point of diminishing returns.
What happened to all that? Even the cheapest computers these days can run XP SP3. The number of people still using XP-SP0 or a 2001-era Linux is like, what, 0.03%? It absolutely makes no sense to talk about running on XP SP0 as a selling point when almost nobody uses XP SP0.
It's not like they're dropping support for SP3.
"And personally, I'm still disappointed there is no Windows 9x version any more."
As a software developer I gave up on Windows 9x 5 years ago. I used to worry about Windows 9x users 6 years ago. However, I did not have access to Windows 9x (all my machines were running XP), making it very hard to develop and test for it. Finding a Windows 9x CD or ISO was almost impossible even 6 years ago. I asked my user base to help me with testing on Windows 9x, and nobody responded. Once in a while, maybe once every 4 months, one user (of the approximately 20000 in total) asks about Windows 9x support, but is not skilled enough to help me with testing.
How can you reasonably expect any software developer to keep supporting Windows 9x in such conditions?
It's not about needing, it's about testing. By dropping support for XP-SP0, you declare that you've never tested your software on XP-SP0. It might work, or it might not. Some code might have recently been written which breaks on SP0 because of a bug that has been fixed since SP3. Or it might not.
Point is, dropping support for older Windows versions decreases the amount of testing needed. That is the biggest value, not about utilizing newer APIs.
"And email or a form online couldn't achieve this information exchange? I don't think I could do a useful bug report in 140 characters."
It could. But by asking this question you are already missing the point. Users choose to communicate via Twitter. I don't tell them to, but they still do. And yes this includes people who complain about bugs via Twitter. Twitter is a valuable source of bug reports because many of these people will most likely not have bothered posting a bug report if Twitter didn't exist.
"And you couldn't have an auto updater (apt-get, whatever) that would keep your users from being tied to yet another piece of software to get your software? RSS is another fine method of informing people in near real time of updates."
I could. But again, you're missing the point. Users who chose not to subscribe to RSS, or not to read my blog, may still be interested in software releases. And there are quite a few of those people out there.
"So, still, I view it as pretty useless given that there are equal and better ways of accomplishing the same tasks."
If so then you are missing the point. This isn't about what you regard as the best tool for the job, but what others choose to use. I don't think Twitter is the best communication medium either, but many people use it, there's a lot of feedback on it, and that's what makes it valuable.
Twitter is not useless. As a software developer I regularly check on Twitter what people say about my software. Dozens of improvements have been made thanks to feedback on Twitter. Many users also regularly check my tweets in order to be informed about software updates and other things that they might be interested in.
More FreeBSD zealots huh? It's not false. I've seen it happening at least a few times. Once I tried upgrading Subversion, and Ports silently upgraded Berkeley DB for me. This broke a few Apache modules and a few PHP modules. I wasn't aware of the problem until a user emailed me!
Yes I probably know shit. I also know that apt has never uninstalled a kernel on me, so I don't care whether I "know shit". I just care that stuff keeps working, and with apt, it does. With ports, it doesn't.
"The best"? Ports will blow up your system if you try to update a package A that depends on package B version 2.0, while the already installed packages C and D depend on B version 1.0. Ports will happily upgrade B to 2.0 without warning you, thus breaking C and D. Apt never does this. I shouldn't have to manually inspect every dependency to ensure that nothing will break if I update packages!
Sure, *installing* software on FreeBSD is easy. But managing updates with Ports is a total pain and it had made me very wary of updating *anything* at all on my FreeBSD system, which is probably not good for my system's long-term security. Last week my FreeBSD server broke, and this time I ditched it in favor of Debian Linux. Until FreeBSD gets rid of ports I'm never using it again.
"Thanks, Captain Anecdote, but you've left out even the anecdotal evidence. What's all this exclusive writing you're doing with Ruby? I've been doing all my grocery list work in Ruby too, and it's *totally* fast enough."
I'm not the GP, but New York Times, MTV, Aboutus.com (high-ranking Alexa site), Yellow Pages, are all running Ruby. I'd love to give you even more examples but I've signed NDAs.
"I think Ruby is a fantastic language, but then I see comments like this modded up to 5 that are completely nonsensical. This makes Ruby fandom seem more like Java 1999, which makes me think twice about my positive opinion of it."
I can say the same thing about comments that complain about Ruby's speed without providing any kind evidence that the interpreter's speed is the bottleneck in their application. This makes it seem like bashing Ruby is just the latest fad, which makes it very hard for me to take any of these complaints seriously. If you cry wolf several times then nobody will listen to you anymore.
Every time a story is posted about Ruby performance improvements, someone will post something along the lines of "x times faster than super ultra duper slow is still slow". Even if Ruby is 1000 times faster, there will still be people complaining. My guess is that none of these people actually use Ruby in production to be able to tell how much interpreter performance actually matters in the grand scheme of things.
"Because obviously you have no other important work to do until it's finished."
Human multitasking is very, very, very bad for productivity. By switching task one will lose his concentration, and it will take a long time before one's back into "the zone". If you have two tasks to finish, it's faster if you finish them serially. If you multitask between them every 10 minutes then it might take you twice as long to finish the tasks.
If I have to wait 3 minutes every time I want to see a browser rendering it will totally kill my productivity, even if I have other tasks.
surely you are only going to submit your final work and not every single change that you make to your WIP
Actually, a web developer should and has to submit every single change. As a developer you'll want to catch cross-browser rendering differences early, instead of finding out after 2 months that the awesome design that you made works in Firefox and Opera (locally tested) but totally broken in IE with no way to fix it thanks to IE bugs.
Browsershots is not a serious alternative. Everything that you send to Browsershots will be placed into a giant queue so you'll have to wait about 30 minutes before you see the results.
I've always found stories along the lines of "$ENTITY wastes $X amount of $RESOURCE per year" dubious. Given enough users who each use a piece of $RESOURCE, the total amount of used resources will always be large no matter how little each individual user uses. There's no way to win.
Slashdot Mirror
No, awesomebar must stay. I use it daily and it is one of THE best features of Firefox 3. The old bar was too dumb and it annoyed me to no end that I can't even do a substring search in the title of the pages I visited.
If you think supporting older platforms is as simple as "test for an API at runtime, check for a possible error or null pointer, and then decide what to execute" then you've never written any serious desktop software with lots of users.
You are talking about browser security updates while running on unpatched versions of Windows? That's like complaining that your door manufacturer won't make doors for your house while all the windows in your house can be opened and don't have any locks.
Yes, nowadays. 6 years ago good virtualization software was scarces.
Now, fast forward 6 years later. The once-in-4-months guy who asks about Windows 9x has now become once-in-a-year. And you still think it's worth it to spend effort on supporting Windows 9x, at the cost of fixing bugs and optimizing the software?
It isn't about just API changes, it's about behavior changes as well. Bug fixes change the behavior subtly, and if you are relying on the absence of certain bugs, then you're screwed if you didn't test your software on earlier versions of Windows.
"No. Fundamentally, what is a web browser? It's a program that sends out tcp/ip packets, waits for the response, and displays stuff on screen."
You'd be surprised how many things can go wrong, even if it's just "a program that sends out tcp/ip packets, waits for the response, and displays stuff on screen".
- What if you rely on the fact that you can draw a line in your window, from a positive coordinate to a negative coordinate? And what if older versions of Windows had a bug that causes the entire screen to become corrupted? Oops, should have tested that.
- What if you implemented code in the installer which registers Firefox in Windows Firewall, but forgot to write fallback code for when Windows Firewall is not available? Oops, should have tested that.
- You could say "just develop on older versions of Windows!" What if you develop for XP-SP0, and rely on the fact that Windows's Unicode engine converts invalid data into "?". What if this later turns out to be unspecified behavior, and they got rid of that in order to optimize some things in Windows, and now the invalid data makes the entire program crash? Oops, should have tested that on newer Windows versions!
All of these are made up scenarios, but they *could* be true. The biggest software that I'm developing right now is a web application deployment platform built on top of Apache, and you'd be surprised how many corner cases there are that I have to consider. Fixing something on one version of Apache can break older versions, and fixing something on older versions can break things on newer versions.
You are seriously underestimating how much effort it takes to test software and how easily things can break.
"It also decreases the compatibility with the systems your userbase use. Smart move!"
If dropping support for 0.5% of by user base decreases 30% of my testing effort, which I then can allocate into fixing bugs and making things better for the other 99.5% of the user base, then yes it actually is a smart move.
"I really wonder how many of the legal and illegal XP users combined actually have SP3. Yes the illegal XP users are a legitimate userbase, because they are a big part of the reason that the OS got adopted so successfully."
There's no obligation to support people who break the law.
"So Moz is only going to support the current shipping service pack for XP and Vista. Why? Is Firefox doing anything (better question SHOULD it be) low level enough for the current version to matter?"
Yes, bug fixes in the operating system. If you write code then you'd have to test your code on all supported versions of Windows to make sure that there's no weird Windows bug which breaks your code. The more OS versions you support, the more testing you have to do. All the effort spent on testing $ANCIENT_VERSION_OF_WINDOWS could have been spent on fixing bugs in the application or optimizing things. Furthermore, older OS versions typically have less users. It doesn't take a genius to see that at some point you'd reach the point of diminishing returns.
What happened to all that? Even the cheapest computers these days can run XP SP3. The number of people still using XP-SP0 or a 2001-era Linux is like, what, 0.03%? It absolutely makes no sense to talk about running on XP SP0 as a selling point when almost nobody uses XP SP0.
It's not like they're dropping support for SP3.
"And personally, I'm still disappointed there is no Windows 9x version any more."
As a software developer I gave up on Windows 9x 5 years ago. I used to worry about Windows 9x users 6 years ago. However, I did not have access to Windows 9x (all my machines were running XP), making it very hard to develop and test for it. Finding a Windows 9x CD or ISO was almost impossible even 6 years ago. I asked my user base to help me with testing on Windows 9x, and nobody responded. Once in a while, maybe once every 4 months, one user (of the approximately 20000 in total) asks about Windows 9x support, but is not skilled enough to help me with testing.
How can you reasonably expect any software developer to keep supporting Windows 9x in such conditions?
It's not about needing, it's about testing. By dropping support for XP-SP0, you declare that you've never tested your software on XP-SP0. It might work, or it might not. Some code might have recently been written which breaks on SP0 because of a bug that has been fixed since SP3. Or it might not.
Point is, dropping support for older Windows versions decreases the amount of testing needed. That is the biggest value, not about utilizing newer APIs.
"And email or a form online couldn't achieve this information exchange? I don't think I could do a useful bug report in 140 characters."
It could. But by asking this question you are already missing the point. Users choose to communicate via Twitter. I don't tell them to, but they still do. And yes this includes people who complain about bugs via Twitter. Twitter is a valuable source of bug reports because many of these people will most likely not have bothered posting a bug report if Twitter didn't exist.
"And you couldn't have an auto updater (apt-get, whatever) that would keep your users from being tied to yet another piece of software to get your software? RSS is another fine method of informing people in near real time of updates."
I could. But again, you're missing the point. Users who chose not to subscribe to RSS, or not to read my blog, may still be interested in software releases. And there are quite a few of those people out there.
"So, still, I view it as pretty useless given that there are equal and better ways of accomplishing the same tasks."
If so then you are missing the point. This isn't about what you regard as the best tool for the job, but what others choose to use. I don't think Twitter is the best communication medium either, but many people use it, there's a lot of feedback on it, and that's what makes it valuable.
Twitter is not useless. As a software developer I regularly check on Twitter what people say about my software. Dozens of improvements have been made thanks to feedback on Twitter. Many users also regularly check my tweets in order to be informed about software updates and other things that they might be interested in.
More FreeBSD zealots huh? It's not false. I've seen it happening at least a few times. Once I tried upgrading Subversion, and Ports silently upgraded Berkeley DB for me. This broke a few Apache modules and a few PHP modules. I wasn't aware of the problem until a user emailed me!
Yes I probably know shit. I also know that apt has never uninstalled a kernel on me, so I don't care whether I "know shit". I just care that stuff keeps working, and with apt, it does. With ports, it doesn't.
"The best"? Ports will blow up your system if you try to update a package A that depends on package B version 2.0, while the already installed packages C and D depend on B version 1.0. Ports will happily upgrade B to 2.0 without warning you, thus breaking C and D. Apt never does this. I shouldn't have to manually inspect every dependency to ensure that nothing will break if I update packages!
Sure, *installing* software on FreeBSD is easy. But managing updates with Ports is a total pain and it had made me very wary of updating *anything* at all on my FreeBSD system, which is probably not good for my system's long-term security. Last week my FreeBSD server broke, and this time I ditched it in favor of Debian Linux. Until FreeBSD gets rid of ports I'm never using it again.
That depends on how you define "longer":
1 - (3 / 4) -> 25% longer
4 / 3 - 1 -> 33% longer
And how many people use Fibre Channel for it to matter?
"Thanks, Captain Anecdote, but you've left out even the anecdotal evidence. What's all this exclusive writing you're doing with Ruby? I've been doing all my grocery list work in Ruby too, and it's *totally* fast enough."
I'm not the GP, but New York Times, MTV, Aboutus.com (high-ranking Alexa site), Yellow Pages, are all running Ruby. I'd love to give you even more examples but I've signed NDAs.
"I think Ruby is a fantastic language, but then I see comments like this modded up to 5 that are completely nonsensical. This makes Ruby fandom seem more like Java 1999, which makes me think twice about my positive opinion of it."
I can say the same thing about comments that complain about Ruby's speed without providing any kind evidence that the interpreter's speed is the bottleneck in their application. This makes it seem like bashing Ruby is just the latest fad, which makes it very hard for me to take any of these complaints seriously. If you cry wolf several times then nobody will listen to you anymore.
What are you talking about? This is about server-side software, not executable applets in clients' browsers.
Tell that to MTV and New York Times. Yes, they run Rails. Not on the front page, but nevertheless, they use it on very busy parts of their sites.
And heck, do I even need to mention 37signals? Those guys receive tons and tons of requests per second.
Every time a story is posted about Ruby performance improvements, someone will post something along the lines of "x times faster than super ultra duper slow is still slow". Even if Ruby is 1000 times faster, there will still be people complaining. My guess is that none of these people actually use Ruby in production to be able to tell how much interpreter performance actually matters in the grand scheme of things.
"Because obviously you have no other important work to do until it's finished."
Human multitasking is very, very, very bad for productivity. By switching task one will lose his concentration, and it will take a long time before one's back into "the zone". If you have two tasks to finish, it's faster if you finish them serially. If you multitask between them every 10 minutes then it might take you twice as long to finish the tasks.
If I have to wait 3 minutes every time I want to see a browser rendering it will totally kill my productivity, even if I have other tasks.
surely you are only going to submit your final work and not every single change that you make to your WIP
Actually, a web developer should and has to submit every single change. As a developer you'll want to catch cross-browser rendering differences early, instead of finding out after 2 months that the awesome design that you made works in Firefox and Opera (locally tested) but totally broken in IE with no way to fix it thanks to IE bugs.
Browsershots is not a serious alternative. Everything that you send to Browsershots will be placed into a giant queue so you'll have to wait about 30 minutes before you see the results.
I've always found stories along the lines of "$ENTITY wastes $X amount of $RESOURCE per year" dubious. Given enough users who each use a piece of $RESOURCE, the total amount of used resources will always be large no matter how little each individual user uses. There's no way to win.