I've reported a half-dozen mistakes using the "Report a Bug" link, and they've all been responded to within a few days. Most of these have been of the form "Can't turn left", but one was of the "You think that street takes 10 minutes to drive along. It really takes 30, find better directions".
It certainly used to be true that updates took a while. In 2004 I reported a street missing and it took 2 years to see an update, and I really have no idea if the fix was related to my email or not. The new system has a check-box to notify when the report is received, and what the verdict is when it's processed.
If you've had a bad experience before the change, it's worth trying again.
(obDisclosure: I work for Google, but not on the maps teams)
I stopped drinking caffeine in high school when the perma-shakes set in. I was having somewhere near the equivalent of 30-40 cups over the course of a 19-20 hour day and getting about 4 hours of sleep in order to keep full time school, full time job, and a very active social life all going.
The shakes quit after about 3 days. The headache after about 2 weeks. And somewhere about 2 years later I no longer felt permanently exhausted.
The nice thing now is that I find I can stay awake as long as I need to as long as I don't have high-sugar foods or have any alcohol. I just catch up the next day with little or no problem. I can't imagine going back to caffeine. As a computer-geek, I think it would be hard to do it just in moderation. Everyone else around me has the perpetual can of Coke next to their mouse.
My workplace (in the US) offers flu shots and is quite clear about thimerosal being in the vaccine. They have an extra stash on the side for pregnant women that are explicitely non-thimerosal.
I think the answer largely will come from the large enterprises that use open source - the ones that are big enough to not need a contract from a place like Canonical or RedHat, but instead will just do any work they need on the inside.
I made this argument successfully at two financial firms where I worked: I'm about to reduce the cost of our software deployments by upwards of a million dollars per yet. The tradeoff is that the software is somewhat less polished and might be missing features we want but don't strictly need. The cost of a single engineer to help us meet our needs is a drop in the bucket, let's hire one.
Well, in one case we hired, in one case I simply got assigned the task, but in any event - I think it will be self-interest that moves things forward.
I think to some degree you already see this - my employer, Google, releases millions of lines of code per year. IBM, HP and Sun probably do similar sized code drops. I remember that a good chunk of Debian Developers are paid by their employers to do the work that they do.
Eclipse is another example where corporations are participating because of self-motivation. Members of the Eclipse foundation are required to produce a product based on Eclipse, so they have a reasonable interest in furthering it.
https://launchpad.net/~canonical-kernel-team appears to be the magic list. The team's changed a bunch since I was at Canonical, so Ben Collins is the only name I know on the list.
I suspect in practice, it depends on who you get looking at the screen. In the same way that when you phone for RedHat support you don't get a kernel engineer, you're not going to with Canonical either. =) As always, there's some magic in getting escalated to the right person who has the specific experience you need to solve your problem. I suspect that the way it winds up actually working is that there's a few people in the world at any company who understand, say, the scheduler, the VM system, or ACPI enough to truly solve every problem. For the rest, Canonical probably has proportionally as many people who are capable of digging into the problems to customers actually served.
ISVs haven't attached themselves strongly to Ubuntu yet, but I don't know how much of that is the usual chicken and egg problem. I tend to look at the Ubuntu growth story as being similar to the Microsoft one. After they hit ubiquity on the desktop, it simply became easier to have one environment between desktop and server.
Of course, I was a Novell admin at the time and thought people were nuts. =) I still do in a lot of ways, but I expect that it's possibly how this story will play out.
Ubuntu's story on the Server isn't the great one I'd certainly hoped it would be by now, but I suspect that this growth path is why Mark is continuing to focus on the desktop. It's great space to grow in, and having the Ubuntu logo on the login manager screen is a great way to build mindshare.
And if they follow along the same path as Microsoft the rest of the way, I'm pleased that I still know most of management and can arrange to smack them in person. =)
(obDisclosure: I used to work for Canonical and am a DD)
Without any stats to back this up, I'm guessing that 200 full time Canonical employees could totally trounce the amount of work that the 1000 or so DDs do.
But that's not the point, is it?
Debian in a lot of ways is better off because of Ubuntu. Look at the quality of the bug reports in Launchpad. Debian would be totally and utterly crushed if the maintainers of the various packages had to deal with the noise level that comes into there.
Ubuntu also makes a lot of compromises to keep average end users happy. Debian doesn't need to do that and can push for ultimately the right solution to things. Having Mark and Matt having pretty much final say on what happens in main means that when something needs to happen, it happens. In Debian, the maintainer has pretty much final say over packages and many maintainers have been known to dig in heels.
Ubuntu and Debian are different worlds, and both are richer because of the other's existence.
The difference between Debian and Ubuntu on the server is twofold:
1) Stabilisation time. 2) Bug fix and support time.
The first is important. The stablisation period for Debian can be upwards of 6 months, with packages not getting updated in there. When I used to co-own an ISP, that was always frustrating to me. I couldn't run Debian Stable because I needed to have recent PHP and other web gadgets to keep my customers happy. Testing is the world of Unstable and Stable getting neither recent software, nor security fixes. So the server ran unstable, and I prayed they stayed up. For environments that run a little less on the leading edge (say, bank servers and whatnot), you're looking at environments that often have policies like "We run two major releases behind of Solaris". In those cases, Debian stable would cut it, but:
2) Bug Fix and Support time isn't there. I would expect that a financial institution would consider now deploying Dapper now that Hardy is released. It's had time to age and mature, and the set of bugs in it are pretty well mapped out. There's also 3 (Well, 2.5 now) years of support left on it at that point, so plenty of time to move to Hardy when the 10.4LTS release comes out.
Don't get me wrong, I'm a DD and I love Debian. It's critical that we have a viable alternative out there that isn't controlled by corporate interests. But in not being controlled by them, it's not going to serve them, either.
(obDisclosure: I'm the former manager of Canonical's support and service department)
I'm curious in which way you consider Canonical's support to be inferior? At the time when I left Canonical, one Linux mag (I don't remember which one off hand, sorry.) rated us as tied with RH for providing support.
You have actually *tried* buying support from Canonical, right? =)
We were cheerfully providing 7x24 support, though with essentially no hold time and with an escalation setup internally that you could get relatively quickly to people with 10+ years Linux experience.
We also did professional services gigs for folks as well, and traveled around the world doing those.
The ISV certification story isn't great yet for Ubuntu, but the support story was one we were certainly proud of.
One of the reasons we chose git was to make sure that we can't do that sort of blocking. While obviously the Core Technical Team can control what winds up in the master repositories, part of the reason we chose a distributed revision control system was to make sure that ultimately we can't block new ideas and new features.
If you'd like to chat more, come by #android on FreeNode.
(obDisclosure: I work in the Open Source Programs Office at Google)
I hope the textbook then went on to explain opportunistic key exchange? In case it didn't (and for the benefit of the rest of slashdot), that's where you assume that your connection is not likely to be intercepted on the first connection attempt - for most of us, this is a reasonable default, this isn't "Enemy of the State". The client blindly accepts the key exchange, memorising the server's key. Assuming the first exchange was valid, you now have a reasonable guarantee that future exchanges will be, too.
C'mon, it's not like most of us don't do this with SSH on a regular basis.
Remember that intercepting data is hard, but doable at a number of points. Getting the ability to intercept and alter that data in flight is beyond the ability of most people.
Let's think it through for a sec:
* You have to be sitting at a point where the traffic will reliably be flowing through. In practice with modern ISPs, that's going to be at the firewall on one end of the connection or other. The exception to this is something like the NSA which can just ask for your ISP to route your traffic - but if the gov'ts out to get you, https isn't going to protect you.
* You now have to hack the box in a way that it will redirect the stream of traffic to you. This is probably actually easier than it seems. Yay Linksys.
* Generate a cert that's signed by something the browser trusts. But make it only for a short period of time. Long enough to collect all the data you want, though. Let's say, 12 hours?
* Now you need a device somewhere that will take that stream of traffic, and handle the live encoding/decoding of it to hand it along. Doing this on the Linksys would be simplest, but it would certainly fall over under the load. Or you could send it somewhere else, and your DSL uplink will fall over under the load.
* Pray that whatever windows box you exploited somewhere doesn't get turned off or virus scanned in the meantime, because banks really don't like a set of tech support calls saying that their certificates are invalid.
I'd argue that the necessary hacks make it easier to just sift through your recycling. It's not even the gross job that it used to be of having to dig through newborn's diapers.
I was loving this until I saw the September launch date. WTF? Here, folks, have some bikes for 45 days. Then we'll see you in six months when the snow melts.
Nice to see this for next year, though. Traffic is awful.
Actually, we don't usually open source stuff that for whatever reason isn't actually considered "Good Enough". If there's no one left to work on it, then who will handle the commits, security notices, etc.?
Whether it should've been Open Source before is a different question, where a community might have built up that could take it over. But I don't know this product at all and can't guess at how much special sauce is in there.
(obDisclosure, I work in Google's Open Source Programs Office)
As a paying customer, you have a phone number. If they don't answer an email, phone up and ask for a supervisor and bitch. It's no different than you'd treat any other company.
(obDisclosure: I'm a Google employee, but not in the gmail department)
As long as you don't plan to have any presence in that foreign country, then you're fine. If your airplane happens to make a stopover in that country, and it turns out there's a warrant for your arrest for unpaid court fines, however, you could run into trouble.
Slashdot Mirror
Why is seeking blood so important to you? "At least someone got the axe".
To quote a friend of mine: "I hope you'll treat yourself as harshly when the time comes."
Google stopped using third-party providers in at the least the US and Canada:
http://google-latlong.blogspot.com/2009/10/your-world-your-map.html
http://google-latlong.blogspot.com/2010/04/keeping-canadas-map-current.html
I've reported a half-dozen mistakes using the "Report a Bug" link, and they've all been responded to within a few days. Most of these have been of the form "Can't turn left", but one was of the "You think that street takes 10 minutes to drive along. It really takes 30, find better directions".
It certainly used to be true that updates took a while. In 2004 I reported a street missing and it took 2 years to see an update, and I really have no idea if the fix was related to my email or not. The new system has a check-box to notify when the report is received, and what the verdict is when it's processed.
If you've had a bad experience before the change, it's worth trying again.
(obDisclosure: I work for Google, but not on the maps teams)
I stopped drinking caffeine in high school when the perma-shakes set in. I was having somewhere near the equivalent of 30-40 cups over the course of a 19-20 hour day and getting about 4 hours of sleep in order to keep full time school, full time job, and a very active social life all going.
The shakes quit after about 3 days. The headache after about 2 weeks. And somewhere about 2 years later I no longer felt permanently exhausted.
The nice thing now is that I find I can stay awake as long as I need to as long as I don't have high-sugar foods or have any alcohol. I just catch up the next day with little or no problem. I can't imagine going back to caffeine. As a computer-geek, I think it would be hard to do it just in moderation. Everyone else around me has the perpetual can of Coke next to their mouse.
My workplace (in the US) offers flu shots and is quite clear about thimerosal being in the vaccine. They have an extra stash on the side for pregnant women that are explicitely non-thimerosal.
I think the answer largely will come from the large enterprises that use open source - the ones that are big enough to not need a contract from a place like Canonical or RedHat, but instead will just do any work they need on the inside.
I made this argument successfully at two financial firms where I worked: I'm about to reduce the cost of our software deployments by upwards of a million dollars per yet. The tradeoff is that the software is somewhat less polished and might be missing features we want but don't strictly need. The cost of a single engineer to help us meet our needs is a drop in the bucket, let's hire one.
Well, in one case we hired, in one case I simply got assigned the task, but in any event - I think it will be self-interest that moves things forward.
I think to some degree you already see this - my employer, Google, releases millions of lines of code per year. IBM, HP and Sun probably do similar sized code drops. I remember that a good chunk of Debian Developers are paid by their employers to do the work that they do.
Eclipse is another example where corporations are participating because of self-motivation. Members of the Eclipse foundation are required to produce a product based on Eclipse, so they have a reasonable interest in furthering it.
Tks,
Jeff Bailey
https://launchpad.net/~canonical-kernel-team appears to be the magic list. The team's changed a bunch since I was at Canonical, so Ben Collins is the only name I know on the list.
I suspect in practice, it depends on who you get looking at the screen. In the same way that when you phone for RedHat support you don't get a kernel engineer, you're not going to with Canonical either. =) As always, there's some magic in getting escalated to the right person who has the specific experience you need to solve your problem. I suspect that the way it winds up actually working is that there's a few people in the world at any company who understand, say, the scheduler, the VM system, or ACPI enough to truly solve every problem. For the rest, Canonical probably has proportionally as many people who are capable of digging into the problems to customers actually served.
ISVs haven't attached themselves strongly to Ubuntu yet, but I don't know how much of that is the usual chicken and egg problem. I tend to look at the Ubuntu growth story as being similar to the Microsoft one. After they hit ubiquity on the desktop, it simply became easier to have one environment between desktop and server.
Of course, I was a Novell admin at the time and thought people were nuts. =) I still do in a lot of ways, but I expect that it's possibly how this story will play out.
Ubuntu's story on the Server isn't the great one I'd certainly hoped it would be by now, but I suspect that this growth path is why Mark is continuing to focus on the desktop. It's great space to grow in, and having the Ubuntu logo on the login manager screen is a great way to build mindshare.
And if they follow along the same path as Microsoft the rest of the way, I'm pleased that I still know most of management and can arrange to smack them in person. =)
(obDisclosure: I used to work for Canonical and am a DD)
Without any stats to back this up, I'm guessing that 200 full time Canonical employees could totally trounce the amount of work that the 1000 or so DDs do.
But that's not the point, is it?
Debian in a lot of ways is better off because of Ubuntu. Look at the quality of the bug reports in Launchpad. Debian would be totally and utterly crushed if the maintainers of the various packages had to deal with the noise level that comes into there.
Ubuntu also makes a lot of compromises to keep average end users happy. Debian doesn't need to do that and can push for ultimately the right solution to things. Having Mark and Matt having pretty much final say on what happens in main means that when something needs to happen, it happens. In Debian, the maintainer has pretty much final say over packages and many maintainers have been known to dig in heels.
Ubuntu and Debian are different worlds, and both are richer because of the other's existence.
Tks,
Jeff Bailey
(obDisclosure: I used to work for Canonical)
The difference between Debian and Ubuntu on the server is twofold:
1) Stabilisation time.
2) Bug fix and support time.
The first is important. The stablisation period for Debian can be upwards of 6 months, with packages not getting updated in there. When I used to co-own an ISP, that was always frustrating to me. I couldn't run Debian Stable because I needed to have recent PHP and other web gadgets to keep my customers happy. Testing is the world of Unstable and Stable getting neither recent software, nor security fixes. So the server ran unstable, and I prayed they stayed up. For environments that run a little less on the leading edge (say, bank servers and whatnot), you're looking at environments that often have policies like "We run two major releases behind of Solaris". In those cases, Debian stable would cut it, but:
2) Bug Fix and Support time isn't there. I would expect that a financial institution would consider now deploying Dapper now that Hardy is released. It's had time to age and mature, and the set of bugs in it are pretty well mapped out. There's also 3 (Well, 2.5 now) years of support left on it at that point, so plenty of time to move to Hardy when the 10.4LTS release comes out.
Don't get me wrong, I'm a DD and I love Debian. It's critical that we have a viable alternative out there that isn't controlled by corporate interests. But in not being controlled by them, it's not going to serve them, either.
Tks,
Jeff Bailey
(obDisclosure: I'm the former manager of Canonical's support and service department)
I'm curious in which way you consider Canonical's support to be inferior? At the time when I left Canonical, one Linux mag (I don't remember which one off hand, sorry.) rated us as tied with RH for providing support.
You have actually *tried* buying support from Canonical, right? =)
We were cheerfully providing 7x24 support, though with essentially no hold time and with an escalation setup internally that you could get relatively quickly to people with 10+ years Linux experience.
We also did professional services gigs for folks as well, and traveled around the world doing those.
The ISV certification story isn't great yet for Ubuntu, but the support story was one we were certainly proud of.
Tks,
Jeff Bailey
One of the reasons we chose git was to make sure that we can't do that sort of blocking. While obviously the Core Technical Team can control what winds up in the master repositories, part of the reason we chose a distributed revision control system was to make sure that ultimately we can't block new ideas and new features.
If you'd like to chat more, come by #android on FreeNode.
(obDisclosure: I work in the Open Source Programs Office at Google)
Just remember to load kismet onto the laptop first. The essid is probably hidden, and the person who knows it isn't due back for 6 months...
The default personality for the Hurd is Posix-like, but there's nothing stopping a different personality from being implemented on top.
I hope the textbook then went on to explain opportunistic key exchange? In case it didn't (and for the benefit of the rest of slashdot), that's where you assume that your connection is not likely to be intercepted on the first connection attempt - for most of us, this is a reasonable default, this isn't "Enemy of the State". The client blindly accepts the key exchange, memorising the server's key. Assuming the first exchange was valid, you now have a reasonable guarantee that future exchanges will be, too.
C'mon, it's not like most of us don't do this with SSH on a regular basis.
Remember that intercepting data is hard, but doable at a number of points. Getting the ability to intercept and alter that data in flight is beyond the ability of most people.
Let's think it through for a sec:
* You have to be sitting at a point where the traffic will reliably be flowing through. In practice with modern ISPs, that's going to be at the firewall on one end of the connection or other. The exception to this is something like the NSA which can just ask for your ISP to route your traffic - but if the gov'ts out to get you, https isn't going to protect you.
* You now have to hack the box in a way that it will redirect the stream of traffic to you. This is probably actually easier than it seems. Yay Linksys.
* Generate a cert that's signed by something the browser trusts. But make it only for a short period of time. Long enough to collect all the data you want, though. Let's say, 12 hours?
* Now you need a device somewhere that will take that stream of traffic, and handle the live encoding/decoding of it to hand it along. Doing this on the Linksys would be simplest, but it would certainly fall over under the load. Or you could send it somewhere else, and your DSL uplink will fall over under the load.
* Pray that whatever windows box you exploited somewhere doesn't get turned off or virus scanned in the meantime, because banks really don't like a set of tech support calls saying that their certificates are invalid.
I'd argue that the necessary hacks make it easier to just sift through your recycling. It's not even the gross job that it used to be of having to dig through newborn's diapers.
L. Ron Hubbard?
Oh wait, different Sci Fi writer. It's way too easy to conflate them.
I was loving this until I saw the September launch date. WTF? Here, folks, have some bikes for 45 days. Then we'll see you in six months when the snow melts.
Nice to see this for next year, though. Traffic is awful.
Actually, we don't usually open source stuff that for whatever reason isn't actually considered "Good Enough". If there's no one left to work on it, then who will handle the commits, security notices, etc.?
Whether it should've been Open Source before is a different question, where a community might have built up that could take it over. But I don't know this product at all and can't guess at how much special sauce is in there.
(obDisclosure, I work in Google's Open Source Programs Office)
As a guess, most people don't use automated emails. I solved the problem by doing an email->rss for things that weren't urgent.
Urgent things get dealt with right away, so they don't wind up bunching up in a conversation (I delete them rather than archiving them).
obDisclosure: I'm a Google employee, but not in the gmail group.
As a paying customer, you have a phone number. If they don't answer an email, phone up and ask for a supervisor and bitch. It's no different than you'd treat any other company.
(obDisclosure: I'm a Google employee, but not in the gmail department)
As long as you don't plan to have any presence in that foreign country, then you're fine. If your airplane happens to make a stopover in that country, and it turns out there's a warrant for your arrest for unpaid court fines, however, you could run into trouble.
They can also fine them, and intercept payments from Canadian advertisers in the same way that happens if you decide not to pay taxes.
They'd just cease any Facebook assets that happen to pass through Canada.
Why on earth would you ever give a doctor your social security number?
When anyone other than my employer or my bank asks me if they can have my SSN, the answer is "no".
Québec had it when I lived there last year. I think BC might have it too.
So 80% of the population. =)
Oh, horseshit. Part of what other countries have been doing the past 5 years is making sure that the US economy tanking doesn't mean they go down too.
That's why Canada's economy, to take the USs largest trading partner for example, is actually growing right now, despite tightening in the US.
The US hasn't led the economic pack in a very very long time.
Something I've never understood is why so many people I know try to get out of jury duty. It seems like something that would be fascinating to do.
It also seems like having actually educated computer geeks on these juries might actually result in better verdicts.