I've found that, at Google, the scale means that virtually any area has really meaty, interesting problems to solve. Coding business logic in some Java app takes on a whole new character when your business logic will be called on to process hundreds of queries per second, and every obscure corner case is guaranteed to get exercised, and you also have to assume that the system executing your code may fail at any point in time (due to scale and the number of systems, not the quality of the hardware) and that the work still must be guaranteed to get done, without hiccup... and fast.
Plus, if you find that you're really unhappy with the team and project you get assigned to, you can always move. There's a tremendous amount of internal mobility in Google. Even within your team there tends to be a lot of freedom for individual engineers to define their own job and role. Especially if you're good, it's quite easy to take on a 20% project doing something really interesting to you and eventually grow that into your 80% job.
Trust me, I know people at Google and I've interviewed with them, and it DOESN'T work like that.
Hehe. I know a lot of people at Google, and I've interviewed with them... in fact I work at Google, and I do interviews at Google.:-)
It's possible that you're right, but I don't think the text-only information flow is really as much of a problem as you paint it. The interviewers definitely write up the non-CS aspects of the interviews. If there's a problem I don't think it lies with the process but with the ability of the interviewers to recognize the sort of person who is able to make the world change. That's a pretty difficult trait to find, and to recognize, and I suspect that like many such traits it is recognizable primarily by people who have it.
None of that affects my original argument here, though, which is that Yegge is right that Amazon's approach to hiring isn't good, and Google's is better. Google's probably isn't better for startups, but Google isn't a startup, and neither is Amazon.
See, when teams do their own hiring they get bogged down in evaluating whether or not the candidate already knows how to do some specific areas of their job.
I worked for years at a company that had the teams do their own hiring. And while interviewing candidates was one of the hardest things I did, I never felt that we were bogged down evaluating whether the candidate knew how to perform some specific area. We looked for smart people who knew how to write code. If someone is smart enough, they can pick up what they need to know.
That's great... but not consistent with what I've seen in many places over my 20-year career. Your company was exceptional -- or at least your team was. I still think Google's approach is better for maintaining high standards across the company (other than letting me sneak in somehow; nobody's perfect).
I bet you he gets reprimanded as opposed to rewarded for his "not rant"... though, with Google, you never know.
I doubt it. There was a lot of really great insight in that post, and a lot of passion for making Google better. I think the impact to his career will be non-negative, and more likely to be positive than zero.
(Disclaimer: I work for Google, but don't know this guy, or his manager. My comment is based on my general perception of Google culture, which appears to me to be quite supportive of risk-taking and insightful dissent.)
I've never heard of a company that didn't leave the decision of who to hire up to the teams. Is this person saying that Google hiring is done by HR?
No, engineer hiring decisions at Google are made by engineers... just not necessarily the engineers on the team that's hiring. It's definitely different, but I've come to the decision that it's really a fundamentally good idea.
See, when teams do their own hiring they get bogged down in evaluating whether or not the candidate already knows how to do some specific areas of their job. But that's pointless, because whatever their job is right now, it'll be different in a year or two. What matters in the long run isn't how much an engineer already knows about tool X or methodology Y, but how good he or she is at solving problems with whatever tools are at hand -- which includes being able to learn whatever tools are appropriate.
So not having any specific position in mind when interviewing a candidate helps the interviewer focus on the more important talents and skills, the ones that will matter two years from now. And the same actually applies when looking at personality as well. You don't want to hire someone that meshes extremely well with this particular team, because the team will change. Instead, you want someone who works well with people, in general.
Finally, the other problem with having teams do their own hiring is that the quality of the hiring decisions will tend to depend on the quality of the team. So a weak team will tend to hire weak candidates. Google's approach of having each candidate interviewed by multiple engineers from different teams, whose comments and opinions are then evaluated by a hiring committee made up of still other engineers from other teams, helps to ensure that the bar remains high.
It really doesn't matter whether this was a targeted, sophisticated attack or not. The fact is that if RSA had done a decent job of securing its keys it wouldn't matter who was attacking them.
Any company with secret keys remotely as valuable as RSAs should have generated them and managed them ONLY in high-security HSMs (host security modules) configured to refuse to ever divulge the keys under any circumstances, except to securely transport them to another HSM. That plus reasonable logical access controls on the HSMs, with separation of authority for all important operations, and strong physical security around the HSMs makes it virtually impossible for any attacker, no matter how skilled, sophisticated or well-funded, to get at the data.
This really isn't rocket science. Lots of banks and lots of other security-conscious companies do this sort of thing all the time. Given who RSA's clientele was, if they'd gone to the NSA and asked for help they'd have gotten all the free consultation they needed from some of the best there are, if they'd needed it. Which they shouldn't have.
Whether it was a sophisticated team from a world superpower or a couple of random script kiddies is really just a question of how much gross negligence.
Does the browser automatically block insecure content from secure (HTTPs) pages?
(Even though Chrome does in fact warn you of this. Props to MS, though, they HAVE warned about this since IE6-- though Im pretty sure IE9 does NOT block it automatically).
Even if Chrome warns the user, I guess what they're saying is after the page has loaded, it's too late. Any passive eavesdropper can see which included resources you've downloaded over an unencrypted connection.
Chrome doesn't download the unencrypted resources unless you tell it to. The warning pops up and asks you if you want to download the insecure pieces or not.
There is a real easy answer to this question. The reason this is happening is because people keep asking the government to "solve" ever more problems. In addition, instead of trying to solve those problems that are properly the business of government at the local level, people try to get them addressed at the state or federal level.
Of course they do. People will use the most effective tool available, the one that gives them the best leverage to accomplish their goals. Unless it's a purely local problem they're trying to solve, they'll naturally reach for the biggest hammer. This is why giving government such broad, sweeping power is a bad idea. It *will* be used.
Time will tell, but I think we can expect Google to actively support all of the platforms Chrome runs on, and to release full source code under a fairly permissive license.
Right, just like they did with Android Honeycomb (or Sugar Smacks or whatever the fuck 3.0 is).
There's been extensive discussion of why Google didn't release Honeycomb source. I'm not saying it was right, just that Google claimed it was an exceptional case, and explained why. I believe it was an exception and that ICS will be released. Time will tell, of course.
The law in the US varies from state to state. Where I live, the trespassing statute includes a clause that states that it is a defense against charges of trespassing that the business was open to the public at the time and you were not interfering with the owner's use of the property. This puts the burden on the owner to prove that you were actually causing a problem, and significantly decreases the power of business owners (except those who limit their clientele) to enforce what happens on their premises.
I think the problem is that the card has to do computation and without a battery in the card, doing enough computation for secure crypto is not really possible.
No, strong cryptography is not only possible but easy with or without a battery. AES is very efficient, and very strong.
The reason a battery is important is because it allows the chip to continuously monitor what's being done to it and to recognize patterns of usage that look like attacks and shut down (or even just slow down). When all power is provided by the attacker, the attacker has vastly increased ability to manipulate the operations of the chip, but cutting power at strategic moments, inducing faults by providing inadequate power, monitoring power consumption to see what can be learned from it, etc.
However, I don't think this news is all that interesting. The industry has known for a long time that Mifare Classic and its derivatives were weak, and DESfire was just a bandaid over an already-shaky system. The band-aid was applied not so that NXP could guarantee a round of planned obsolescence, but because customers demanded something that wouldn't require them to change their systems too much.
Microsoft did standardize C#, but actual development of the language and tools moves so fast that non-MS implementations always lag. And MS only supports Windows (by design).
Time will tell, but I think we can expect Google to actively support all of the platforms Chrome runs on, and to release full source code under a fairly permissive license. An open standard plus an open source, multi-platform reference implementation will be truly open in a way that C# isn't and Microsoft doesn't want it to be.
That's why I was talking about my personal e-mail account.
Business e-mail is different. Many companies have policies in place that automatically delete old e-mails after a reasonable period of time, as a matter of legal hygiene. However, that just means there's even less reason to bother with organizing business e-mail, because the deletion means that there's even less problem with clutter confusing search.
On my personal email account, archived messages are offline; this makes search (or re-indexing) faster but leaves me without those messages when away from my laptop. But more than anything I archive because a single inbox with X years and tens of thousands of messages is pretty cluttered, and I know that eventually I'll want to sort through them to eliminate messages that will never be useful.
Not me. In my personal e-mail account I have every non-spam e-mail message I've received since 1996, and I see no reason why I should ever take the time to sort through them and eliminate useless cruft. Why should I? Decent search means I can always find what I'm looking for, and keeping everything means there's no chance that I deleted it just because at one point in time I thought it would be useless. Heck, I've even at times gone through old e-mails which are in and of themselves useless, but collectively give clues about when some sequence of important life events happened in the past.
Given the way storage capacities keep growing, I see no reason to ever delete any e-mail (spam aside).
I recently switched from an iPhone 4 to a Nexus S 4G, and my experience is exactly the opposite. The reason I switched was because I recently started working for Google and I'm doing some work on Google Wallet, so I decided I'd better get more familiar with the platform. But I expected to find that Android was less polished than iOS, and I expected to miss my iPhone (which I gave to my wife).
In fact, I think that Honeycomb (don't know about previous versions of Android) is much more polished and better thought-out than iOS from an interface and usability perspective. There are a handful of things that aren't as good; I really like the scrolling date bars in iOS and the drop-down list selection in Android is clunky, but there are far, far more ways in which my Nexus S is better.
To start with, I greatly prefer the app organization scheme in Android. I spent way too much time trying to find some way to organize apps on my iPhone so that I could quickly find the stuff I use frequently but without burying the infrequently-used stuff on one of several rarely-used app pages or in some rarely-used app folder. On the iPhone I frequently had to resort to typing the app name in the search bar for my lesser-used apps. Android's approach is much better.
I also really like the "Car Home" mode, which simplifies the UI down to six large buttons focused on stuff you're likely to want to do while driving. And what makes it especially useful is the excellent voice search capability. I use my phone constantly while driving now, but never look at the screen or type anything. I even carry on conversations via SMS while driving, but never looking at the screen or punching buttons. As long as I speak a little more slowly than normal, and enunciate clearly, it's very nearly perfect.
Another little bit of polish that really impresses me is the way Android handles competing audio tasks. I like to listen to audiobooks while driving, and so I'm often listening to a book while also using the navigation software. I tried several different navigation apps on iOS, but all of them talked right over my book, resulting in me not being able to understand either the story or the directions. On Android, the book (or music, or whatever), is automatically paused when the navigation app talks, and when the book resumes it backs up about one second, ensuring that I don't miss anything.
I much prefer Android's approach to notifications, too, and I think the mail app is much nicer. There are a lot more things I prefer about Android, but this is getting long enough.
Anyway, the bottom line is that I had an iPhone 4 for eight months, and an iPod touch for 2-3 years before that. I've only had my Nexus S for a few weeks, and I don't regret the switch in the slightest. In fact, I like the Nexus much better. To me, it feels not just more flexible, but more polished and better thought-out. And more flexible.
I'm sure that coming from a Google engineer this will be taken with a large grain of salt. But that doesn't change the fact that it's my honest opinion; and if I didn't like the Nexus better, I would say so.
Google is just catching up to Microsoft. Windows has had this capability for many years, of other people remotely accessing it. In fact, Microsoft has even had to apply major resources to reducing access to this feature, due to overwhelming demand.
Does Microsoft's solution work even over the Internet, when both machines are behind firewalls? How about when the machines are running different operating systems (i.e. not Windows)?
I hope some people encrypt stuff and store in blobs (albeit, I'm sure, somewhere in the agreement this must be forbidden for funny reasons)
It's not forbidden at all. It's not very useful, though, because you have to decrypt the data sometime. If you do it in your code running on GAE then you might as well not have bothered. You can do it on the end-user's browser, in Javascript, but that doesn't make sense for many apps.
Really? Are you sure about that? Because we have ever higher rates of students failing basic math and science tests upon entrance into universities that have been the same for over 100 years. You apparently have been hiding under a rock whilst your education system has been crumbling.
That's because we have a higher percentage of young people going to college. It actually indicates an increase in the median education level, not a decline.
Breaking the user experience in order to ‘fix’ something is a totally broken concept; you cannot do it. If you break the user experience, you may feel that you have ‘fixed’ something in the code, but if you fixed it by breaking the user, you just violated that second point; you thought the code was more important than the user. Which is not true.”
Hmm. So this doesn't count everytime the Kernel APIs change and a bunch of device drivers get broken? IMHO it's the users that get hurt by the lack of stable kernel APIs since the original developers are the only people that have the skills, source and tools to make the fix - if they are still interested.
That's not a contradiction so much as it's a compromise, a concession to the fact that the world is bigger and more complex than we might wish, and to the fact that there are many users with different -- and even competing -- requirements.
In this case, it's trading off the ability of the code to change as needed to support the needs of all users better against the need of a subset of users for the ABI to remain stable so that specific third-party drivers will continue to work. It's also a way of goading third-party driver makers to open their source and get it put into the mainline kernel source, again to improve the overall usability and flexibility of the kernel.
Stable and unstable ABIs each have their own problems, problems which ultimately effect users. Linus' position is that a stable ABI is the worse of the two choices, though I'm sure he'd be the first to admit that neither is ideal.
At some point, someone will challenge the legality of this practice of blocking legal recourse.
It has been challenged, many times. Congress even weighed in with the Federal Arbitration Act -- passed in 1925, don't think this is a new thing by any means -- and specifically stated that arbitration clauses are legal and enforceable. Courts have found that there are some cases in which they aren't, for example if the arbitrator can be shown to be biased. But even there, the Supreme Court found in 1967 that you basically have to try arbitration first before you can appeal to the court system.
Binding arbitration clauses in contracts are settled law and new challenges aren't likely to change that. In fact, they're not likely to survive summary judgment. I'm less sure about binding arbitration for class action suits; I think it could be argued that class action provides a form of remedy which isn't available through arbitration and therefore cannot be replaced by it.
My thoughts exactly... if they blocked 25 out then people using eudora, Thunderbird, etc would be screwed. I think the original port 25 out poster doesn't have something configured right or something just like the parent suggests
Nah, it happens, and the solution is to use 587 instead of 25. Technically that's the right port to use anyway. 587 is for mail submission, 25 is for communication between SMTP servers. RFC 4409 defines the mail submission protocol, which includes authentication. Because it's an authenticated submission channel it's easy to shut down any accounts being abused by spammers.
All mail servers and mail clients of note support authenticated submission on port 587.
Slashdot Mirror
I've found that, at Google, the scale means that virtually any area has really meaty, interesting problems to solve. Coding business logic in some Java app takes on a whole new character when your business logic will be called on to process hundreds of queries per second, and every obscure corner case is guaranteed to get exercised, and you also have to assume that the system executing your code may fail at any point in time (due to scale and the number of systems, not the quality of the hardware) and that the work still must be guaranteed to get done, without hiccup... and fast.
Plus, if you find that you're really unhappy with the team and project you get assigned to, you can always move. There's a tremendous amount of internal mobility in Google. Even within your team there tends to be a lot of freedom for individual engineers to define their own job and role. Especially if you're good, it's quite easy to take on a 20% project doing something really interesting to you and eventually grow that into your 80% job.
Trust me, I know people at Google and I've interviewed with them, and it DOESN'T work like that.
Hehe. I know a lot of people at Google, and I've interviewed with them... in fact I work at Google, and I do interviews at Google. :-)
It's possible that you're right, but I don't think the text-only information flow is really as much of a problem as you paint it. The interviewers definitely write up the non-CS aspects of the interviews. If there's a problem I don't think it lies with the process but with the ability of the interviewers to recognize the sort of person who is able to make the world change. That's a pretty difficult trait to find, and to recognize, and I suspect that like many such traits it is recognizable primarily by people who have it.
None of that affects my original argument here, though, which is that Yegge is right that Amazon's approach to hiring isn't good, and Google's is better. Google's probably isn't better for startups, but Google isn't a startup, and neither is Amazon.
See, when teams do their own hiring they get bogged down in evaluating whether or not the candidate already knows how to do some specific areas of their job.
I worked for years at a company that had the teams do their own hiring. And while interviewing candidates was one of the hardest things I did, I never felt that we were bogged down evaluating whether the candidate knew how to perform some specific area. We looked for smart people who knew how to write code. If someone is smart enough, they can pick up what they need to know.
That's great... but not consistent with what I've seen in many places over my 20-year career. Your company was exceptional -- or at least your team was. I still think Google's approach is better for maintaining high standards across the company (other than letting me sneak in somehow; nobody's perfect).
I bet you he gets reprimanded as opposed to rewarded for his "not rant"... though, with Google, you never know.
I doubt it. There was a lot of really great insight in that post, and a lot of passion for making Google better. I think the impact to his career will be non-negative, and more likely to be positive than zero.
(Disclaimer: I work for Google, but don't know this guy, or his manager. My comment is based on my general perception of Google culture, which appears to me to be quite supportive of risk-taking and insightful dissent.)
I've never heard of a company that didn't leave the decision of who to hire up to the teams. Is this person saying that Google hiring is done by HR?
No, engineer hiring decisions at Google are made by engineers... just not necessarily the engineers on the team that's hiring. It's definitely different, but I've come to the decision that it's really a fundamentally good idea.
See, when teams do their own hiring they get bogged down in evaluating whether or not the candidate already knows how to do some specific areas of their job. But that's pointless, because whatever their job is right now, it'll be different in a year or two. What matters in the long run isn't how much an engineer already knows about tool X or methodology Y, but how good he or she is at solving problems with whatever tools are at hand -- which includes being able to learn whatever tools are appropriate.
So not having any specific position in mind when interviewing a candidate helps the interviewer focus on the more important talents and skills, the ones that will matter two years from now. And the same actually applies when looking at personality as well. You don't want to hire someone that meshes extremely well with this particular team, because the team will change. Instead, you want someone who works well with people, in general.
Finally, the other problem with having teams do their own hiring is that the quality of the hiring decisions will tend to depend on the quality of the team. So a weak team will tend to hire weak candidates. Google's approach of having each candidate interviewed by multiple engineers from different teams, whose comments and opinions are then evaluated by a hiring committee made up of still other engineers from other teams, helps to ensure that the bar remains high.
It works really well, IMO.
It really doesn't matter whether this was a targeted, sophisticated attack or not. The fact is that if RSA had done a decent job of securing its keys it wouldn't matter who was attacking them.
Any company with secret keys remotely as valuable as RSAs should have generated them and managed them ONLY in high-security HSMs (host security modules) configured to refuse to ever divulge the keys under any circumstances, except to securely transport them to another HSM. That plus reasonable logical access controls on the HSMs, with separation of authority for all important operations, and strong physical security around the HSMs makes it virtually impossible for any attacker, no matter how skilled, sophisticated or well-funded, to get at the data.
This really isn't rocket science. Lots of banks and lots of other security-conscious companies do this sort of thing all the time. Given who RSA's clientele was, if they'd gone to the NSA and asked for help they'd have gotten all the free consultation they needed from some of the best there are, if they'd needed it. Which they shouldn't have.
Whether it was a sophisticated team from a world superpower or a couple of random script kiddies is really just a question of how much gross negligence.
Does the browser automatically block insecure content from secure (HTTPs) pages? (Even though Chrome does in fact warn you of this. Props to MS, though, they HAVE warned about this since IE6-- though Im pretty sure IE9 does NOT block it automatically).
Even if Chrome warns the user, I guess what they're saying is after the page has loaded, it's too late. Any passive eavesdropper can see which included resources you've downloaded over an unencrypted connection.
Chrome doesn't download the unencrypted resources unless you tell it to. The warning pops up and asks you if you want to download the insecure pieces or not.
There is a real easy answer to this question. The reason this is happening is because people keep asking the government to "solve" ever more problems. In addition, instead of trying to solve those problems that are properly the business of government at the local level, people try to get them addressed at the state or federal level.
Of course they do. People will use the most effective tool available, the one that gives them the best leverage to accomplish their goals. Unless it's a purely local problem they're trying to solve, they'll naturally reach for the biggest hammer. This is why giving government such broad, sweeping power is a bad idea. It *will* be used.
Time will tell, but I think we can expect Google to actively support all of the platforms Chrome runs on, and to release full source code under a fairly permissive license.
Right, just like they did with Android Honeycomb (or Sugar Smacks or whatever the fuck 3.0 is).
There's been extensive discussion of why Google didn't release Honeycomb source. I'm not saying it was right, just that Google claimed it was an exceptional case, and explained why. I believe it was an exception and that ICS will be released. Time will tell, of course.
The law in the US varies from state to state. Where I live, the trespassing statute includes a clause that states that it is a defense against charges of trespassing that the business was open to the public at the time and you were not interfering with the owner's use of the property. This puts the burden on the owner to prove that you were actually causing a problem, and significantly decreases the power of business owners (except those who limit their clientele) to enforce what happens on their premises.
I think the problem is that the card has to do computation and without a battery in the card, doing enough computation for secure crypto is not really possible.
No, strong cryptography is not only possible but easy with or without a battery. AES is very efficient, and very strong.
The reason a battery is important is because it allows the chip to continuously monitor what's being done to it and to recognize patterns of usage that look like attacks and shut down (or even just slow down). When all power is provided by the attacker, the attacker has vastly increased ability to manipulate the operations of the chip, but cutting power at strategic moments, inducing faults by providing inadequate power, monitoring power consumption to see what can be learned from it, etc.
However, I don't think this news is all that interesting. The industry has known for a long time that Mifare Classic and its derivatives were weak, and DESfire was just a bandaid over an already-shaky system. The band-aid was applied not so that NXP could guarantee a round of planned obsolescence, but because customers demanded something that wouldn't require them to change their systems too much.
Microsoft did standardize C#, but actual development of the language and tools moves so fast that non-MS implementations always lag. And MS only supports Windows (by design).
Time will tell, but I think we can expect Google to actively support all of the platforms Chrome runs on, and to release full source code under a fairly permissive license. An open standard plus an open source, multi-platform reference implementation will be truly open in a way that C# isn't and Microsoft doesn't want it to be.
Heh. I just checked and my personal e-mail account (which is currently hosted on a Google Apps domain) has 41,178 e-mails in it, nearly 2.8 GiB.
Search works just fine.
That's why I was talking about my personal e-mail account.
Business e-mail is different. Many companies have policies in place that automatically delete old e-mails after a reasonable period of time, as a matter of legal hygiene. However, that just means there's even less reason to bother with organizing business e-mail, because the deletion means that there's even less problem with clutter confusing search.
On my personal email account, archived messages are offline; this makes search (or re-indexing) faster but leaves me without those messages when away from my laptop. But more than anything I archive because a single inbox with X years and tens of thousands of messages is pretty cluttered, and I know that eventually I'll want to sort through them to eliminate messages that will never be useful.
Not me. In my personal e-mail account I have every non-spam e-mail message I've received since 1996, and I see no reason why I should ever take the time to sort through them and eliminate useless cruft. Why should I? Decent search means I can always find what I'm looking for, and keeping everything means there's no chance that I deleted it just because at one point in time I thought it would be useless. Heck, I've even at times gone through old e-mails which are in and of themselves useless, but collectively give clues about when some sequence of important life events happened in the past.
Given the way storage capacities keep growing, I see no reason to ever delete any e-mail (spam aside).
I recently switched from an iPhone 4 to a Nexus S 4G, and my experience is exactly the opposite. The reason I switched was because I recently started working for Google and I'm doing some work on Google Wallet, so I decided I'd better get more familiar with the platform. But I expected to find that Android was less polished than iOS, and I expected to miss my iPhone (which I gave to my wife).
In fact, I think that Honeycomb (don't know about previous versions of Android) is much more polished and better thought-out than iOS from an interface and usability perspective. There are a handful of things that aren't as good; I really like the scrolling date bars in iOS and the drop-down list selection in Android is clunky, but there are far, far more ways in which my Nexus S is better.
To start with, I greatly prefer the app organization scheme in Android. I spent way too much time trying to find some way to organize apps on my iPhone so that I could quickly find the stuff I use frequently but without burying the infrequently-used stuff on one of several rarely-used app pages or in some rarely-used app folder. On the iPhone I frequently had to resort to typing the app name in the search bar for my lesser-used apps. Android's approach is much better.
I also really like the "Car Home" mode, which simplifies the UI down to six large buttons focused on stuff you're likely to want to do while driving. And what makes it especially useful is the excellent voice search capability. I use my phone constantly while driving now, but never look at the screen or type anything. I even carry on conversations via SMS while driving, but never looking at the screen or punching buttons. As long as I speak a little more slowly than normal, and enunciate clearly, it's very nearly perfect.
Another little bit of polish that really impresses me is the way Android handles competing audio tasks. I like to listen to audiobooks while driving, and so I'm often listening to a book while also using the navigation software. I tried several different navigation apps on iOS, but all of them talked right over my book, resulting in me not being able to understand either the story or the directions. On Android, the book (or music, or whatever), is automatically paused when the navigation app talks, and when the book resumes it backs up about one second, ensuring that I don't miss anything.
I much prefer Android's approach to notifications, too, and I think the mail app is much nicer. There are a lot more things I prefer about Android, but this is getting long enough.
Anyway, the bottom line is that I had an iPhone 4 for eight months, and an iPod touch for 2-3 years before that. I've only had my Nexus S for a few weeks, and I don't regret the switch in the slightest. In fact, I like the Nexus much better. To me, it feels not just more flexible, but more polished and better thought-out. And more flexible.
I'm sure that coming from a Google engineer this will be taken with a large grain of salt. But that doesn't change the fact that it's my honest opinion; and if I didn't like the Nexus better, I would say so.
Interesting, thanks.
Still no Linux support, though, so it wouldn't be much use to me, while the Chrome extension might be (haven't tried it yet).
Google is just catching up to Microsoft. Windows has had this capability for many years, of other people remotely accessing it. In fact, Microsoft has even had to apply major resources to reducing access to this feature, due to overwhelming demand.
Does Microsoft's solution work even over the Internet, when both machines are behind firewalls? How about when the machines are running different operating systems (i.e. not Windows)?
I hope some people encrypt stuff and store in blobs (albeit, I'm sure, somewhere in the agreement this must be forbidden for funny reasons)
It's not forbidden at all. It's not very useful, though, because you have to decrypt the data sometime. If you do it in your code running on GAE then you might as well not have bothered. You can do it on the end-user's browser, in Javascript, but that doesn't make sense for many apps.
College isn't about education anymore - it's vocational training now.
It's both. General education requirements are part of every university degree, regardless of whether the degree program is job-focused or not.
Really? Are you sure about that? Because we have ever higher rates of students failing basic math and science tests upon entrance into universities that have been the same for over 100 years. You apparently have been hiding under a rock whilst your education system has been crumbling.
That's because we have a higher percentage of young people going to college. It actually indicates an increase in the median education level, not a decline.
Hmm. So this doesn't count everytime the Kernel APIs change and a bunch of device drivers get broken? IMHO it's the users that get hurt by the lack of stable kernel APIs since the original developers are the only people that have the skills, source and tools to make the fix - if they are still interested.
That's not a contradiction so much as it's a compromise, a concession to the fact that the world is bigger and more complex than we might wish, and to the fact that there are many users with different -- and even competing -- requirements.
In this case, it's trading off the ability of the code to change as needed to support the needs of all users better against the need of a subset of users for the ABI to remain stable so that specific third-party drivers will continue to work. It's also a way of goading third-party driver makers to open their source and get it put into the mainline kernel source, again to improve the overall usability and flexibility of the kernel.
Stable and unstable ABIs each have their own problems, problems which ultimately effect users. Linus' position is that a stable ABI is the worse of the two choices, though I'm sure he'd be the first to admit that neither is ideal.
At some point, someone will challenge the legality of this practice of blocking legal recourse.
It has been challenged, many times. Congress even weighed in with the Federal Arbitration Act -- passed in 1925, don't think this is a new thing by any means -- and specifically stated that arbitration clauses are legal and enforceable. Courts have found that there are some cases in which they aren't, for example if the arbitrator can be shown to be biased. But even there, the Supreme Court found in 1967 that you basically have to try arbitration first before you can appeal to the court system.
Binding arbitration clauses in contracts are settled law and new challenges aren't likely to change that. In fact, they're not likely to survive summary judgment. I'm less sure about binding arbitration for class action suits; I think it could be argued that class action provides a form of remedy which isn't available through arbitration and therefore cannot be replaced by it.
I wasn't talking to you :-)
My thoughts exactly... if they blocked 25 out then people using eudora, Thunderbird, etc would be screwed. I think the original port 25 out poster doesn't have something configured right or something just like the parent suggests
Nah, it happens, and the solution is to use 587 instead of 25. Technically that's the right port to use anyway. 587 is for mail submission, 25 is for communication between SMTP servers. RFC 4409 defines the mail submission protocol, which includes authentication. Because it's an authenticated submission channel it's easy to shut down any accounts being abused by spammers.
All mail servers and mail clients of note support authenticated submission on port 587.