For example? If you find something that's exploitable you can get paid for it, you know.
There's one bug that gives a warning if you compile it.
There are a few warnings, but none that represent actual problems, AFAIK. Point me to the on you're mentioning?
Because it hasn't been fixed, I know crappy Android developers aren't even checking their warnings. More generally, I get annoyed at all the giant refactors for no particularly good reason.
You're surmising there isn't a good reason, but you don't know.
But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.
Sounds like Google has improperly partitioned developers into silos.
Not any more than is unavoidable.
Oh yeah, that brings up another problem I have with Android: in some places, the documentation sucks and the metaphors aren't well-thought out. Which of course, leads to more refactoring when things get uncomfortable.
I can't respond to this without more detail. But... of course. Like all software (and perhaps more than some), Android grows organically and stuff that seemed to be a good idea turns out not to be.
Oh yeah, and the build process starts with a giant 'find' command. What a joke.
Yeah, the build system is terrible. It's especially bad when compared with the system used by the rest of Google, which is the most elegant and powerful system I've seen in 30 years of programming. Android can't use that one because it depends deeply on internal Google infrastructure. The move from make to ninja improved build times, but didn't fundamentally change the ramshackle nature of the build system.
Don't even get me started on repo, I hate that thing.
It seems to me that it's like democracy... the worst possible way to make git work for large projects, except for all of the others. Git is a nice tool in many ways, but it doesn't scale well.
Oh yeah, and adb.......sysdeps_win32.cpp wtf. Who on earth taught them to do cross-platform development like that?
Windows? Well there's your problem; get a real dev platform:P
And the whole ADB design is wrong, how many types of sockets are there? A smart-socket is a dumb idea. If you want to see how to do device communication, look at what Apple did. They have a beautiful design on that section. I will say the lockless algorithm in adb is quite nice. Kudos to whoever did that one. In short, the problems in Android come from poor design, and poor division of labor (not mapping to the underlying problem), not from the raw number of developers. You are right that more lines of code means more chances for mistakes, but that is not the dominating factor.
More components, more interactions, more points of possible miscommunication, those are the dominating factors. And modern mobile platforms are big and complicated.
I think it's better than iOS, for example,
I've spent a lot of time working at the low levels of both Android and iOS and I am certain this is true.
So then......what sort of bugs are getting by these 'conscientious developers'
Various; check the CVEs.
(I'm seriously doubting that tbh, I've seen a lot of crap in Android osp.
For example? If you find something that's exploitable you can get paid for it, you know.
But it's good at least at a management level you are pushing these things)? It is true that Android is big, but that's not an excuse for insecurity, because there are a lot of people working on it, also.
Increasing the number people working on a project doesn't decrease security bugs, it increases them. Some security bugs arise due to simple developer mistakes, reviews can catch those and more staff helps there. But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.
In addition, any given set of development processes produces a certain number of bugs per line of code. Better processes can drive this number down, but no one knows how to make it zero. That fact in turn means that as a project grows, the number of bugs in it also grow. Big projects have lots of bugs, period.
I should also point out that Android is actually pretty good in terms of vulnerabilities per line of code. I think it's better than iOS, for example, though that's not something I can substantiate with data. One item I can point to, though: There are some flagship Android devices which have no known rooting method, and which have remained unrootable for long periods of time. As far as I know, no version of iOS has been resistant to jailbreaking for more than a few days after release, and rarely does it take more than a couple of weeks to get even a persistent jailbreak.
Google's lack of care for security is institutionalized. It is part of their MO.
Yeah, that's why we so often hear about security breaches at Google leaking millions of users' private data.
Oh, wait... that's never happened.
Actually, I was a software and systems security consultant for 15 years before I joined Google. In that time I worked for many fortune 500 companies, financial institutions, even government and military organizations. Based on that experience and on my six years working on security at Google, I'll tell you that Google is better at security than any private company I've ever seen, and better than all but the most security-conscious of government agencies and military organizations. Further, the only way in which Google is less secure than the best is that Google doesn't have armed guards.
Heh. I once made the mistake of carrying a USB drive into a Google data center. The frisk on the way out found it, and I thought for a while I might lose my job, and was trying to figure out if there was anything I might be prosecuted for. In the end, they settled for reprimanding me and keeping the USB drive. They wouldn't even give me a copy of its contents (lest I'd managed to steganographically hide some data).
Security is not something that can be tacked on as an afterthought, it has to be designed in from the beginning. If programmers don't worry about security, if managers don't give time in a sprint to do a security check, then your software will have more and more security holes.
This is all true. In Google's Android team, all designs must go through security and privacy reviews before implementation, and all code must be reviewed first by a peer before it can be submitted to the code repository, and then by a security reviewer after completion, on a feature-by-feature basis. Automated security testing and fuzzing tools are also applied, and there is a dedicated attack team that is focused on trying to (a) find vulnerabilities and (b) systematize architectural and procedural countermeasures. Google's Project Zero team also regularly attacks Android, as well as other important software from other companies.
However, in any large system vulnerabilities are an unavoidable fact of life even after all that conscientious developers can do, and modern mobile systems are very large. The only solutions are (a) defense in depth, which attempts to ensure that when vulnerabilities are found other layers of the defenses make them unexploitable and (b) find and fix them before the bad guys do. Vulnerability rewards programs are the latter, and higher payouts are better, not worse, as they provide incentive for researchers to stay "white hat" and to find as many as possible and report them along with detailed explanations, demonstration exploits, validation tests and fixes. Due to the Android update problem (i.e. many devices don't get updates quickly, if at all) Android focuses more on defense in depth than most systems, but also invests significantly in vulnerability discovery.
Note: I'm a member of Google's Android security platform team. My job is to build platform components that are used by the system and by apps to build secure systems.
Actually it doesn't matter in the slightest. If you can pass the interview, Google will attempt to hire you. If you're a citizen, that'll be easy. If you're not, it'll be harder, but Google will work through whatever visa options are available.
The people writing code for Google are third world south asian foreigners with no foundational training in IT. Their "degrees" are equivalent to a community college certificate of completion, not even equivalent to an associates degree. They are trained to bang on keyboards and generate code. They are not engineers; they are code monkeys.
This is a troll, but I'l respond anyway, just because some might find the response interesting.
The majority of Google engineers have masters degrees, the largest portion of them from top tier universities. Not that Google particularly cares about degrees; it's entirely possible (though rare) to get hired as a Google software engineer without any degree at all, assuming you get an employee referral or have something on your resume that convinces the recruiters that you have a shot. Assuming that's the case, you get a phone screen, and if you pass that a series of fairly tough onsite interviews. To get through those interviews you need to have an excellent command of CompSci and software engineering topics, and you need to be good at problem solving and be able to think and code on your feet. "Code monkeys" will not make it. If anything it's harder than it should be, which unfortunately results in rejection of lots of good people. Since interviewing is an imprecise science (art?), Google chooses to err on the side of making it too hard and rejecting good people.
Anyone who is interested in interviewing with Google should do a couple of things first.
One, brush up on your CS fundamentals. Algorithms, data structures, big-O complexity analysis and testing methodology are all essential. With regard to data structures and algorithms, it's more important that you deeply understand the basic ones, including less-obvious aspects of how they get executed on real machines (e.g. cache line usage) than it is that you know about all the obscure ones. For example, you absolutely should thoroughly understand hash tables, their construction and growth costs, space overhead, etc., while knowing the details of tries, bloom (and bloomier) filters, etc., is certainly good but probably not going to have an impact on whether you get hired. Regarding programming languages, it doesn't matter which one you know, but you must be quite competent in one because you will be asked to write code, and it must be good code -- tight, professional, readable and correct. Minor details of syntax don't matter (no one will care if you drop a semi-colon; compilers catch those errors), and you don't have to remember every obscure corner of the standard library, or even precise function/method names.
Two, practice beforehand to blow off any rust and/or smooth out any rough spots. There's a great book "Cracking the Coding Interview" that has about 150 sample problems of the same level of difficulty and complexity as found in real interviews. Work through them all (or at least enough to feel confident of your ability), solve them, code them (on paper, not in an IDE) and evaluate your solutions. Note that the goal is not to memorize the solutions, because none of the questions you receive in the interviews will be from the book. Those questions are banned, as are many others that are found online or elsewhere that many candidates might have seen them.
Doing those two things will maximize your chances of getting an offer. They won't guarantee it, of course. As I said, the interview process is tough, but being prepared will allow you to present the best version of you and give you the best chance.
I mostly use Google Photos for finding photos, but those aren't fully quality. I keep the full quality images (including RAWs) on my desktop machine in a directory tree organized by date (YYYY/MM/DD). I wrote a script that places them in the correct directories by date. Then I back them up to Google Drive. I got a promotional deal a few years ago that gives me 1 TB of Drive space free (no time limit). They also get synced to my wife's laptop, so we have two copies in the house, one of them easily portable, and two copies in the cloud, one full quality and one "high" quality (Google's term; and they are pretty good).
I also use kphotoalbum (a KDE program I've contributed to off and on for years) as a photo manager, but it requires manually tagging images (though the tagging flow is highly optimized and very efficient) and Google's automatic keyword search is so good that I've fallen behind on tagging, making it kphotoalbum less useful.
The creator of "material design" need to be shot. There's a difference between not being limited by the physical world, and needlessly disconnect us from what we have already learned.
The whole point of material design (the reason for the name "material") is to build UIs that follow well-established physical-world processes. UIs are supposed to behave as though they're constructed of physical objects that move in ways that are familiar to humans.
Anyway, I don't think you're going to get wireless charging in any high-end phone for at least the next few years.
The Nexus 6 made it work. Samsung is still making it work.
I should have qualified my whole post with "Using current-generation Qualcomm SoCs". Nexus 6 used an older, slower SoC that runs cooler. Samsung uses their Exynos SoCs. This is an example of how Qualcomm's dominance is hurting the ecosystem (See https://hardware.slashdot.org/...).
The vast majority of people are just looking at the brand name, interface, memory and user-facing features when shipping at a phone.
You're right that consumers don't know or care who made their SoC. But manufacturers have to choose something, and what they choose has a huge impact on what they can offer consumers. Right now, in the upper end of the mobile phone market there is basically no competition to Qualcomm which means phone makers don't have any realistic options. That's bad, and I completely agree that it hurts the ecosystem. Competition is good, lack of competition is bad.
In the mid and lower tiers there's lots of competition, and things are pretty good in the tablet space, too, mainly because nVidia is a solid competitor there (the Tegra series are great high-performance SoCs, but too power-hungry for phones. Tablets have much bigger batteries and can afford the power cost.) But Qualcomm owns the upper end of the phone market.
I am told that Verizon still loads bloatware on it
I don't believe that's the case. In any case, don't buy it from Verizon, buy it from Google. Then it won't have bloatware on it, and it will not be locked down. If you need to pay over time, Google will finance it at pretty much exactly the same monthly payment that Verizon will.
As for the rest of your list:
1) Smaller phone
The Pixel (not Pixel XL) is pretty close to the same size as your Nexus 5. It's the same width, and just 6mm taller.
2) SD storage
Your Nexus 5 doesn't have it either. I agree it would be nice to have.
Although consumers wish it weren't so, phone design is engineering, and tradeoffs have to be made. You can't have good performance without a big radiative heat sink, which pretty much mandates a metal body, and you can't charge wirelessly through a metal body.
4) SD card: nope
Is this somehow different from SD storage?
5) Larger battery instead of thinner phone
My Pixel XL has great battery life. The smaller Pixel is also quite decent.
6) Lower price
Google's going after the high end of the market. Fast processors, high resolution displays (in part for VR), high-end cameras, etc. That may not be you, but it is a legitimate market segment... in fact it's the most profitable market segment.
7) Nexus with no bloatware or lockdown
Pixel does provide that.
8) Removable battery
Your Nexus 5 doesn't have that either. I liked the removable battery on my phones, but personally I don't really see the need today. That may be because I tend to get a new phone every year, so battery degradation doesn't bother me, and while being able to swap in a full battery seems like a good solution to insufficient battery life, in practice it's a pain in many ways... and I don't feel like my phone's battery life is insufficient. I doubt I'd ever swap batteries if I did have a removable one. YMMV, of course... but apparently you don't feel too strongly about this feature since you continue using a phone that doesn't have it.
... and they will be massive ( people don't want )
People do want phablets. The reason that the whole industry has gone to big phones ever since the first phablets his the market is because they dramatically outsell smaller phones. Look at Google's Pixel and Pixel XL: essentially the same device, other than size. The XL has dramatically outsold its smaller sibling, to an even greater degree than expected, so much so that Google has a hard time keeping the XL in stock.
thin ( people don't care )
There's not quite as much market evidence here, but thinner phones do seem to sell better. A big part of this is that people associate thick with "old", when it comes to devices, which is probably largely a result of manufacturers chasing thinner and thinner designs. But I think part of it is real, too. I know that I prefer lighter, thinner phones. They feel better in my hand and fit better in my pocket.
and fragile ( people hate )
True, but the fragile part is the screen, and there's really not that much that can be done about that. Extremely hard glass is used to minimize scratches, but that hardness means that sharp force shatters it. Making the screen smaller would help, but people like big screens. Phones are getting much less fragile in one way: the industry is moving towards good water resistance. Not so much that you can take your phone SCUBA diving, or even swimming, but enough that if you take it out in the rain, or even drop it into the bathtub, it'll be fine.
Wireless charging is incompatible with metal bodies, and metal bodies are all but necessary for high-end CPU/GPU performance.
The problem is that when they're working hard fast CPUs and GPUs pump out a lot of heat, and when they got hot they throttle down and performance nosedives. Good performance in occasional bursts is good for some usage patterns, but it's bad for games, bad for heavy camera usage, and bad for benchmarks.
So in practice, phone performance is all about heat management, and the most effective way to ensure that the chips stay cool is to provide a large heat sink with a large exterior surface area to spread and radiate that heat. Spreading out the heated surface is important or you get hot spots -- potentially very painful hot spots. The Nexus 5X was terrible that way, since basically the only place it could effectively radiate was through the metal ring around the fingerprint scanner, which becomes unpleasantly hot during heavy usage.
You can't radiate heat through the front of the phone, because it's all glass. The edges can work, and have the advantage that there's often a hand touching them during heavy usage, and the skin on that hand does a good job of carrying away excess heat (skin is liquid cooled, as long as temps don't get too high), but they're small. What works best is an all-metal body, which provides a large heat sink with excellent conduction characteristics and is exposed to air and frequently touched (unless you wrap the body in a big insulating case, of course... but even if you do that it's still a large heat sink).
And you can't charge wirelessly through a metal body.
I like wireless charging, but I honestly don't miss it on my Pixel XL. The reason is a combination of three things: good battery life, fast charging and USB C. Good battery life and fast charging mean that I no longer bother to charge my phone at night. I really only charge it in my car, where there's really no place for a wireless charging pad anyway. Fast charging means that if I'm in the car for 40 minutes or so per day, that's all my phone needs to stay charged. USB C's reversible connector also makes a surprising amount of difference. Mini and micro USB connectors, like type A, almost always require at least two attempts to insert correctly. USB C slides right in first time, every time because it's reversible and also somewhat more forgiving of insertion angle.
Anyway, I don't think you're going to get wireless charging in any high-end phone for at least the next few years.
Chrome now reloads Facebook pages up to 28% faster. The rest of the web won't see the benefit.
That's not what the article says. What it says is:
Facebook, just like other pages, says its pages now reload 28 percent faster, too
As for how this feat is accomplished (would have been nice if that was in the summary), what now happens is that when you hit "reload" the browser only reloads the main page. It obviously has to load any resources requested by the new version of the page that weren't requested by the previous version, but it doesn't reload resources that were already loaded for the previous version.
Wrong. Linux Mint beats Ubuntu''s UI in every way. No fucking 'tiles' cluttering the screen and you can open as many instances as you like. Ubuntu copied all the UI errors of ms.
Irrelevant. For non-geeks there's exactly one distribution, Ubuntu.
OTOH if, like me, you dislike OSX Photos, don't use iCloud or have an iDevice, it's really annoying how Photos insists on popping up whenever you connect a camera or insert an SD card. I consider Photos one of the things I most dislike about using OS X.
They understand math just fine. They also understand ambiguity. What is the difference between 1% and 1.5%? 0.5%, 50%, or 67%? On the other hand, 50bps makes it perfectly clear to everyone who knows what basis points are.
And the percentage values are perfectly clear to everyone who knows what percentages are. What ambiguity are you talking about? I have no problem with basis points (though the name is odd), but percentage is a very well-defined and unambiguous concept.
What's there to choose from? Linux. Great idea, but hardly the system for the non-geek. Sad to say it, folks, but it ain't.
Lots of non-geeks happily using Linux disagree. In fact, for the least computer-savvy a good consumer-oriented Linux (i.e. Ubuntu) is generally a far better choice than Windows because it's harder to mess up. ChromeOS is even better that way.
Odd as it may sound, the main reason is that there's so much to choose from. And it all already starts with the distribution.
Nonsense. For non-geeks there's exactly one distribution, Ubuntu.
And then which GUI?
Again, there's exactly one, and it's Ubuntu's default.
And which editor?
Editor? You've clearly shifted away from discussing non-geeks here.
For many, many users, Ubuntu has everything they need. Actually, it has vastly more than the many need... many (most?) users only need a web browser, which is why Chromebooks are increasingly popular.
And Windows, let's be honest, Windows is itself living off inertia. There has been exactly zero improvement since XP, and depending on whether you consider privacy an important aspect you could easily say that it's been getting worse.
Agreed.
So yes, I can't really argue against him. Mac OS is probably the best, or let's rather say, the least crappy OS currently supported by its maker.
OS X is fine. Windows is fine. Ubuntu is fine. They all work. Depending on what applications you need, one of them may not work so well for you... Linux is most likely to be problematic that way, Windows least.
You know that Evita is a fictional play, right? And also that the Che in that play is not Che Guevara
Che in Evita is no specific real person (certainly not Che Guevara). He is the "everyman", and his name pretty much means exactly that. "Che" is slang in much of South America that means something like "friend", "pal", "buddy", "guy", etc. (as well as some other uses, such as an interjection used to get attention, like the English "Hey" or the Spanish "Oye", which literally means "listen"). "Che" is a word that you might call a friend, or some random person on the street, which is why it's a good everyman name. Think "Joe Sixpack", though that has some other connotations that Che lacks.
Incidentally, according to Wikipedia, Che Guevara got his nickname because he used "che" a lot.
In the musical, Che plays the role of narrator and commentator.
That quote is basically from Andrew Lloyd Webber.
Actually, Tim Rice. Webber wrote the music, Rice wrote the lyrics. That doesn't change the point of the quote, though. Sometimes quotes have value because they carry the authority of the person who said them, sometimes the words just carry a valuable message. In this case, it's an accurate, brief description of what happened to Argentina under Peron. Does that mean it will happen in the US? Doubtful, but there are enough parallels that we really do need to be vigilant.
Of course, the Google-powered Raspberry Pi devices will all phone home. Right?
Not necessarily, it depends on what you use. Many of the AI tools are inherently cloud-based, relying on Google's models for image recognition, etc. Those are too big and too complex to run outside of a data center. But you can also build your own TensorFlow models and use Google's cloud service to train them (a computationally-expensive process, which Google has custom hardware to accelerate), then download the trained model and execute it on the RPi (or a different machine), offline.
For clarity, I am currently downloading a video onto my MicroSD card from my Android app. So yes, "SD Card" is generalized to "external storage". I have no idea what the consumerist.com write-up means by "The feature doesn’t support any and all Android devices that have a microSD slot, either".
Fixed the quote for you.
I guess what this means is that there are some devices that can't use SD. I don't know what the constraints are... maybe it only works on devices with sufficiently-good hardware DRM (there are various levels, and Netflix does adjust its behavior based on what your hardware has), or maybe it only works if the SD card is configured as adopted storage (which is encrypted for security, making it also unusable for sharing Netflix videos). Or maybe The Verge is just wrong and it does work on all devices. Or something else.
Slashdot Mirror
For example? If you find something that's exploitable you can get paid for it, you know.
There's one bug that gives a warning if you compile it.
There are a few warnings, but none that represent actual problems, AFAIK. Point me to the on you're mentioning?
Because it hasn't been fixed, I know crappy Android developers aren't even checking their warnings. More generally, I get annoyed at all the giant refactors for no particularly good reason.
You're surmising there isn't a good reason, but you don't know.
But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.
Sounds like Google has improperly partitioned developers into silos.
Not any more than is unavoidable.
Oh yeah, that brings up another problem I have with Android: in some places, the documentation sucks and the metaphors aren't well-thought out. Which of course, leads to more refactoring when things get uncomfortable.
I can't respond to this without more detail. But... of course. Like all software (and perhaps more than some), Android grows organically and stuff that seemed to be a good idea turns out not to be.
Oh yeah, and the build process starts with a giant 'find' command. What a joke.
Yeah, the build system is terrible. It's especially bad when compared with the system used by the rest of Google, which is the most elegant and powerful system I've seen in 30 years of programming. Android can't use that one because it depends deeply on internal Google infrastructure. The move from make to ninja improved build times, but didn't fundamentally change the ramshackle nature of the build system.
Don't even get me started on repo, I hate that thing.
It seems to me that it's like democracy... the worst possible way to make git work for large projects, except for all of the others. Git is a nice tool in many ways, but it doesn't scale well.
Oh yeah, and adb.......sysdeps_win32.cpp wtf. Who on earth taught them to do cross-platform development like that?
Windows? Well there's your problem; get a real dev platform :P
And the whole ADB design is wrong, how many types of sockets are there? A smart-socket is a dumb idea. If you want to see how to do device communication, look at what Apple did. They have a beautiful design on that section. I will say the lockless algorithm in adb is quite nice. Kudos to whoever did that one. In short, the problems in Android come from poor design, and poor division of labor (not mapping to the underlying problem), not from the raw number of developers. You are right that more lines of code means more chances for mistakes, but that is not the dominating factor.
More components, more interactions, more points of possible miscommunication, those are the dominating factors. And modern mobile platforms are big and complicated.
I think it's better than iOS, for example,
I've spent a lot of time working at the low levels of both Android and iOS and I am certain this is true.
Heh. Damning with faint praise, eh?
So then......what sort of bugs are getting by these 'conscientious developers'
Various; check the CVEs.
(I'm seriously doubting that tbh, I've seen a lot of crap in Android osp.
For example? If you find something that's exploitable you can get paid for it, you know.
But it's good at least at a management level you are pushing these things)? It is true that Android is big, but that's not an excuse for insecurity, because there are a lot of people working on it, also.
Increasing the number people working on a project doesn't decrease security bugs, it increases them. Some security bugs arise due to simple developer mistakes, reviews can catch those and more staff helps there. But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.
In addition, any given set of development processes produces a certain number of bugs per line of code. Better processes can drive this number down, but no one knows how to make it zero. That fact in turn means that as a project grows, the number of bugs in it also grow. Big projects have lots of bugs, period.
I should also point out that Android is actually pretty good in terms of vulnerabilities per line of code. I think it's better than iOS, for example, though that's not something I can substantiate with data. One item I can point to, though: There are some flagship Android devices which have no known rooting method, and which have remained unrootable for long periods of time. As far as I know, no version of iOS has been resistant to jailbreaking for more than a few days after release, and rarely does it take more than a couple of weeks to get even a persistent jailbreak.
Google's lack of care for security is institutionalized. It is part of their MO.
Yeah, that's why we so often hear about security breaches at Google leaking millions of users' private data.
Oh, wait... that's never happened.
Actually, I was a software and systems security consultant for 15 years before I joined Google. In that time I worked for many fortune 500 companies, financial institutions, even government and military organizations. Based on that experience and on my six years working on security at Google, I'll tell you that Google is better at security than any private company I've ever seen, and better than all but the most security-conscious of government agencies and military organizations. Further, the only way in which Google is less secure than the best is that Google doesn't have armed guards.
Heh. I once made the mistake of carrying a USB drive into a Google data center. The frisk on the way out found it, and I thought for a while I might lose my job, and was trying to figure out if there was anything I might be prosecuted for. In the end, they settled for reprimanding me and keeping the USB drive. They wouldn't even give me a copy of its contents (lest I'd managed to steganographically hide some data).
Security is not something that can be tacked on as an afterthought, it has to be designed in from the beginning. If programmers don't worry about security, if managers don't give time in a sprint to do a security check, then your software will have more and more security holes.
This is all true. In Google's Android team, all designs must go through security and privacy reviews before implementation, and all code must be reviewed first by a peer before it can be submitted to the code repository, and then by a security reviewer after completion, on a feature-by-feature basis. Automated security testing and fuzzing tools are also applied, and there is a dedicated attack team that is focused on trying to (a) find vulnerabilities and (b) systematize architectural and procedural countermeasures. Google's Project Zero team also regularly attacks Android, as well as other important software from other companies.
However, in any large system vulnerabilities are an unavoidable fact of life even after all that conscientious developers can do, and modern mobile systems are very large. The only solutions are (a) defense in depth, which attempts to ensure that when vulnerabilities are found other layers of the defenses make them unexploitable and (b) find and fix them before the bad guys do. Vulnerability rewards programs are the latter, and higher payouts are better, not worse, as they provide incentive for researchers to stay "white hat" and to find as many as possible and report them along with detailed explanations, demonstration exploits, validation tests and fixes. Due to the Android update problem (i.e. many devices don't get updates quickly, if at all) Android focuses more on defense in depth than most systems, but also invests significantly in vulnerability discovery.
Note: I'm a member of Google's Android security platform team. My job is to build platform components that are used by the system and by apps to build secure systems.
It really depends if you are an H1B or not.
Actually it doesn't matter in the slightest. If you can pass the interview, Google will attempt to hire you. If you're a citizen, that'll be easy. If you're not, it'll be harder, but Google will work through whatever visa options are available.
The people writing code for Google are third world south asian foreigners with no foundational training in IT. Their "degrees" are equivalent to a community college certificate of completion, not even equivalent to an associates degree. They are trained to bang on keyboards and generate code. They are not engineers; they are code monkeys.
This is a troll, but I'l respond anyway, just because some might find the response interesting.
The majority of Google engineers have masters degrees, the largest portion of them from top tier universities. Not that Google particularly cares about degrees; it's entirely possible (though rare) to get hired as a Google software engineer without any degree at all, assuming you get an employee referral or have something on your resume that convinces the recruiters that you have a shot. Assuming that's the case, you get a phone screen, and if you pass that a series of fairly tough onsite interviews. To get through those interviews you need to have an excellent command of CompSci and software engineering topics, and you need to be good at problem solving and be able to think and code on your feet. "Code monkeys" will not make it. If anything it's harder than it should be, which unfortunately results in rejection of lots of good people. Since interviewing is an imprecise science (art?), Google chooses to err on the side of making it too hard and rejecting good people.
Anyone who is interested in interviewing with Google should do a couple of things first.
One, brush up on your CS fundamentals. Algorithms, data structures, big-O complexity analysis and testing methodology are all essential. With regard to data structures and algorithms, it's more important that you deeply understand the basic ones, including less-obvious aspects of how they get executed on real machines (e.g. cache line usage) than it is that you know about all the obscure ones. For example, you absolutely should thoroughly understand hash tables, their construction and growth costs, space overhead, etc., while knowing the details of tries, bloom (and bloomier) filters, etc., is certainly good but probably not going to have an impact on whether you get hired. Regarding programming languages, it doesn't matter which one you know, but you must be quite competent in one because you will be asked to write code, and it must be good code -- tight, professional, readable and correct. Minor details of syntax don't matter (no one will care if you drop a semi-colon; compilers catch those errors), and you don't have to remember every obscure corner of the standard library, or even precise function/method names.
Two, practice beforehand to blow off any rust and/or smooth out any rough spots. There's a great book "Cracking the Coding Interview" that has about 150 sample problems of the same level of difficulty and complexity as found in real interviews. Work through them all (or at least enough to feel confident of your ability), solve them, code them (on paper, not in an IDE) and evaluate your solutions. Note that the goal is not to memorize the solutions, because none of the questions you receive in the interviews will be from the book. Those questions are banned, as are many others that are found online or elsewhere that many candidates might have seen them.
Doing those two things will maximize your chances of getting an offer. They won't guarantee it, of course. As I said, the interview process is tough, but being prepared will allow you to present the best version of you and give you the best chance.
That sure sounds like a lot of work, especially the script-writing part to file by date, when the date's already in the file
The script uses the date in the file (from the EXIF data, specifically).
I mostly use Google Photos for finding photos, but those aren't fully quality. I keep the full quality images (including RAWs) on my desktop machine in a directory tree organized by date (YYYY/MM/DD). I wrote a script that places them in the correct directories by date. Then I back them up to Google Drive. I got a promotional deal a few years ago that gives me 1 TB of Drive space free (no time limit). They also get synced to my wife's laptop, so we have two copies in the house, one of them easily portable, and two copies in the cloud, one full quality and one "high" quality (Google's term; and they are pretty good).
I also use kphotoalbum (a KDE program I've contributed to off and on for years) as a photo manager, but it requires manually tagging images (though the tagging flow is highly optimized and very efficient) and Google's automatic keyword search is so good that I've fallen behind on tagging, making it kphotoalbum less useful.
The creator of "material design" need to be shot. There's a difference between not being limited by the physical world, and needlessly disconnect us from what we have already learned.
The whole point of material design (the reason for the name "material") is to build UIs that follow well-established physical-world processes. UIs are supposed to behave as though they're constructed of physical objects that move in ways that are familiar to humans.
Anyway, I don't think you're going to get wireless charging in any high-end phone for at least the next few years.
The Nexus 6 made it work. Samsung is still making it work.
I should have qualified my whole post with "Using current-generation Qualcomm SoCs". Nexus 6 used an older, slower SoC that runs cooler. Samsung uses their Exynos SoCs. This is an example of how Qualcomm's dominance is hurting the ecosystem (See https://hardware.slashdot.org/...).
The vast majority of people are just looking at the brand name, interface, memory and user-facing features when shipping at a phone.
You're right that consumers don't know or care who made their SoC. But manufacturers have to choose something, and what they choose has a huge impact on what they can offer consumers. Right now, in the upper end of the mobile phone market there is basically no competition to Qualcomm which means phone makers don't have any realistic options. That's bad, and I completely agree that it hurts the ecosystem. Competition is good, lack of competition is bad.
In the mid and lower tiers there's lots of competition, and things are pretty good in the tablet space, too, mainly because nVidia is a solid competitor there (the Tegra series are great high-performance SoCs, but too power-hungry for phones. Tablets have much bigger batteries and can afford the power cost.) But Qualcomm owns the upper end of the phone market.
I am told that Verizon still loads bloatware on it
I don't believe that's the case. In any case, don't buy it from Verizon, buy it from Google. Then it won't have bloatware on it, and it will not be locked down. If you need to pay over time, Google will finance it at pretty much exactly the same monthly payment that Verizon will.
As for the rest of your list:
1) Smaller phone
The Pixel (not Pixel XL) is pretty close to the same size as your Nexus 5. It's the same width, and just 6mm taller.
2) SD storage
Your Nexus 5 doesn't have it either. I agree it would be nice to have.
3) Wireless charging
Wireless charging is incompatible with high performance. See https://tech.slashdot.org/comm...
Although consumers wish it weren't so, phone design is engineering, and tradeoffs have to be made. You can't have good performance without a big radiative heat sink, which pretty much mandates a metal body, and you can't charge wirelessly through a metal body.
4) SD card: nope
Is this somehow different from SD storage?
5) Larger battery instead of thinner phone
My Pixel XL has great battery life. The smaller Pixel is also quite decent.
6) Lower price
Google's going after the high end of the market. Fast processors, high resolution displays (in part for VR), high-end cameras, etc. That may not be you, but it is a legitimate market segment... in fact it's the most profitable market segment.
7) Nexus with no bloatware or lockdown
Pixel does provide that.
8) Removable battery
Your Nexus 5 doesn't have that either. I liked the removable battery on my phones, but personally I don't really see the need today. That may be because I tend to get a new phone every year, so battery degradation doesn't bother me, and while being able to swap in a full battery seems like a good solution to insufficient battery life, in practice it's a pain in many ways... and I don't feel like my phone's battery life is insufficient. I doubt I'd ever swap batteries if I did have a removable one. YMMV, of course... but apparently you don't feel too strongly about this feature since you continue using a phone that doesn't have it.
... and they will be massive ( people don't want )
People do want phablets. The reason that the whole industry has gone to big phones ever since the first phablets his the market is because they dramatically outsell smaller phones. Look at Google's Pixel and Pixel XL: essentially the same device, other than size. The XL has dramatically outsold its smaller sibling, to an even greater degree than expected, so much so that Google has a hard time keeping the XL in stock.
thin ( people don't care )
There's not quite as much market evidence here, but thinner phones do seem to sell better. A big part of this is that people associate thick with "old", when it comes to devices, which is probably largely a result of manufacturers chasing thinner and thinner designs. But I think part of it is real, too. I know that I prefer lighter, thinner phones. They feel better in my hand and fit better in my pocket.
and fragile ( people hate )
True, but the fragile part is the screen, and there's really not that much that can be done about that. Extremely hard glass is used to minimize scratches, but that hardness means that sharp force shatters it. Making the screen smaller would help, but people like big screens. Phones are getting much less fragile in one way: the industry is moving towards good water resistance. Not so much that you can take your phone SCUBA diving, or even swimming, but enough that if you take it out in the rain, or even drop it into the bathtub, it'll be fine.
no deal.
Wireless charging is incompatible with metal bodies, and metal bodies are all but necessary for high-end CPU/GPU performance.
The problem is that when they're working hard fast CPUs and GPUs pump out a lot of heat, and when they got hot they throttle down and performance nosedives. Good performance in occasional bursts is good for some usage patterns, but it's bad for games, bad for heavy camera usage, and bad for benchmarks.
So in practice, phone performance is all about heat management, and the most effective way to ensure that the chips stay cool is to provide a large heat sink with a large exterior surface area to spread and radiate that heat. Spreading out the heated surface is important or you get hot spots -- potentially very painful hot spots. The Nexus 5X was terrible that way, since basically the only place it could effectively radiate was through the metal ring around the fingerprint scanner, which becomes unpleasantly hot during heavy usage.
You can't radiate heat through the front of the phone, because it's all glass. The edges can work, and have the advantage that there's often a hand touching them during heavy usage, and the skin on that hand does a good job of carrying away excess heat (skin is liquid cooled, as long as temps don't get too high), but they're small. What works best is an all-metal body, which provides a large heat sink with excellent conduction characteristics and is exposed to air and frequently touched (unless you wrap the body in a big insulating case, of course... but even if you do that it's still a large heat sink).
And you can't charge wirelessly through a metal body.
I like wireless charging, but I honestly don't miss it on my Pixel XL. The reason is a combination of three things: good battery life, fast charging and USB C. Good battery life and fast charging mean that I no longer bother to charge my phone at night. I really only charge it in my car, where there's really no place for a wireless charging pad anyway. Fast charging means that if I'm in the car for 40 minutes or so per day, that's all my phone needs to stay charged. USB C's reversible connector also makes a surprising amount of difference. Mini and micro USB connectors, like type A, almost always require at least two attempts to insert correctly. USB C slides right in first time, every time because it's reversible and also somewhat more forgiving of insertion angle.
Anyway, I don't think you're going to get wireless charging in any high-end phone for at least the next few years.
Ctrl-F5 doesn't refresh the cache on a Mac. That's "Cmd (Apple) + Shift + R”
Or "Cmd (Apple) + R".
Chrome now reloads Facebook pages up to 28% faster. The rest of the web won't see the benefit.
That's not what the article says. What it says is:
Facebook, just like other pages, says its pages now reload 28 percent faster, too
As for how this feat is accomplished (would have been nice if that was in the summary), what now happens is that when you hit "reload" the browser only reloads the main page. It obviously has to load any resources requested by the new version of the page that weren't requested by the previous version, but it doesn't reload resources that were already loaded for the previous version.
Is there? Which one? Ubuntu? Kubuntu? Edubuntu? Whateverbuntu?
Ubuntu. Non-geeks don't even know about the others.
Wrong. Linux Mint beats Ubuntu''s UI in every way. No fucking 'tiles' cluttering the screen and you can open as many instances as you like. Ubuntu copied all the UI errors of ms.
Irrelevant. For non-geeks there's exactly one distribution, Ubuntu.
OTOH if, like me, you dislike OSX Photos, don't use iCloud or have an iDevice, it's really annoying how Photos insists on popping up whenever you connect a camera or insert an SD card. I consider Photos one of the things I most dislike about using OS X.
They understand math just fine. They also understand ambiguity. What is the difference between 1% and 1.5%? 0.5%, 50%, or 67%? On the other hand, 50bps makes it perfectly clear to everyone who knows what basis points are.
And the percentage values are perfectly clear to everyone who knows what percentages are. What ambiguity are you talking about? I have no problem with basis points (though the name is odd), but percentage is a very well-defined and unambiguous concept.
What's there to choose from? Linux. Great idea, but hardly the system for the non-geek. Sad to say it, folks, but it ain't.
Lots of non-geeks happily using Linux disagree. In fact, for the least computer-savvy a good consumer-oriented Linux (i.e. Ubuntu) is generally a far better choice than Windows because it's harder to mess up. ChromeOS is even better that way.
Odd as it may sound, the main reason is that there's so much to choose from. And it all already starts with the distribution.
Nonsense. For non-geeks there's exactly one distribution, Ubuntu.
And then which GUI?
Again, there's exactly one, and it's Ubuntu's default.
And which editor?
Editor? You've clearly shifted away from discussing non-geeks here.
For many, many users, Ubuntu has everything they need. Actually, it has vastly more than the many need... many (most?) users only need a web browser, which is why Chromebooks are increasingly popular.
And Windows, let's be honest, Windows is itself living off inertia. There has been exactly zero improvement since XP, and depending on whether you consider privacy an important aspect you could easily say that it's been getting worse.
Agreed.
So yes, I can't really argue against him. Mac OS is probably the best, or let's rather say, the least crappy OS currently supported by its maker.
OS X is fine. Windows is fine. Ubuntu is fine. They all work. Depending on what applications you need, one of them may not work so well for you... Linux is most likely to be problematic that way, Windows least.
You know that Evita is a fictional play, right? And also that the Che in that play is not Che Guevara
Che in Evita is no specific real person (certainly not Che Guevara). He is the "everyman", and his name pretty much means exactly that. "Che" is slang in much of South America that means something like "friend", "pal", "buddy", "guy", etc. (as well as some other uses, such as an interjection used to get attention, like the English "Hey" or the Spanish "Oye", which literally means "listen"). "Che" is a word that you might call a friend, or some random person on the street, which is why it's a good everyman name. Think "Joe Sixpack", though that has some other connotations that Che lacks.
Incidentally, according to Wikipedia, Che Guevara got his nickname because he used "che" a lot.
In the musical, Che plays the role of narrator and commentator.
That quote is basically from Andrew Lloyd Webber.
Actually, Tim Rice. Webber wrote the music, Rice wrote the lyrics. That doesn't change the point of the quote, though. Sometimes quotes have value because they carry the authority of the person who said them, sometimes the words just carry a valuable message. In this case, it's an accurate, brief description of what happened to Argentina under Peron. Does that mean it will happen in the US? Doubtful, but there are enough parallels that we really do need to be vigilant.
This is google. Their AI offering don't have any installable component, not even on clusters.
One of their offerings is TensorFlow training. When it's done you download the model and run it locally.
Of course, the Google-powered Raspberry Pi devices will all phone home. Right?
Not necessarily, it depends on what you use. Many of the AI tools are inherently cloud-based, relying on Google's models for image recognition, etc. Those are too big and too complex to run outside of a data center. But you can also build your own TensorFlow models and use Google's cloud service to train them (a computationally-expensive process, which Google has custom hardware to accelerate), then download the trained model and execute it on the RPi (or a different machine), offline.
For clarity, I am currently downloading a video onto my MicroSD card from my Android app. So yes, "SD Card" is generalized to "external storage". I have no idea what the consumerist.com write-up means by "The feature doesn’t support any and all Android devices that have a microSD slot, either".
Fixed the quote for you.
I guess what this means is that there are some devices that can't use SD. I don't know what the constraints are... maybe it only works on devices with sufficiently-good hardware DRM (there are various levels, and Netflix does adjust its behavior based on what your hardware has), or maybe it only works if the SD card is configured as adopted storage (which is encrypted for security, making it also unusable for sharing Netflix videos). Or maybe The Verge is just wrong and it does work on all devices. Or something else.