In San Francisco, we've got "light" rail vehicles covering (generally heavily trafficked) portions of the city as part of the MUNI system (MUNIcipal Railway -- www.sfmta.com). Here's how a trip on MUNI goes:
1.) Walk the half a block or so to a train stop (in my case... pretty much any area in the city is no more than a couple of blocks away from a train, bus, or cable car stop).
2.) Wait 10 minutes, realize that there are no trains coming in the distance.
3.) Call 511 (www.511.org) to see when the next train is coming. Automated prediction thing says 20 minutes (note: they're supposed to run every 10-12 minutes). Options are: wait in the fog while a steady stream of trains go the other direction or go wait at home for 20 minutes.
4.) Board train. Travel ten blocks until the train suffers a mechanical failure (stepper motor, doors not properly closing and thus blaring an alarm for 5-10 minutes until the driver figures it out, automated switching gear craps out, etc, etc) or the driver simply decides to turn the train around for the hell of it.
5.) Arrive at your destination. If your destination is a subway terminal, be prepared to wait (forcibly) for 5-10 minutes in the car because the automated control system doesn't see fit to let anyone off because of traffic ahead (in spite of the fact that the train is entirely in the station).
Alternate #5.) If you're departing from the subway aiming to get to a surface stop, be prepared to wait 10-15 minutes for the automated control system to decide to allow the train to enter the road (since there's no dedicated right of way in most instances).
This is the best case scenario. Worst case the driver hits and kills someone (happens more often than you'd think). All of this fawning over the French trains makes me wonder how they pulled it off. San Francisco made the grave mistake of paying Alcatel to design the train control system... what a pile of garbage that is.
While the majority of the problems come from either poorly designed control systems (thanks Alcatel!) or horrendous trains (thanks for nothing Breda!), I suspect there's a cultural element at work. In America we don't take pride in our rail systems the way the Japanese or French do. We don't have a constant hard on for efficiency, reliability, or punctuality the way that the Germans do. As such, I suspect that even if we didn't have to contend with the automotive lobby, an American rail system (either long distance travel, local LRVs, or somewhere in between) is just doomed. Doomed, I say.
Edgy hasn't been beta for a while. At least not according to ubuntu.com. This does not look like a beta to me. That said, I don't really care if it's beta or not. It's not that bugs are being ignored, it's that they're being dismissed for being non-issues.
I've yet to deal with an Ubuntu, Kubuntu, or Xubuntu install that didn't require some serious fiddling. I'm disappointed, but not too much, that I couldn't boot a 6.10 release CD on my machine. That I could not apt-get and download a fixed version (considering that the fix is about as trivial as they come) makes me think twice about my choice of distributions.
I've got a Fuji F30 (which does not have a mass storage mode). I had to manually add some lines to/etc/udev/rules.d/45-libgphoto2.rules to get the permissions set properly. Said camera worked just fine with Dapper. Of course the rules file is not empty in Edgy, but it's certainly missing some well known USB IDs.
These are pretty stupid regressions to be making, if only because they're so trivial to fix to boot. I certainly don't hold out a lot of hope for Feisty.
Case in point, the 3dfx xorg driver. Worked fine in Dapper. Broken in Edgy. A two line patch to add the proper prototype for a function fixes the problem in Edgy. Bug report is closed because it's been fixed in Feisty.
Or how about the USB hot plug stuff missing a bunch of digital camera IDs? Pretty well documented, but nope. Not fixed in Edgy. As a result, using a digital camera with Ubuntu requires lots of digging.
Ordinarily I'd agree. However, consider that the student is being held responsible for email sent to that account, forwarding is not allowed, and the only Windows Live mail client (supposedly?) is a Windows program. Given those conditions, I'd be damn sure to consider switching to a more rational educational institution.
At the uni I attend, they've switched to Lotus Notes for email. However, they still maintain (in a very half-assed manner) IMP for people who want webmail, and POP3+SSL for people who use their own mail clients.
You can get 6M/768k ADSL for $60/mo (from an ISP that's gotten the Broadband Reports "gold" award if those kinds of things matter to you). If you need more than the eight included static IP addresses, perhaps you should be looking at business level accounts. That's if you're in an SBC/AT&T area (like the vast majority of the Bay Area). If you're in a Verizon area, try $40/mo for a 3M/768k profile.
Check out Scribus. I'm unsure if there's an official OSX port, but given that it's a Qt application...
Or, check out one of the LaTeX distributions and combine it with a superior editor like TextMate. I certainly wouldn't feel too bad about not having PageMaker.
I'm curious if you bothered to read F-Secure's blog:
So we cracked the algorithm. This enabled us to calculate the download URLs for any future date. In fact, we did this already in May 2005, and we informed the local police in Germany as well as the affected ISPs. But we didn't want to talk about it publically then - we didn't want to fill in the virus writer on this. But he must know this by now.
Mod the parent up. I've had occasion to call 911 on my cell phone a handful of times.
Recently, on my way to San Francisco I saw a car that had driven off the highway, and into a ditch (wheels were still spinning). So I called 911. By the time I was able to get through to a real person, I had crossed the Golden Gate Bridge, and my phone promptly died. Being on hold for that long (5-10 minutes) is just UNACCEPTABLE. This was at about 1:30 in the morning. So once I arrived at my destination, I pluged my phone in and called 911 again. Again it was routed to the CHP dispatch center in Vallejo.
On the other hand, I was walking buy a building on fire, in San Francisco, a few month ago. After asking a woman who worked there, to ensure the building was empty, I called 911 from my cell phone. This time the call got routed to a San Francisco emergency dispatch center. At which point I was able to get a few details to the dispatcher before my call was dropped (Verizon's network is not that great out here).
The lesson I've learned: it's a better idea to find a landline, than to try and call 911 from a cell phone.
Honestly, I'm not sure what all the fuss is about Vonage (or other VoIP providers). 911 service from cell phone providers is pretty lousy.
For example, take KDE Kioslaves, nice for KDE apps but if they had implemented the same functionality in the kernel filesystem layer it could have been used by all Linux programs, not just the ones compiled against KDE libraries.
Right, but KDE is not Linux only. Developing a user level filesystem layer was a good thing(tm). Further, you could write a wrapper library (although I am under the assumption that one exists) to provde any application with nearly transparent access to the kio library.
Are you going to claim that a mechanic who uses the computer in your car to tell him you have a bad sparkplug is a bad mechanic? Or are you going to be quietly grateful that he was able to fix your problem for $50 in 1/2 an hour instead of the old school "hard core" method of slowly replacing part after part until you figure out which was the broken one, which costs you lots of time and money?
No car will tell you that the SPARK PLUG is bad. More likely is that the car would tell you that the spark did not have the intended effect (generally a misfire).
I would chastize the mechanic who saw a misfire code, and could only think to replace the spark plugs. There are any number of components that could be at fault, and the diagnostic codes will generally only tell you the symptoms.
Any mechanic who started replacing parts to clear the codes, instead of doing proper diagnostic work isn't worth his or her salt.
By calling proper diagnostic work the "hard core" method, you've just showed how bogus your analogy is.
Blackboard, for all intents and purposes, gets the job done for the teachers that use it. Yoou should see some of the alternatives.
One teacher (Ms. Cheung, a PhD candiate at Cal), has created a Yahoo! *e-mail* account for the purpose of sending files to it. She then gave every student in the class the login and password, so we can retreive files from it.
Another teacher (Human Sexualities prof., Sociology department) required that students buy a $16 remote (requiring a $12.50/semester subscription) to track our comings and goings, take our asinine multiple choice tests on, etc. Said remote works with einstruction.com to allow us to check our grade and such. It's got perhaps the most craptastic interface I've ever seen. It fucking WISHES it was as good as WebCT or Blackboard (and yes, I've used both).
Now, said teacher (*cough*Carrington*cough*) could have used Blackboard to distribute course materials, like most of the other Uni professors I have do. He could use the craptastic eInstruction interface. No, he wants to be different. He sends out e-mails to the 450+ students in the class.::bangs head on desk::
That wouldn't be so evil (nah.. it would.. who fucking uses e-mail to distribute files to a large audience!?), if it worked reliably. Instead he wasted a good 5 minutes of each class for the first month of instruction dealing with administrivia. He sunk so far as to announce that GMail was blackholing his e-mail. His solution? Encourage students to pay for a Hotmail or Yahoo! account. Hell, even the school's e-mail server is flagging his messages as "possibly spam"....
Man.. the problems were more with American Airlines mechanics, and less with the DC-10 itself. The AA mechanics tried to take a shortcut that caused stress fratctures, resulting in an engine falling off.
Where does BART intermix with traffic? From what I've seen in Oakland, Richmond, and San Francisco, BART uses elevated tracks or underground tracks. None are shared with non-rail traffic.
OTOH, San Francisco's MUNI and their light rail vehicles (LRVs) have tracks on the roadway (as well as dedicated subway tracks). The lack of automation doesn't bother me at all. The complete atrocity that the Breda cars (and their resulting Italian quality control) have become drives me nuts. San Francisco paid big bucks to Alcatel (ha) and after suing them got some manner of automated control for the trains whilst in the subway. It works okay, when it works. But the Breda cars weren't built to spec, so they're too big to run more than two or three cars per train. The emergency brakes on the Breda cars are so bad that their speed has to be limited pretty severely. If these Breda cars were the proper length, they could fit longer trains in the subway, and be significantly more efficient with or without automation. What happens is that MUNI runs a few shorter trains in place of one long one. So, everyone crowds on the first train, and the second train a few minutes later is nearly empty. The automated control (when it actually works) for the subway portion of the tracks does bupkis for speeding up the trains.
Further, I suspect that a large portion of the cost related to MUNI comes from the fact that these trains are overweight (I believe 10s of tons over spec), causing increased wear on the tracks. While the old Boeing trains were pretty damn unreliable, I suspect that the maintenance for the in-road tracks was not so astronomical (altho MUNI is hardly a model of financial restraint or efficiency).
The automated train control system is just as much of a time waster when the train never gets a go signal to allow it to enter the subway, and the driver won't let the passenger's off for a good 5-10 minutes. Is this more dangerous than the train operators who occassionally smack these trains into cars? Sure. Is it significantly more efficient? No, because both Alcatel and Breda suck (see above).
The BART system, OTOH, runs trains of eight to ten (maybe 12) cars in length. Even tho I don't think it's automated, it works quite well. People don't jam themselves onto one or two cars. In San Francisco, at least, BART only has a handful of stops. MUNI has many, many stops. Nearly every other block on the streets is a stop.
I'd be curious to hear from someone in the (Santa Clara) valley to hear hear how the VTA rail system works out for you guys, and how it compares to BART.
it hit the mid 30s in the North Bay, and high 20s-low 30s in the East Bay today. Hot enough to be #@$@# annoying. Of course, today, it was probably raining or something in San Francisco proper.
I'm unsure how you'd define catastrophic. In this case if the throttle module dies, your engine won't run. If you're driving down the highway you'll coast to a stop. This is pretty darn dangerous. A failure rate of nearly 100% within 50,000mi is unacceptable IMO.
An inductive (say hall sensor) pickup may be somewhat more reliable. However I think there are plenty of car owners who have hall pickups in their distributors and have had at least an occasional problem with said pickup.
The problem here is that you're comparing a theoretically more reliable electronic design against a purely mechanical design which almost never fails.
Slashdot Mirror
In San Francisco, we've got "light" rail vehicles covering (generally heavily trafficked) portions of the city as part of the MUNI system (MUNIcipal Railway -- www.sfmta.com). Here's how a trip on MUNI goes:
1.) Walk the half a block or so to a train stop (in my case... pretty much any area in the city is no more than a couple of blocks away from a train, bus, or cable car stop).
2.) Wait 10 minutes, realize that there are no trains coming in the distance.
3.) Call 511 (www.511.org) to see when the next train is coming. Automated prediction thing says 20 minutes (note: they're supposed to run every 10-12 minutes). Options are: wait in the fog while a steady stream of trains go the other direction or go wait at home for 20 minutes.
4.) Board train. Travel ten blocks until the train suffers a mechanical failure (stepper motor, doors not properly closing and thus blaring an alarm for 5-10 minutes until the driver figures it out, automated switching gear craps out, etc, etc) or the driver simply decides to turn the train around for the hell of it.
5.) Arrive at your destination. If your destination is a subway terminal, be prepared to wait (forcibly) for 5-10 minutes in the car because the automated control system doesn't see fit to let anyone off because of traffic ahead (in spite of the fact that the train is entirely in the station).
Alternate #5.) If you're departing from the subway aiming to get to a surface stop, be prepared to wait 10-15 minutes for the automated control system to decide to allow the train to enter the road (since there's no dedicated right of way in most instances).
This is the best case scenario. Worst case the driver hits and kills someone (happens more often than you'd think). All of this fawning over the French trains makes me wonder how they pulled it off. San Francisco made the grave mistake of paying Alcatel to design the train control system... what a pile of garbage that is.
While the majority of the problems come from either poorly designed control systems (thanks Alcatel!) or horrendous trains (thanks for nothing Breda!), I suspect there's a cultural element at work. In America we don't take pride in our rail systems the way the Japanese or French do. We don't have a constant hard on for efficiency, reliability, or punctuality the way that the Germans do. As such, I suspect that even if we didn't have to contend with the automotive lobby, an American rail system (either long distance travel, local LRVs, or somewhere in between) is just doomed. Doomed, I say.
So, okay. If the ISPs shouldn't build out in low profit areas, why are we all paying into a Universal Service Fund?
https://launchpad.net/bugs/89581
Especially when these bugs are regressions.
Also,
6.06 (Dapper Drake) is the long term support (3-5 years support).
6.10 (Edgy Eft) is a final release, but supposed to have, at most, 18 months of support.
Edgy hasn't been beta for a while. At least not according to ubuntu.com. This does not look like a beta to me. That said, I don't really care if it's beta or not. It's not that bugs are being ignored, it's that they're being dismissed for being non-issues.
I've yet to deal with an Ubuntu, Kubuntu, or Xubuntu install that didn't require some serious fiddling. I'm disappointed, but not too much, that I couldn't boot a 6.10 release CD on my machine. That I could not apt-get and download a fixed version (considering that the fix is about as trivial as they come) makes me think twice about my choice of distributions.
I've got a Fuji F30 (which does not have a mass storage mode). I had to manually add some lines to /etc/udev/rules.d/45-libgphoto2.rules to get the permissions set properly. Said camera worked just fine with Dapper. Of course the rules file is not empty in Edgy, but it's certainly missing some well known USB IDs.
/ 6602
See also the bug report: https://launchpad.net/ubuntu/+source/gphoto2/+bug
These are pretty stupid regressions to be making, if only because they're so trivial to fix to boot. I certainly don't hold out a lot of hope for Feisty.
Case in point, the 3dfx xorg driver. Worked fine in Dapper. Broken in Edgy. A two line patch to add the proper prototype for a function fixes the problem in Edgy. Bug report is closed because it's been fixed in Feisty.
Or how about the USB hot plug stuff missing a bunch of digital camera IDs? Pretty well documented, but nope. Not fixed in Edgy. As a result, using a digital camera with Ubuntu requires lots of digging.
Ordinarily I'd agree. However, consider that the student is being held responsible for email sent to that account, forwarding is not allowed, and the only Windows Live mail client (supposedly?) is a Windows program. Given those conditions, I'd be damn sure to consider switching to a more rational educational institution.
At the uni I attend, they've switched to Lotus Notes for email. However, they still maintain (in a very half-assed manner) IMP for people who want webmail, and POP3+SSL for people who use their own mail clients.
You can get 6M/768k ADSL for $60/mo (from an ISP that's gotten the Broadband Reports "gold" award if those kinds of things matter to you). If you need more than the eight included static IP addresses, perhaps you should be looking at business level accounts. That's if you're in an SBC/AT&T area (like the vast majority of the Bay Area). If you're in a Verizon area, try $40/mo for a 3M/768k profile.
So how about comparing Scribus to Quark or InDesign? IMO, Scribus is a pretty powerful Quark clone, and getting better every day.
Check out Scribus. I'm unsure if there's an official OSX port, but given that it's a Qt application...
Or, check out one of the LaTeX distributions and combine it with a superior editor like TextMate. I certainly wouldn't feel too bad about not having PageMaker.
Sure, and in some states you can be summoned via a notice in the newspaper.
http://www.w3.org/TR/REC-CSS2/fonts.html#font-desc riptions
Notice that you *can* embed fonts with CSS. No obnoxious Flash shit to deal with. Okay... it's MSIE only, but it is part of the CSS standard.
--
alex
Read the F-Secure blog.
Or read my previous comment.
F-Secure didn't simply crack the algorithm yesterday.
I'm curious if you bothered to read F-Secure's blog:
So we cracked the algorithm. This enabled us to calculate the download URLs for any future date. In fact, we did this already in May 2005, and we informed the local police in Germany as well as the affected ISPs. But we didn't want to talk about it publically then - we didn't want to fill in the virus writer on this. But he must know this by now.
Something to think about.
Mod the parent up. I've had occasion to call 911 on my cell phone a handful of times.
Recently, on my way to San Francisco I saw a car that had driven off the highway, and into a ditch (wheels were still spinning). So I called 911. By the time I was able to get through to a real person, I had crossed the Golden Gate Bridge, and my phone promptly died. Being on hold for that long (5-10 minutes) is just UNACCEPTABLE. This was at about 1:30 in the morning. So once I arrived at my destination, I pluged my phone in and called 911 again. Again it was routed to the CHP dispatch center in Vallejo.
On the other hand, I was walking buy a building on fire, in San Francisco, a few month ago. After asking a woman who worked there, to ensure the building was empty, I called 911 from my cell phone. This time the call got routed to a San Francisco emergency dispatch center. At which point I was able to get a few details to the dispatcher before my call was dropped (Verizon's network is not that great out here).
The lesson I've learned: it's a better idea to find a landline, than to try and call 911 from a cell phone.
Honestly, I'm not sure what all the fuss is about Vonage (or other VoIP providers). 911 service from cell phone providers is pretty lousy.
For example, take KDE Kioslaves, nice for KDE apps but if they had implemented the same functionality in the kernel filesystem layer it could have been used by all Linux programs, not just the ones compiled against KDE libraries.
Right, but KDE is not Linux only. Developing a user level filesystem layer was a good thing(tm). Further, you could write a wrapper library (although I am under the assumption that one exists) to provde any application with nearly transparent access to the kio library.
--
alex
Are you going to claim that a mechanic who uses the computer in your car to tell him you have a bad sparkplug is a bad mechanic? Or are you going to be quietly grateful that he was able to fix your problem for $50 in 1/2 an hour instead of the old school "hard core" method of slowly replacing part after part until you figure out which was the broken one, which costs you lots of time and money?
No car will tell you that the SPARK PLUG is bad. More likely is that the car would tell you that the spark did not have the intended effect (generally a misfire).
I would chastize the mechanic who saw a misfire code, and could only think to replace the spark plugs. There are any number of components that could be at fault, and the diagnostic codes will generally only tell you the symptoms.
Any mechanic who started replacing parts to clear the codes, instead of doing proper diagnostic work isn't worth his or her salt.
By calling proper diagnostic work the "hard core" method, you've just showed how bogus your analogy is.
You think Blackboard is bad? Yikes.
::bangs head on desk::
...
Blackboard, for all intents and purposes, gets the job done for the teachers that use it. Yoou should see some of the alternatives.
One teacher (Ms. Cheung, a PhD candiate at Cal), has created a Yahoo! *e-mail* account for the purpose of sending files to it. She then gave every student in the class the login and password, so we can retreive files from it.
Another teacher (Human Sexualities prof., Sociology department) required that students buy a $16 remote (requiring a $12.50/semester subscription) to track our comings and goings, take our asinine multiple choice tests on, etc. Said remote works with einstruction.com to allow us to check our grade and such. It's got perhaps the most craptastic interface I've ever seen. It fucking WISHES it was as good as WebCT or Blackboard (and yes, I've used both).
Now, said teacher (*cough*Carrington*cough*) could have used Blackboard to distribute course materials, like most of the other Uni professors I have do. He could use the craptastic eInstruction interface. No, he wants to be different. He sends out e-mails to the 450+ students in the class.
That wouldn't be so evil (nah.. it would.. who fucking uses e-mail to distribute files to a large audience!?), if it worked reliably. Instead he wasted a good 5 minutes of each class for the first month of instruction dealing with administrivia. He sunk so far as to announce that GMail was blackholing his e-mail. His solution? Encourage students to pay for a Hotmail or Yahoo! account. Hell, even the school's e-mail server is flagging his messages as "possibly spam".
Blackboard, I can live with that.
--
alex
Man.. the problems were more with American Airlines mechanics, and less with the DC-10 itself. The AA mechanics tried to take a shortcut that caused stress fratctures, resulting in an engine falling off.
Where does BART intermix with traffic? From what I've seen in Oakland, Richmond, and San Francisco, BART uses elevated tracks or underground tracks. None are shared with non-rail traffic.
OTOH, San Francisco's MUNI and their light rail vehicles (LRVs) have tracks on the roadway (as well as dedicated subway tracks). The lack of automation doesn't bother me at all. The complete atrocity that the Breda cars (and their resulting Italian quality control) have become drives me nuts. San Francisco paid big bucks to Alcatel (ha) and after suing them got some manner of automated control for the trains whilst in the subway. It works okay, when it works. But the Breda cars weren't built to spec, so they're too big to run more than two or three cars per train. The emergency brakes on the Breda cars are so bad that their speed has to be limited pretty severely. If these Breda cars were the proper length, they could fit longer trains in the subway, and be significantly more efficient with or without automation. What happens is that MUNI runs a few shorter trains in place of one long one. So, everyone crowds on the first train, and the second train a few minutes later is nearly empty. The automated control (when it actually works) for the subway portion of the tracks does bupkis for speeding up the trains.
Further, I suspect that a large portion of the cost related to MUNI comes from the fact that these trains are overweight (I believe 10s of tons over spec), causing increased wear on the tracks. While the old Boeing trains were pretty damn unreliable, I suspect that the maintenance for the in-road tracks was not so astronomical (altho MUNI is hardly a model of financial restraint or efficiency).
The automated train control system is just as much of a time waster when the train never gets a go signal to allow it to enter the subway, and the driver won't let the passenger's off for a good 5-10 minutes. Is this more dangerous than the train operators who occassionally smack these trains into cars? Sure. Is it significantly more efficient? No, because both Alcatel and Breda suck (see above).
The BART system, OTOH, runs trains of eight to ten (maybe 12) cars in length. Even tho I don't think it's automated, it works quite well. People don't jam themselves onto one or two cars. In San Francisco, at least, BART only has a handful of stops. MUNI has many, many stops. Nearly every other block on the streets is a stop.
I'd be curious to hear from someone in the (Santa Clara) valley to hear hear how the VTA rail system works out for you guys, and how it compares to BART.
--
alex
If you're going to suggest/consider WebObjects, I highly recommend you guys look at Ruby on Rails.
-
alex
it hit the mid 30s in the North Bay, and high 20s-low 30s in the East Bay today. Hot enough to be #@$@# annoying. Of course, today, it was probably raining or something in San Francisco proper.
--
alex
I'm unsure how you'd define catastrophic. In this case if the throttle module dies, your engine won't run. If you're driving down the highway you'll coast to a stop. This is pretty darn dangerous. A failure rate of nearly 100% within 50,000mi is unacceptable IMO.
An inductive (say hall sensor) pickup may be somewhat more reliable. However I think there are plenty of car owners who have hall pickups in their distributors and have had at least an occasional problem with said pickup.
The problem here is that you're comparing a theoretically more reliable electronic design against a purely mechanical design which almost never fails.
--
alex