https://en.wikipedia.org/wiki/Trickle-down_economics means something different. "Creating jobs" is not "trickle-down economics".
1,633 karma · joined June 7, 2013
This is your expected outcome when you are wealthy.
"Which brings us to the most important question still facing Project Ara: what the hell kind of modules are people going to build? Woolridge and his team took their user research to the Mobile World Congress conference in Barcelona in February, where they started showing it to potential partners: carriers, tech companies, fashion brands, everyone.
Turns out they all have ideas. Better speakers, flashlights, panic buttons, fitness trackers, projectors, app-shortcut buttons, kickstands, a million other things. Some are incredibly high-tech—pro-level cameras clearly fascinate the Ara team, and they all get excited at the idea of replacing my hideous tape recorder with a microphone module—but some aren’t. Bertrand shows me a small compact case for storing makeup, and a small hollow pillbox. They’re also building “style” modules, which don’t do anything except look nice. Apparently, when given the opportunity to make anything that plugs into their phone, people come up with some pretty useless ideas."
> It's not that "many" of the components aren't available, it's all the components anyone cared about. It seems like you won't be able to swap out the CPU, GPU, RAM, battery or screen.
The article addresses this directly:
"After lots of research and testing, they made a big decision: rather than turn every single piece of the phone into modules, from the processor to the RAM to the hard drive, they’d consolidate all that into the standard frame. They found that people don't care about, or want to think about, the processor in their phone. And they especially don't want to worry about it being compatible with all their apps. Users just want a good phone with good specs that does all the basics well, and then they want a place to play on top of that."
They did the research. It turned out that people didn't care about those components after all.
If you think your research is better, build the product.
> No, I'm not, but clearly old-style permissions could have been reimplemented as forwarding calls to a new-style API that returned blank data if the user chose blank data for that app's permission, just as privacy mods for rooted phones have already done.
Not only is this clearly possible, and a good idea, but it is also pretty much exactly how Android implements it. If you don't use the new API, you'll just get blank data.
I've never used the app you're talking about, but it sounds buggy to me.
I distrust me by default, and you should too. Humans cannot write correct code, and the way to keep high code quality is to maximise our ability to fix the errors that result from having humans involved. I don't want me submitting any code that hasn't been looked at by another person. While I do (almost every day) manage to write some CLs that get approved without comments, I definitely have many CLs every day where somebody will say "This is confusing" or "There's no test for this part" or "Here's a better idea that I had".
If your team members are engaging in passive-aggressive abuse then you should find new ones, not try to do your job without interacting with them.
A person of the same experience level as me will routinely find things that I missed, just because they didn't spend two hours writing the code and are taking a fresh look at it. The same thing is true of a person more junior than me, if we can make them not be shy and write comments like "I don't understand what this does, therefore it is too confusing". No reviewer guarantees code quality, because nothing guarantees code quality, but my experience is consistently that 1 reviewer is a massive improvement over 0 reviewers, with marginal improvement based on reviewer experience.
The true cost of not doing code review is that your code will be harder to maintain in future, giving continual costs for its entire lifespan. The only code I consider to have a cost/benefit ratio that makes it worth skipping the review phase is code that I don't intend to keep for very long.
I am very carefully not going to comment on this beyond linking to public documentation on the issue. This article appears to claim that sites which aggregate links for the purpose of displaying ads are not banned by Google's policies. Here is a link to the policy on such sites:
https://support.google.com/adwordspolicy/answer/6020954?hl=e...
The "Low Value Content" heading is the most pertinent one.
A passenger said they were too sick to fly, so the plane went back to the gate. When it reached the gate, the passenger changed their story and things got more complicated.
The law enforcement agent quickly cleared it up after arriving.
Looks like all the staff here did the best they reasonably could do with the information they were given.
Possibly the most important detail here is one they call out explicitly in the article: this is the first time anybody's run a large scale experiment of this form which was not based on selecting candidates who were likely to benefit highly from receiving the extra money.
I am completely convinced that giving people extra money can cause a permanent, substantial increase in their income and living standards, if I get to pick the tiny fraction of the population who receive it. That's well-established and easy, and also not viable as a long term solution.
I really want to see if it works the same way when you aren't selecting the best candidates, but just distribute the money blindly. No matter what the answer is, this is really important research that will drive economic policy decisions. We're about to get the answer to one of the biggest economic policy questions of our time, and that's awesome.
I recommend reading page 2 of the paper, which discusses the specific set of features that XRay offers. How do I get perf or DTrace to give me the six things listed there? I can only think of ways to get a couple of them.
There is no need to add more researchers; we can't fund the ones we already have. Efforts like the one you describe are demotivating people from training in a function that we don't need more of, which is a reasonable thing to do.
The lesson that I take from this is that saying "no" to people who want to build a bad idea isn't sufficient, because it's just pitting your energy against theirs. You need to lick the chocolate by building something that is good enough to remove the incentive to build the bad idea, without replicating its worst flaws.
I should have built the damn thing myself.
Building reliable services out of unreliable dependencies is a part of what we do. At the lowest level, we're building services out of individual machines that have a relatively high rate of failure, and the same basic principles can be applied at every layer of the stack: make a bunch of copies, and make sure their failure modes are uncorrelated.
You're probably confusing us with the US, which has some constitutional guarantees.
The reasons why this happens are complex and difficult to debug. Please contact your ISP and ask them to pass the details of the problem on to us.
All you're really doing here is observing that the 3.6bn poorest people are really poor.
This does not support your statement that "the 1%" owns more than the rest of the world.
However, that statement happens to be true. If you look at the Credit Suisse wealth report that those oxfam figures are cherry picked from, you'll find that the 1% (globally) comprises about half the population of the US.
It's you, in other words.
I can't tell you about other companies, but ours is pretty straightforward: you tell us what your strongest areas are, we'll give you interviews that line up with those areas. There's no strict guarantees and you should expect a spread of different questions, but whatever it is that you're good at, expect us to offer you a chance to show us that you're good at it.
It's probably only a useful technique at companies which are big enough and flexible enough to find a use for you, whatever your skill set happens to be. For a company that only has one job opening and needs a specific sort of person to fill it, this sort of pick-your-interview-subject approach doesn't help them.
(Trick questions are useless: they primarily serve to make the interviewer feel clever, not to demonstrate the abilities of the candidate)
You did not have a phone screen. What you are describing is the initial contact with a recruiter, to establish what roles you're interested in, explain how the process works, and arrange dates. Had you proceeded past this, you would probably have had a phone screen next, which would be with an engineer giving you a technical problem to solve.
I also rated myself 4-6 on most categories, and was hired; that's an entirely reasonable score on the scale they give. I don't know what happened in your conversation with the recruiter, but it sounds like you made it clear you weren't interested and that was the end of it.
There is a very direct relationship to consider here, because the consumers and the workers are often the same people. If one worker takes one week to manufacture an item which that worker is not willing to buy at a price of one week's wages, then they should not expect to be able to make a living from this.
What unions can do - and frequently have done - is raise the minimum price of goods and transfer some fraction of this to the manufacturing workers. If this makes the goods too expensive, then the factory closes down because people aren't buying them.
The cost of labour is substantially lower in various Asian countries. That isn't going to change, and you've effectively stated that you're unwilling to accept paying local labour similar rates. The conclusion you should be drawing from this is that the only way to make manufacturing work in this environment is to massively improve the productivity per unit of labour. You need to be getting away from people assembling things with their hands, and towards workers who build and maintain manufacturing automation.
Sadly, when this opportunity arose in the recent past, it was those same unions who tried very hard to block it, and were successful in that goal - manufacturing is still a laborious manual process.
Want to change this? Stop learning how to weld. Learn how to build a welding robot.
On the understanding that I can't tell you any more than what it already says in the paper, the key detail that you're looking for is section 4.1.2:
""" Maglev originally used the Linux kernel network stack for packet processing. It had to interact with the NIC using kernel sockets, which brought significant overhead to packet processing including hardware and software interrupts, context switches and system calls [26]. Each packet also had to be copied from kernel to userspace and back again, which incurred additional overhead. Maglev does not require a TCP/IP stack, but only needs to find a proper backend for each packet and encapsulate it using GRE. Therefore we lost no functionality and greatly improved performance when we introduced the kernel bypass mechanism – the throughput of each Maglev machine is improved by more than a factor of five. """
My understanding is that RPS just steers packets into the Linux TCP stack. Nothing on the maglev machine wants to process the TCP layer; that workload can be distributed over the backends.
Well, it's "not new" in the sense that this system's been running google.com for about 8 years now ;)
This is just the first time that we've published how it works.
No.
Edit: expanding on this a little, it's not something that's been released so we can't talk about it. I don't think I can comment on "illumin8"s proposals other than to say that I'm pretty sure they don't work here.
It's certainly a very good idea to serve as much of your content from cache as is possible, and I don't think anybody would be surprised by that statement. However, they still have the same amount of page generation code, they're just running it at a different time. I'm not sure I'd call that "no back end". I'd call it an interesting choice of tradeoffs to optimise query latency.
The problem with results like "ego depletion" is that their utility is fuzzy at best. With no clear application, we don't have a body of practical results using it.