python has this now after 2.5, iirc. it's handy when you want an unbounded calculator =D
HN user
hedgie
a friend dated someone who was a new lawyer and tried representing him/herself in a divorce. after crying on the stand it did not end well.
Google glass is an interesting idea that conflicts with basic tenants of psychology. Facial recognition and attractiveness are critical to how we interact with others. This drive is so powerful that glasses used to correct vision are replaced by lenses that touch your eye, or aren't worn at all.
People would rather have plastic TOUCH their eye with somewhat rigid gas permeable lenses than mar their facial appearance with glasses. My eye flinches when I move my finger towards it and I still jammed contacts in there for years. The association of our facial appearance with our social identity is so powerful that we readily choose it over vision or comfort and pay more to do so.
Google glasses sound awesome, but the psychology against shit like this is powerful. I'm glad they're spending the money on it, but without some serious money invested in overcoming these psychological hurdles they won't go far.
who wants to drink from the FIRE HOSE?
so the counterargument is that the opportunity cost doesn't exist because the hypothetical MS grad earning more is bad at managing money?
no serious person writes native code that vulnerable to timing attacks. if native crypto code has a measurable difference in execution time for different code paths that usually results in huge security advisories, patches, and it's against openssl a published paper. if the native code is written with constant time taken for all execution paths then by definition a timing attack is not possible. even if they are very close in execution time the timing attack is much more difficult, if not impossible.
timing attacks are only easier against native code written by people who don't know what they're doing, which means they made different execution paths take variable amounts of time, didn't examine the generated assembly by a hardware expert, and didn't bother to mask the crypto operations with proper noise generated using a cryptographically secure prng.
a timing attack doesn't require constant duration for execution paths in the code. even with the noise in server communications remote timing attacks are often feasible - the noise filters out when you up the number of measurements or use the statistical techniques most modern side channel attacks rely on.
remote timing attacks contain noise by default, as they rely on server communications passed across a network with latency instead of examining the hardware directly to determine execution time. if you compare the network latency to the cache timing you'll find the noise is actually pretty fucking substantial.
a timing attack relies on a average difference in execution time between two paths of code. certain noise isn't going to protect you - for example, if everything on average takes 200ms longer, the average difference in execution time is still there.
>That point of yours actually points to a potential vulnerability in server-side (possibly native-code) encryption, not client-side encryption, which we discuss here.
...it also relates to the time it takes to generate a response from the client, server was just a specific example. side channel attacks are extremely flexible. the only reasonably secure crypto code is code that executes in the same amount of time no matter the execution path.
lastly, if you're using protocols to prevent mitm attacks, you've already reached a level of sophistication where you may as well just throw javascript crypto out and use a real crypto package. if you're not using those protocols the information is basically free and you shouldn't add any crypto because that might mistakenly convince people that they're secure.
timing attacks don't necessarily need access to the actual machine to work. his point is valid because a side channel timing attack may arise from the differences in time it takes to receive a response from the server. there are remote timing attacks that take advantages in the differences in execution time between paths in the code. this means anyone observing message traffic may be able to execute a side channel attack, instead of just people with access to the hypothetical backdoors you mention.
you are saying not safe as if the term has a standard meaning across all contexts. anything can be cracked - the question is whether the time it takes to crack a computer is worth it compared to the data stored on the computer. in almost any case you actually need cryptography and it's not just a nice to have (aka credit cards, personal information) it's not worth using anything but native code.
a timing or voltage dependence on the key used for the encryption/decryption is often exploited by side channel attacks. this dependence can be used in some sophisticated attacks to reduce the key space dramatically. c and asm/microcode are close enough to the hardware that the operations let you analyze potential side channel leakage. for instance, if i look at the generated assembly it's possible to reason if the time/voltage used by the decryption operation is a function of the key used in the decryption.
when a virtual machine is introduced the just in time compilation itself may introduce these dependencies between timing/voltage and the key used in decryption even if the source code does not appear to. however, unlike in c, you can't just go examine the compiled assembly to ensure a timing attack wasn't added by the compiler. the actual native code becomes a function of the virtual machine installed.
the guy above you knows what he's talking about.
i have no idea why you're being downvoted. auto and avionics companies go through hell to test this stuff at a level that involves the hardware and how it integrates with the software. this just doesn't happen in most software companies.
this is much more than a software problem. i've heard of people verifying opcode behavior on avionics processors to determine the correct implementation of the hardware - when your software relies on it it's fair game.
i don't doubt that google could do this if they made it a priority. but it's a huge issue that encompasses more than a "software algorithm." if the collisions sensors degrade over time doesn't matter if the software works.
my father worked full time while receiving his phd in the professional field he was employed in. he has had a very successful academic career. his dissertation was no joke and he has advanced much further than others from more prestigious universities.
i don't understand this mindset and the fact it exists is why i would never go back for a phd (pure math phd drop out). this is why so much research ends up being inapplicable garbage that doesn't advance a profession so much as hit the current vogue in academics. half the shit i saw pushed the current boundaries of human knowledge further away from anything applicable, interesting, or worth spending 6 years of your life on.
the most annoying part about being a type I diabetic is hearing people who haven't even looked up the basics of the disease rant about diet or corn.
I'm very lucky to work in a place where they understand the limitations of this policy.
Most of the product we work on (not a CRUD app) is finished or at least at a fairly mature state. But the area I work on is not. For a while they harped on us about following the process. But due to their lack of interest on what we were doing and some managers protecting us, we ended up able to make rapid changes in response to test failures, often several times a day.
It was incredible. They would seek investigations through change requests on bugs found in testing. Immediately after they were entered - before the change request even went to the overseeing group of project engineers and subject matter experts - we would tell them what caused the problem and write that we had committed a fix to the mainline. This circumvented days of waiting for a response that would have blown our schedule apart.
It paid off big. Today for the first time our tests all started passing. They've been failures for years and no one expected anything close.
There's a time for process. When a lot can break or you have a finished/safety-critical product you want to lock it down. But in initial development of new features, you have to throw it out and do what's right.
For a while they were demanding change control with CRs over software that had never been written or run successfully. Why even bother writing the CR if it never worked in the first place? That means the software wasn't done in the first place, not in a state requiring change control!
It was unusually rapid iteration between the test and development teams, who should sit next to each other and immerse themselves in making the software work. Only by rapidly uncovering and overturning problems like this can you ever get something close enough to stable to lock it down this way.
Development and test respected each other, understood what had to be done, and by working together discussing behavior and the test environment were able to determine what the software should do and how best to test this functionality.
There were times where waiting for the process would have taken us 5 days to get approval to fix a bug. By talking with our project engineer and going ahead with the testers - who realized it was not the time to stick to formal process - we were able to succeed.
I'm very lucky. The testers were cool and understood the state of the software and were willing to shout across the cube and explain what was failing. We worked together and managed to succeed by knowing when a process was important and when the managers would be happier to go around it.
The problems encountered here are mainly about people. We had testers and others who trusted and worked with us. When you don't have that - like the author of the article - it takes some social engineers and lawyer like knowledge and parsing of company policy to get around the problems.
i consistently ask myself how the fuck IBM sells anything to anybody.
maximizing salary is exactly what the study looked it. the approximation of finance = top salary is less accurate than the data they used.
i'm not sure that's true either. remember the study is comparing people who could have entered an ivy but didn't with people who did get into an ivy. since state schools admit more people with lower rankings who's to say that the smooth entry in high finance is due to the degree? it could be the ability of the person who got accepted to the ivy that makes the difference.
it may be more difficult at first, but an terrible ivy educated quant isn't gonna stick around very long. and a good state school educated quant may take longer to get in but eventually get there anyways. which is what the study actually suggests.
this is odd in finance since the real measure of someone in that field is revenue generated. no one cares you went to podunk state if you outperform everyone else. i know someone who's absolutely brilliant with a math phd from a state school that is working as a quant now. now that he's in his career is gonna be determined by revenue generated, not the degree on his wall.
you can't really control for a financial job salary either. they're heavily based on bonuses and hence performance of the trader. if they are making bank it's likely related to the natural ability that got him into the ivy in the first place. which is the same level as those people who went to a state school that were followed in the study.
like most fields, the people at the top of finance make disproportionately more than those in the trenches, who are not rich by any reasonable definition. if you worm your way up in a traditional company/create a successful product the same imbalance in pay exists. but for finance, we judge salaries based on the top performers, where as for engineers we tend to think of the average.
not sure that's the case.
"Here, however, is what was explosive: Dale and Krueger concluded that students, who were accepted into elite schools, but went to less selective institutions, earned salaries just as high as Ivy League grads. For instance, if a teenager gained entry to Harvard, but ended up attending Penn State, his or her salary prospects would be the same.
In the pair's newest study, the findings are even more amazing. Applicants, who shared similar high SAT scores with Ivy League applicants could have been rejected from the elite schools that they applied to and yet they still enjoyed similar average salaries as the graduates from elite schools. In the study, the better predictor of earnings was the average SAT scores of the most selective school a teenager applied to and not the typical scores of the institution the student attended."
there's a guy at work with a phd in math from princeton. there are plenty of people with his job title that didn't spend all that money to get there. most of them went to the great in state engineering school and spent far less money for the same result.
http://www.usnews.com/education/blogs/the-college-solution/2...
i hated math when i entered college despite having passed the AP calc exam in high school. i didn't see the point and couldn't understand why i was learning about functions. i had no idea how to even think about the subject beyond what i had been told to memorize.
the second semester of my sophomore year i decided that my interest in computers and desire to have a job lead to me changing my major from psychology to computer science. i signed up for calc II as my first college math class and felt exactly like you did, getting an A+ despite not having taken math for almost 2 years.
i hated high school math because it felt like pointless memorizing of stupid facts. i loved college math because it was about describing and reasoning about these conceptual objects and i didn't have to memorize a thing if i could just remember how to derive it. they explain how to think about these objects, and once i understand the framework behind the subject i enjoyed it much much more.
the fact they were reasoning, explaining/proving why the math worked, and presenting the logic behind their thinking was enough to make me love it. i went dual math/cs and eventually got a MS in pure math.
i agree completely.
that's a good point.
at my large company i do this every day on the embedded system i work on, which luckily is not a CRUD app. i guess i would hope they would ask me about that XD
databases can get tricky. but you're right, if something complicated like a bloom filter is used to solve subset-query it's probably in an third-party API they grabbed somewhere that handles most of the difficulty.
that formula narrows it down pretty well once the constants are defined and takes about a minute to determine. with more time than is found in a typical job interview you could actually go much further.
the real criticism of the question is that the real skill they're trying to test is better determined by directly asking about Fermi calculations relating to computer software and hardware.
the golf ball question could be interesting in it's own right, but it's asked in a context where additional information to optimize the solution is not available and an optimized solution couldn't be determined due to time constraints. hence the formula sucks and you end up simplifying it with fudge factors that only demonstrate that you are able to use basic algebra to model the volume of a bus and a golf ball.
see:
http://en.wikipedia.org/wiki/Sphere_packing
there are numerous practical reasons you would want to solve this problem. for example, say you work in an orange factory. you want to pack oranges of radius n. perhaps you would like to determine and minimize the amount of shrink wrap you have to stretch around them for transport, or keep track of the materials cost for accounting purposes.
that's essentially the same problem and uses the same formula, you're just solving for the dimensions of the container instead of the number of golf balls. you can save a lot of money minimizing the wrapping material if you pump out hundreds/thousands of packed oranges a day and choose an optimal packing.
alternatively, if you have to ship it in a non-optimal packing like boxes, perhaps it's good to calculate the materials cost to pack your product to estimate future expenses.
that article lists other problems where sphere packing is integral to the solution. just because an application doesn't seem obvious doesn't mean there isn't one.
if someone honestly expected me to challenge this interview question without understanding how it could be useful i would rather not work there. people have been studying this problem for practical reasons ever since they had to stack cannonballs for transport, it's not exactly a contrived example.
that may be an unfair assumption on my part. i just assumed that when people ask these abstract riddles, they're really looking for some way of testing your intuition and not something this mundane and boring.
it really boils down to basic algebra with some constant fudge factors. meanwhile, cs people have a host of sophisticated tools to estimate asymptotic behavior for the worst, best, and average case, or error bounds on solutions to NP complete problems as a function of the number of iterations of approximation algorithms, or trade-offs when certain pre and post conditions on the data influence the run-time of canonical algorithms (think searching).
the basic toolset of computer scientists is so advanced i guess i'm shocked anyone would ask such a relatively simple problem when there are much better ones out there.
well, pg is some dude defining identity on a blog, and the people i mention are famous scientists who quantified personality and isolated introversion/extraversion using a statistical theory with predictive value. this theory explained the behavior of dogs that Pavlov had noted in the fifties. the preference was eventually linked by Eysenck to levels of cortical arousal.
whether you consider it part of your identity or not is moot since introversion/extraversion still defines a consistent set of reactions to external events.
the article is wrong on every level. introversion has nothing to do with confidence. i speak very confidently when i want to. i was an excellent ta and can present on subjects clearly. in the course of my studies and career i have had several people tell me that i was the only person who could clearly explain complicated mathematical concepts to them. i enjoy talking to people and discussing with them.
i am still an introvert and have a preference for isolation that is consistent in my reactions to external events. this preference does not determine my reaction to all events. how introverted i am is a measure of the consistency of my preference towards solitude. i like talking with people - i just don't like it all the time.
i'm sure some people don't consider them introverts or extraverts. they usually fall on the middle of the scale, with no distinguished preference towards either category. however, their existence does not disprove that other people have strong preferences towards introversion or extraversion.
I often do ask at least one of these questions on an interview. I don’t do it because I care about a precise answer or whether you know the exact dimensions of a golf ball. I care simply because if you can’t do Fermi calculations, you can’t make long term architectural decisions. You’ll build a system which handles 2x today’s load very nicely and which I need to replace in 2-3 years, or you might overarchitect a system which can handle 1000x more load than I’ll ever need.
...why not just ask a question about building a real-time monitoring system itself and judge the responses there?
i would never pass this test. i would solve this problem using variables for dimensions of the bus and a constant "packing factor" (or assume the optimal cannonball packing and approximate the golf balls as spheres) and write an express formula for the solution. then i would substitute in various constants for the dimensions and adjust the packing factor to find a range of solutions.
the problem with the question is they want an intuitive solution. giving them this formula and evaluating for a range of variables would just piss them off, but it's the best way to approximate the answer of something that poorly defined.
seeing as personality is defined as a preferred set of reactions to external events, your preferred style of social interaction is part of your identity by definition.
this is shorthand for saying "I prefer alone time to recharge" or "I am energized by the company of others," which is a fundamental aspect of identity.
factor analysis of personality breaks down personality into related sets of consistent behaviors. introversion/extroversion exists in even the simplest model. the distinction was first noticed by Jung. it was even observed in dogs by Pavlov, who found that dogs that were active around other dogs fell asleep when left alone, where as dogs that seemed exhausted by the same events perked up when isolated.
introversion/extraversion is not a constant preference. sometimes introverts like parties. but individuals have a preference for one or the other that forms a preferred set of responses to external events, which makes it part of the definition of personality.
this is an article based on folk psychology written in ignorance of thousands of articles on this subject, starting with Jung, experimentally noted by Pavlov in animals, and made rigorous in the work of Hans Eysenck. Eysenck used factor analysis to rigorously define extraversion and identified it as a basic dimension of human personality.
this is an incontrovertible finding of modern psychology. extraversion/introversion form one of the parts of the five factor model, which uses factor analysis to identify five core factors of human personality. some models have more, some less - that's the art of the technique. but they all have introversion/extraversion.
there is a distinction between shyness and introversion, where the former is mostly likely meant to mean socially anxious. however, introversion is an enduring personality trait that factor analysis consistently identifies.
you should see the crazy amount big companies spend on IBM tools. people pay big money for clearcase.
licenses for clearcase cost enormous amounts. yet clearcase is missing many of the features found in open-source (and free) distributed version control systems. meanwhile, there is no free alternative to the routers, which may actually be necessary at some of the installed locations.
this doesn't include the huge server costs to run clearcase after you buy the license, which aren't necessary for distributed version control systems like git or mercurial. and big companies often spend more money buying other IBM tools to integrate for which free alternatives exist...
the amount of money spent on this purchase is fucking peanuts compared to what many large private sector companies spend on IBM software that lacks most of the features found in your favorite open-source alternative.
consider this statement politically agnostic, but military spending is the closest thing we have to govt subsidized R+D in this country. there several enormously useful and successful military inventions that no commercial company would have touched.
gps and the internet are two of the most notable and visible examples with astronomical infrastructure costs. no private company would undertake a risk like this yet both have substantially improved society. the microwave and digital cameras are two others that a private company may have eventually created.
this isn't an argument for military spending, just the fact that without a government body that focuses entirely on applied research and development the military is the next best thing.
aleph-null? what the fuck?
"You're completely wrong. College doesn't even get close to teaching the state of the art."
encryption is basically pure math. if you don't have a solid understanding of graduate level math you can't even follow the state of the art. knowing how encryption is broken takes EVEN MORE, with advanced statistical methods being added to the mix.
"state of the art" encryption is really decades (or century) old mathematical problems. shit like padding is new, but the core of the algorithm has been studied for years by mathematicians - the fact they haven't solved it in that long a time is why we even use it for encryption
"And the really state of the art stuff- you don't get in college anyway as an undergrad and if you're a graduate student you're reading the same things that people doing it on the job are reading."
wrong. you can't even read the mathematical definitions of some encryption algorithms without graduate level courses.
i work with people who are "experts" in the area and have been doing it for 20 years with an engi background. due to never learning the math i have to translate for them and i'm horrified at the shit they end up doing. they don't know why or how the algorithms work so they end up picking the wrong ones for the wrong reasons or implementing them in insecure ways.
anything that relies on pure math this much (like algorithms for stock trading) isn't something you learn on the job.
he had graduate level training in number theory at oxford, which is the basis of public key encryption and the algorithm he invented. it's not an edge case, it supports that you can't skip graduate level training and do this work.