those are aggregate statistics from the the web sites hosted by a university's libraries, representing quite a few different designs, all of which have worked just fine when we tested them in Opera. (as you might suspect, we do focus practically all of our testing on Firefox, Safari, and IE)
i installed Opera just now, and browsed around our 4 primary applications, and they work just the same as in Firefox, Safari, and IE.
so it's not a case of "an interface that doesn't work in opera"... it's an example of a demographic (our students, faculty, and staff) who simply don't seem to use Opera in any significant numbers.
we're actually seeing about 5 times as many Lynx users as Opera users, and we're definitely counting the "spoofed" user-agent with "Opera" at the end as Opera, not MSIE.
That's exactly why he's suggesting that they assign their most experienced engineers -- the ones who know best how the applications fit together and how all the little pieces interact -- to oversee the process of approving and applying those patches.
Because exactly as you've pointed out -- it's not the small maintenance and enhancement programming that makes a project good. It's the higher-level decisions by the project managers that can determine whether code changes will be successful.
I will bring it up. That should be trivial to implement, but there are several layers of management which will have to be convinced to deviate from the existing behavior, and to allow us to release it to the public.
I believe OCLC went with 302 due to incomplete/nonexistant implementations of 303 status in pre-HTTP/1.1 clients, but that was a long time ago.
I spent the past couple of weekends working on a messageboard in Rails. I don't know about the "ten times faster development" claims... but I do feel like I'm getting around three times as much done versus working in PHP -- and I already knew PHP, but just started to pick up Ruby a couple of weeks ago. When they say this framework "fits your brain", they really mean it.
The Rails folks are very good at marketing -- but they surely haven't forgotten to put a solid product behind that buzz.
As for Ruby losing to Python? Well...
At work, we're in the middle of re-implementing OCLC's PURL redirection server (which is a tasty casserole of Perl, C, and god only knows what else). With the goal of demonstrating that we don't need our own private copy of Apache (as OCLC uses), a pile of ReWrite rules, and an army of Perl scripts to work with its Berkeley DB backend, I threw together a quick demo using Ruby's WEBrick servlet and connected it to PostgreSQL. Thankfully, I was able to persuade the decision-makers that a scripting language and an RDBMS are a reasonable solution to our problem... but their attitude toward Ruby was similar to yours. "I dunno, I haven't heard much about it, let's use something else."
We settled on Python, which, of course, has its own SimpleHTTPServer which fills roughly the same niche as WEBrick. But it's slower, it dies if you throw too many concurrent connections at it, and its built-in methods are far cruder than those of its Ruby counterpart. I'm going to have to write a lot more code to pull it off in Python.
Obviously this is an anecdotal example... but I just keep coming across things in Ruby that simply make more sense, and just work better than they do in other systems. After a couple of weeks, I'm certainly sold -- even though $PREFERRED_LANGUAGE will keep paying the bills, Ruby is a great tool to have at my disposal.
well, they're providing documentation, among other things. and honestly... unless you're an IBM customer, you're really not in a position to say what they're offering and not offering.
well, it would help if its filesystem layout looked more than vaguely like every other Unix and Unix-like OS in the world. Installing software in/sw is not something you have to do on a real Unix... or even on most Unix knockoffs.
one thing is for sure: if Mac OS X is a Unix OS, it's the one that's least like the others. to be sure, this arbitrary differentiation is something Apple consumers value, but it's just a headache for any developer who wants to support BSD *and* OS X.
Messageboards and IM are very convenient for keeping in touch with people who have moved to other cities. What you've said would imply that we should restrict our social lives to those who live within a 30-mile radius at the moment. I think that's a far more dismal prospect than using another new technology to stay in contact with people.
People have written letters, sent telegrams, and called each other for hundreds of years. Long-distance communication is part of human social behavior -- regardless of whether your very narrow definition recognizes that.
The vast majority of blog-style web sites are written and controlled by a single user. Slashdot has several editors, and all of the stories are contributed by visitor.
Make no mistake: Slashdot is not what people are talking about when they complain of the spam that blogs have dumped into Google..
the advantage of ethanol isn't that it's more efficient than gasoline, or cleaner -- the adantage is that it's a drop-in replacement fuel for most internal-combustion engines that now burn gasoline.
sure, as long as there's oil, ethanol doesn't really look efficient or affordable except as a fuel oxygenator. but if the oil reserves were to run out sometime soon, ethanol could be poured into most of our existing infrastructure and ease the transition. that's why it's important -- not because it's inherently superior to petroleum, but because it can be manufactured (from scratch) much more quickly.
The idea that software code produced as part of academic research could be anything but open-source is appalling. How can the software possibly be peer-reviewed for its merits if its source code is kept secret?
Personally, I don't trust the results of any research that is based on proprietary, black-box software. Keeping the source code hidden may work in the retail software business, but it simply doesn't cut it in research.
Show us the source code, or your research is freaking useless.
Slashdot Mirror
i installed Opera just now, and browsed around our 4 primary applications, and they work just the same as in Firefox, Safari, and IE.
so it's not a case of "an interface that doesn't work in opera"... it's an example of a demographic (our students, faculty, and staff) who simply don't seem to use Opera in any significant numbers.
we're actually seeing about 5 times as many Lynx users as Opera users, and we're definitely counting the "spoofed" user-agent with "Opera" at the end as Opera, not MSIE.
i'm pretty sure most log analysis tools will be counting that as Opera already. Webalizer definitely does.
if i get this in metamod, you can bet i'm marking it unfair!
Because exactly as you've pointed out -- it's not the small maintenance and enhancement programming that makes a project good. It's the higher-level decisions by the project managers that can determine whether code changes will be successful.
#!/bin/sh
# updates the sound list
path=$1
find $path -name "*.[Oo][Oo][Gg]" -print > soundlist.txt
find $path -name "*.[Mm][Pp][3]" -print >> soundlist.txt
find $path -name "*.[Ww][Aa][Vv]" -print >> soundlist.txt
find $path -name "*.[Ff][Ll][Aa][Cc]" -print >> soundlist.txt
find $path -name "*.[Aa][Ii][Ff][Ff]" -print >> soundlist.txt
#!/bin/sh
# play random file from filelist
filelist=$1
len=`wc -l $filelist`
n=`expr $RANDOM % $len`
play `sed -n ${n}p $filelist`
I believe OCLC went with 302 due to incomplete/nonexistant implementations of 303 status in pre-HTTP/1.1 clients, but that was a long time ago.
The Rails folks are very good at marketing -- but they surely haven't forgotten to put a solid product behind that buzz.
As for Ruby losing to Python? Well...
At work, we're in the middle of re-implementing OCLC's PURL redirection server (which is a tasty casserole of Perl, C, and god only knows what else). With the goal of demonstrating that we don't need our own private copy of Apache (as OCLC uses), a pile of ReWrite rules, and an army of Perl scripts to work with its Berkeley DB backend, I threw together a quick demo using Ruby's WEBrick servlet and connected it to PostgreSQL. Thankfully, I was able to persuade the decision-makers that a scripting language and an RDBMS are a reasonable solution to our problem... but their attitude toward Ruby was similar to yours. "I dunno, I haven't heard much about it, let's use something else."
We settled on Python, which, of course, has its own SimpleHTTPServer which fills roughly the same niche as WEBrick. But it's slower, it dies if you throw too many concurrent connections at it, and its built-in methods are far cruder than those of its Ruby counterpart. I'm going to have to write a lot more code to pull it off in Python.
Obviously this is an anecdotal example... but I just keep coming across things in Ruby that simply make more sense, and just work better than they do in other systems. After a couple of weeks, I'm certainly sold -- even though $PREFERRED_LANGUAGE will keep paying the bills, Ruby is a great tool to have at my disposal.
well, they're providing documentation, among other things. and honestly... unless you're an IBM customer, you're really not in a position to say what they're offering and not offering.
eComStation has been maintaining os/2 under license from IBM for a few years now.
you make it sound like globalization is some kind of quantitative phenomena...
sigh.
it's got a long way to go before it's in the same class as the *BSD's.
one thing is for sure: if Mac OS X is a Unix OS, it's the one that's least like the others. to be sure, this arbitrary differentiation is something Apple consumers value, but it's just a headache for any developer who wants to support BSD *and* OS X.
that link is in the summary, dude.
Yeah, but can it tell my fortune?
i can't imagine anything more hair-raising than modifying the BIOS while windows is running
I'd just like them to shut up all on their own.
Freedom of speech doesn't guarantee an audience.
People have written letters, sent telegrams, and called each other for hundreds of years. Long-distance communication is part of human social behavior -- regardless of whether your very narrow definition recognizes that.
Make no mistake: Slashdot is not what people are talking about when they complain of the spam that blogs have dumped into Google..
Slashdot represents thousands of voices.
Most blogs represent one voice only.
The inefficiency of an existing manufacturing process is usually considered a reason to research it more, not to abandon it.
you owe me a keyboard. and a coffee.
sure, as long as there's oil, ethanol doesn't really look efficient or affordable except as a fuel oxygenator. but if the oil reserves were to run out sometime soon, ethanol could be poured into most of our existing infrastructure and ease the transition. that's why it's important -- not because it's inherently superior to petroleum, but because it can be manufactured (from scratch) much more quickly.
now if only it didn't have the fatal flaw of that freaking hinge.
Personally, I don't trust the results of any research that is based on proprietary, black-box software. Keeping the source code hidden may work in the retail software business, but it simply doesn't cut it in research.
Show us the source code, or your research is freaking useless.