I would much prefer my everyday applications to be written in languages that don't constantly segfault because of pointer arithmetic, raise null pointer exceptions because nullable and nonnullable types are not distinguished, or give syntax errors at runtime because they happen to be fully interpreted.
The only time Python segfaults is when you have some really crazy code, or far far more commonly when you have C code in your system and that code is bad. Most dynamic languages also are not fully interpreted -- Python is not, and Ruby is interpreted, but won't raise syntax errors at runtime. The exception is if you are doing source code generation, which Rails does a fair amount of, but is not very common in Python code.
Now, the null pointer exceptions don't happen in these languages because there are no pointers, but similar things do happen. And they happen in Java too. Java not statically typed enough? Well, whatever, you get back to me when you have that awesome statically typed language with no slop that anyone actually does useful things with.
I don't think experience has shown us that statically typed languages are more reliable than dynamic. Programs that are developed with obsessive attention to detail, extensive review, and formalized practices and standards are reliable. None of those has anything to do with static typing; static typing is the absurd notion that the computer can be disciplined for you. If you look at something like programming by contract, it has nothing to do with static typing -- it's all about the programmers writing the system spending time indicating the exact needs and promises of the API, and language gives those programmers a structure in which to describe and automatically confirm those promises.
yet, no-one seems to be particularly hindered by the DRM in iTunes
I've lost access to most of the (thankfully limited) content I bought through iTMS, and I will not purchase anything from them in the future. DRMs default-deny policy is the digital equivalent of crappy customer service built on a fragile and unforgiving bureaucracy. Apple's shit stinks just like anyone else's, and DRM is shit and will likely always be shit.
Any system where you have to ask permission to use things you've already paid for and are entirely encapsulated on your own system will be a shitty system. That said, I actually imagine a pure-streaming system would actually work better, except for the numerous technical limitations and the anti-consumer territorialism of the services. And Apple is more territorial than most.
Honestly I can only imagine DRM being decent if controlled and regulated by a non-profit or governmental agency. Which isn't actually the conclusion I'd have expected when I started writing this reply. Huh.
Personally I find Ion to be nicer than Ratpoison, though I wasn't that familiar with screen when I tried Ratpoison so that might have been an issue. Ion, though not under extremely active development, seems to be usable for a wider variety of tasks.
Both are tiled window managers, so you allocate the screen to frames and put apps in frames, rather than arranging your app windows directly.
They aren't starving because there is no food, they are starving because of conflict and war, because the nations they live in aren't failed because they never worked to begin with, because there's of the political machinations of minor figures and the obstinance of bureaucrats.
Africa is a land that could feed all its occupants, with resources for industry, trade, construction and any number of kinds of advancement. Africa doesn't lack in these things. But a variety of disfunctions and injustices mean that people go hungry, that fields lay fallow, that traditional social structures have decayed and modern social structures have not replaced them.
So laptops seem like a perfectly good investment to me. And they sure as hell don't need our food of all things. You make food from land and labor, which (barring war or the misuse of land) are readily available in the third world.
Just because they need browsers?
on
Google to Buy Opera?
·
· Score: 3, Insightful
Anyway, here's my $0.2: Google cares about browsers. They are really good at providing services over the web -- with relatively low overhead on the backend too -- but they rely on browsers for actual user experience. The quality of browsers directly effects the quality of application they can provide. They flirt with other interfaces -- like Google Earth and the like -- but their core is the browser.
They don't need a browser of their own, but they need a competitive browser market. Firefox, thus, is very important to them -- even if it never gains a majority market share, it forces Microsoft to improve IE again. Opera may have a similar strategic value, especially because on mobile phones it seems like it's mostly Opera or something proprietary, and proprietary means that Google could be locked out or extorted to provide access fees. It doesn't matter that much to them if another browser does well on mobile phones, just like it doesn't matter that much if Firefox or IE win, so long as they have a quality browser(s) available.
I also sometimes wonder how Opera is really doing financially. If they are strapped for cash -- and I have zero idea how they are doing -- that may limit their ability to improve the product, or even the viability of the product entirely. So Google might just be trying to keep the market healthy (from their perspective) by keeping different products in the play.
I kept its firmware and server updated up until about 3 months ago when I gave up after a disk failure; later revisions helped a little but not a lot. I have the skills to perhaps fix the installation, but not the will; I use Ubuntu because I don't like to waste my time futzing with stuff. Figuring out how to install an unthreaded (and not packaged) version of Perl on my system is not the kind of thing that makes me happy. (If I was feeling snarky, which apparently I am, I would also note that the quality and robustness of the server isn't surprising to me when it's written in Perl)
In response to the parent and WAVs: I don't think that's a good option over wireless. Of course the server can decode any format, that's easy; but it's still bullshit when they implied that it plays formats besides MP3, such as Ogg.
I got one of these a while ago, and I've never really been happy with it. Setting it up on Debian wasn't terribly hard (with alien), but not that easy either. On Ubuntu I can't get it to run at all, some research showed it had something to do with Perl and threads and whatever version of libraries Ubuntu was using, but I couldn't find any resolution. The software itself never impressed me; the web UI was clunky, it would segfault fairly regularly, and always spewed out a variety of warnings. It didn't deal very well with the size of my music collection; by only using the file browsing mode I could get by (I keep my music well organized in folders), but other modes (e.g., browsing by artist parsed from id3 tags) were too slow.
The box itself seemed like too dumb of a client, asking the server about what it should do in response to every action. Perhaps the wireless connection back to my computer wasn't good enough (it was a fair distance), but even so, the fact it could play an MP3 *at all* would indicate it should have a good enough connection to present a usable UI. But the response was always slow, with little indication whether it was working or not. I probably wouldn't have minded the slowness of certain operations if I could tell reliably that it was definitely *doing* something. But instead I'd have to wait 10 seconds and try again if it seemed to have not noticed the remote signal.
For actual listening, I could get maybe 30 minutes of play before it randomly stopped. Getting it going again was hard, involving rebooting several different pieces and finally just praying it would start working. I could never understand what was going on.
It's entirely possible that a bad connection to my computer leads to a general degredation of... everything. If I can get it working again I'll probably try to connect it via ethernet. But even if that is the problem, the degredation is not very graceful.
Another thing that annoyed me, and may or may not still be the case, is that it only plays MP3s. I got the impression that it played oggs from its marketing, but that's just bullshit. The server software happens to be able to transcode to MP3. Having the server transcode to MP3 is stupid (and uses up a lot of CPU to boot), and I ended up simply transcoding all my oggs to mp3 and keeping them on disk instead of having it do this on the fly.
Point the third: please explain how anonymous closures are superior to lambda constructs, list comprehensions, or generators each used in the appropriate context.
There are two things I can think of (and I'm saying this as a Python advocate): finalization and some kinds of callbacks (some callbacks are best presented as functions, so they are already fine in Python). Finalization currently is done in python with try:finally:, and it's easy to forget the proper wrapping. Python 2.5 will add a new construct for this, described in PEP 343 (with some acknowledged heritage from Ruby). The second, callbacks, I think is largely addressed with coroutines, described in PEP 342.
Some people would say that Ruby's one feature -- anonymous closures -- is superior because it is responsible for all sorts of functionality that is implemented via several constructs in Python. That I would disagree with -- the features (things like looping) are such fundamental patterns in a language that their use will always be idiomatic, no matter how elegantly they fit into some underlying syntax or functionality.
I added this feature (using the database as the source of the model) to SQLObject a couple years ago, before I'd ever heard of Rails. But, after adding it, it never seemed like that neat of a feature, and it only gets moderate use. I don't claim SQLObject was the first... rather that it's not that great a feature compared to using the class itself as an authoritative representation (which no one uses in Rails because they don't have a choice, since ActiveRecord doesn't implement that).
No one familiar with Python development should have ever been wowed by anything Rails does from a technical point of view. All the surprise about these features is coming from Java and PHP people, who have lived in darkness and to whom all light is blinding and full of amazement. I don't have a problem with that -- you'll get no arguments from me that Rails is better than what PHP or Java offers. But it doesn't mean Rails is novel.
IronPython isn't abandoned, it's just in some weird Microsoft limbo. It's by the original author of Jython, who got hired by Microsoft and has apparently been caught in some bureaucratic limbo where he spends most of his time in meetings (though another programmer internal to MS has also been allocated, from what I understand).
SELECT * FROM address, transaction, lineitem where lineitem.cost > 200 and address.city = 'New New York'.
OK. That's actually buggy SQL since you'll get the cross product of those tables, but I'll assume you mean:
SELECT * FROM address, transaction, lineitem where lineitem.cost > 200 and address.city = 'New New York' and lineitem.transaction_id = transaction.transaction_id and transaction.address_id = address.address_id
From what I understand Google uses C++, Python, and Java. Java is used mostly for internal accounting projects. C++ is used for all the stuff that has to be Really Fast, and I suspect lots of code gets migrated from Python to C++ during the development cycle. They use SWIG to interface between Python and C++. I haven't heard about them using many other languages, except XSLT and other special-purpose languages.
There's your problem -- you're mixing SQL code in with your app code. Bad developer! Bad! You're introducing SQL injection holes
Of all the bugs SQLObject has had, I don't think SQL injection has ever come up. Some languages are stupid (stupid stupid stupid) and encourage SQL injection. E.g., in PHP the "right" way to construct SQL is something like "select * from foo where name = '" . addslashes(stripslashes($name)) . "'". Or some monstrosity, depending on whether magic quotes is on, and what database you are using. This is insanely bad. If you forget addslashes everything will work until someone puts a ' into the input. (With separate weird problems if you forget stripslashes -- or include it when you shouldn't)
Python (and other sane languages) use something like query("select * from foo where name = %s", (name,)) (SQLObject gives this a different syntax, but same idea). With this, if you forget the substitution or do it incorrectly it will be Completely Broken -- because you'll be sending a query like select * from foo where name = Tom. This is a good poka yoke.
As far as putting SQL in the code, sometimes a query is best expressed at the time you will use it. If you want all customers in an area code, is it really best to make a customersInAreaCode(areaCode) method, or just use Customer.selectBy(areaCode=X)? They look pretty much equivalent to me -- except the latter comes for free, and is completely localized to the place you use it. That localization is a negative if it means you are duplicating code; however, creating an abstraction before any duplicate code would be created is also a negative.
As far as the other issues: SQLObject uses the Active Record model (which Rails' ActiveRecord happens to be named after) and is best suited to Application Databases. There are pluses and minuses to this. You can often use a mixture of both styles, if you find a need. But if you are an organization of web developers without dedicated database personel and with a tight schedule, you will be best served by the Application Database style of development, because (from a developer's point of view) it gives you the most control.
(a) I think you mean 4k of code, not 4000 lines (which would be quite large for a wiki), and (b) if you want small, in Wiki terms, 23 (wrapped) lines is closer to what you should shoot for (at least in Python).
If you are doing network programming -- stuff like VOIP, chat servers, etc -- then you should definitely look at Twisted. You can use it for web development too, but it's a bit challenging.
Rails has taught us some important lessons, but they aren't really technical lessons:
We shouldn't sit around and say "oh, those poor people using PHP/Java/etc, too bad they don't know about what you can do using X". Instead we should talk more loudly and insistently about the advantages of our platforms. If you do it right people will pay attention.
We haven't concentrated enough on full-stack integration. We've been overvaluing decoupled pick-and-choose components. Full-stack integration doesn't have to mean coupling -- it can just be a matter of presentation, and making sure tools are complimentary. Not all of the Python frameworks are coming at it from this direction, but TurboGears very much is.
Things like screencasts are nice.
After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.
As for Ruby: I think the
two languages are largely equivalent in terms of what you
can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.
For something more legally and ethically unambiguous there is also MP3tunes and eMusic, though they both have limited selections of generally independent music. Strangely enough mp3.com doesn't seem to have mp3s on it anymore. There's also some labels like Magnatune that distribute mp3s.
All it will take is the RIAA to make downloading mp3s of songs which the hold the copyrights for illegal...
Yes, that would do it. Or all it would take is for the RIAA to make it illegal not to tithe 10% of all your income to them, and we could all be arrested. Luckily the RIAA doesn't make law, and the law as it currently stands doesn't seem to make downloading from allofmp3.com illegal.
you are downloading music from an unauthorized distributor and the RIAA would be more than pleased to stop that in one way or the other.
allofmp3.com is an authorized distributor in Russia, with music licensed from a licensing authority in that country. The organization is more similar to the US organizations BMI or ASCAP than the RIAA, but apparently they have the authority to license this kind of distribution in that country. (I don't think the RIAA actually has licensing rights at all.) The RIAA would be more than pleased to do lots of things, but they are not the government, they cannot make law, and just because they might not like this it is not necessarily illegal.
It is correct that it's implausible that allofmp3.com contributes any significant amount of money back to artists. I'd be interested if anyone outside of Russia has ever received a check from that licensing organization. It may not be ethical, but ethics are not law. It would be lovely if someone would set up a direct-to-artist compensation system, so that people could support artists while (legally or illegally) working around the organizations that claim to represent them. I think that would lead to a much better ethical balance than the current systems that the RIAA and their members have set up.
Anyway, such is the ways of globalization. Companies can shop around to different countries for low wages and little worker protection. Consumers can shop around to different countries for friendly copyright laws.
For the 3rd time, the Chicago El is not light rail - the trains are longer, heavier, faster, and more frequent, all of which make them louder than typical light rail systems.
Not that I'm saying the El is a modern system (it's obviously not). But if you are slower than the El, your system sucks -- the El is not a fast system. From what I understand, LRT (at least at-grade LRT) is also heavier than "heavy" rail systems (I presume including the El, since it uses fairly normal cars). The "L" in LRT is just a fraudulent term based on the fact they use a different kind of rail, even though their cars are heavier. This doesn't necessarily make the noise worse; but it does mean that LRT is not energy-efficient (and tends to be worse than cars, in terms of BTUs per passenger-mile).
I don't buy it. Mass transit sucks everywhere when compared to a well-functioning (or even rather disfunctional) system with cars. (I'm not at all pro-car, I'm just being realistic)
New York transit isn't great. It's comprehensive, and that's important. It makes it a useful system in a way that very few US transit systems are. But mere utility isn't the same as being good; we set our sites very low. But because we've gotten used to that, people think New York has great transit, because even having a choice not to have a car seems incredible.
No mass transit system is as fast as a car -- total door-to-door travel time -- unless the traffic is attrocious. Well, commuter rail might be an exception, because it's one of the most efficient forms of mass transit, but it's only so efficient because it's not at all comprehensive -- both the times it runs, and its destinations. Even faster, more modern trains are only nominally faster than cars, and the better and faster the system, the smaller the number of its destinations, causing a fractured travel experience of ever slower modes. And the fractured experience isn't just slow, it is distracting and alienating. You can bring 10 kids on one train or a bus, but you can't transfer (unless you don't mind losing a kid or two). You can carry your groceries home if you can do it on one bus, but that's about it. And that's not even taking into account the cost, which can often be quite extravagant -- it costs $10 in Chicago for a family of four to take the train or bus round trip.
Traditional mass transit is a nice option, but it only really succedes when cars fail; because they are too expensive, or traffic is too horrible, parking is not available, or you just are unable to drive. Any system that feeds off the disfunction of another -- that cannot stand on its own feet and compete favorably to a functioning competitor -- is a sad system. And that's what we have with traditional mass transit.
With that in mind, I'm not sure that Monorail is a good system. But I know LRT isn't, and Subways aren't, and buses aren't. I don't know that Monorail is significantly different from those, but at least it's an attempt instead of choosing a system proven to be a failure. (OK, they are choosing one of those too...)
Personally I have hope for PRT, which is less proven still, but at least attempts to solve the real problems that public transit faces, with a model that is closer to something that works (cars) while still having many of the benefits we look for in public transit.
Now, if Seattle were to follow the lead of these guys, they might be able to leapfrog cities like New York, without asking for an unrealistic change of geography or demographics.
I think PRT (Personal Rapid Transit: see also this Salon article) could be an excellent way to move kids about, and there's a lot of possible efficiencies when you build a public transit system that is appropriate for children. Because PRT could take children directly to their schools, it's every bit as good as a school bus, but with less time in transit, thus less fuel, no driver cost, more predictable schedules for parents, more flexibility of destination (useful when a child has more than one home)...
Of course it's still in development, and has had a hard time finding support. But then, the post asked how tech can help...
As the older people start to retire I am sure younger people in the company will see where the promotion opportunities are and will learn on the job as needed.
Mainframe jobs aren't going to be appealing as a promotion; they have been dead-end jobs for a long time now. They are skilled jobs supporting important services, and the jobs lead nowhere; that's why it's hard to find people. Dead-end technologies are a bitch that way.
If we're talking about URL management, an interesting Python project is a port of Rails' Routes. This is notable in particular because it is reversable -- you can both unpack a URL to a controller and set of arguments, and pack a controller and set of arguments back into a URL.
It's a very new project, so I don't think it's been used in any Python framework yet. But it would probably be applicable to quite a few of them (perhaps including CherryPy).
Slashdot Mirror
Now, the null pointer exceptions don't happen in these languages because there are no pointers, but similar things do happen. And they happen in Java too. Java not statically typed enough? Well, whatever, you get back to me when you have that awesome statically typed language with no slop that anyone actually does useful things with.
I don't think experience has shown us that statically typed languages are more reliable than dynamic. Programs that are developed with obsessive attention to detail, extensive review, and formalized practices and standards are reliable. None of those has anything to do with static typing; static typing is the absurd notion that the computer can be disciplined for you. If you look at something like programming by contract, it has nothing to do with static typing -- it's all about the programmers writing the system spending time indicating the exact needs and promises of the API, and language gives those programmers a structure in which to describe and automatically confirm those promises.
Any system where you have to ask permission to use things you've already paid for and are entirely encapsulated on your own system will be a shitty system. That said, I actually imagine a pure-streaming system would actually work better, except for the numerous technical limitations and the anti-consumer territorialism of the services. And Apple is more territorial than most.
Honestly I can only imagine DRM being decent if controlled and regulated by a non-profit or governmental agency. Which isn't actually the conclusion I'd have expected when I started writing this reply. Huh.
Both are tiled window managers, so you allocate the screen to frames and put apps in frames, rather than arranging your app windows directly.
Africa is a land that could feed all its occupants, with resources for industry, trade, construction and any number of kinds of advancement. Africa doesn't lack in these things. But a variety of disfunctions and injustices mean that people go hungry, that fields lay fallow, that traditional social structures have decayed and modern social structures have not replaced them.
So laptops seem like a perfectly good investment to me. And they sure as hell don't need our food of all things. You make food from land and labor, which (barring war or the misuse of land) are readily available in the third world.
They don't need a browser of their own, but they need a competitive browser market. Firefox, thus, is very important to them -- even if it never gains a majority market share, it forces Microsoft to improve IE again. Opera may have a similar strategic value, especially because on mobile phones it seems like it's mostly Opera or something proprietary, and proprietary means that Google could be locked out or extorted to provide access fees. It doesn't matter that much to them if another browser does well on mobile phones, just like it doesn't matter that much if Firefox or IE win, so long as they have a quality browser(s) available.
I also sometimes wonder how Opera is really doing financially. If they are strapped for cash -- and I have zero idea how they are doing -- that may limit their ability to improve the product, or even the viability of the product entirely. So Google might just be trying to keep the market healthy (from their perspective) by keeping different products in the play.
In response to the parent and WAVs: I don't think that's a good option over wireless. Of course the server can decode any format, that's easy; but it's still bullshit when they implied that it plays formats besides MP3, such as Ogg.
The box itself seemed like too dumb of a client, asking the server about what it should do in response to every action. Perhaps the wireless connection back to my computer wasn't good enough (it was a fair distance), but even so, the fact it could play an MP3 *at all* would indicate it should have a good enough connection to present a usable UI. But the response was always slow, with little indication whether it was working or not. I probably wouldn't have minded the slowness of certain operations if I could tell reliably that it was definitely *doing* something. But instead I'd have to wait 10 seconds and try again if it seemed to have not noticed the remote signal.
For actual listening, I could get maybe 30 minutes of play before it randomly stopped. Getting it going again was hard, involving rebooting several different pieces and finally just praying it would start working. I could never understand what was going on.
It's entirely possible that a bad connection to my computer leads to a general degredation of... everything. If I can get it working again I'll probably try to connect it via ethernet. But even if that is the problem, the degredation is not very graceful.
Another thing that annoyed me, and may or may not still be the case, is that it only plays MP3s. I got the impression that it played oggs from its marketing, but that's just bullshit. The server software happens to be able to transcode to MP3. Having the server transcode to MP3 is stupid (and uses up a lot of CPU to boot), and I ended up simply transcoding all my oggs to mp3 and keeping them on disk instead of having it do this on the fly.
Some people would say that Ruby's one feature -- anonymous closures -- is superior because it is responsible for all sorts of functionality that is implemented via several constructs in Python. That I would disagree with -- the features (things like looping) are such fundamental patterns in a language that their use will always be idiomatic, no matter how elegantly they fit into some underlying syntax or functionality.
No one familiar with Python development should have ever been wowed by anything Rails does from a technical point of view. All the surprise about these features is coming from Java and PHP people, who have lived in darkness and to whom all light is blinding and full of amazement. I don't have a problem with that -- you'll get no arguments from me that Rails is better than what PHP or Java offers. But it doesn't mean Rails is novel.
IronPython isn't abandoned, it's just in some weird Microsoft limbo. It's by the original author of Jython, who got hired by Microsoft and has apparently been caught in some bureaucratic limbo where he spends most of his time in meetings (though another programmer internal to MS has also been allocated, from what I understand).
SELECT * FROM address, transaction, lineitem where lineitem.cost > 200 and address.city = 'New New York' and lineitem.transaction_id = transaction.transaction_id and transaction.address_id = address.address_id
In SQLObject you would typically write this as:
Transaction.select((Address.q.id == Transaction.q.id) & (LineItem.q.transactionID == Transaction.q.id) & (Address.q.city == 'New New York') & (LineItem.q.cost > 200))
The code and the result are pretty much the same.
Well, no points for the docs on this one (hey, it's open source) but there is some help for outer joins noted here.
From what I understand Google uses C++, Python, and Java. Java is used mostly for internal accounting projects. C++ is used for all the stuff that has to be Really Fast, and I suspect lots of code gets migrated from Python to C++ during the development cycle. They use SWIG to interface between Python and C++. I haven't heard about them using many other languages, except XSLT and other special-purpose languages.
Python (and other sane languages) use something like query("select * from foo where name = %s", (name,)) (SQLObject gives this a different syntax, but same idea). With this, if you forget the substitution or do it incorrectly it will be Completely Broken -- because you'll be sending a query like select * from foo where name = Tom. This is a good poka yoke.
As far as putting SQL in the code, sometimes a query is best expressed at the time you will use it. If you want all customers in an area code, is it really best to make a customersInAreaCode(areaCode) method, or just use Customer.selectBy(areaCode=X)? They look pretty much equivalent to me -- except the latter comes for free, and is completely localized to the place you use it. That localization is a negative if it means you are duplicating code; however, creating an abstraction before any duplicate code would be created is also a negative.
As far as the other issues: SQLObject uses the Active Record model (which Rails' ActiveRecord happens to be named after) and is best suited to Application Databases. There are pluses and minuses to this. You can often use a mixture of both styles, if you find a need. But if you are an organization of web developers without dedicated database personel and with a tight schedule, you will be best served by the Application Database style of development, because (from a developer's point of view) it gives you the most control.
(a) I think you mean 4k of code, not 4000 lines (which would be quite large for a wiki), and (b) if you want small, in Wiki terms, 23 (wrapped) lines is closer to what you should shoot for (at least in Python).
If you are doing network programming -- stuff like VOIP, chat servers, etc -- then you should definitely look at Twisted. You can use it for web development too, but it's a bit challenging.
Rails has taught us some important lessons, but they aren't really technical lessons:
After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.
As for Ruby: I think the two languages are largely equivalent in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.
For something more legally and ethically unambiguous there is also MP3tunes and eMusic, though they both have limited selections of generally independent music. Strangely enough mp3.com doesn't seem to have mp3s on it anymore. There's also some labels like Magnatune that distribute mp3s.
It is correct that it's implausible that allofmp3.com contributes any significant amount of money back to artists. I'd be interested if anyone outside of Russia has ever received a check from that licensing organization. It may not be ethical, but ethics are not law. It would be lovely if someone would set up a direct-to-artist compensation system, so that people could support artists while (legally or illegally) working around the organizations that claim to represent them. I think that would lead to a much better ethical balance than the current systems that the RIAA and their members have set up.
Anyway, such is the ways of globalization. Companies can shop around to different countries for low wages and little worker protection. Consumers can shop around to different countries for friendly copyright laws.
New York transit isn't great. It's comprehensive, and that's important. It makes it a useful system in a way that very few US transit systems are. But mere utility isn't the same as being good; we set our sites very low. But because we've gotten used to that, people think New York has great transit, because even having a choice not to have a car seems incredible.
No mass transit system is as fast as a car -- total door-to-door travel time -- unless the traffic is attrocious. Well, commuter rail might be an exception, because it's one of the most efficient forms of mass transit, but it's only so efficient because it's not at all comprehensive -- both the times it runs, and its destinations. Even faster, more modern trains are only nominally faster than cars, and the better and faster the system, the smaller the number of its destinations, causing a fractured travel experience of ever slower modes. And the fractured experience isn't just slow, it is distracting and alienating. You can bring 10 kids on one train or a bus, but you can't transfer (unless you don't mind losing a kid or two). You can carry your groceries home if you can do it on one bus, but that's about it. And that's not even taking into account the cost, which can often be quite extravagant -- it costs $10 in Chicago for a family of four to take the train or bus round trip.
Traditional mass transit is a nice option, but it only really succedes when cars fail; because they are too expensive, or traffic is too horrible, parking is not available, or you just are unable to drive. Any system that feeds off the disfunction of another -- that cannot stand on its own feet and compete favorably to a functioning competitor -- is a sad system. And that's what we have with traditional mass transit.
With that in mind, I'm not sure that Monorail is a good system. But I know LRT isn't, and Subways aren't, and buses aren't. I don't know that Monorail is significantly different from those, but at least it's an attempt instead of choosing a system proven to be a failure. (OK, they are choosing one of those too...)
Personally I have hope for PRT, which is less proven still, but at least attempts to solve the real problems that public transit faces, with a model that is closer to something that works (cars) while still having many of the benefits we look for in public transit.
Now, if Seattle were to follow the lead of these guys, they might be able to leapfrog cities like New York, without asking for an unrealistic change of geography or demographics.
Of course it's still in development, and has had a hard time finding support. But then, the post asked how tech can help...
Leonard Richardson, who wrote the article in question, also recently wrote articles on SQLObject and Cheetah.
It's a very new project, so I don't think it's been used in any Python framework yet. But it would probably be applicable to quite a few of them (perhaps including CherryPy).