I actually do most of my work in public, directly in AOSP. This is different from most Android engineers, who work on an internal tree which gets dumped to AOSP with each major release. So, not only can I tell you what I'm working on, anyone who cares can follow my work in near real-time.
Yeah, although keep in mind that the GNex was an unusual case. There are binary components that Google doesn't have source to and the SoC maker is out of business, and the code seems to have gone with them. After learning a lesson from the GNex, Google has worked to ensure contractually that no Nexus device will be left in the same situation.
The same convergence happened in the phone industry for exactly the same reason... regulations give only one provider in an area the right to run wires to your house. There's huge incentive for such local monopolies to consolidate to form regional monopolies. But the basis is the government-mandated local monopolies. Now, granted that there are some good reasons for the local monopolies; it would be a pain to have a dozen companies all tearing up your street to install their own wires... but there are lots of ways that could be addressed.
AFAIK, all candidates get paired with a recruiter, regardless of who contacts whom, at least they do if the process goes to the interview stage, because it's the recruiter who sets all of that up.
I think your recruiter violated policy in saying what he said. In addition, I suspect it may not actually have been true, because from what I know of the hiring process the recruiter doesn't get detailed feedback from the hiring committee on the rationale for the no-hire decision. I suspect the recruiter just told you something he thought would let you down gently, without knowing the real rationale. The same may have been true for the AC. Or maybe I'm wrong.
As for the bullet-dodging... I doubt it:-). There's a reason Google has been rated the #1 place to work six years running. Not that you don't enjoy what you do, I'm sure you do, and perhaps even more than you'd have enjoyed Google. But I strongly suspect you'd have enjoyed working at Google very much. I do, and I've worked for small startups, too. The rewards are different. Google is cool mostly because you work with a lot of really amazing people and work on things that have tremendous real-world impact. A billion people use my software on a daily basis. That's hard to get elsewhere. You also generally have a great deal of say in what you work on, and how it gets done, which is similar to a startup. The downside of Google is that it is a big corporation, which means there's a certain amount of bureaucratic overhead which you generally don't have to put up with at a small company. And you obviously also don't get the same sense of helping to set the company's direction as a whole. And, of course, while Google compensation is probably better than most startups, it doesn't come with the stock options that promise to maybe someday make you an instant millionaire.
There's no doubt that the process is imperfect. In fact, the bar is quite deliberately set so that there are a large number of false negatives (bad no-hire decisions), to keep the number of false positives extremely low.
As for your particular complaint... I think that people who don't think well on their feet actually won't perform well at Google. Rather than one person plugging away for a month to come up with that ingenious solution you mention, the approach at Google is to get a half-dozen people together and collaboratively work through the same solution space in a few hours. Will they come up with your ingenious solution? I can't guarantee it... but the odds are actually pretty high. I work with some seriously bright people (I can't figure out why they keep me around; but I'm not complaining).
I don't want to imply that slower, more methodical thinking styles are bad. In fact, I think you can make a good argument that Google needs more methodical thinkers. But for better or worse, the culture is one of rapid-fire thinking and speaking, heavy on collaboration, light on process.
I guess what I'm trying to say is that I think Google's interview process does select for the kind of people Google wants to hire, and you may simply not be that kind of person. That's not to say that your'e not highly intelligent and deeply competent... just that you don't fit the culture.
(Obviously I'm assuming a lot based on a few words from your post. Please excuse me if I'm off base.)
It's worth pointing out that libertarians *do* have a solution to the lack of competition in the ISP space: remove the regulations that prop up the regional monopolies. However, since we're apparently not going to do that, additional regulations are necessary to prevent the government-mandated monopolies from screwing us too badly.
Actually, for the system image we do want to enable installation of custom signing keys, so you don't have to unlock/relock. The current situation encourages modders to leave their bootloaders unlocked, which is bad because if someone finds your device they can flash a custom/malicious system and gain unlimited access to your data (well, disk encryption is another barrier, but we prefer defense in depth). So custom signing keys will make it easier for modders to secure their devices. I won't say when, but I will say that's something we want to enable on Nexus devices.
For the trusted OS, it's different. The problem is that the trusted OS has access to device secrets that don't change when the device is re-flashed. Worse, the trusted apps make use of those secrets as the root from which they bootstrap all of their cryptographic keys. This means that if someone can flash a custom trusted OS they can extract those keys, and then subvert all of the security provided by the real trusted OS. Worse yet, sometimes those secrets aren't device-unique, but may be the same across a whole batch of devices. In those cases the TEE apps derive device-unique keys using the per-batch keys and the device serial number. But that means an attacker who can flash a malicious trusted OS to one device can compromise the entire batch.
So... the only way to have any security from this TEE stuff is to very tightly control what code is allowed to run in it. Which means no customization. That's sad, but it's what we have to do.
So, when a 50+ bright person comes, they may adjust the job description and offer him/her something instead of letting him/her go. Maybe something more managerial.
Only if he or she is interested in management. The engineering track at Google goes up to the VP level, so there's no need for engineers to jump over to management unless they want to. I know lots of 50+ engineers at Google (I'm a Google SWE, and 45 years old).
I'm a Google employee and have access to some internal statistics, and I can tell you it's older than that. I don't know how much I can share, but I'll mention that the median age for engineers in Google US is closer to 35, and about a quarter of Google US engineers are over 40. That's consistent with my current team; my previous team was older, probably half over 40 with a fair number in their 50s and a few in their 60s.
Further, the median age is climbing. Partly because existing employees are aging but also because the age of new hires is increasing.
When they start to reduce the process of interviewing down to a standardized series of questions and tests, they remove the human from the process too.
(I do interviews at Google)
Google doesn't use standardized questions or tests. The app mentioned just provides some decent questions. At least for software engineer interviews, though, the interviewer would be foolish to use a question read from an app on the spot. The Google SWE interview questions are complex technical problems, designed to give the interviewer a chance to watch the candidate solve problems on the spot, and write code. To do that effectively, the interviewer has to know the question well, and to have explored most of the potential answer space, and to have some idea about how different kinds of candidates will respond to it.
Googlers call the process of exploring the answer space "calibrating" the question, and it's a pretty important and serious process. Generally it starts with grabbing a few other Google SWEs and doing mock interviews to see how they handle the question, and ultimately interviewers like to use the same set of questions with many candidates because seeing how several candidates handle it really nails the calibration down. I have a couple of questions that I have so well-calibrated that I can make 90% of a hire/no-hire decision in the first five minutes. Basically, good candidates blow through the first stages in a couple of minutes, while poor candidates struggle for a half hour. I don't make the hire/no-hire decision in the first five minutes, though, because there are exceptions. Some people just take a while to settle down / warm up, which is cool.
I suppose you could use an uncalibrated question from an app during an interview and then calibrate it after the fact. I've done that (without the app), asking a question that I haven't already calibrated, then after the interview getting some of my teammates to solve the same problem. It's not nearly as good as going into the interview with well-calibrated questions, though, because you don't understand the solution space well enough to effectively direct the candidate.
Actually, I just looked up qDroid and it's specifically for non-technical interviews. I had it run up some questions for a sample position, and they actually look pretty good. All open-ended, exploratory stuff, with lots of suggested followups.
This is the MBA mindset of trying to remove the variables in the process
FWIW, I'm sure Google employs some MBAs, but I've never met any of them. Google is an engineer-driven company, top to bottom. All eng managers are required to be competent engineers themselves, and for most engineers their entire management chain, up to and including the CEO, is all technical. There are negatives to this SWE-heavy structure, but it's far better than any other company I've worked for (and I've been around the block).
Heh. During my phone screen they sent me the Docs link... but the recruiter had neglected to give me write permission, or to give the interviewer ownership so he could give me write permission. So we just did it verbally.
Later, an internal headhunter told me I had scored off the charts on the first interview, but the hiring committee rejected me because of the school I graduated from.
I don't think so. Google does not give candidates any feedback on the reason they weren't hired.
Also, that makes no sense. I graduated from a school no one has heard of, and they hired me. I have a colleague who didn't go to college at all, didn't even finish high school, and a couple of others that only have associates degrees. Google really doesn't care very much about the school you went to, or if you went to school.
The key to interviewing at Google is to drink the kool aide before you arrive. Download and use the core software they make available. If you're not enthusiastic enough about their tool chain to do that, mere competence won't carry you over the finish line.
(I interview software engineers at Google)
This really isn't true. I mean, certainly some level of interest and enthusiasm is important, but the interview process doesn't really focus on that. SWE questions are pretty much all technical, about algorithms, data structures and coding. Not to test your knowledge of those topics (Google isn't really concerned with what you know, but with how smart you are) but to see how well you can solve problems on your feet. There is a significant component of the interviewer's report that covers "Googliness" which probably partially covers enthusiasm, but is much more about whether your personality is a good fit for the culture -- are you a nice person, friendly, interested in technology and solving problems, etc.
Not even talking about the money spent, there is just no practical way for me to micro-pay for every site I go to
Check out Google Contributor. Of course it only micro-pays to sites that use Google's ad services, not all sites. But Google's ad services do cover a large chunk of the Internet. It's also still experimental.
It does work. I've done it in team environments. It works quite well, actually.
Anything works if you're willing to put enough effort into it. But if your goal is to reduce the amount work of required to make the code readable to multiple developers with multiple tab widths, it doesn't. It merely adds an additional load on everyone to make sure that everything follows the fairly complex formatting rules.
The one way it does work without too much pain (except the line-wrapping problem and other tool problems I mention below) is if you have really good tool support. Something like clang-format configured to work out the indentation and apply the proper mix of tabs for indent levels plus spaces for alignment. Especially if you run the formatter in a commit hook or similar. But if you've got something like that, it doesn't matter anyway because you can use spaces and everyone can automagically reformat the code to whatever indentation size (and other style) they prefer. With a decent editor and a good formatting tool, it's trivial to get the editor to reformat to the preferred style on load and the common style on save.
And then by using spaces you don't have the problem that all command line tools output bits of code with 8-character tabs. You see the same thing in your editor and on the CLI. And web-based code browsers and whatever other ways you look at your code.
An issue that arises with lots of automatic reformatting is line-breaking, but you have the same problem with using tabs of varying widths for varying indentation sizes. The guy who likes 8-space tabs will always want to line wrap much earlier than the guy who likes 1-space tabs, and that problem exists whether you use spaces and reformat or use tabs and change your editor config.
All in all, this effort to allow developers to use different indentation sizes just creates headaches for everyone. It's much simpler and less error prone to mandate a fixed indentation size and specify that it must be done with spaces. And if you have an engineer who refuses to follow the coding style, you should fire him, and thank your lucky stars that you did so, because that attitude is going to bite you in other areas that actually matter.
You can't really install this yourself, unfortunately. And I really do consider it unfortunate, though there are good reasons for it.
To make it really secure you have to run it in TrustZone, which means you have to be able to build and flash a trusted OS and apps. At present, all of the trusted OSes are closed source, proprietary and tightly-held. Google is going to fix that, but even when there's an open source trusted OS, you won't be able to install it, because you won't have the signing keys needed to get the bootloader to accept it. Unfortunately, this is one area where I don't think Google is going to enable users to do their own thing, not even on Nexus devices.
The reason is that if we provide a way for users to build and sign their own trusted OSes, we also inevitably enable attackers the ability to replace the trusted OS with a malicious one, which destroys our ability to make any security guarantees. The whole point of a TEE is to provide a trustworthy environment so that we can provide some security guarantees even if the primary system is totally subverted -- or perhaps even replaced with a malicious system.
So, this functionality is going to be as-provided by the OEM of your device.
In any case, even if you could you wouldn't want to use it right now. It's a work in progress. In the next few weeks the new feature set will become available, and will be the default for AOSP builds, but that will be running in the main system, not the TEE. So you can see what the functionality is, and even use it, but you won't get the security guarantees provided by the TEE until you get an update from your OEM that includes a new TEE-based implementation.
Has what Marx proposed been tried on any scale larger than a hippie commune?
No. Why is that?
It's certainly not because Marx's ideas are new, or because there aren't a lot of devotees of them. I posit that the reason it hasn't been tried at scale is that every attempt to scale it up breaks down as soon as you get more than a few hundred people.
Marx was a decent economist for his day, but had no understanding of human nature. An understanding of game theory, had it existed in his day, would have tremendously improved his ideas, I think. In addition, his economic theories have holes you can drive a 747 through, mainly because they seriously underestimate the knowledge component of labor, and the resulting impact of innovation, and completely ignore the value of organization. It's the latter problem that results in imposition of heavy-handed, centrally-controlled economies in all attempts to build communal societies at scale. Since Marx's structure eliminates any reasonable mechanism for self-organization of a dynamic economy, implementers try to paper it over with central committees. Unfortunately, central organization is not only horribly inefficient because the complexity of a significant economy is far beyond the comprehension of any group of humans, it inevitably creates powerful, self-interested elites. That generates resentment among the populace, which provokes top-down imposition of population control systems... propaganda, powerful secret police, etc. -- the hallmarks of the real-world communist state.
It's pretty obvious why Marxism can't work at scale, once you recognize the fact that collective ownership eliminates the ability of the economy to self-organize for efficient production. As long as the economy is small and organization is simple and obvious, it works. But beyond a few hundred people... it can't. Perhaps after we've passed the AI singularity, when all production is automated, and all organization of production as well, then communal ownership will work, and may even be essential. Or maybe not.
I don't dispute that there are regular droughts, but I'm wondering how that helps to find the cause of this particular one. I don't believe there's a 500-year clock mechanism somewhere that is responsible for triggering them.
You misunderstand what "500-year drought" means. The 500 years is a mean interval between such droughts, not a fixed value. It doesn't mean there's some mechanism that causes a drought every 500 years, or even about every 500 years.
Want your language to become the next lingua franca? The first thing you need is a time machine. You have to go back in time and find some culture that is going to become extremely influential and somehow get them to adopt your language.
Features of grammar, spelling, etc. are irrelevant. There can be no better proof than the current widespread dominance of English.
Or as close as they can possibly get, and the H1-B is edging fairly close.
Of course there's plenty of domestic STEM talent, just not for $45K a year with no benefits.
That may well be true... but it's clearly not what Facebook and Microsoft are worried about. The way H1-Bs visas work, the employer has to demonstrate that they are paying their foreign employees as well as their American employees, so the strategy you describe really only works for companies who pay all of their employees peanuts. It's possible, perhaps, that the availability of H1-B employees helps them keep their employee salaries down a little, simply by increasing supply. But I doubt it. Based on my experience it's far more likely that they can't hire enough qualified people at any price.
I mean, seriously, you're talking about some of the highest-paying companies with the most employee benefits and perks. How many people do you know who got a job offer from Facebook or Microsoft and turned it down because it wasn't enough money? And how many do you know who hated their Facebook job so much they wanted to escape from it? I actually do know a few people who found the Microsoft culture so toxic that they wanted to leave, but I hear that's changing, and in any case I don't see MS having enormous retention problems among their non-H1-B employees... and they have to treat the H1-Bs essentially the same.
I don't follow the argument that more H1-Bs are needed to provide jobs to Americans, and I'm sure that there are lots of companies that abuse H1-Bs in exactly the way you describe, but Facebook, Microsoft, Google, Apple and other such top-tier US engineering companies are not among them.
Smooth text, in particular, is much easier on the eyes.
Hmm, I didn't realize s-m-o-o-t-h was an accepted spelling of "blurry".
What are you talking about? Smoothing text with anti-aliasing does make it blurry, but that's the whole point of high-resolution displays... you can get truly smooth curves *without* anti-aliasing. High resolution displays are the polar opposite of blurry.
Which only matters if all indentation, including alignment, is done with tabs. The moment you throw in a few spaces to line something up on a non-tab boundary (say, to align a second line of arguments with the first argument), then you have a mess, unless your tab width is set to exactly the value that whoever touched the code before you set it to.
And here is what you are doing wrong. Tabs are for indentation, spaces are for alignment.
Yes, I used that argument 20 years ago, too. It doesn't actually work. People mess it up way too often.
I've been coding way too long to care about indentation bullshit anymore. If a file does not have uniform indentation style, reindent it with a standard tool (*), and then commit the reindent-only change to local git.
Absolutely. Lately, clang-format has become one of my favorite tools ever.
Slashdot Mirror
I actually do most of my work in public, directly in AOSP. This is different from most Android engineers, who work on an internal tree which gets dumped to AOSP with each major release. So, not only can I tell you what I'm working on, anyone who cares can follow my work in near real-time.
Perhaps. Personally, I see quite a lot of creativity.
Yeah, although keep in mind that the GNex was an unusual case. There are binary components that Google doesn't have source to and the SoC maker is out of business, and the code seems to have gone with them. After learning a lesson from the GNex, Google has worked to ensure contractually that no Nexus device will be left in the same situation.
The same convergence happened in the phone industry for exactly the same reason... regulations give only one provider in an area the right to run wires to your house. There's huge incentive for such local monopolies to consolidate to form regional monopolies. But the basis is the government-mandated local monopolies. Now, granted that there are some good reasons for the local monopolies; it would be a pain to have a dozen companies all tearing up your street to install their own wires... but there are lots of ways that could be addressed.
AFAIK, all candidates get paired with a recruiter, regardless of who contacts whom, at least they do if the process goes to the interview stage, because it's the recruiter who sets all of that up.
I think your recruiter violated policy in saying what he said. In addition, I suspect it may not actually have been true, because from what I know of the hiring process the recruiter doesn't get detailed feedback from the hiring committee on the rationale for the no-hire decision. I suspect the recruiter just told you something he thought would let you down gently, without knowing the real rationale. The same may have been true for the AC. Or maybe I'm wrong.
As for the bullet-dodging... I doubt it :-). There's a reason Google has been rated the #1 place to work six years running. Not that you don't enjoy what you do, I'm sure you do, and perhaps even more than you'd have enjoyed Google. But I strongly suspect you'd have enjoyed working at Google very much. I do, and I've worked for small startups, too. The rewards are different. Google is cool mostly because you work with a lot of really amazing people and work on things that have tremendous real-world impact. A billion people use my software on a daily basis. That's hard to get elsewhere. You also generally have a great deal of say in what you work on, and how it gets done, which is similar to a startup. The downside of Google is that it is a big corporation, which means there's a certain amount of bureaucratic overhead which you generally don't have to put up with at a small company. And you obviously also don't get the same sense of helping to set the company's direction as a whole. And, of course, while Google compensation is probably better than most startups, it doesn't come with the stock options that promise to maybe someday make you an instant millionaire.
There's no doubt that the process is imperfect. In fact, the bar is quite deliberately set so that there are a large number of false negatives (bad no-hire decisions), to keep the number of false positives extremely low.
As for your particular complaint... I think that people who don't think well on their feet actually won't perform well at Google. Rather than one person plugging away for a month to come up with that ingenious solution you mention, the approach at Google is to get a half-dozen people together and collaboratively work through the same solution space in a few hours. Will they come up with your ingenious solution? I can't guarantee it... but the odds are actually pretty high. I work with some seriously bright people (I can't figure out why they keep me around; but I'm not complaining).
I don't want to imply that slower, more methodical thinking styles are bad. In fact, I think you can make a good argument that Google needs more methodical thinkers. But for better or worse, the culture is one of rapid-fire thinking and speaking, heavy on collaboration, light on process.
I guess what I'm trying to say is that I think Google's interview process does select for the kind of people Google wants to hire, and you may simply not be that kind of person. That's not to say that your'e not highly intelligent and deeply competent... just that you don't fit the culture.
(Obviously I'm assuming a lot based on a few words from your post. Please excuse me if I'm off base.)
It's worth pointing out that libertarians *do* have a solution to the lack of competition in the ISP space: remove the regulations that prop up the regional monopolies. However, since we're apparently not going to do that, additional regulations are necessary to prevent the government-mandated monopolies from screwing us too badly.
Actually, for the system image we do want to enable installation of custom signing keys, so you don't have to unlock/relock. The current situation encourages modders to leave their bootloaders unlocked, which is bad because if someone finds your device they can flash a custom/malicious system and gain unlimited access to your data (well, disk encryption is another barrier, but we prefer defense in depth). So custom signing keys will make it easier for modders to secure their devices. I won't say when, but I will say that's something we want to enable on Nexus devices.
For the trusted OS, it's different. The problem is that the trusted OS has access to device secrets that don't change when the device is re-flashed. Worse, the trusted apps make use of those secrets as the root from which they bootstrap all of their cryptographic keys. This means that if someone can flash a custom trusted OS they can extract those keys, and then subvert all of the security provided by the real trusted OS. Worse yet, sometimes those secrets aren't device-unique, but may be the same across a whole batch of devices. In those cases the TEE apps derive device-unique keys using the per-batch keys and the device serial number. But that means an attacker who can flash a malicious trusted OS to one device can compromise the entire batch.
So... the only way to have any security from this TEE stuff is to very tightly control what code is allowed to run in it. Which means no customization. That's sad, but it's what we have to do.
So, when a 50+ bright person comes, they may adjust the job description and offer him/her something instead of letting him/her go. Maybe something more managerial.
Only if he or she is interested in management. The engineering track at Google goes up to the VP level, so there's no need for engineers to jump over to management unless they want to. I know lots of 50+ engineers at Google (I'm a Google SWE, and 45 years old).
Ummm. The median age at Google is 29.
Cite?
I'm a Google employee and have access to some internal statistics, and I can tell you it's older than that. I don't know how much I can share, but I'll mention that the median age for engineers in Google US is closer to 35, and about a quarter of Google US engineers are over 40. That's consistent with my current team; my previous team was older, probably half over 40 with a fair number in their 50s and a few in their 60s.
Further, the median age is climbing. Partly because existing employees are aging but also because the age of new hires is increasing.
When they start to reduce the process of interviewing down to a standardized series of questions and tests, they remove the human from the process too.
(I do interviews at Google)
Google doesn't use standardized questions or tests. The app mentioned just provides some decent questions. At least for software engineer interviews, though, the interviewer would be foolish to use a question read from an app on the spot. The Google SWE interview questions are complex technical problems, designed to give the interviewer a chance to watch the candidate solve problems on the spot, and write code. To do that effectively, the interviewer has to know the question well, and to have explored most of the potential answer space, and to have some idea about how different kinds of candidates will respond to it.
Googlers call the process of exploring the answer space "calibrating" the question, and it's a pretty important and serious process. Generally it starts with grabbing a few other Google SWEs and doing mock interviews to see how they handle the question, and ultimately interviewers like to use the same set of questions with many candidates because seeing how several candidates handle it really nails the calibration down. I have a couple of questions that I have so well-calibrated that I can make 90% of a hire/no-hire decision in the first five minutes. Basically, good candidates blow through the first stages in a couple of minutes, while poor candidates struggle for a half hour. I don't make the hire/no-hire decision in the first five minutes, though, because there are exceptions. Some people just take a while to settle down / warm up, which is cool.
I suppose you could use an uncalibrated question from an app during an interview and then calibrate it after the fact. I've done that (without the app), asking a question that I haven't already calibrated, then after the interview getting some of my teammates to solve the same problem. It's not nearly as good as going into the interview with well-calibrated questions, though, because you don't understand the solution space well enough to effectively direct the candidate.
Actually, I just looked up qDroid and it's specifically for non-technical interviews. I had it run up some questions for a sample position, and they actually look pretty good. All open-ended, exploratory stuff, with lots of suggested followups.
This is the MBA mindset of trying to remove the variables in the process
FWIW, I'm sure Google employs some MBAs, but I've never met any of them. Google is an engineer-driven company, top to bottom. All eng managers are required to be competent engineers themselves, and for most engineers their entire management chain, up to and including the CEO, is all technical. There are negatives to this SWE-heavy structure, but it's far better than any other company I've worked for (and I've been around the block).
Heh. During my phone screen they sent me the Docs link... but the recruiter had neglected to give me write permission, or to give the interviewer ownership so he could give me write permission. So we just did it verbally.
Later, an internal headhunter told me I had scored off the charts on the first interview, but the hiring committee rejected me because of the school I graduated from.
I don't think so. Google does not give candidates any feedback on the reason they weren't hired.
Also, that makes no sense. I graduated from a school no one has heard of, and they hired me. I have a colleague who didn't go to college at all, didn't even finish high school, and a couple of others that only have associates degrees. Google really doesn't care very much about the school you went to, or if you went to school.
The key to interviewing at Google is to drink the kool aide before you arrive. Download and use the core software they make available. If you're not enthusiastic enough about their tool chain to do that, mere competence won't carry you over the finish line.
(I interview software engineers at Google)
This really isn't true. I mean, certainly some level of interest and enthusiasm is important, but the interview process doesn't really focus on that. SWE questions are pretty much all technical, about algorithms, data structures and coding. Not to test your knowledge of those topics (Google isn't really concerned with what you know, but with how smart you are) but to see how well you can solve problems on your feet. There is a significant component of the interviewer's report that covers "Googliness" which probably partially covers enthusiasm, but is much more about whether your personality is a good fit for the culture -- are you a nice person, friendly, interested in technology and solving problems, etc.
Not even talking about the money spent, there is just no practical way for me to micro-pay for every site I go to
Check out Google Contributor. Of course it only micro-pays to sites that use Google's ad services, not all sites. But Google's ad services do cover a large chunk of the Internet. It's also still experimental.
It does work. I've done it in team environments. It works quite well, actually.
Anything works if you're willing to put enough effort into it. But if your goal is to reduce the amount work of required to make the code readable to multiple developers with multiple tab widths, it doesn't. It merely adds an additional load on everyone to make sure that everything follows the fairly complex formatting rules.
The one way it does work without too much pain (except the line-wrapping problem and other tool problems I mention below) is if you have really good tool support. Something like clang-format configured to work out the indentation and apply the proper mix of tabs for indent levels plus spaces for alignment. Especially if you run the formatter in a commit hook or similar. But if you've got something like that, it doesn't matter anyway because you can use spaces and everyone can automagically reformat the code to whatever indentation size (and other style) they prefer. With a decent editor and a good formatting tool, it's trivial to get the editor to reformat to the preferred style on load and the common style on save.
And then by using spaces you don't have the problem that all command line tools output bits of code with 8-character tabs. You see the same thing in your editor and on the CLI. And web-based code browsers and whatever other ways you look at your code.
An issue that arises with lots of automatic reformatting is line-breaking, but you have the same problem with using tabs of varying widths for varying indentation sizes. The guy who likes 8-space tabs will always want to line wrap much earlier than the guy who likes 1-space tabs, and that problem exists whether you use spaces and reformat or use tabs and change your editor config.
All in all, this effort to allow developers to use different indentation sizes just creates headaches for everyone. It's much simpler and less error prone to mandate a fixed indentation size and specify that it must be done with spaces. And if you have an engineer who refuses to follow the coding style, you should fire him, and thank your lucky stars that you did so, because that attitude is going to bite you in other areas that actually matter.
You can't really install this yourself, unfortunately. And I really do consider it unfortunate, though there are good reasons for it.
To make it really secure you have to run it in TrustZone, which means you have to be able to build and flash a trusted OS and apps. At present, all of the trusted OSes are closed source, proprietary and tightly-held. Google is going to fix that, but even when there's an open source trusted OS, you won't be able to install it, because you won't have the signing keys needed to get the bootloader to accept it. Unfortunately, this is one area where I don't think Google is going to enable users to do their own thing, not even on Nexus devices.
The reason is that if we provide a way for users to build and sign their own trusted OSes, we also inevitably enable attackers the ability to replace the trusted OS with a malicious one, which destroys our ability to make any security guarantees. The whole point of a TEE is to provide a trustworthy environment so that we can provide some security guarantees even if the primary system is totally subverted -- or perhaps even replaced with a malicious system.
So, this functionality is going to be as-provided by the OEM of your device.
In any case, even if you could you wouldn't want to use it right now. It's a work in progress. In the next few weeks the new feature set will become available, and will be the default for AOSP builds, but that will be running in the main system, not the TEE. So you can see what the functionality is, and even use it, but you won't get the security guarantees provided by the TEE until you get an update from your OEM that includes a new TEE-based implementation.
Has what Marx proposed been tried on any scale larger than a hippie commune?
No. Why is that?
It's certainly not because Marx's ideas are new, or because there aren't a lot of devotees of them. I posit that the reason it hasn't been tried at scale is that every attempt to scale it up breaks down as soon as you get more than a few hundred people.
Marx was a decent economist for his day, but had no understanding of human nature. An understanding of game theory, had it existed in his day, would have tremendously improved his ideas, I think. In addition, his economic theories have holes you can drive a 747 through, mainly because they seriously underestimate the knowledge component of labor, and the resulting impact of innovation, and completely ignore the value of organization. It's the latter problem that results in imposition of heavy-handed, centrally-controlled economies in all attempts to build communal societies at scale. Since Marx's structure eliminates any reasonable mechanism for self-organization of a dynamic economy, implementers try to paper it over with central committees. Unfortunately, central organization is not only horribly inefficient because the complexity of a significant economy is far beyond the comprehension of any group of humans, it inevitably creates powerful, self-interested elites. That generates resentment among the populace, which provokes top-down imposition of population control systems... propaganda, powerful secret police, etc. -- the hallmarks of the real-world communist state.
It's pretty obvious why Marxism can't work at scale, once you recognize the fact that collective ownership eliminates the ability of the economy to self-organize for efficient production. As long as the economy is small and organization is simple and obvious, it works. But beyond a few hundred people... it can't. Perhaps after we've passed the AI singularity, when all production is automated, and all organization of production as well, then communal ownership will work, and may even be essential. Or maybe not.
I don't dispute that there are regular droughts, but I'm wondering how that helps to find the cause of this particular one. I don't believe there's a 500-year clock mechanism somewhere that is responsible for triggering them.
You misunderstand what "500-year drought" means. The 500 years is a mean interval between such droughts, not a fixed value. It doesn't mean there's some mechanism that causes a drought every 500 years, or even about every 500 years.
Want your language to become the next lingua franca? The first thing you need is a time machine. You have to go back in time and find some culture that is going to become extremely influential and somehow get them to adopt your language.
Features of grammar, spelling, etc. are irrelevant. There can be no better proof than the current widespread dominance of English.
Or as close as they can possibly get, and the H1-B is edging fairly close.
Of course there's plenty of domestic STEM talent, just not for $45K a year with no benefits.
That may well be true... but it's clearly not what Facebook and Microsoft are worried about. The way H1-Bs visas work, the employer has to demonstrate that they are paying their foreign employees as well as their American employees, so the strategy you describe really only works for companies who pay all of their employees peanuts. It's possible, perhaps, that the availability of H1-B employees helps them keep their employee salaries down a little, simply by increasing supply. But I doubt it. Based on my experience it's far more likely that they can't hire enough qualified people at any price.
I mean, seriously, you're talking about some of the highest-paying companies with the most employee benefits and perks. How many people do you know who got a job offer from Facebook or Microsoft and turned it down because it wasn't enough money? And how many do you know who hated their Facebook job so much they wanted to escape from it? I actually do know a few people who found the Microsoft culture so toxic that they wanted to leave, but I hear that's changing, and in any case I don't see MS having enormous retention problems among their non-H1-B employees... and they have to treat the H1-Bs essentially the same.
I don't follow the argument that more H1-Bs are needed to provide jobs to Americans, and I'm sure that there are lots of companies that abuse H1-Bs in exactly the way you describe, but Facebook, Microsoft, Google, Apple and other such top-tier US engineering companies are not among them.
Hmm, I didn't realize s-m-o-o-t-h was an accepted spelling of "blurry".
What are you talking about? Smoothing text with anti-aliasing does make it blurry, but that's the whole point of high-resolution displays... you can get truly smooth curves *without* anti-aliasing. High resolution displays are the polar opposite of blurry.
goose-incarnated mostly covered why your suggestion is bad, but I'll add one more point, which I discovered after making your argument 20 years ago:
It doesn't work. Mixing tabs and spaces correctly is complicated, so it inevitably gets messed up.
Which only matters if all indentation, including alignment, is done with tabs. The moment you throw in a few spaces to line something up on a non-tab boundary (say, to align a second line of arguments with the first argument), then you have a mess, unless your tab width is set to exactly the value that whoever touched the code before you set it to.
And here is what you are doing wrong. Tabs are for indentation, spaces are for alignment.
Yes, I used that argument 20 years ago, too. It doesn't actually work. People mess it up way too often.
I've been coding way too long to care about indentation bullshit anymore. If a file does not have uniform indentation style, reindent it with a standard tool (*), and then commit the reindent-only change to local git.
Absolutely. Lately, clang-format has become one of my favorite tools ever.