I use a standing desk and alternate between sitting on an exercise ball, sitting on a nice office chair and standing. Being able to change position every hour or two keeps me more awake and leaves me feeling better at the end of the day. Taking a couple of breaks per day for some exercise, whether going for a bike ride, working out on the weights / rowing machine or just going for a walk is really important, too.
I find this is getting more and more important as I get older (I'm 50).
It's a 2012, though I first leased it in 2013. Part of why it was so cheap is that they were trying to get it off the lot so I got a great deal on the lease terms. When the initial lease period ended in 2015 they offered me a one-year extension at the same payments (~$230 per month). When the extension ended, I bought the car for $6K. Nissan's big screwup was massively overestimating the residual value at the end of the lease. Competition from EVs with longer range, plus bad press about short-lived Leaf batteries (the lack of thermal management means that Leafs in hot climates have battery life problems) depressed the used market. Nissan had estimated that after two years my Leaf would be worth $20K, but after three years it was worth $6K. Their error was essentially a $14K windfall for me.
How can they not "do" the work they're showing you? I was talking about a portfolio of work. Their githubbitbucketsourceforge whatever. How can you not talk to them about that very work they created and not know they can't do the work they're literally showing you?
If it's open source and you can see the history of commits on projects of significant size in which they collaborated with many others, then, sure, it's very difficult for them to claim ownership of something others have done. But the vast majority of programmers don't have a substantial body of open source work that they've done, because most of their work has been professional. They'll tend to have a couple of small student projects, or a handful of weekend-and-evening projects, but (a) they're likely to be too trivial to be really informative and (b) they're likely to be single-person or small-team projects that are sufficiently obscure that they could easily have lifted them from someone else.
So if you want to discuss work of real note, usually what you're asking them to tell you about is closed-source work they've done. You can read the summary on their resume and then chat with them about it. But if they're at all good at lying they can easily tell you about work that was done near them, rather than by them. For new graduates and intern candidates, they can also often talk about work their classmates have done. It's tempting to believe that if they can talk the talk they're the real deal, but it's just not so.
On the other hand, if you give them a problem to solve and ask them to design and then implement a solution, there's no way they can fake that. The closest they can come is if they get lucky and you happen to pose a problem that they've seen before... but that's actually pretty obvious, and also pretty easy to avoid -- just invent a sufficiently-novel problem. It's also extraordinarily unlikely that they can get lucky repeatedly in that fashion. This is part of why Google has candidates do a sequence of interviews with different engineers. They might be able to fool one; they're very unlikely to be able to fool four or five.
The downside (one of the downsides) of this approach is that you obviously have to choose a self-contained and relatively trivial problem, since they have to be able to understand it, design a solution, write the code and explain how they'd test it in about 40 minutes. So it doesn't test their ability to navigate large codebases, or balance complicated competing concerns, or any of a dozen other things you'd really like to know. What it does do, though, is give you an opportunity to watch them think their way through a problem and consider design alternatives and tradeoffs on a small scale. As it turns out, people who can do this well, consistently, can also handle bigger problems.
Perhaps the biggest problem with this sort of coding interview is that while it's true that someone who performs well in this environment is extremely likely to perform well on real projects, the converse is not true. Many good engineers perform poorly in this sort of timeboxed, high-pressure test (though Google interviewers do attempt to make it collegial and unpressured), and this system rejects them. I make a habit of telling candidates that the best thing for them to do is to approach the interviews as a series of fun and interesting puzzles to solve, to focus on the puzzles rather than on the context or on trying to impress the interviewer. Many people can't do this, and the fact that Google primarily hires people who can clearly biases the hiring process in a certain way that may or may not be beneficial.
What is clear, though, is that after 30 years as a professional software engineer, Google is the only place I've worked where I never have to wonder if my colleagues are competent. It's hard to overstate the value of this fact. In previous companies, whenever I began working with an engineer from another organization, or a new hire, or whatever, there was always a
High school GPA was < 2.0. College was better, but not great. I know another Google engineer who never finished high school. I know another who finished her associate's degree with a 2.0 GPA.
I used to believe that I could chat with someone about their work and come away with a solid idea of how good they were, but then I made some bad hires that made me realize how wrong I was. Your method does filter out the bad liars, but not the good ones. The good ones know enough to be able to explain the work, point out pros and cons, key design decisions, etc., and explain the rationale... but that is far from the same thing as meaning they could actually do the work they're describing.
Google has solid data on the results of their interview process; they've been tinkering and experimenting with it for years. And the interview process works very well at doing what it's designed to do: Reject weak candidates. It also rejects a lot of strong candidates, which is unfortunate, but it does an outstanding job of avoiding the bad hires, which is the primary goal.
Google has a mole within its decision making hierarchy.
Nah. The problem is that Google mostly doesn't have a decisionmaking hierarchy. I say "problem" but it many ways it's also Google's core advantage, though it clearly has its downsides as well.
Google is a very bottom up company. Throughout most of the organization, decisions are made primarily by the engineers doing the work. They choose a team to work for (new hires are assigned to a team, but most people switch every few years), then look at the problems/opportunities with that team's products and decide what they think needs to be improved/built. They sell their managers / peers on their ideas and, assuming they're successful, set their objectives and key results (OKRs), then go to work.
Performance reviews and promotions are evaluated primarily based on demonstrated impact, which is a vague term that has several dimensions but is mostly driven by measures of user engagement. Doing great work on a product no one uses is "low impact", as is doing minor work on a successful product. Keep in mind that Google measures success primarily by the "toothbrush metric", which is how many people use a product daily, and that a million users isn't "successful". Successful products have 10E8 to 10E9 users. The most impactful, and therefore most promotable, thing you can do is to launch an entirely new product that becomes successful -- though to be clear people are highly rewarded for doing less visible impactful things, such as building internal infrastructure.
This creates a very unusual company dynamic, very different from the typical corporate hierarchy. It's designed to harness the brainpower of the large and very bright staff not only to figure out how to build the technology, but also to decide what to build. Promising projects that have potential for great impact find it very easy to hire lots of talented engineers. Projects that are failing, or even just stagnating, find their staff drifting away as people seek more impactful work.
There are top-down, hierarchical decisions. Upper management does give direction, and perhaps the most powerful lever they wield is headcount allocation. But successful -- or just promising -- projects find it easy to grow their headcount allocation. One of the strongest signals a team can give to the next layer up is that there are lots of engineers who would like to join it. That's not the only decisionmaking criterion, but it's a powerful one. The mere fact that many people want to work on something is considered a good indicator that that thing is important and worth working on, because if it weren't likely to be impactful why would so many impact-seeking engineers want to work on it?
Throughout most of the company, most of the time, this non-hierarchical, bottom-up structure works very well. The most talented people do seek out the most impactful projects, both because it gives them the best shot at promotion and because it maximizes the odds that they're doing something of benefit for humanity (and, yes, there is a lot of that sort of altruistic sentiment at Google, and it's not feigned or faked). In fact, many of Google's biggest failures were caused when management didn't allow this "natural" self-allocation of talent but instead used arbitrary incentives to drive specific employee behaviors.
But there are some clearly pathological cases as well, and messaging seems to be the most obvious. I think that people look at messaging and think "This is a simple problem, and if we can solve it well we have a chance to build something that most of humanity uses on a daily basis". It looks easy, and incredibly impactful (per the toothbrush metric), so projects get spun up and attract lots of engineering staff. But while it's easy to build a chat tool, getting hundreds of millions of people to decide to use it is not so easy, so projects stagnate, staff leaves to do other stuff and eventually the project gets shut down because the handful of die-hards who are left to maintain it get overwhelmed and can't keep up.
So no "mole", no deliberate sabotage. Just a very unusual organization structure with some unusual failure modes.
True, but I'd guess it works pretty well for him, too. I watched a couple videos and a lot of them are about the interactions between the kid and his parents and sisters, and it's pretty clearly enjoyable for all of them. According to the Wikipedia article, the whole thing was Ryan's idea originally, too -- in a babyish way, of course, since he was only four at the time. He just asked his mom why he wasn't on YouTube.
Perhaps more important, it means he has both of his parents home with him so he gets a lot of time with them, unlike most kids his age who spend a lot of time in daycare while mom and dad are at work. He'll also be able to afford to go to whatever school he wants and should have a rich, experience-filled life, assuming his parents keep their heads on straight and manage the money well.
It could all go horribly wrong, of course, but it could also set him up for a great life.
The drivers aren't open, usually ever, so you're fucked because only the manufacturer could update or supply the newer versions.
If you get a device that launched with Oreo or Pie, this shouldn't be a problem. Those devices must support project Treble, which imposes a well-defined hardware abstraction layer between vendor space (those drivers you mention) and the system (everything above). It should then be possible to install any newer system image on the device, leaving the vendor partition unchanged, and it should work. For some number of releases, at least; at some point new systems will stop supporting old HALs.
Note that this assumes your device has an unlockable bootloader. If the bootloader can't be unlocked then you can only install OEM system images, so as soon as your device maker stops providing updates, you're done. Don't buy an Android device whose bootloader you can't unlock.
Chrome also supports QUIC, which requires a long-lived GUID (ie. a unique browser ID).
Cite?
I think you're referring to the Connection ID, but it is not long-lived and it is not global, i.e. not a unique browser ID. Its purpose is to enable connection migration, seamless continuation of an existing connection when the device changes IP addresses (switches LANs, goes from Wifi to cellular or vice versa, etc.). It's actually required to change on every migration, and allowed to change at almost any other point in time, so it's definitely not long-lived, even for a given connection, and is certainly not global.
Chat has more functionality than Hangouts in the same way Slack has more functionality than IRC.
I can't think of a single thing Hangouts does that Chat doesn't, and several things that Chat does that Hangouts doesn't. I don't think you know what you're talking about.
The only thing in your rant that I disagree with is:
Chat, which is a clone of Hangouts but with more bullshit and less functionality
Chat actually has more functionality. It's taken over as the messaging tool of choice inside Google because it's better. Among other things you can actually send files other than images to people through it. Very convenient when you're talking about some file to just be able to include it in the conversation. The chat room functionality is a little better, too, and the web UI is better if you're someone (like me) who frequently has a dozen conversations ongoing.
The big downside of Chat is that it's so enterprise-focused that you can only use it with people in your organization. This is really annoying, because I use Hangouts to chat with many external partners, which means that I have to use both Hangouts and Chat. Worse, Chat is still semi-integrated into Hangouts, so my Chat messages also appear in Hangouts, meaning I get duplicates.
All the rest, though, I agree. Google should make the incremental improvements that Hangouts needs (including pulling in some of the Chat features it lacks) and drop all of the other stuff. I don't think that's what's going to happen, though.
I wouldn't call the chance non-zero. Google may way see this a a thread to them, especially if it goes global. They have a vested interest in this not being a thing. Apple has already fought against this kind of thing in the US courts, so I wouldn't be surprised if they don't take a stand as well.
TL;DR we're trying to make it technically impossible for us to decrypt user data on Pixel devices. Not to prevent law enforcement access, but to ensure that no insider, no matter how privileged, can do it. This has the -- pleasant, in my personal opinion -- side effect of making laws like this ineffective. Until/unless, of course, they attempt to force companies to build in what amount to active back doors. I'm pretty confident Google would fight that (note that that's a personal opinion; I do not decide or communicate legal policy). Also, we're planning to eventually mandate this in all Android devices of a certain class.
[C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will likely become a requirement in a future release.
Of course, this only affects data stored on Android devices. User data that is shared with Google through the use of Google's apps and services, is obviously available to Google in plaintext, else it couldn't be used to provide said services, and couldn't be used for ad targeting which in many cases is the "fee" for those services. Not without major breakthroughs in homomorphic encryption, anyway. That data is subject to normal warrants and subpoenas, of course, no need for this decryption law. However, warrants and subpoenas are also subject to judicial oversight and court challenges, and the legal team can redact and filter the provided data to narrow it to just what the court actually requires.
I have a few cans of bear spray, for when I go hiking in bear country, obviously. Just after I got the first one, I was camping with my extended family. Wishing to know how the spray dispersed (range, cloud shape, etc.), in case I ever needed to use it, I decided it would be a good idea to do a little test. The family (about 15 people) was sitting around the campfire chatting. It was a windless day, so I decided I could go in any direction to do my testing. I picked a direction and walked about 100 yards from camp, squeezed the trigger and noted the size and shape of the resulting orange cloud. The cloud quickly dissipated, so I walked back to camp and to my trailer to put the bear spray away. I also sat down in the trailer and started reading a book.
About five minutes later, I heard shouts of pain and anger from the direction of the campfire. I walked out to find everyone fleeing the area, rubbing their eyes and complaining loudly. It turned out that there was a little bit of air movement after all. Not enough to be felt, but enough to waft the (invisible) cloud of bear spray a hundred yards in a few minutes. And it turned out that I had chosen a direction that was directly upwind of the campfire.
Re "This is one of the unsolved problems of security."
Keep the next big idea as a spoken topic among 10 ~ 100 workers?
A walk in vault with no electronic devices and notes on paper.
Look deep into the political and friendship past of all trusted workers.
You omitted the crucial part of the post you quoted (emphasis mine, obviously):
There are too many avenues of attack, and you can't shut them all without really slowing down things inside the business and causing problems.
Yes it's possible to reduce the threat of insider attacks by reducing the set of insiders with access and carefully vetting that small group, and also by adding other measures like technical and and procedural mechanisms to require multiple people to be involved in any access to sensitive data, but anything you do that way is going to "really slow things down inside the business and cause problems". Sometimes data is so sensitive it's worth the hassle and expense. Most of the time, it's not.
The reasoning behind that is, even if su required the password, someone as root could write a program to allow them to become another user anyway, so it's not going to make a difference.
More than that, it would be actively bad for su to require the password. It would make less-thoughtful sysadmins believe that root can't act as any user. This can still happen, witness techno-vampire's misunderstanding, but it would be much worse if he couldn't do a simple test and discover his error in a few seconds.
You're a member of a tiny, tiny minority. Most people want their phones to do more stuff.
See, these things SEEM helpful and that, and I'd LOVE to believe that there are developers out there that are willing to spend their time on projects that purely make my life easier.
Why says they're doing it purely to make your life easier? They're doing it to make their devices more competitive, to make you want to shell out your money for their phone rather than a competitor's phone.
These AI apps aren't there for you, they're there for the people that wrote the software that employ AI.
How are any of the things mentioned not there to benefit the user?
Who would have thought you would do such a 180!
I didn't do a 180. Do you really believe that your phone doesn't send data back to it's servers? You don't know what other things that AI is doing, and you certainly don't know if that AI is sending data about your personal ways, back to a server in another part of the world.
The AI stuff is going to happen, regardless, because it creates value for the users, value that most people really like. The only question is where it's going to be done. Sure, developers may ignore the AI hardware and continue sending the data back to the server, but AI hardware on the device at least makes it possible for developers who want to make privacy a part of their value proposition to keep the data local.
I can see (though not really agree with) your argument that you don't like this AI stuff. But there's absolutely zero sense in your argument that you would prefer it can only be done in the cloud, rather than locally.
Qualcomm announced its new flagship 855 mobile platform today.
I'm thinking, "Cool!"
The 855 also features a new multi-core AI engine...
I'm thinking, "Not cool"
Why? Lots of stuff in phones today makes use of neural network models... stuff like voice recognition, text translation and image content identification to name some prominent ones. Dedicated hardware can perform these calculations faster and with lower power consumption -- and in some cases that will be the difference between making it feasible to do on-device and having to send the data off to the cloud for processing, which is better for privacy.
Well, it would presumably support Office365 and all its webapps. Perhaps that might not be super useful for a general purpose PC, but for a light duty workstation it could do well.
Given their move to a Chromium-based browser, it could potentially also run all of the Chrome web apps. Throw in an Android container, and you'd have something equivalent to ChromeOS, except that I presume it would run the MS webapps "natively" (right now, to run Office365 on a Chromebook you have to use the Office365 Android app in the Android container, or so I read). If the set of Universal Windows Platform apps grows to be something useful, those would provide another advantage over Chromebooks.
And, honestly, Lite probably doesn't need to actually be better than ChromeOS. If it's only as good then it may provide a way to stop the bleeding, and that's probably enough. Microsoft still has the dominant PC OS. That dominance is at risk because of the success of ChromeOS in education, which may create a generation of users who are accustomed to something else. Or maybe not; after all, Apple tried that strategy in the past and failed. But if Microsoft can get an MS-branded equivalent into the markets currently being served by Chromebooks it may be possible to mitigate the risk they pose.
Though it's not really evidence of anything, I'm quite certain that it would be far, far easier to convince my dad to use a Microsoft browser OS than to use Chrome OS. It wouldn't surprise me if there were a bunch of other people out there who really only need an enhanced browser and would be happy to try one from Microsoft but won't stray outside of the MS fold.
By about the time an electric car actually pays for itself in terms of gasoline saved, it's nearly time to replace the battery. which throws you back about another year again before you start to see savings.
Not my experience at all. I fully expect to get 200K miles, or more, from the battery in my Leaf. And that's not a random guess, that's a projection of the decline curve I have been measuring monthly. And even when the battery capacity is diminished enough that the range is getting constraining, the battery will still hold 15+ kWh. Little enough that it doesn't make sense to drag it around the road any more... but enough that it would make an awesome backup battery for my house.
The Nissan Leaf may be $30K while the average price for a new car is $33K, but that's only because the average new car is not a compact, which is the classification that the Leaf falls in. A brand new compact vehicle can be purchased for $20K or sometimes even less.
True, but total cost of ownership of the Leaf will often be lower. You trade a higher payment for lower fuel and maintenance costs. So it's not a car for the wealthy, it's a car for the prudent whose driving patterns fit certain (extremely common) profiles.
I did this exact analysis quite thoroughly several years ago before I bought my Leaf. In practice I find that I actually underestimated the operational cost difference... and the purchase price difference turned out to go the other direction, thanks to some stupidity by Nissan. The latter part was luck and not repeatable, but my Leaf has worked out to be an incredibly inexpensive car to own and operate. 100K miles into it, my total cost per mile (excluding insurance) has been about 19 cents[*], and that includes the full purchase price. The next 100K miles (and I see no reason it won't make them; the battery has only lost about 10% of its initial capacity, and capacity loss is front-loaded, and there's really very little else to go wrong) should cost under three cents per mile[**].
If I'd paid full price, of course, the numbers for my first 100K miles would be different, about $15K more, so about 34 cents per mile. A Honda Fit, at $20K purchase price, plus $8.5K for gas (35 mpg, $3 per gallon), a little more in maintenance due to oil changes and a new set of brake pads... call it $2K, would be a titch cheaper, at $30,500, or 30.5 cents per mile. But if you look at the next 100K miles, the fuel/energy savings really kicks in.
Plus, electric cars are more fun to drive. Going the other way, there is the range limitation, of course. If you regularly need to drive long distances, a Leaf is not for you. If you need to do it only occasionally, you may still be money ahead buying the Leaf and renting an ICEV for those trips. Depends on the details.
[*] Total purchase price (sum of all lease payments plus buyout): $15K. Charging station for home: $500. Total maintenance costs so far are a couple of sets of new tires, one alignment and a windshield replacement: $1K. I get about 4mi/kWh, at a cost of ~$0.10/kWh, so 100,000/4*.1 = $2500 in electricity. Totalling those up, I've spent $19K. 19 cents per mile.
[**] For the next 100K miles I'd expect to get three new sets of tires and replace some brake pads. The maintenance schedule says that at 150K miles I should get the oil changed (the oil is actually a coolant, not a lubricant, but eventually does need to be changed). The dealership says they'll want $100 for that. Figure maybe another alignment, too. Add all of that up, and call it $1200 in expected maintenance. Round up to $2000 to be conservative. I'm now on a "time of use" electricity plan which charges me $0.034/kWh off-peak, which is the only time I charge. 100000/4*.034 = $850. So the next 100K miles will cost me about $2850, which is 2.85 cents per mile.
My first thought on this, is its a bad idea to utilize imperfect machine learning algorithms for critical interactions. This is bound to go bad at a really bad time.
As opposed to utilizing imperfect bio-machine learning algorithms for critical interactions? We know those go bad at really bad times, too.
Being able to read signs would be of great benefit to many Tesla drivers every day, and it's relatively easy to do.
It does read speed limit signs, but that's all. It doesn't really act on them, either, other than to set the default cruise speed if cruise isn't currently active, and to issue a chime if you're currently exceeding the speed limit plus a user-provided offset.
Depends on the cost of power, the "math" needed for that cryptocurrency, the math ability of the GPU at a price, the way a cryptocurrency was set up.
Right now, the math for all of the major cryptocurrencies is such that unless your power is basically free, GPU-based mining is unprofitable. And if you have really cheap power, you'll make much more money by using ASICs.
Yes, there are the ASIC-resistant coins, but they're in the noise.
Slashdot Mirror
Ever notice only hipsters use standing desks?
I never knew I was a hipster!
I use a standing desk and alternate between sitting on an exercise ball, sitting on a nice office chair and standing. Being able to change position every hour or two keeps me more awake and leaves me feeling better at the end of the day. Taking a couple of breaks per day for some exercise, whether going for a bike ride, working out on the weights / rowing machine or just going for a walk is really important, too.
I find this is getting more and more important as I get older (I'm 50).
Can I ask what model-year you have?
It's a 2012, though I first leased it in 2013. Part of why it was so cheap is that they were trying to get it off the lot so I got a great deal on the lease terms. When the initial lease period ended in 2015 they offered me a one-year extension at the same payments (~$230 per month). When the extension ended, I bought the car for $6K. Nissan's big screwup was massively overestimating the residual value at the end of the lease. Competition from EVs with longer range, plus bad press about short-lived Leaf batteries (the lack of thermal management means that Leafs in hot climates have battery life problems) depressed the used market. Nissan had estimated that after two years my Leaf would be worth $20K, but after three years it was worth $6K. Their error was essentially a $14K windfall for me.
How can they not "do" the work they're showing you? I was talking about a portfolio of work. Their githubbitbucketsourceforge whatever. How can you not talk to them about that very work they created and not know they can't do the work they're literally showing you?
If it's open source and you can see the history of commits on projects of significant size in which they collaborated with many others, then, sure, it's very difficult for them to claim ownership of something others have done. But the vast majority of programmers don't have a substantial body of open source work that they've done, because most of their work has been professional. They'll tend to have a couple of small student projects, or a handful of weekend-and-evening projects, but (a) they're likely to be too trivial to be really informative and (b) they're likely to be single-person or small-team projects that are sufficiently obscure that they could easily have lifted them from someone else.
So if you want to discuss work of real note, usually what you're asking them to tell you about is closed-source work they've done. You can read the summary on their resume and then chat with them about it. But if they're at all good at lying they can easily tell you about work that was done near them, rather than by them. For new graduates and intern candidates, they can also often talk about work their classmates have done. It's tempting to believe that if they can talk the talk they're the real deal, but it's just not so.
On the other hand, if you give them a problem to solve and ask them to design and then implement a solution, there's no way they can fake that. The closest they can come is if they get lucky and you happen to pose a problem that they've seen before... but that's actually pretty obvious, and also pretty easy to avoid -- just invent a sufficiently-novel problem. It's also extraordinarily unlikely that they can get lucky repeatedly in that fashion. This is part of why Google has candidates do a sequence of interviews with different engineers. They might be able to fool one; they're very unlikely to be able to fool four or five.
The downside (one of the downsides) of this approach is that you obviously have to choose a self-contained and relatively trivial problem, since they have to be able to understand it, design a solution, write the code and explain how they'd test it in about 40 minutes. So it doesn't test their ability to navigate large codebases, or balance complicated competing concerns, or any of a dozen other things you'd really like to know. What it does do, though, is give you an opportunity to watch them think their way through a problem and consider design alternatives and tradeoffs on a small scale. As it turns out, people who can do this well, consistently, can also handle bigger problems.
Perhaps the biggest problem with this sort of coding interview is that while it's true that someone who performs well in this environment is extremely likely to perform well on real projects, the converse is not true. Many good engineers perform poorly in this sort of timeboxed, high-pressure test (though Google interviewers do attempt to make it collegial and unpressured), and this system rejects them. I make a habit of telling candidates that the best thing for them to do is to approach the interviews as a series of fun and interesting puzzles to solve, to focus on the puzzles rather than on the context or on trying to impress the interviewer. Many people can't do this, and the fact that Google primarily hires people who can clearly biases the hiring process in a certain way that may or may not be beneficial.
What is clear, though, is that after 30 years as a professional software engineer, Google is the only place I've worked where I never have to wonder if my colleagues are competent. It's hard to overstate the value of this fact. In previous companies, whenever I began working with an engineer from another organization, or a new hire, or whatever, there was always a
How many 2.0 GPA hires do you think Google has?
/me raises hand.
High school GPA was < 2.0. College was better, but not great. I know another Google engineer who never finished high school. I know another who finished her associate's degree with a 2.0 GPA.
You get them to explain their work.
Doesn't work.
I used to believe that I could chat with someone about their work and come away with a solid idea of how good they were, but then I made some bad hires that made me realize how wrong I was. Your method does filter out the bad liars, but not the good ones. The good ones know enough to be able to explain the work, point out pros and cons, key design decisions, etc., and explain the rationale... but that is far from the same thing as meaning they could actually do the work they're describing.
Google has solid data on the results of their interview process; they've been tinkering and experimenting with it for years. And the interview process works very well at doing what it's designed to do: Reject weak candidates. It also rejects a lot of strong candidates, which is unfortunate, but it does an outstanding job of avoiding the bad hires, which is the primary goal.
Google has a mole within its decision making hierarchy.
Nah. The problem is that Google mostly doesn't have a decisionmaking hierarchy. I say "problem" but it many ways it's also Google's core advantage, though it clearly has its downsides as well.
Google is a very bottom up company. Throughout most of the organization, decisions are made primarily by the engineers doing the work. They choose a team to work for (new hires are assigned to a team, but most people switch every few years), then look at the problems/opportunities with that team's products and decide what they think needs to be improved/built. They sell their managers / peers on their ideas and, assuming they're successful, set their objectives and key results (OKRs), then go to work.
Performance reviews and promotions are evaluated primarily based on demonstrated impact, which is a vague term that has several dimensions but is mostly driven by measures of user engagement. Doing great work on a product no one uses is "low impact", as is doing minor work on a successful product. Keep in mind that Google measures success primarily by the "toothbrush metric", which is how many people use a product daily, and that a million users isn't "successful". Successful products have 10E8 to 10E9 users. The most impactful, and therefore most promotable, thing you can do is to launch an entirely new product that becomes successful -- though to be clear people are highly rewarded for doing less visible impactful things, such as building internal infrastructure.
This creates a very unusual company dynamic, very different from the typical corporate hierarchy. It's designed to harness the brainpower of the large and very bright staff not only to figure out how to build the technology, but also to decide what to build. Promising projects that have potential for great impact find it very easy to hire lots of talented engineers. Projects that are failing, or even just stagnating, find their staff drifting away as people seek more impactful work.
There are top-down, hierarchical decisions. Upper management does give direction, and perhaps the most powerful lever they wield is headcount allocation. But successful -- or just promising -- projects find it easy to grow their headcount allocation. One of the strongest signals a team can give to the next layer up is that there are lots of engineers who would like to join it. That's not the only decisionmaking criterion, but it's a powerful one. The mere fact that many people want to work on something is considered a good indicator that that thing is important and worth working on, because if it weren't likely to be impactful why would so many impact-seeking engineers want to work on it?
Throughout most of the company, most of the time, this non-hierarchical, bottom-up structure works very well. The most talented people do seek out the most impactful projects, both because it gives them the best shot at promotion and because it maximizes the odds that they're doing something of benefit for humanity (and, yes, there is a lot of that sort of altruistic sentiment at Google, and it's not feigned or faked). In fact, many of Google's biggest failures were caused when management didn't allow this "natural" self-allocation of talent but instead used arbitrary incentives to drive specific employee behaviors.
But there are some clearly pathological cases as well, and messaging seems to be the most obvious. I think that people look at messaging and think "This is a simple problem, and if we can solve it well we have a chance to build something that most of humanity uses on a daily basis". It looks easy, and incredibly impactful (per the toothbrush metric), so projects get spun up and attract lots of engineering staff. But while it's easy to build a chat tool, getting hundreds of millions of people to decide to use it is not so easy, so projects stagnate, staff leaves to do other stuff and eventually the project gets shut down because the handful of die-hards who are left to maintain it get overwhelmed and can't keep up.
So no "mole", no deliberate sabotage. Just a very unusual organization structure with some unusual failure modes.
His parents did, and are monetising their son.
True, but I'd guess it works pretty well for him, too. I watched a couple videos and a lot of them are about the interactions between the kid and his parents and sisters, and it's pretty clearly enjoyable for all of them. According to the Wikipedia article, the whole thing was Ryan's idea originally, too -- in a babyish way, of course, since he was only four at the time. He just asked his mom why he wasn't on YouTube.
Perhaps more important, it means he has both of his parents home with him so he gets a lot of time with them, unlike most kids his age who spend a lot of time in daycare while mom and dad are at work. He'll also be able to afford to go to whatever school he wants and should have a rich, experience-filled life, assuming his parents keep their heads on straight and manage the money well.
It could all go horribly wrong, of course, but it could also set him up for a great life.
The drivers aren't open, usually ever, so you're fucked because only the manufacturer could update or supply the newer versions.
If you get a device that launched with Oreo or Pie, this shouldn't be a problem. Those devices must support project Treble, which imposes a well-defined hardware abstraction layer between vendor space (those drivers you mention) and the system (everything above). It should then be possible to install any newer system image on the device, leaving the vendor partition unchanged, and it should work. For some number of releases, at least; at some point new systems will stop supporting old HALs.
Note that this assumes your device has an unlockable bootloader. If the bootloader can't be unlocked then you can only install OEM system images, so as soon as your device maker stops providing updates, you're done. Don't buy an Android device whose bootloader you can't unlock.
Chrome also supports QUIC, which requires a long-lived GUID (ie. a unique browser ID).
Cite?
I think you're referring to the Connection ID, but it is not long-lived and it is not global, i.e. not a unique browser ID. Its purpose is to enable connection migration, seamless continuation of an existing connection when the device changes IP addresses (switches LANs, goes from Wifi to cellular or vice versa, etc.). It's actually required to change on every migration, and allowed to change at almost any other point in time, so it's definitely not long-lived, even for a given connection, and is certainly not global.
Chat has more functionality than Hangouts in the same way Slack has more functionality than IRC.
I can't think of a single thing Hangouts does that Chat doesn't, and several things that Chat does that Hangouts doesn't. I don't think you know what you're talking about.
The only thing in your rant that I disagree with is:
Chat, which is a clone of Hangouts but with more bullshit and less functionality
Chat actually has more functionality. It's taken over as the messaging tool of choice inside Google because it's better. Among other things you can actually send files other than images to people through it. Very convenient when you're talking about some file to just be able to include it in the conversation. The chat room functionality is a little better, too, and the web UI is better if you're someone (like me) who frequently has a dozen conversations ongoing.
The big downside of Chat is that it's so enterprise-focused that you can only use it with people in your organization. This is really annoying, because I use Hangouts to chat with many external partners, which means that I have to use both Hangouts and Chat. Worse, Chat is still semi-integrated into Hangouts, so my Chat messages also appear in Hangouts, meaning I get duplicates.
All the rest, though, I agree. Google should make the incremental improvements that Hangouts needs (including pulling in some of the Chat features it lacks) and drop all of the other stuff. I don't think that's what's going to happen, though.
I wouldn't call the chance non-zero. Google may way see this a a thread to them, especially if it goes global. They have a vested interest in this not being a thing. Apple has already fought against this kind of thing in the US courts, so I wouldn't be surprised if they don't take a stand as well.
Here's how at least one part of Google feels about it: https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html.
TL;DR we're trying to make it technically impossible for us to decrypt user data on Pixel devices. Not to prevent law enforcement access, but to ensure that no insider, no matter how privileged, can do it. This has the -- pleasant, in my personal opinion -- side effect of making laws like this ineffective. Until/unless, of course, they attempt to force companies to build in what amount to active back doors. I'm pretty confident Google would fight that (note that that's a personal opinion; I do not decide or communicate legal policy). Also, we're planning to eventually mandate this in all Android devices of a certain class.
From the Android Pie Compliance Definition Document, emphasis mine:
Of course, this only affects data stored on Android devices. User data that is shared with Google through the use of Google's apps and services, is obviously available to Google in plaintext, else it couldn't be used to provide said services, and couldn't be used for ad targeting which in many cases is the "fee" for those services. Not without major breakthroughs in homomorphic encryption, anyway. That data is subject to normal warrants and subpoenas, of course, no need for this decryption law. However, warrants and subpoenas are also subject to judicial oversight and court challenges, and the legal team can redact and filter the provided data to narrow it to just what the court actually requires.
I have a few cans of bear spray, for when I go hiking in bear country, obviously. Just after I got the first one, I was camping with my extended family. Wishing to know how the spray dispersed (range, cloud shape, etc.), in case I ever needed to use it, I decided it would be a good idea to do a little test. The family (about 15 people) was sitting around the campfire chatting. It was a windless day, so I decided I could go in any direction to do my testing. I picked a direction and walked about 100 yards from camp, squeezed the trigger and noted the size and shape of the resulting orange cloud. The cloud quickly dissipated, so I walked back to camp and to my trailer to put the bear spray away. I also sat down in the trailer and started reading a book.
About five minutes later, I heard shouts of pain and anger from the direction of the campfire. I walked out to find everyone fleeing the area, rubbing their eyes and complaining loudly. It turned out that there was a little bit of air movement after all. Not enough to be felt, but enough to waft the (invisible) cloud of bear spray a hundred yards in a few minutes. And it turned out that I had chosen a direction that was directly upwind of the campfire.
Oops.
Re "This is one of the unsolved problems of security." Keep the next big idea as a spoken topic among 10 ~ 100 workers? A walk in vault with no electronic devices and notes on paper. Look deep into the political and friendship past of all trusted workers.
You omitted the crucial part of the post you quoted (emphasis mine, obviously):
Yes it's possible to reduce the threat of insider attacks by reducing the set of insiders with access and carefully vetting that small group, and also by adding other measures like technical and and procedural mechanisms to require multiple people to be involved in any access to sensitive data, but anything you do that way is going to "really slow things down inside the business and cause problems". Sometimes data is so sensitive it's worth the hassle and expense. Most of the time, it's not.
The reasoning behind that is, even if su required the password, someone as root could write a program to allow them to become another user anyway, so it's not going to make a difference.
More than that, it would be actively bad for su to require the password. It would make less-thoughtful sysadmins believe that root can't act as any user. This can still happen, witness techno-vampire's misunderstanding, but it would be much worse if he couldn't do a simple test and discover his error in a few seconds.
No I don't need those things that you mentioned.
You're a member of a tiny, tiny minority. Most people want their phones to do more stuff.
See, these things SEEM helpful and that, and I'd LOVE to believe that there are developers out there that are willing to spend their time on projects that purely make my life easier.
Why says they're doing it purely to make your life easier? They're doing it to make their devices more competitive, to make you want to shell out your money for their phone rather than a competitor's phone.
These AI apps aren't there for you, they're there for the people that wrote the software that employ AI.
How are any of the things mentioned not there to benefit the user?
Who would have thought you would do such a 180!
I didn't do a 180. Do you really believe that your phone doesn't send data back to it's servers? You don't know what other things that AI is doing, and you certainly don't know if that AI is sending data about your personal ways, back to a server in another part of the world.
The AI stuff is going to happen, regardless, because it creates value for the users, value that most people really like. The only question is where it's going to be done. Sure, developers may ignore the AI hardware and continue sending the data back to the server, but AI hardware on the device at least makes it possible for developers who want to make privacy a part of their value proposition to keep the data local.
I can see (though not really agree with) your argument that you don't like this AI stuff. But there's absolutely zero sense in your argument that you would prefer it can only be done in the cloud, rather than locally.
Qualcomm announced its new flagship 855 mobile platform today.
I'm thinking, "Cool!"
The 855 also features a new multi-core AI engine...
I'm thinking, "Not cool"
Why? Lots of stuff in phones today makes use of neural network models... stuff like voice recognition, text translation and image content identification to name some prominent ones. Dedicated hardware can perform these calculations faster and with lower power consumption -- and in some cases that will be the difference between making it feasible to do on-device and having to send the data off to the cloud for processing, which is better for privacy.
In what way is this a bad thing?
Well, it would presumably support Office365 and all its webapps. Perhaps that might not be super useful for a general purpose PC, but for a light duty workstation it could do well.
Given their move to a Chromium-based browser, it could potentially also run all of the Chrome web apps. Throw in an Android container, and you'd have something equivalent to ChromeOS, except that I presume it would run the MS webapps "natively" (right now, to run Office365 on a Chromebook you have to use the Office365 Android app in the Android container, or so I read). If the set of Universal Windows Platform apps grows to be something useful, those would provide another advantage over Chromebooks.
And, honestly, Lite probably doesn't need to actually be better than ChromeOS. If it's only as good then it may provide a way to stop the bleeding, and that's probably enough. Microsoft still has the dominant PC OS. That dominance is at risk because of the success of ChromeOS in education, which may create a generation of users who are accustomed to something else. Or maybe not; after all, Apple tried that strategy in the past and failed. But if Microsoft can get an MS-branded equivalent into the markets currently being served by Chromebooks it may be possible to mitigate the risk they pose.
Though it's not really evidence of anything, I'm quite certain that it would be far, far easier to convince my dad to use a Microsoft browser OS than to use Chrome OS. It wouldn't surprise me if there were a bunch of other people out there who really only need an enhanced browser and would be happy to try one from Microsoft but won't stray outside of the MS fold.
By about the time an electric car actually pays for itself in terms of gasoline saved, it's nearly time to replace the battery. which throws you back about another year again before you start to see savings.
Not my experience at all. I fully expect to get 200K miles, or more, from the battery in my Leaf. And that's not a random guess, that's a projection of the decline curve I have been measuring monthly. And even when the battery capacity is diminished enough that the range is getting constraining, the battery will still hold 15+ kWh. Little enough that it doesn't make sense to drag it around the road any more... but enough that it would make an awesome backup battery for my house.
The Nissan Leaf may be $30K while the average price for a new car is $33K, but that's only because the average new car is not a compact, which is the classification that the Leaf falls in. A brand new compact vehicle can be purchased for $20K or sometimes even less.
True, but total cost of ownership of the Leaf will often be lower. You trade a higher payment for lower fuel and maintenance costs. So it's not a car for the wealthy, it's a car for the prudent whose driving patterns fit certain (extremely common) profiles.
I did this exact analysis quite thoroughly several years ago before I bought my Leaf. In practice I find that I actually underestimated the operational cost difference... and the purchase price difference turned out to go the other direction, thanks to some stupidity by Nissan. The latter part was luck and not repeatable, but my Leaf has worked out to be an incredibly inexpensive car to own and operate. 100K miles into it, my total cost per mile (excluding insurance) has been about 19 cents[*], and that includes the full purchase price. The next 100K miles (and I see no reason it won't make them; the battery has only lost about 10% of its initial capacity, and capacity loss is front-loaded, and there's really very little else to go wrong) should cost under three cents per mile[**].
If I'd paid full price, of course, the numbers for my first 100K miles would be different, about $15K more, so about 34 cents per mile. A Honda Fit, at $20K purchase price, plus $8.5K for gas (35 mpg, $3 per gallon), a little more in maintenance due to oil changes and a new set of brake pads... call it $2K, would be a titch cheaper, at $30,500, or 30.5 cents per mile. But if you look at the next 100K miles, the fuel/energy savings really kicks in.
Plus, electric cars are more fun to drive. Going the other way, there is the range limitation, of course. If you regularly need to drive long distances, a Leaf is not for you. If you need to do it only occasionally, you may still be money ahead buying the Leaf and renting an ICEV for those trips. Depends on the details.
[*] Total purchase price (sum of all lease payments plus buyout): $15K. Charging station for home: $500. Total maintenance costs so far are a couple of sets of new tires, one alignment and a windshield replacement: $1K. I get about 4mi/kWh, at a cost of ~$0.10/kWh, so 100,000/4*.1 = $2500 in electricity. Totalling those up, I've spent $19K. 19 cents per mile.
[**] For the next 100K miles I'd expect to get three new sets of tires and replace some brake pads. The maintenance schedule says that at 150K miles I should get the oil changed (the oil is actually a coolant, not a lubricant, but eventually does need to be changed). The dealership says they'll want $100 for that. Figure maybe another alignment, too. Add all of that up, and call it $1200 in expected maintenance. Round up to $2000 to be conservative. I'm now on a "time of use" electricity plan which charges me $0.034/kWh off-peak, which is the only time I charge. 100000/4*.034 = $850. So the next 100K miles will cost me about $2850, which is 2.85 cents per mile.
My first thought on this, is its a bad idea to utilize imperfect machine learning algorithms for critical interactions. This is bound to go bad at a really bad time.
As opposed to utilizing imperfect bio-machine learning algorithms for critical interactions? We know those go bad at really bad times, too.
Being able to read signs would be of great benefit to many Tesla drivers every day, and it's relatively easy to do.
It does read speed limit signs, but that's all. It doesn't really act on them, either, other than to set the default cruise speed if cruise isn't currently active, and to issue a chime if you're currently exceeding the speed limit plus a user-provided offset.
Depends on the cost of power, the "math" needed for that cryptocurrency, the math ability of the GPU at a price, the way a cryptocurrency was set up.
Right now, the math for all of the major cryptocurrencies is such that unless your power is basically free, GPU-based mining is unprofitable. And if you have really cheap power, you'll make much more money by using ASICs.
Yes, there are the ASIC-resistant coins, but they're in the noise.
A few obscure coins are ASIC-resistant, but there's not enough work being done on them to affect GPU prices.
now the price of video cards should return to normal and the supply will be able to fill the demand
Does mining have any effect on the availability of GPUs any more? I doubt it. ASIC mining rigs have taken over.