How To (really) Trust A Mathematical Proof - <AUTHOR> http://www.sciencenews.org/view/generic/id/38623/title/Math_Trek__How_to_(really)_trust_a_mathematical_proof <comment><USER2> The mention of the Russell-Whitehead proof brought back memories. It's from Principia Mathematica (same title as Newton's book, but it's a different work.) Here's a representative page:

[http://quod.lib.umich.edu/cache/a/a/t/aat3201.0001.001/00000...](http://quod.lib.umich.edu/cache/a/a/t/aat3201.0001.001/00000401.tifs.gif)

Look at the last line of 54:43. Then look at the page number. This isn't a joke. It's really how bad axiomatic mathematics is.

During my last year of high school and first year of college, I was fascinated by this stuff to the point that I couldn't think about anything else. After digesting Peano arithmetic, I moved on to Zermelo-Frenkel set theory (the "set theory" that we normally use is self-contradictory and therefore meaningless to a mathematician.) I worked through Godel's incompleteness theorem. I tried my best to understand non-Euclidean geometries. And a bunch of other stuff that I don't even care to remember now.

Soon, predictably, it started affecting my health. At that point, I broke down and gave up that shit for good. The stuff I do today is positively quotidian by comparison. But it makes me happy. Even now, I'm occasionally uneasy about living in a universe where we don't know (actually, _can't know_ ) if the continuum hypothesis is true or false. But I shove the thought quickly from my head.

The point of all this is to tell you guys that unless you really know what you're getting into, don't think too deeply about the meaning of proof :-)

<comment><USER3> In our actual, factual physical universe, the Continuum Hypothesis isn't so much "true" or "false" as "irrelevant". It's possible the universe is fundamentally discrete, in which case it just doesn't apply to anything physical, and even if it turns out to be continuous in some sense, it's likely to be some hybrid continuous/discrete combo where the hypothesis still doesn't apply to anything physical.

(One of the points made in Reflections on Relativity ( <http://www.mathpages.com/rr/rrtoc.htm> ) is that both a continuous universe and a discrete universe, taking the traditional senses of the term, are logically contradictory things to build a universe out of, and Einsteinian relativity calls for an odd mixture of both. No clean link to a single page as, IIRC, the point is made over a series of sections, culminating in a unique (AFAIK) discussion of Zeno's Paradoxes, which I _can_ link to: <http://www.mathpages.com/rr/s3-07/3-07.htm> although you really need to read the sections before that for full impact.)

So, sleep easy. It is nothing more and nothing less than a choice of axiom. The axiom of choice is similarly irrelevant in the real universe; since use of the axiom calls for the selection of an infinite set from another infinite set, possibly uncountable, it has no particular connection to the real, finite universe.

<comment><USER2> That makes sense, and it's likely that if I read through the entire book that you linked to, I'd grasp it pretty clearly. But it was certainly out of my mental reach as an 18-year old. And believe me, I tried.

In general, it appears that our ability to ask philosophical questions, especially of the mathematical variety, far outpaces our ability to find answers or even _comprehend_ answers that others have come up with. It is highly plausible that this is linked to the disturbingly high occurrence of depression, bordering on mental illness, among mathematicians. (I know enough mathematicians personally for that observation to have some statistical validity, but anyone who has read many biographies of mathematicians should get the sense of it.)

What I'm trying to say is that while many of the questions of mathematical philosophy pique our curiosity greatly, and it can certainly be a rewarding experience to get a taste of the beauty of the field, everyone should have a mental threshold for how much they are willing to get involved. Perhaps this is obvious to other people, but since it was a painful lesson for me, I feel obliged to share it :-)

</comment></comment></comment><comment><USER4> "There is no permanent place for ugly mathematics"

-G.H.Hardy

I loathe these automatic proof systems (at least the state of the art today) - I think they may be useful for verifying that a complex CPU correctly implements integer arithmetic - but these proofs have little to offer a human mathematician. Let's follow Paul Erdos who said "one need not believe in god, but a mathematician should believe in The Book" The Book is where god (the supreme fascist) has collected the shortest and most elegant proofs in mathematics. Here's a great book written in this spirit (dedicated to Erdos) -

<http://books.google.com/books?id=KvQr9l0wgf8C>

when a theorem prover can produce a proof as elegant as as the one given in this book of say sperner's lemma then I'll give them another look. (No disrespect to Russell or the creators of these programs is intended, of course)

<comment><USER5> I don't agree.

Lots of proofs are irreducibly ugly, even when the idea behind them is simple. Just too many edge cases and details. Automatic proof systems can avoid this.

I think of it much like garbage collection and higher order functions. The machine code of a garbage collected program might be messier than a manually managed one. But python code is prettier than c code.

<comment><USER4> you have strong point - i hadn't thought about it this way before. Just the other day someone called me out on a derivation and i spent a couple of hours writing out a very tedious proof. there were lots of special cases and i really resented the bastard when i was done. the experience was very much like filling out IRS forms. it would have been very nice to have a proof assistant to back up the points where i would have much preferred to handwave. I really like the comparison to manual memory management that's exactly what this proof felt like - freeing the mallocs.

but think about the following two situations: (1) you have serious doubt as to whether a statement is true. presenting a proof removes all doubt. Computer proofs, no matter how ugly, are a win for this situation (2) you have overwhelming experimental evidence that something is true and you want a mathematical proof to help you understand _why_ it is true. Computerized proofs are less helpful here - this is where you want an elegant and simple proof. it should be very intuitive how the result depends on the assumptions. it should be something you'll be able to remember when you're 70 years old.

<comment><USER5> I actually suspect the second situation won't happen for a long time.

My guess is that we will instead have proof _assistants_. Basically, what will happen is that a human will come up with the big idea which motivates the proof, and will direct the proof assistant through the details.

I'm thinking something along the lines of Isabelle or Coq + ProofGeneral, except of course much better.

<comment><USER6> Or more along the lines of Computer Assisted Chess.

A person assisted by a computer can play better chess than any human, and also better than any computer.

Maybe it will be the same here.

</comment></comment></comment></comment></comment><comment><USER6> "Most of what you learn from a textbook is in the exercises"

That explains a lot ....

Too bad no one told me that back when it mattered.

</comment><comment><USER7> "A proof is a repeatable exercise in persuasion"

\- Couldn't track the source. Shucks.

Computer proofs have their value, but so far it is mostly in determining whether a proposition is true or false. One still needs a mathematician- written proof to get insight into the problem. This is unlikely to go away anytime soon.

Furthermore, for most important unsettled problems in maths, we already have a very strong inkling that the statement will turn out true/false. Dramatic surprises in maths are very, very rare. Gödel's incompleteness theorem is the only one that comes to mind.

</comment><comment><USER8> The "library of foundational proofs" sounds a little like this graph of hyperlinked theorems online: <http://us.metamath.org/mpegif/mmset.html#overview></comment>


Full Disclosure: The Internet Dark Age [pdf] - <AUTHOR> http://www.politaia.org/wp-content/uploads/2013/12/Full-Disclosure-NSA-GCHQ-Hacks.pdf

<comment><USER3> I just read through the whole document and it felt like someone was narrating a bad infomercial. It takes 30 pages for the document to get into the technical bits and then the research (and mitigation!) methods feel somewhat half-hearted.

1\. The "fix" is to log in to the system and _manually disable at runtime_ the VLAN and firewall rules. Nothing is said about making the fixes permanent - <USER2> if the authors have never experienced a wedged modem or router. Or had their power go out. (Perhaps they assume everyone has an UPS in place.)

2\. The presence of extra VLAN is clear, that's true. I would have wanted to see redacted traffic dumps from a controlled lab network, where the authors actually show that the device attaches to a known VLAN. Right now we have nothing but their inference about egress firewall going up shortly after device boot.

It looks like a real deal. It's just presented in a way that puts me off. I'm waiting for external confirmation and more technical data.

<comment><USER4> From the terminal sessions, it seems like they're basically describing an IP management interface for a unit that is presumed to be doing modem only (have no IP), and characterizing things in the most sensationalist way possible.

Of course the default gateway is close - it's the next IP hop. If it's indeed being used as a NSA/GCHQ backdoor, the actual attacker is at a different address.

Traffic snooping is surely much easier to implement upstream, and your ISP is indeed upstream of everywhere, despite what this paper alludes to.

As far as a branching off point for attacks on your network - given that this seems to be a modem-only unit, there's still your router between it and your local network. It seems that its attack surface remains the same as for a dumb PPPoE translator.

edit: Actually they could be describing an entire modem+router combo, but an error in saying the lan PC initiates its own "PPPoE" request threw me off. The interfaces look like a multi-port router (in the one's I've seen, the CPU usually has one ethernet interface which goes into the port of a vlan-capable switch). Really, the lack of showing what the complete config looks like when the user's PC is online makes it hard to see what they're actually getting at.

The only actual suspicious thing presented here is the specific 30/8 IP address, and perhaps that has another explanation (address reuse?). Independent verification is needed, but _definitely_ not using their flawed "Method 2" which clearly changes your modem's complete setup :P.

</comment></comment><comment><USER5> I read the whole paper, and it doesn't at all look like the "real deal".

No actual evidence in the form of malware samples (after exploitation of the netwrok), detected "duplicate" certificates or whatever is provided. Not even network captures of any MITM traffic going to the hidden VLAN.

The only "evidence" provided was the presence of the hidden VLAN, which got assigned some 30.x.x.x IPv4 addr via DHCP.

This could simply be some internal management VLAN of the ISP. As the author had stated, the ISP installs updates remotely. So that's their way of connecting to the router. Regardless of updates, ISPs always have a way of managing their equipment remotely.

A WHOIS was performed by the author, and the address turns out to belong to the DoD. Howerver, it's more likely that since this is a "private" VLAN, this address has nothing to do with internet WHOIS records. It was just made up by the ISP.

The authors getting a ping of 8ms to the NSA/GCHQ, is really just them talking to some local server at their ISP.

Also the described attack on TOR seems completely wrong. No details were provided, but the basic premise looks to be just wrong.

To conclude, this whole paper smells to me of sensationalism and confirmation bias.

</comment><comment><USER6> A discussion of this paper came up a bit in reference to attacks on Tor. It looks incredibly misguided.

[https://news.ycombinator.com/item?id=6887850](https://news.ycombinator.com/item?id=6887850)

[https://news.ycombinator.com/item?id=6888251](https://news.ycombinator.com/item?id=6888251) \-- one of the better comments that explains what the authors probably thought they were observing.

</comment><comment><USER7> You should probably append [pdf] to the title.

<comment><USER7> Thanks!

</comment></comment><comment><USER8> Has this research been peer reviewed anywhere?

<comment><USER9> No big peer review needed - all it takes is a couple of people in GB taking a look at what in blazes their routers are doing.

But to those of us who have heard/known of TR069, we knew that stuff like this would eventually surface...

<comment><USER10> Small point. The devices called out by the authors are not routers, they are MODEMS which are only installed on Fibre To The Cabinet installations. (These modems are then connected, usually, to an ISP-supplied router such as the BT Home Hub or whatever equivalent your ISP chooses to use.)

Fibre installs are by no means the majority or even the standard in the UK. But obviously the general "don't trust your ISP router if you really think the security services are after you" advice would seem to hold good no matter how you're connected.

<comment><USER9> The basic points (TR069, remote-accessible backdoors for "configuration changes" by the provider - greetings and my personal choice swear words to Telefonica/O2 Germany here!) are still valid for DSL connections.

The router is _the_ perfect gateway into your private home network, especially as Windows disables the firewall in a "home network"...

</comment></comment></comment></comment><comment><USER11> Warning. This is a PDF download link.

<comment><USER12> May I ask why this is a problem / requires a warning?

<comment><USER13> PDF renderers have been historically insecure due to the PDF format being a complete mess

<comment><USER12> I see. Thanks for explaining.</comment></comment></comment></comment>


Is latency killing our minds? [audio] - <AUTHOR> https://podcasts.apple.com/ca/podcast/3-is-latency-killing-our-minds/id1510813211?i=1000473654195 <comment><AUTHOR> As a former audio professional, it is plain obvious to me that latency is a major contributor to "Zoom Fatigue". It takes significant effort not to interrupt each other and to compensate for the delay.

The latency would be natural if you were talking hundreds of meters apart. It's not when your interlocutor appears to be be close by.

<comment><USER2> My sister is one of those people who often starts talking while others are still speaking. Skyping with her drives me mad because the latency amplifies the awkwardness of trying to race to the end of a sentence before she interrupts. Because of the delay, she spends half of her part of the conversation starting sentences, then pausing and saying "what?" when others are now already half-way through their thought and now stuttering because she's interrupted at a more awkward moment than usual.

It is very hard to hold serial (versus parallel) conversations with latency, and especially with this kind of speaker, and so I've avoided the whole zoom craze from the get-go.</comment></comment>


The truth about Unix: The user interface is horrid (1981) [pdf] - <AUTHOR> http://www.bradleymonk.com/w/images/9/91/The_truth_about_Unix_Don_Norman.pdf <comment><USER2> Critiquing the usability of ancient Unix was like shooting fish in a barrel. Fortunately, Norman went on to better things.</comment>


Ask HN: What's wrong with all those dating sites? - <AUTHOR> What's your biggest peeve about the state of dating services on the web today and how could they become better?
Is there certain functionality that you think all dating sites must offer?  i.e. location down to postal code or even year/month/day of birth.
Do you think the techniques sites use to reduce/remove the number of spam/predators/trolls go to far and actually detract from the user  experience?  i.e. captchas, super-long/detailed registration forms and surveys/compatibility tests, back-end automation to remove accounts according to preset criteria, etc.
There's gotta be a better way to build this mousetrap. <comment><USER2> I used to work at OkCupid. I could talk to you at length about the ups and downs and ins and outs of online dating, but the moral of the story I gleaned from my time there can be summed up pretty easily:

People just want a _ton_ of attractive/dateable people within a keyboard's reach, and if your site does any filtering on their behalf, people need to trust that it actually works.

Most of the variations in online dating sites focus on optimizing pieces of that. The big guys (Match.com, eHarmony) make sure they get huge user numbers by campaigning on national TV, and they apply some simple internal filters that are 'approved by a doctor.' Smaller sites can't compete with that, so concentrate more on making sure you only run into people you'd actually be attracted to (see JDate). OkCupid's on the smaller side, and focuses on community building (for numbers) and uses mathematically semi-sound calculation coupled with quiz questions to create a user-driven but rigorous- feeling people filter. Basically everyone that's successful fits somewhere in that model.

If I were you, I would focus less on specific features or trying to build a better datetrap. Instead, figure out what it'll take for you to get fifty thousand people signed up, approximately all at the same time, and then how you'll keep the site growing over time. If you get big numbers, the dating stuff will follow (MySpace...).

</comment><comment><USER3> There's nothing wrong with the dating services. The people are broken.

People lie. Solve that one and you may have something. (True.com tried to do this.)

Also, most dating sites act as a sort of amplification for the user's dating filters and skill at attracting interest. However, I believe that most people are lonely because their dating filters are broken, and because they have trouble attracting interest. Dating sites only help these people fail faster and at greater scale.

(Exception: tall women. They are not necessarily damaged, they really do have a sort of search problem that is more solveable at scale.)

I have started to think that a really successful dating site would start from the premise that the user is broken and cannot be relied on to find or choose a partner. Maybe use social networks so that their friends help them find someone? Or even anonymous strangers, for karma points? Straight women do this sort of thing anyway (straight guys tend to use these sites alone) and if a woman gets all her female friends to come on board, that helps solve the female-male ratio.

</comment><comment><USER4> The biggest problem is that the incentive of the dating site is to make money, not to help people get together. If your service is really good at getting people together, boom! There goes your userbase as they all hook up and log off.

Financially speaking it is better to give users the ILLUSION of someone out there being for you, while stringing them along and milking them for as much cash as possible.

<comment><USER2> Yah, this is too true. The worst thing you can do for your bottom line on a dating site is make a real, long-term match. There go two really happy users, and whatever ad revenue or monthly subscription fee they were making you.

But if you don't care about your site making money, this is a non-issue. And if you're growing faster than you're connecting people, it's a moot point anyhow.

<comment><USER5> This seems to be a failure of imagination.

It seems to me that a successful long term match should be your best advertising. But I haven't seen any web sites capture that or use it at all effectively. Or feed it back into their site/algorithm design.

I'm not saying this lightly: I got married about 6 weeks ago to an amazing woman that I met (thanks Aston!) on OKCupid!

I'd be more than happy to do testimonials and such, but no one's ever contacted me.

<comment><USER2> Congrats, man.

OkCupid loves testimonials and was for a period of time collecting and categorizing them for some vague future use as publicity. You should send something their way just in case.

As far as using that stuff for algorithmic purposes goes, I think they mostly are interpreted as proof that what exists is actually working (and thus doesn't need tweaking?). Also, depending on your demographic, certain types of testimonials are less appealing. Not sure if OkCupid is still courting the youngsters, but if they are marriage stories (as awesome as they are) may serve to scare away a profitable demographic, advertising-wise.

</comment></comment></comment></comment><comment><USER6> I think the fundamental problem is that the reason people are on most of these dating sites is because they can't find a date elsewhere. Building a good dating site means solving that problem: making dating online more intuitive than flirting in real life. This is hard, because you've got however many billion/million years of evolution working against you.

On the other hand, there are some groups for whom physical flirting is already cumbersome. Busy professionals/entrepreneurs (arguably above-average dating material) don't necessarily have time to chat up people at coffee shops. People of a particular faith or with a particular medical condition may be genuinely afraid of simply meeting random people. There has been some success with this sort of 'longtail/niche' dating site.

<comment><USER7> Spolsky mentioned jdate on his podcast - dating for Jews as a successful online-only product.

</comment></comment><comment><USER8> how about the simple fact that it doesn't work?

1) In the real world, you compete for the woman's attention only with people she sees throughout her day. Out of which maybe 5 will initiate a conversation.

On the net, same woman, you are competing with every single guy within 50 miles. Out of which almost every single one will initiate a conversation.

2) In the real world, you see the woman as she is.

On the web, you see myspace angles, copy pastes of likes/dislikes. And lets not forget all those bots and guys pretending to be a girl .

3) You gotta remember that if a woman is good looking, there is ABSOLUTELY no reason for her to go on a crappy dating site. Its not like she doesn't get offered dates everywhere she goes.

Same goes for the guys really, you'll have much higher chances if you start asking women in the real world.

<comment><USER9> My observation is that online dating not only works but has by now become totally mainstream. I keep hearing about couples which met on the Internet, in fact I would say that this is true about 100% of the weddings I'm attending this year. It's no longer something that warrants even a lifted brow. My perception may be biased by living in the Bay Area, but even if so, then it's just a matter of time.

This does not mean that the dating sites are particularly good right now, just that the demand is so great that people are willing to suffer the poorest UIs to get to the good stuff.

<comment><USER10> I met my mate on the Internet, but not on a dating site. There's a large difference!

</comment></comment></comment><comment><USER11> Semirecently got out of a long relationship. So long that I was basically a kid when it started and if there was such a thing as a dating site on the Internet at the time I knew nothing about it.

I've not tried any dating sites. Why?

1\. The factors that attract me to a girl are difficult to quantify and encode digitally. But relatively easy to sense in a face-to-face interaction.

2\. I trust my own senses and instincts more than second or third parties when it comes to gleaning truthful information about someone. I am confident in my ability to read people in face-to-face situations. Why put a computer in the middle given that it essentially hobbles that critical ability?

3\. I believe seconds/minutes/hours spent messing around with dating websites would be better spent out in the wild meeting, hanging out with and getting to know girls in person.

4\. I suspect "permanently single" people are disproportionately attracted to these various tools and I'm better off fishing from a random sample to find who I'm looking for rather than a negatively biased sample. Or, ideally, I'm better fishing from a better-than-random sample biased, for example, by people I know and trust in the real world and THEIR extended circles of friends.

5\. I strongly suspect that the hypothetical girl I like is basically feeling the same way and taking the same approach that I am.

Perhaps I'm off-base. And perhaps I will modify my views with time but this is what keeps me away from such sites currently.

</comment><comment><USER12> As my data structures professor would say: "Bipartite matching is a hard problem, specially when it involves women!"

Seriously, though...

IMHO the most successful dating site would probably start off as a Linked In like social network, where you could have matches based on the people you know. Matching algorithms of any sort (like Match.com Chemistry.com eHarmony.com, etc use) could be used to improve the matches, but I think that having a "recommendation" from people you already trust would be a very big plus. This is probably why pre-existing social newtworks like Facebook, MySpace, Hi5, et al usually end up being used for such purposes.

</comment><comment><USER13> Hmmm to be honest nothing screams "Plan B" more than a dating site. Honestly I have never used the service because most of the women I date are from referrals from friends and family. So there's that element of trust right there. Made me feel safer! Maybe if you could build dating site that applies that element of trust. Maybe you could have the said "dater" try to earn some sort of "trust" points. Make it so that the more trust points they have. The better partner they are. This is just off the top of my head though and it worth experimenting.

</comment><comment><USER14> Here are my thoughts on the topic.First in the real world people don't go around with profile info printed on their shirts, and mathematically filtering people based on that information. People in the real world interact and exchange information differently from what most dating sites do. I have a few online female friends(no girlfriends yet though) and I've met6 them all in different online communities. Mostly music sites like last.fm or different internet forums specialized in my favorite music genres. Basically if you want to make a dating site, don't, instead make an online community where people can interact and communicate about a specific topic of interest. Sites that just offer communication(myspace) might have a lot of users, but the users have to search for people with the same interests and stuff. In a specialized community, that problem is solved, and people can just discus stuff they like. In Bulgaria most dating sites are filled with 14-15 year whores who just want some attention, i wouldn't date girls like that, even if they were my age, they are just to boring(boring girl:I like music, and parties, and chatting with friends; interesting girl:dating sites are boring.)

</comment><comment><USER15> Channeling PG for a moment: Make something people want.

I think that on the whole, most dating sites are more concerned with figuring out how to make a buck off someone than what their users want.

If you use Wordtrackers keyword tool which people normally use for SEO purposes and type in "dating"... 4 out of the top 10 keyword are related to free dating sites, but how many dating sites can you name that are free?

I can only think of one off the top of my head (penty of fish) - and Markus is making a killing with his site. [edit: if you take the social networks like facebook and myspace into account, you have a couple more - but the traffic to those sites is less qualified, IE not people specifically looking for dates]

I think that if you can build a decent site (it really doesn't have to be that fancy) that you can run free - I think you would have a better chance at success than simply trying to build more complex functionality and charge people for it.

Make the site simple, make it user friendly.

</comment><comment><USER16> I think the key to a successful dating site is both privacy and safety. Women want to know that they are not going to get raped or be caught off guard with someone who has obviously lied about themselves. If you could establish a method that would allow people to feel secure with the site, it could go miles.

The other issue is privacy. By joining these sites, you are opening yourself up to not only your personality and private information but revealing your real identity online. If people could trust that the information about themselves or the interactions they have with other members would never be made public, I think you would see a surge in rates.

<comment><USER13> Honestly I don't why someone would downmod your comment. I think it plays well with the "Trust" points idea I've pitched a few comments up.

<comment><USER16> Yeah, thanks, I agree with what you mentioned as well. From my experience, people tend to date within their social circles because of those very reasons.

</comment></comment></comment><comment><USER17> simple: girl to guy ratio

<comment><USER18> The real question is - how do you entice more girls to sign up? Girls not only attract guys in to joining (obviously) but more girls as well.

<comment><USER15> I saw an interesting solution to this by the brits a couple years ago.. I think the site was "datemymate" or something to that effect.

Essentially the idea was that the friends of someone would sign up, and then start writing their friends profile - the idea I think was to mimic how women find their friends dates in the real world.

From what I understand, their female/male ratio was very good to the point where at times the females outnumbered the men - whereas on other dating sites this is just not the case.

<comment><USER8> doesn't look like it worked out, stats aren't that good: Started: December, 2005 Total Male Members: 338 Total Female Members: 417

<comment><USER19> I think he probably meant: <http://www.mysinglefriend.com/>

<comment><USER20> MSF's _actual_ advantage is that it's fronted by Sarah Beeny (Americans: she is probably as well-known in England as Martha Stewart is in the US), a national TV personality - even if it were "conventional" it would still have achieved critical mass.

</comment></comment></comment></comment></comment></comment><comment><USER21> A new niche play might be to figure out how to adapt the dating genre to the iPhone. Maybe a GPS-based play.

But I think the key continues to be -- find a good niche. But not so nichey that only 8 people are interested.

<comment><USER22> A _niche play_? Really? You might want to take a break from those bizdev2.0 blogs for a while...

</comment></comment><comment><USER23> Here's an interesting idea for a (niche) dating site:

One for people who spend more time reading books than watching tv or movies.

</comment><comment><USER24> dating sites are too complicating. Most of the dating sites which I have seen lately make me sick to be honest. How can I find a match in the middle of a smog? I want less complex and more fun. Illuminate the complexity and you'll reach your goal.

</comment><comment><USER25> Dating sites are a stupid idea in the first place. Your system or algorithm cannot ever hope to compete with 30 seconds of face to face interaction, ideally with that first meeting occurring by way of mutual friends.

Sorry, but building a better dating web site is trying to drive a nail with a screw driver. People who need help dating need a larger and more active social circle. They don't need a dating website. Anyone trying to sell a dating site will inevitably discover they're hawking snake oil and surrender to that reality.

<comment><USER3> Actually, that's a pretty good idea. A site with _no_ fancy profiles, just some really light filtering for age and location, and then a parade of people you can video chat with for 30 seconds. As the 30 seconds winds down, both partners have to press a big "greenlight" button to continue chatting.

This might be like skydiving for some people but I bet it would ultimately make them more confident. And it could be sort of addicting -- if you hate this guy/girl, just wait a few seconds.

<comment><USER26> woome.com attempts to recreate that, in fact almost exactly like you are describing...eerie.

</comment></comment></comment><comment><USER27> These websites exist to solve people's problems in dating, and dating problems are like depression in that there are so many causes that it's impossible to find a single cure.

The bureaucratic categories that people have to box themselves into for many of these websites are not very useful. For example, "Christian/Protestant" and "Atheist/Agnostic/Other" are enormous categories. Instead of equality-matching over these bureaucratic buckets, a better matching question might be something like "Do you meditate?".

Dating ultimately comes down to interpersonal chemistry, which is very subjective. By contrast, online dating often comes down to objective criteria like race, age, and religious affiliation, which simply aren't usually relevant in predicting whether a match is possible.

If I were to build a dating site, I would:

1\. Unapologetically make it a niche site for intellectuals, targeting people from solid schools and graduate programs. This is a group of people who (1) tend to prefer each other, and would pay a premium for an elite dating site, and (2) tend to have difficulty in dating that is not due to personality problems.

2\. Use Amazon book-recommendations style comparisons to define a metric for "similar tastes" in books, movies, and hobbies, then match people based on that. My site would be AI-driven, because while interpersonal chemistry is really difficult to nail down, one can probably get closer by using similar artistic inclinations than by assessing people according to bureaucratic categories.

3\. Concentrate on building a real off-line community, with meetups and speed- date events, which the dating site would supplement. This would implicitly imply that the site would be focused on a few major cities, at least when it started.</comment>


The Vision Intel, AMD and Nvidia Are Chasing: Heterogeneous Computing - <AUTHOR> http://wccftech.com/intel-amd-nvidia-future-industry-hsa/ <comment><USER2> I think the emphasis on unified memory is a bit of a red herring here. In my experience, heterogeneous computing means optimizing data placement such that the parallel-friendly number crunching is done entirely on the GPU and I/O, process control, and telemetry are orchestrated by the CPU.

Failure to consider data placement destroys much of the potential perf gain for getting the above right IMO. And unified memory won't make this any better if BW within a GPU is ~1 GB/s and system bandwidth is ~10x less. It will just sweep the problem under the rug.

Further, I have seen attempts to smear parallel computations system-wide, treating all the ALUs as equivalent, but this frequently breaks determinism when the compilers for the two different processor architectures create associatively different implementations of the same computation. And I see no resolution to that problem right now.

That said, GPUs have advanced enormously in the past decade. Branching is nowhere near the big deal it once was, the cache (L1 and register file) for a GPU core (an SMX not NVIDIA's silly redefinition of a SIMD lane) is surprisingly large, and insanely fast atomic ops can resolve a lot of potential concurrency issues (even deterministically if one prudently employs fixed-point math).

<comment><USER3> > I think the emphasis on unified memory is a bit of a red herring here. In my > experience, heterogeneous computing means optimizing data placement

Unified memory definitely doesn't change this aspect. It just makes it a whole lot easier to do from a software engineering standpoint.

It is quite painful to deal with GPU buffers, memory mappings and DMA transfers. Unified memory makes this a bit easier and as an added bonus, eases latency hiding by allowing the driver to do DMA transfers transparently and reduces driver overhead from poking the CPU and GPU page tables.

<comment><USER2> I'd suggest creating a templated buffer class that manages data uploads/downloads and exposes the appropriate pointer on the appropriate device. And from an algorithmic standpoint, don't pingpong large buffers of data between the CPU and GPU. I've been following this practice for 7 years now and it seems to work well. Ergo I really don't need unified memory and I'm pretty happy with the world of NUMA. Sadly, I suspect I'm an outlier.

For I think the real pain point is that GPU programming requires the ability to parallelize seemingly serial algorithms in a strongly-typed language in an age where 90+% of the engineers I know do all their coding in single-threaded, weakly-typed Python/R/Ruby/Javascript so they never get the opportunity to develop the relevant mindset to do so. As an aside, to hit close to floating point SOL on a CPU in SSE/AVX often requires a mindset similar to GPU programming (but sssshhhhh... don't tell the "recompile and run" peeps about that because it doesn't fit their comforting narrative).

And it's not a problem for me personally as a former C and assembler videogame and embedded system developer but it is a huge problem to find such talent these days because Python/R/Ruby/Javascript.

All IMO of course.

<comment><USER3> > I'd suggest creating a templated buffer class that manages data > uploads/downloads and exposes the appropriate pointer on the appropriate > device.

This is the easy part.

The hard part is getting this right in the big picture, to avoid having the CPU wait for the GPU and vice versa. Pipeline stalls will easily ruin your performance, to the point where single threaded CPU code runs faster because the high latency of data transfers.

This is where modern GPU memory management really helps. For example, in OpenGL, you can use GL_MAP_BUFFER_PERSISTENT and _COHERENT to map your buffers once right after you create them and keep the pointer to the mapped buffer for the entire lifetime of the buffer (see ARB_buffer_storage). When you do this, you're responsible for the synchronization so that the CPU and GPU never touch the same parts of the buffer concurrently. CUDA probably has something similar.

This adds some complexity to the application but now it's done explicitly in the application and there are no surprises. And the CPU/GPU page tables don't have to be modified, TLBs flushed and so on, so you get a bit of extra perf from there.

And I totally agree with the point about the mindset of single threaded programmers with dynamic languages. I was once put into a project where a scientific application was written in Python and some "big matrix" operations were done in C. The matrix ops were on the top of the profile so they assumed that it can be made faster by simply "porting" them over to GPGPU.

Well the matrices weren't that big (a few kilobytes) and the operations were done sequentially, one by one in the application. To make it work, the operations would have had to be batched but this would have meant a big refactoring to the entire Python codebase. This was way too complex for the chemists and phycisists who had written the code. They were really smart people with the domain knowledge but they didn't possess the mindset to think about making it efficient.

<comment><USER2> The approach I've taken to this dilemma is to work directly with the scientists to understand the quantities they are trying to compute rather than attempt to port the code itself (yes, I actively choose refactoring over porting).

Once the underlying algorithm has been deconstructed, one then reconstructs it parallelized in CUDA/OpenCL/whatever. In my experience, the implementation language and APIs can easily lead one to a suboptimal realization of algorithms.

Once done, the original python code can serve as a reference implementation for conformance and unit testing. Of course, if you have 1M+ lines of legacy code, this probably won't work. But in my experience so far, the core algorithms have been less than 50K lines of code, and usually less than 10K.

IMO sometimes one has to stand one's engineering ground to persuade them to make the right decision. And bonus, one ends up a ground floor domain expert at the end.

Finally, I turned down a very prestigious project 4+ years ago because they wouldn't let me take the above approach. They opted instead to do it entirely with compiler directives. That project still hasn't officially shipped. It has, however, driven a significant amount of improvement in said compiler directives.

</comment></comment></comment></comment></comment><comment><USER4> I've been working a lot with GPUs recently, and so far it's been a mixture of really awesome, and really hateful. Dealing with memory is a huge pain, and the language limitations are pretty bad. So many workloads these days are _so_ parallelizable it seems like a shame that the difficulty of working with GPUs turns people away from them. I strongly look forward to the day when this stuff is "fully mainstream" and it receives more attention from the compiler folks. Having a unified memory pipeline would be an excellent first step.

I can't wait to play with a Tegra X1 SOC! That's a whole lot of power in a an embedded device. Would be excellent for real time embedded video processing or computer graphics.

</comment><comment><USER5> The elephant in the room is that language development seems basically stalled. Meanwhile the bad old "C for GPUs" languages we are stuck with are CUDA, Metal and OpenCL, of which OpenCL is no good wrt compiler/tools/driver quality and the other two are proprietary and thus of limited potential.

<comment><USER3> Well everything is about to change once we get the SPIR-V intermediate language for Vulkan (and possibly OpenGL and CL too). It's an intermediate language with some similarity to LLVM IR.

That should enable 3rd parties to author compilers targetting SPIR-V, allowing other programming languages without having to use C as an intermediate target.

<comment><USER6> What bout HSAIL / LLVM: [https://github.com/HSAFoundation/HLC-HSAIL- Development-LLVM](https://github.com/HSAFoundation/HLC-HSAIL-Development-LLVM)

(HSA Intermediate Language LLVM support)

It would seem an IR is already available and it's already integrated on an existing LLVM branch. From skimming around it seems AMD has been working hard to do what is necessary to get things merged into LLVM mainline.

<quote> My highest priority is to get the backend upstreamed as soon as possible, so I would appreciate feedback about any kinds of blocking issues on that.

Thanks

Matt Arsenault </quote>

[http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/085545.h...](http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/085545.html)

<comment><USER3> I'm sure this work hasn't gone unnoticed in SPIR-V development, I wouldn't even be surprised if it's partially the same guys doing it. That said, I haven't been involved in that so I don't know for sure.

LLVM IR has a few weak points for this kind of IR. It has architecture dependent parts and the format has changed in the past so it is coupled to LLVM development cycles. You can argue whether that's a good or bad thing but it's a thing to be considered.

There were two earlier versions of SPIR, coupled with different LLVM versions. SPIR-V is independent of LLVM but still semantically similar to LLVM IR, so compiling back and forth between the two isn't too difficult. AFAIK there has been discussions about adding a SPIR-V backend to LLVM trunk (can't find the mailing lists).

The SPIR-V spec is already out and there has been some projects already using it, although you can't run it on a GPU yet (unless you work for a GPU vendor, that is).

[https://www.khronos.org/spir](https://www.khronos.org/spir)

</comment></comment></comment></comment><comment><USER7> I find the article a bit overoptimistic about the future and applicability of heterogenous computing.

The problem with delegating tasks to GPGPU's is, that GPGPU cores can do only a very limited subset of what a CPU can do.

First of all, each GPGPU core has only a small amount of fast local memory available. In most applications, tasks need to be able to access databases, large in memory datastructures and what not. The GPGPU architecture is not designed for that. When data outside the core's local memory is needed, data transfer to and from individual cores is costly and when too much of that has to happen, the benefit of the many GPGPU cores rapidly disappears.

Second, a GPGPU core does not have access to other components, e.g. IO controllers. So it can't directly read from disk or write to the network. This again limits the types of work that a GPGPU core can do by a lot. For all network and disk access it needs to communicate with the CPU, and again, this communication is slow.

And finally there's a difficulty of another nature. OpenCL or CUDA does not integrate nicely with higher level languages such as Java. The article mentions Aparapi, which is one solution that tries to deal with this by compiling Java code to OpenCL. The trouble with this is that Java code is living in another world as OpenCL; code that works well for Java might perform horribly on the GPGPU, because the GPGPU's architecture with its memory locality is so different. So to write Java code that will be compiled to well performing OpenCL, you have to code it with OpenCL in mind, and you have to be aware of the manner in which Aparapi will convert your code to OpenCL. This defeats the purpose of Aparapi; it might very well be easier to just write your code in OpenCL so at least you have a clear view what is going on.

<comment><USER8> So GPGPU is useful for computation intensive/ no branching map reduce of vectors that can be fit into GPU memory.

Can we have a smart VM that profiles the code and sees that kind of code and put it on GPU?

<comment><USER3> > So GPGPU is useful for computation intensive/ no branching map reduce of > vectors that can be fit into GPU memory.

Modern GPUs can do full dynamic branching and process data structures that aren't flat (ie. vectors/matrices). It's not restricted to such simple tasks any more.

I don't think we'll ever have VMs that are smart enough to do decisions like this better than an engineer can. Or even close. What we really need is smart engineers who better understand what the technology is suitable for and can make good decisions on when to employ it.

<comment><USER9> That's interesting to hear! I took the udacity CUDA course a few years ago, and at that time they were very keen on memory access coalescing, and if a warp had two control paths they were executed sequentially.

As such I didn't think I could figure out how to make use of it for my applications (merging sorted lists of integers, dijkstra's algorithm etc) as typically you're branching and jumping around memory all over the place.

Can you suggest anywhere I can learn about these advances that mean the same rules don't apply?

</comment></comment></comment></comment><comment><USER10> Will the future not be CPU,GPU,FPGA integrated circuit? At least for some server applications that would make sense to gain maximum efficiency.

[http://www.theplatform.net/2015/07/29/why-hyperscalers- and-c...](http://www.theplatform.net/2015/07/29/why-hyperscalers-and-clouds- are-pushing-intel-into-fpgas/)

<comment><USER11> FPGA's are never as efficient as dedicated silicon they are flexible but that flexibility comes at a huge cost both in performance and materials. FPGA's are used in situations where it's not commercially viable to spin your own chips and where you can offset the high cost of FPGA's to your consumer.

If anything the "future" might be in on-demand core configs similar to how modern ARM SOC's are being built from a combination of "small" and "big" cores with different features and performance head space that allows for more efficient power usage for small devices.

So core-specific optimizations for different applications (Database, Web Server, Video Streaming etc.) might be quite possible especially when combined with user-programmable micro-code might be much better than FPGA's. Basically you might have a dedicated CPU (that you might even be able to partial design yourself by submitting VLSI code or something similar) which is specifically tuned for your application e.g. a web application server CPU with 4 big cores that handle executing the application code it self, with additional smaller cores that handle things like HTTP, SSL, session cache etc. each with dedicated register/extensions optimized for those actions e.g. LZMA or AES extensions.

<comment><USER12> FPGAs with larger cells (e.g., entire ALUs) can potentially beat all the shit out of GPUs in most use cases (because of the better control over memories). You'll have the best of both worlds here - routing flexibility of FPGAs and fast ASIC cells.

<comment><USER11> That's not really true FPGA CPU's tend to be very slow relatively to the speed of the FPGA and comparable ASIC's.

Yes you can program the FPGA to do say LZMA very quickly but you can just as well build a dedicated SIMD ASIC that will do the same and at much lower cost.

If you design your CPU to include current ISA big cores combined with small mission specific SIMD ASIC's it will be better than building a CPU with additional FPGA cores or building a CPU on an FPGA which is an insanity to begin with.

I would yield that FPGA are more flexible but if you can build more or less flexible SIMD ASIC's that are user configurable you will get a similar flexibility to FPGA's with better performance still, eventually there's a limit to how many non-generic operations the CPU handles and there will be a fairly low limit on how many of those will deserve dedicated silicon before you over-optimize and lose performance.

<comment><USER12> I am talking of really _large_ but generic cells, much bigger then the current DSP slices. This way FPGA will be a programmable dataflow machine with all the heavy lifting done by the ASIC ALU slices. And it is much more flexible than hoarding the very specific ASIC blocks.

Any problem I was solving on GPUs recently would have been implemented 100x times more efficiently on such an architecture.

<comment><USER11> large and generic cells seem to be exactly what the current GPU architectures bring, and where did the 100x times number came from?

<comment><USER12> The current GPUs have to deal with a cumbersome, often unfit memory hierarchy. What an FPGA-like model would bring is a much more flexible way to configure the local memories layout. Source - experience of getting over 100x difference in performance wity memory opimisations alone.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> The MPI+OpenMP duality has been around the HPC community as a for of heterogenous computing. Recently, with the addition of CUDA to the mix, HPC codes have added yet another code path; I'm skeptical about the maintainability of such systems. It's sad because the three tools exist to solve the same data-parallel paradigm, albeit in different configurations. In an alternative universe, where plan9 had succeeded, I could see this issue addresses by the OS, but I imagine a well designed library+runtime to fill this gap perfectly well. Intel's TBB addresses the shared-memory problem with a work graph, could we extend such philosophy to the three tools?

</comment><comment><USER14> Did anybody try to use APL or another array-oriented language for these multicore chips?

</comment><comment><USER15> Many modern SoC octacore systems are HMP. I don't think the author is really grasping too far into the future. These systems are here now. Google's new nexus phones are 6-8 core HMP as well.

</comment><comment><USER16> I am tired of the misuse of Moore's Law...</comment>


Google foobar - <AUTHOR> https://www.google.com/foobar <comment><AUTHOR> Foobar is a recruitment tool (I think). The link won't work directly as it needs a working session id, but if you search for "headless chrome" you should get a working link in the page above the search results after a few seconds.

<comment><USER2> Thanks. I did the first challenge. Also it didn't work in Firefox Developer Edition.

<comment><USER3> Currently does not work in Safari on OS X either.

</comment></comment></comment><comment><USER3> I remember getting an invite at some point late 2014 or early 2015 and doing a few problems but not submitting as I wasn't serious about interviewing. It's nice that you can see if your solutions passed without any requirement to submit your solutions to Google.

By the way — if you go too long without trying one, you get this:

        foobar:~/ tedmiston$ request
        Requesting challenge...
        Your invitation has expired. Search on to try again later.

Edit - Even Google engineers make errors:

        foobar:~/ tedmiston$ status
        Error(400): Bad request.

I submitted feedback on it. Seems like most commands fail with 400 if your invitation is expired.

</comment><comment><USER4> This appeared while I was searching for something related to Angular a while back. It said something like, "You're speaking our language. Ready for a challenge?" Unfortunately, I was insanely busy at the time and lost the tab. It never came back and I had nothing in my email :-(

</comment><comment><USER5> This has come up before... you need to get redirected to the site to be able to access it.. it gives you a pythonic shell in the browser to do a recruitment test.

</comment><comment><USER6> A first round google interview question I was asked: If you have a web page with two images on it, how many web request will need to be made to render the page? (Assume http 1.1)

I had to ask if he wanted the technically correct answer or the one I bet he (the google recruiter) was given by his engineers. Sadly his google engineers had given him the wrong answer.

<comment><USER7> I don't understand how these interviews work. You can't have a single correct answer to these kind of questions.

\- 3 seems to be the obvious answer.

\- 1 for keep alive stuff but even with a single connection, there are multiple requests. Also, nobody said the images were on the same server.

\- Did I have these images on cache? Maybe 1 then.

\- 4 with favicon request (now we are nitpicking)

\- Hey maybe each resource is behind 5 http redirects.. So 15 would be correct I guess?

\- Base64 encoded images are fun too.

They really have a "set in stone correct answer" and do not discuss these with people?

<comment><AUTHOR> If the question states "to render the page" then it's very likely the answer is about blocking versus non-blocking calls. Images don't block the browser's renderer because they're loaded asynchronously, so the answer is 1. As soon as the browser has fetched the HTML and parsed the header for blocking scripts and CSS it'll build the DOM and render it. The images will be requested during that time, but they won't stop the rendering from happening. The browser will rerender the page as soon as the images load (or sooner if they're progressive JPEGs). The same is true of favicon.ico. That's loaded in the background after the first render.

(I think that's all still true. Browsers move fast.)

<comment><USER3> I'm not sure I understand your comment. Either way we still need the requests for the images to return (or fail) before we can call the page rendered.

<comment><AUTHOR> "rendered" is a slightly tricky term when it comes to browsers. Often when people say "rendered" they mean "the page has loaded, all assets are there, and the whole thing has been drawn on the screen", but when someone from Google says "rendered", especially in a job interview, they probably mean the time to the first paint. That happens after all the blocking assets (synchronously loaded javascript, CSS, etc) have loaded but long before all the other assets (images, async JS, etc) have loaded.

<comment><USER3> That's fair, but agree it is ambiguous the way it's asked.

This front-end doc [1] from Google with a similar example counts a sample page with (1) html, (2) one external css file, and (3) one external image as "a minimum of 2 roundtrips":

> _As a result, this page incurs a minimum of two roundtrips before it can be > displayed._ Once again, the CSS file may take multiple roundtrips, hence the > emphasis on "minimum".

> Notice that our "awesome photo" did not block the domContentLoaded event. > Turns out, we can construct the render tree and even paint the page without > waiting for each asset on the page: _not all resources are critical to > deliver the fast first paint_. In fact, when we talk about the critical > rendering path we are typically talking about the HTML markup, CSS, and > JavaScript. Images do not block the initial render of the page—although we > should also try to get the images painted as soon as possible.

[1]: _Analyzing Critical Rendering Path Performance_ [https://developers.google.com/web/fundamentals/performance/c...](https://developers.google.com/web/fundamentals/performance/critical- rendering-path/analyzing-crp)

</comment></comment></comment></comment></comment></comment><comment><USER8> These are very fun puzzles. I was sad when I lost access because I didn't push the recruit me button it kept offering me. Would have liked to do some more of them.

</comment><comment><USER9> This is a test.

Good luck.

If you logged in after clicking the link on an unnamed app having unknown capabilities, and of unknown provenance, you have failed the test.

<comment><USER10> Is *.google.com really "of unknown provenance"?

<comment><USER11> no, but it is suspected of "having unknown capabilities".

<comment><USER12> who knows what google might do with google's information.</comment></comment></comment></comment>


Four reasons why Drupal should fork PHP - <AUTHOR> http://blog.calevans.com/2011/04/07/four-reasons-why-drupal-should-fork-php/

<comment><USER2> Interesting to read and to ponder. Personally (myself included) more php developers need to make a little effort to give back to the core, it doesnt need to be in bug fixes or new features. The excellent documentation is downloadable, from which you can add your "examples" and start giving back.

Drupal shouldnt fork php, extensions were mentioned, rightfully. The author didnt go into explaining the "whys" for Drupal. As a non Drupal developer im curious to know some of the pain points.

</comment><comment><USER3> This article was ok, but the title is pure sensationalism. The author even concedes that he doesn't want Drupal to fork PHP. Maybe I missed the point of the article then. Seems to me the point was another article that talks about how bad PHP is.

<comment><USER4> Hi!

The point of the post was to start a discussion, which it did. It was aimed at PHP developers, not Drupal developers and my goal was to present a scenario that they could ponder. What IF one of the major projects got to the point where they felt it was in their best interest to fork PHP.

I don't think PHP is bad. As a member of the PHP community, I do everything I can to promote PHP and it's usage, best practices, etc. There are however, lessons we as a community can learn from the projects that have been built on PHP.

I agree with the previous commenter that more PHP developers should give back. Since I'm not a C programmer, I give back through writing, pointing people to tutorials and blog posts around the web, and speaking at user groups around my region. I encourage every PHP developer to get involved in their local PUG and be an active member.

Thank you for taking the time to read the post and comment on it. :)

=C=

</comment></comment><comment><USER5> One reason why they shouldn't: When they fork PHP, they need another team to maintain there PHP fork. A team like.. the team maintaining PHP already.</comment>


Mega will only succeed if developers take the fall - <AUTHOR> http://stupidiswinning.tumblr.com/post/41019465324/mega-will-only-succeed-if-developers-take-the-fall

<comment><USER2> The article seems to be pulling in two directions on MEGA:

1\. It's identical to Dropbox (or spideroak, or tarsnap, etc.)

2\. Its only viable use case is piracy.

These two claims seem at odds...

If nothing else, it's Dropbox where I get 50 GB of free space. If Dropbox can be legitimate and viable, I don't see why this can't (once they work through some kinks and get a good client).

<comment><USER3> 50 GB free at MEGA?! That can't be viable.

Consider: If you can write an rsync-variant with the API, then movie pirating will pay for the Internet population's backup system...

<comment><USER4> >50 GB free at MEGA?! That can't be viable.

Why not? The cost of 50GB of live storage is not that high anymore. Doesn't gmail provide something like that much now already?

If you upload data and no one ever downloads it then there only has to be one copy in one datacenter on the entire internet, which not very expensive. And if you upload data that tons of people are accessing all over the place, they'll have to cache it closer to the destination and that will cost money, but then it generates ad revenue and pays for itself.

Moreover, I don't think anyone with a brain will be using it as a backup solution for anything important, because I highly doubt they'll provide you any kind of service level agreement. It's almost the opposite of a backup: If you upload something then it highly likely gets distributed to the world, but if they have a serious hardware failure (or have another encounter with corrupt law enforcement officials) then your data might go away at random sometime and have to be re-uploaded.

<comment><USER5> As for free Gmail storage, it is ~10.0926 GB as of 2:35 CST. At least according to the Gmail sign-in page.

</comment></comment></comment></comment><comment><USER6> This article abruptly terminated as if author got hit by a bus.

<comment><AUTHOR> I thought a single reference to the 'usual' problems developers can face building on someone's API would be enough by now.

<comment><USER7> For those tuning in now, the "usual" is probably best synthesized in Tim Bray's 'sharecroppers' piece of ten years ago: [https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePl...](https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePlace)

</comment></comment></comment><comment><USER8> All someone has to do is release a white-label, searchable aggregator for links and keys, with instructions on how to copy-paste the key to decrypt the file. No need to interact with the Mega API at all. The developer releases it with a collection of Creative Commons content, legally says "This should only be used for open-access content," and open-sources or sells the source code. Then these sites pop up all over the place with pirated links. Since the aggregator's original authors never intended it for piracy, they're blameless, and the operators who use the site take all the risk of takedowns.

Such an app would bring Mega back to its former infamy. A MegaDropbox is not needed. And no developer needs to take the fall.

Piracy isn't the answer to our arcane copyright laws, or to the industry's failure to embrace digital distribution, so I hope such a thing won't be made. But I'm pretty sure it will be.

<comment><USER9> >Since the aggregator's original authors never intended it for piracy, they're blameless, and the operators who use the site take all the risk of takedowns.

Are you sure? [http://www.wired.com/threatlevel/2013/01/coder-charged- for-g...](http://www.wired.com/threatlevel/2013/01/coder-charged-for-gambling- software/all/)

</comment></comment><comment><USER10> _Be warned: there are only three types of businesses you can build on Mega's API:

\- ones that nobody cares about

\- ones that become features

\- ones that will destroy your life

It's basically just like Twitter and every other platform that rose or fell before them, but with prison sentences._

Can someone please explain what this means?

<comment><USER11> He means one of these three things:

\- No one will use your app and you will fail.

\- Your app will be great, Mega will take the idea and build it into the service and you will fail.

\- Your app is made to promote piracy using the Mega API and you will go to jail.

Not sure I agree but I figure that's what he means.</comment></comment>


Standings in 38th Annual World Finals of the ACM International Collegiate - <AUTHOR> http://icpc.baylor.edu/scoreboard/

<comment><USER2> Competing in algorithmic programming competitions is an extremely eye-opening experience. I competed in 3 ICPC regionals during my time as an undergrad and realized that my level of knowledge in core/fundamental algorithms was (and still is) an absolute joke compared to some of my competition.

I realize I didn't exactly put a lot of time into practicing and learning new material, but now that I've graduated I'm hoping to practice more and eventually try raising my rating on TopCoder. If anything, training for ICPC drilled the basics of algorithms and data structures into my head and lead me to find tons of excellent resources for improving in these competitions (and consequently, programming/problem solving in general).

<comment><USER3> Seriously, having competed in only 1 regional ICPC myself, I was blown away at the level of knowledge of some of the students. Some kids were coming in from high school with serious programming skills. Makes me sad when I go back to work now and never get to use any of these interesting algorithms.

<comment><USER4> NYU team coach here writing from Russia. :)

Indeed, most of the top competitors have been practicing since high school. We were lucky to assemble a team that has been training well before.

MIT's team consists of freshmen who are still in good training since their national high school math olympiad trainings from their respective countries.

<comment><USER5> What puzzled me is that training for high schools varies so much that not all students interested was given some basic help.

</comment></comment></comment></comment><comment><USER6> There is an online judge with problems from the competition: [https://icpc.kattis.com/problems](https://icpc.kattis.com/problems)

Live comments about the problems from the legendary Petr Mitrichev: [https://docs.google.com/document/d/1rjGwA7ChLJr2ibHVbt- GirDp...](https://docs.google.com/document/d/1rjGwA7ChLJr2ibHVbt- GirDpbCjSCG8DkKpfHHdc-ws/pub)

</comment><comment><USER7> Mirror if the site is hard to reach: [http://static.kattis.com/icpc/wf2014/](http://static.kattis.com/icpc/wf2014/)

</comment><comment><USER8> Does scoring well on these contests typically translate into being a good coder in business? (I'm genuinely curious, not implying anything). It certainly means one is bright. Would one be perpetually bored not finding coding for money challenging?

<comment><USER9> I can't speak for typical or usual, but, I attended 2 ACM ICPC regionals (southeast) & am gainfully employed in software. Last I knew, my two teammates were as well.

Of course raw coding talent & algorithmic skill are paramount, but what's neat about this contest is there is only one keyboard per team, so things like these quickly set teams apart:

* ordering the problems according to difficulty

* architecting a solution before implementing it

* concise, effective, communication

* using brute force when elegance adds time

* knowing your environment like the back of your hand

* ability to thrive under pressure

In my opinion, skills like these translate really well to success in the fast- paced, agile shops that are flourishing in many markets.

</comment></comment><comment><AUTHOR> There are several companies in the valley that are going hard for ICPC winners. MemSQL is certainly one of them. In the past contestants were mostly going to big companies like Google. Hopefully we will see more and more of the top competitors joining startups.

</comment><comment><USER10> Those are at T-1h. The actual results are different. 1st place St. Petersburg State University with 7 problems solved.

[https://twitter.com/ICPCNews](https://twitter.com/ICPCNews)

<comment><USER11> The results there (original link) are final for some time now. T-1 only applies until the end of the competition.

</comment></comment><comment><USER12> I think the amazing thing here is that the top 18 teams solved as many problems as Stanford, CMU, and UC Berkeley combined, and those schools are currently 3 of the top 4 ranked CS undergraduate programs in the US.

<comment><USER13> To be frank, competitive programming is a niche field which requires years of practice.

Imagine it like solving problems in mathematics , the better your brain is used to solving similar problems in the past, the faster you will end up solving the relevant task at hand.

</comment></comment><comment><USER14> These standings are pre-freeze, so not final, right?</comment>


A Teacher Did an Experiment to Show the Power of Handwashing - <AUTHOR> https://brightside.me/inspiration-health/a-teacher-did-an-experiment-to-show-the-power-of-handwashing-and-you-cant-stay-unimpressed-795485/ <comment><USER2> They use the word bacteria to refer to what look like molds to me.

Looks like a fun experiment though.

</comment><comment><USER3> Wow. Simple but effective experiment.

</comment><comment><USER4> This page keeps popping up the cookie consent box when I decline the cookies. It's literally unusable without bypassing it via Reader View.

<comment><USER5> Cookie Autodelete on FF might help you cleaning the cookies, e.g. 90 seconds after closing the page cookies get deleted.

</comment></comment><comment><USER6> NOT washing hands is important too. Letting a little bit of bacteria into your body strengthens the immune system. It is important to sometimes let your kids pick up food from the floor and eat it.</comment>


Seymour Cray: "Cray-1 Introduction" (1976) [video] - bra-ket https://www.youtube.com/watch?v=vtOA1vuoDgQ <comment><USER2> Cray's rather famous anti-parallelization quip, "If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?"[0], reminds me somewhat of one of Donald Knuth's statements: "During the past 50 years, I've written well over a thousand programs, many of which have substantial size. I can't think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX"[1]

[0] [https://en.wikipedia.org/wiki/Seymour_Cray#SRC_Computers](https://en.wikipedia.org/wiki/Seymour_Cray#SRC_Computers)

[1] [http://www.informit.com/article/article.aspx?p=1193856&_](http://www.informit.com/article/article.aspx?p=1193856&_)

<comment><USER3> Well, he built his empire on Emitter Coupled Logic. He didn't have the limitations of CMOS to deal with and so parallelism wasn't as necessary for continued computational power.

<comment><USER4> I...I'm not sure I understand what you mean, but it feels rude to downvote based on it. Can you elaborate on that, please?

<comment><USER5> No one is arguing that parallelism is easier or more convenient than serial processing. (I think.) But clock speeds top out eventually, because power usage goes up with the _square_ of the clock rate and eventually your chip just melts. So the only way to get more performance out of a piece of silicon is to put processors side-by-side.

<comment><USER4> I'm not arguing that either, it's the nonsense about ECL and CMOS above that I can't understand.

<comment><USER6> It's not nonsense. By committing to using ECL logic (read: cost is basically no object) Cray didn't _need_ to bother with parallelism to get the best performance possible at the time, and so it was reasonable marketing for him to discount it. If he'd been confined to CMOS (or to a somewhat lesser extent bipolar) logic, he'd have had a very different set of trade-offs to get the performance he needed.

<comment><USER4> > By committing to using ECL logic (read: cost is basically no object)

I don't disagree with your assessment of ECL, but I think you're holding the historical account upside down :-).

> Cray didn't need to bother with parallelism to get the best performance > possible at the time

Let's put things into context first: the Cray-1 _was_ a parallel computer. It had vector processing. That's the most trivial kind of computational parallelism (at least from a mathematical point of view) and the Cray-1 had it! Cray not only "bothered" with parallelism, _his supercomputers were as parallel as they can get_.

However, that wasn't new. There had been vector machines before, like CDC's STAR-100. However, one of the reason why they failed to gain traction was precisely the fact they sacrificed serial performance for that. Turns out that's a really bad, bad, bad idea for scientific computing, because 90% of the problems that involve cranking matrices usually involve cranking _the same_ matrices over and over again.

So "the best performance possible at the time" (much like today, ironically!) turned out to require not only the parallel processing facilities offered by vector instructions, but also good serial performance, which basically boiled down to SQUEEZE MOAR CYCLES!! Remember, this was still five years before RISC became a thing; it was around the time Cocke began designing the IBM 801 (which only became available in 1980!).

At the time, CMOS simply wasn't up to it in that regard. It's not that Cray made a conscious choice to avoid wrestling with CMOS' limitations, there were literally no CMOS logic ICs that moved that fast. Not using CMOS was not a design decision anymore than not using relays was! This was happening at a time when pretty much _all_ serious computing was done with bipolar logic. This was still a good two years away from even the faster companies in the same field (like DEC) abandoned the bipolar logic boat. IBM continued building mainframes with bipolar logic (albeit using TTL, not ECL) well after that (the 4300 was retired in the early 1990s, although I don't know if they were still manufacturing it in TTL; but it definitely was in 1979 when it was introduced!).

When CMOS was adopted later on for high-performance computing later on, it wasn't because of the costs! ECL's power dissipation demands made it technically, not economically, unfeasible to make faster logic circuits.

<comment><USER6> So when shown to be wrong, you redefine the question so you get to be right. Have fun with that.

<comment><USER4> What was the question? I don't see any question mark in the posts above. And how exactly did I redefine it?

I pointed out that this is wrong:

> Cray didn't need to bother with parallelism to get the best performance > possible at the time

because Cray not only bothered with parallelism, but _all_ Cray computers were parallel. And that this is wrong:

> By committing to using ECL logic (read: cost is basically no object)

because cost is hardly the only challenge when working with ECL. And that this is not only a truism, but also unenlightening from a historical perspective:

> If he'd been confined to CMOS (or to a somewhat lesser extent bipolar) > logic, he'd have had a very different set of trade-offs to get the > performance he needed.

First, ECL _is_ bipolar logic, like anything built with BJTs. Second, that would have also been true if he'd been confined to relays or cranks. Of course you get a different set of trade-offs if you use a different technology.

But _no computer company at the time_ was building minicomputers, let alone mainframes or supercomputers, in CMOS! The most megasuperparallel computers of the time, from the C.mmp to the ILLIAC IV were ECL or TTL. Cray's empire was built on _precisely the same technological basis_ as that of every other computer company in the seventies.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> mark-r I had the pleasure of touring the Cray plant in Chippewa Falls and meeting the man himself, not too long after this talk. My expectations were that we would be on one side of a glass window and the computer would be on the other, but no - we walked right up to one that was being tested for delivery, serial #5 I believe it was. They were obviously proud of the cooling system - we were invited to put our hands on the side panels to see how cool it kept. The wire maze on the inside of the "C" was incredible, one trip would have caused an immeasurable amount of damage.

Unfortunately we only met Seymour for a short time, obviously he was quite busy. Even more unfortunate is that I don't remember much of that meeting. The only tidbit I remember clearly is him pointing to a pumpkin on his desk. His daughter had grown it in the garden, and knowing he was already thinking about a Cray 2 machine decided it should be named the "Cray 3".

</comment><comment> at-fates-hands My father recently told me he used to share lab time with Cray when he was in college. He said people would go crazy when he was on campus and follow him wherever he went.

He said he was like the Steve Jobs of his day - if you were into tech, you knew who he was and just wanted to soak up what he was saying.

</comment><comment><USER7> Tangentially related but I had to share:

 _Another favorite pastime [of Seymour Cray] was digging a tunnel under his home; he attributed the secret of his success to "visits by elves" while he worked in the tunnel: "While I'm digging in the tunnel, the elves will often come to me with solutions to my problem."_

[https://en.wikipedia.org/wiki/Seymour_Cray#Personal_life](https://en.wikipedia.org/wiki/Seymour_Cray#Personal_life)

<comment><USER8> I read about it in the "Supermen" book [1], he dug extensive tunnels. Doing repetitive work makes it probably easier to do daydreaming. That's how he designed his Cray super computers architectures in his head.

[1] [http://www.amazon.com/The-Supermen-Seymour-Technical- Superco...](http://www.amazon.com/The-Supermen-Seymour-Technical- Supercomputer/dp/0471048852/)

<comment><USER6> Some geniuses take long walks for inspiration, some dig tunnels and talk to elves. I don't judge.

</comment></comment></comment><comment><USER9> We had a Cray at Apple. I got an account on it and mucked with it for a while, but nothing serious. Its main use was to simulate plastic flow in molds for the cases of Macintosh computers (molds are pretty expensive, $500K to $1M, and you want to make sure they'll work well before you commit to making them).

Turned out that Seymour used MacDraw to design parts of the Cray-3. So we were using each other's computers to design our own computers....

</comment><comment><USER10> I had the opportunity to use a Cray Y-MP 2E at University, early-90s. Even though this was in Brazil, you had to get special approval from the US Government to be able to run your code. I got a free pass as I was limited to 10 mins of CPU time/week. Shell usage didn't count, so 10 mins was plenty of time to play with UNICOS.

It was a beautiful machine. The C-shaped purple machine was impressive, and the refrigeration huge. And we had some nice SGI Indigo workstations as the front-end, so you could optimize your (Forth) code before moving to Cray.

Amazing to think of all that paranoia for 666 Megaflops. My not-so-new Core i7 has 150,000+ Mflops, not counting the GPU.

<comment><USER6> I got to use a Y/MP-48 (COS with VAX/VMS front ends) in the late 80s. Excellent learning experience. The professor offered something like 10 bonus points on the final for anyone that could solve a particular problem (don't recall which one) in a faster time than he was able to achieve. Having done the best I could, I called the local Cray office looking for help. It was a sales office, so the person I talked to could only say he'd see what he could do. A couple of days later, they called and asked if I could come to the office for a bit. Turns out, one of the senior compiler engineers was in town, and he took something like 2 hours out of his trip to teach this college kid all the black magic and voodoo compiler switches and optimization techniques that weren't covered in the class. Very generous and great customer service. I ended up about 12% faster than the shocked professor, and got my A.

<comment><USER10> Love the story, thanks for sharing it.

</comment></comment></comment><comment><USER11> This is splendid! But definitely not Cray's "only surviving talk", since YouTube recommends another:

[https://www.youtube.com/watch?v=jG63r4e6eb8](https://www.youtube.com/watch?v=jG63r4e6eb8)

</comment><comment><USER12> The only good book on Cray I've found is he Supermen: The Story of Seymour Cray and the Technical Wizards Behind the Supercomputer by Murray.

Besides two or three videos, The Supermen, and tangentially related books about the history of CDC, it's hard to find a lot of details about Cray's work. I think the University of Minnesota has some Cray related papers, but I'm not sure what.

<comment><USER13> I loved Supermen. A little light on the technical, but a really fascinating read, particularly if you're into the history of computing.

</comment></comment><comment><USER14> I'd love a transcript of this talk: the audio is poor...

<comment><USER15> It is very amusing though to turn on Google's auto close captioning though :-) (my way of agreeing with this request)

</comment></comment><comment><USER16> Great seeing this again. I remember in its day Cray was like a mythical beast we only heard of since Gov was the only one with enough money to buy one.

The C configuration with hard wrapped wires were awesome. Hard wrapping was the fastest path for electrons from point A to B.

<comment><USER17> What is "hard wrapping"?

PS: No kidding, can't Google it. I only find articles about jewelry instead.

<comment><USER16> Back in the bread boarding days, hard wrapping was using a tool to physically wrap a hair thin insulated wire from one pin on an IC to another pin on an IC.

Not using the PCB foil electrical path but rather a direct short path as possible wire connection between two points.

<comment><USER18> Is this another term for wire wrap, or is it something different?

<comment><USER16> Yes wire wrapping and hard wrapping the same thing.

Hard wrapping was something the current day mags called it (Popular Electronics) for one.

</comment></comment></comment></comment></comment><comment><USER19> What an amazing speaker. He brings what should be boring technical details to life in an engaging, humorous dialogue. Obviously a very technically intelligent man, and an excellent public speaker, that seems like it's a rare combination.

</comment><comment><USER20> Amazing what ~40 years can do. I still find it astounding that my Snapdragon 800 powered phone, a Lumia 1520, is ~800x (130 GFLOPS vs. 160 MFLOPS) faster than the Cray-1 and ~1/24000th the mass (5.5 tons vs. 209g). Truly a "supercomputer in your pocket". Which plays various flappy bird clones. Or Wordament.

</comment><comment><USER21> I still think two of the great tragedies of modern computing were the loss of Seymour Cray and Jay Miner.

[edit: I still have a picture of me standing in the middle of a Cray 2 - <AUTHOR> was a fun machine]

</comment><comment><USER22> Thanks for posting. Seymour Cray is one of my heroes. Great man with great vision. Such a great loss to the world.

</comment><comment><USER23> This talk is an absolute gem. Thank you.

</comment><comment><USER24> nice</comment>


Key-Value Stores: a practical overview, and interfaces for Ruby - <AUTHOR> http://blog.marc-seeger.de/2009/09/21/key-value-stores-a-practical-overview

<comment><USER2> direct link to pdf: [http://blog.marc- seeger.de/assets/papers/Ultra_Large_Sites_S...](http://blog.marc- seeger.de/assets/papers/Ultra_Large_Sites_SS09-Seeger_Key_Value_Stores.pdf)</comment>


U.S. Supreme Court Declines to Referee State Disputes Over Marijuana - <AUTHOR> http://www.nbcnews.com/news/us-news/u-s-supreme-court-declines-referee-state-disputes-over-marijuana-n542551 <comment><USER2> > Nebraska and Oklahoma said Colorado's decriminalization has "increased the > flow of marijuana over their borders," forcing them to expend greater "law > enforcement, judicial system, and penal system resources," thereby harming > the welfare of their residents.

And what about all of the resources you spend prosecuting people for recreation drug use? If you want to save money in that arena then Colorado and Washington have a great idea they can tell you about.

<comment><USER3> this is my main gripe with republican, as opposed to libertarian views. they believe in personal freedom and limited government... except where they don't.

<comment><USER4> The idea that republicans profess to believe in personal freedom in all respects is something libertarians made up to malign Republicans. Republicans, like Democrats, believe that government should regulate the morals of the people when necessary. For Republicans, small government is a means to particular, mostly economic, ends, not an overarching ideological imperative as it is for libertarians. Thus, there is nothing internally inconsistent about Republicans preferring that government intrude minimally into private markets while also preferring a large and strong military apparatus.

<comment><USER5> The fiscal responsibility part of the Republican ideology is largely insincere. Sure, the people who vote Republican believe it, but the elected officials don't. During the Bush years, when the Republicans controlled congress and the presidency, federal spending grew _enormously_.

<comment><USER6> >Sure, the people who vote Republican believe it, but the elected officials don't.

... which is why the Republican Party is set to lose an election that should have been an easy lay-up.

>During the Bush years, when the Republicans controlled congress and the presidency, federal spending grew enormously.

That's how we ended up with the budget sequester, which is the only thing that seems to have actually worked since the Gingrich House in the mid '90s. Now that the sequester is gone federal spending will grow in leaps and bounds no matter who is in power. It's built into the system.

</comment></comment></comment></comment></comment><comment><USER7> Sometimes I wonder about how the country evolves its view on things. And living through the evolution of gay marriage, and legalization of marijuana gives you some nice concrete data points. Watching the will of the people being expressed in these ways is kind of like watching a family dealing with a grumpy relative who slowly changes the way everyone else thinks about things. It isn't "fun" but it is fascinating.

I also know that in my parent's case it is their primary evidence that the country is going downhill fast even while I see it as a hopeful sign that the country can move forward. Not surprisingly, that dissonance is being tapped rather effectively at times by the political process. It is strange to see 'change' as the fuel that is used by others to either accelerate or stop further change.

<comment><USER8> "Progress occurs one obituary at a time".

Religious beliefs by age group: [http://www.pewforum.org/religious-landscape- study/compare/re...](http://www.pewforum.org/religious-landscape- study/compare/religious-tradition/by/age-distribution/)

Millennials have overtaken Baby Boomers: [http://www.pewresearch.org/fact- tank/2015/01/16/this-year-mi...](http://www.pewresearch.org/fact- tank/2015/01/16/this-year-millennials-will-overtake-baby-boomers/)

Shifting Marijuana Beliefs: [http://www.pewresearch.org/fact- tank/2015/04/14/6-facts-abou...](http://www.pewresearch.org/fact- tank/2015/04/14/6-facts-about-marijuana/)

Changing attitudes on same sex marriage: [http://www.pewforum.org/2015/07/29/graphics-slideshow- changi...](http://www.pewforum.org/2015/07/29/graphics-slideshow-changing- attitudes-on-gay-marriage/)

The decline of marriage (somewhat attributable to economic causes IMHO): [http://www.pewsocialtrends.org/2014/09/24/record-share-of- am...](http://www.pewsocialtrends.org/2014/09/24/record-share-of-americans- have-never-married/)

</comment></comment><comment><USER9> Nebraska and Oklahoma continue to fund cartels south of the border when they could start funding their schools and help their budget shortfalls, not to mention contribute to personal freedom, just by ending prohibition.

Just another day in 'states rights' focused states that aren't adult enough to understand what that means. People voted this in en masse, does NE and OK hate freedom?

Colorado, Washington, Alaska, Oregon, DC are all asking the country when we are going to stop funding the black market and cartels.

States continuing to fight a losing and unneeded prohibition battle, will continue to send hundreds of millions and probably billions south to cartels that are quite rich while states budgets are poor. It is time that it ends across the board and quickly. What a waste of time and money prohibition has been.

The moralistic laws from last century making non-violent personal acts into crimes needs to end. It is too costly and the result is a black market with cartels awash in billions and billions.

</comment><comment><USER10> It was a little bit of an odd case to begin with. The idea is kind of that there's a cause of action around state policy creating an inter-state "nuisance" in arguable violation of federal law, but there's no real precedent for that kind of thing in common law, and certainly not in statutory law.

If one were to establish such a cause of action, it would have major implications around things like differing environmental regulations, firearms laws, labor laws, tax policy, welfare, heck even fireworks sales.

I'm not surprised the SC didn't want to leap into that giant legal cluster headache.

</comment><comment> rm_-rf_slash This was a great decision. Such a monumental shift in drug policy should be enshrined in federal legislation, and not dictated by the courts.

<comment><USER11> The complaint is that that Colorado is acting in violation of federal law. If you feel that changes in drug policy should be pursued through federal legislation, then you should be in favor of the Supreme Court upholding existing federal law. Having said that, I agree with Colorado's assesment that the currect target of prosecution is the federal government for failing to enforce its laws (unless there is a specific provision compelling states to act in a certain way).

<comment><USER12> > If you feel that changes in drug policy should be pursued through federal > legislation, then you should be in favor of the Supreme Court upholding > existing federal law.

Personal possession of weed is already completely legal under federal law via the equal protection clause. Once they passed the law saying that it's legal in DC, that means that it's now legal everywhere, even if they haven't yet taken the time to strike the old language from the books.

The only time federal charges are still pursued is if there is a firearm involved.

<comment><USER13> This is the moral equivalent of people telling others they don't need to pay income tax because the fringes of the flag in courtrooms have yellow tassels.

There are zero precedents under the equal protection clause that do anything like what the link suggested. On top of that the equal protection clause by its terms doesn't even apply to the federal government, since it is situated in the fourteenth amendment. It has been reverse incorporated via the fifth amendment due process clause, but again never in any case remotely like what is being suggested. You can't just look at the words "equal protection" and start extrapolating wildly. That's not how these things work.

There are several memorandum from office of the Attorney General that state Justice Department policy as to where efforts should be focused (e.g. [https://www.justice.gov/iso/opa/resources/305201382913275685...](https://www.justice.gov/iso/opa/resources/3052013829132756857467.pdf)) and even before that the federal government tended not to exert a lot of effort on small time marijuana users. But it is emphatically not the case that "personal possession ... is completely legal under federal law".

Please do not spread this type of misinformation, it can be have enormous consequences.

<comment><USER12> Fair enough. In practice though even if the theory doesn't hold up, you'd need to work pretty hard to get charged with possession by the feds. Even if you punched a federal judge while holding a bag of weed, they'd probably still toss the possession charge just to keep jury nullification types from trying to get seated.

</comment></comment></comment></comment></comment><comment><USER14> This is a technical thing. The court decided that Nebraska and Oklahoma can sue the Federal government for failure to enforce Federal law, but cannot sue another state.

<comment><USER13> No that's not it. The whole majority decision is one line long:

"The motion for leave to file a bill of complaint is denied."

That's it. No four justices voted to take the case. That decision sets no precedent and they declined to provide any reasoning which could even be persuasive in terms of trying to predict how they will react to future leave- to-file motions.

We can speculate as to why they decided not to take it, but we can't know for sure because they didn't say.</comment></comment>


FireFox 3 and static file caching problems - <AUTHOR> http://www.west-wind.com/weblog/posts/469125.aspx <comment><USER2> I ran into this too a few months while back, oddly enough with IE. Some proxy server or something was caching old versions of CSS files. After messing around forever with HTTP headers, I found the easiest way to deal with this is the href="blah.css?i=12345" solution mentioned in the article. Works for JS files too.

Rails makes this very easy with asset timestamps: [http://api.rubyonrails.org/classes/ActionView/Helpers/AssetT...](http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html) (well, "easy" sort of... until you have multiple web servers and the times get slightly out of sync)

</comment><comment><USER3> I'm seeing this too, but it corrected itself somehow. When I started developing a site my CSS changes were not noticed without shift-reload, but now they are with a simple reload.

Odd, unless firefox detects update frequency somehow and decides if to do the reload based on that? Seems weird, but I never had a reason to investigate it much.</comment>


Hollow Icons are Bad - <AUTHOR> https://medium.com/design-ux/a93647e5a44b

<comment><USER2> _The red lines indicate areas where cognitive load is occurring. Your brain traces the shapes on the first row an average of twice as much. Your eye scans the outside shape and then scans the inner line to determine if there is value in the "hollow" section.

Icons without this empty core are processed as definite and only the outer lines are processed. Depending on the outline of the shape, this happens pretty fast. No matter the shape, though, the hollow icons take more time to process._

I'd like to see an actual study to back this assertion up. The article makes an off-hand reference to something about how the brain processes the reading of words, but 1) I don't see how that maps to how the brain processes icons and 2) there's no reference cited for that either.

</comment><comment><USER3> The author believes that brains can't comprehend an unfilled shape as a shape, and instead must effectively parse it from individual lines every time. Is it possible his brain is the problem? That is, is there some subset of people who actually do find it difficult to see unfilled images as shapes?

</comment><comment><USER4> Seriously, again?

</comment><comment><USER5> I'm not sure how, in his formulation, words are anything other than "hollow icons", all stroke and no fill.

The author also seems not to have thought out his argument completely; in one breath, he speaks of parsing words as shapes rather than reading individual letters, and in the next he argues that there being only 26 letters in the English alphabet makes English easier to parse than the theoretically infinite set of hollow icons. If letters don't matter to English parsing, why does it matter how many there are? If they _do_ matter, then how is an English word significantly different from a hollow icon?</comment>