yajoe's comments

$0.02 regarding the name of the feature, which I think anchors too much in the "censorship/free speech" principle discussion when it seems you have much more tactical goals (moderator workload, foster specific topics, etc.).

Consider renaming the feature from "pending comments" to "civility filter." In prose one would say Moderators now can require civility via special-purpose moderation on specific threads.

Similarly, consider changing the "[pending]" text to "[Pending civility check]" and changing the "endorse" link to "Affirm civility" (or just "Civil" to keep with one-word nav elements).

Why?

"All speech must be endorsed" --> "Bad Thing"

"All speech must be civil" --> "Good Thing"

This is an interesting feature, and certainly not something I would have expected as the "next" feature to add. When I read "pending comments" I expected something similar to slashdot's old "preview" feature so one could double-check spelling, formatting, etc. i.e. preview the post before submitting to HN. I would not have expected "pending" to mean "pending moderation" given the successful voting feature here.

I would ask what the goals of the change are, but they seem obvious:

1) Limit nastiness and negativity

2) Encourage deeper and pensive comments

3) Cynically, it seems like a private goal would be to limit criticism of YC, though I know this would never be a stated goal. The criticism may simply have increased the priority even though HN has seemed more civil in recent months as an outside observer.

While the change may achieve these results, I would expect the following effects:

1) Fewer comments overall (there is a new "tax" to post, so-to-speak) and as a result there will be fewer visitors in the medium term (sites like HN, reddit, slashdot, huff post, etc all thrive on both the quality _and_ quantity of comments since that's what entertains people). Without controlling the number of front-page stories, you will in effect decrease the available content for viewers to consume. The demand will be filled elsewhere. I always assumed there was a private, invite-only forum for YC and that you would leave HN alone as a great PR platform... this move makes me wonder some more.

2) Comments will trend towards the quality of bane, tokenadult, ChuckMcM, patio11, cperciva, etc (we all know them) at the risk of fewer "provocative" posts. Often the greatest quality posts, however, are in response or to contradict simple-minded or provocative posts.

3) I am concerned by this line: People who regularly endorse comments that fail one or both of these tests will lose the ability to endorse comments. I like meta-moderation and all, but I don't like being reminded that all actions are recorded and tied back to my account. I would ask for some separation between "endorsing" and "agreeing" -- as a continual skeptic, I like reading and promoting contrarian views since it helps us learn.

I look forward to watching the experiment, and as a parting request, would you be able to record and measure the goals? There must be a YC company that can help with that, and I imagine it would be a wonderful blog write-up!

For those who don't know, Greg is one of the common faces of the Seattle VC scene. He is a staple at nearly every startup event -- Startup Weekend, Geekwire events, TechStars, VC panels, etc.

I don't have a dog in the fight, but I did spend some time reading the actual bill since these blog articles felt like more political campaigns than informative pieces. The last time this came up I posted https://news.ycombinator.com/item?id=7303232

The Seattle city council passed a law that made so-called "ride sharing" services legal after intentionally withholding prosecution for over a year. The law isn't perfect, but it does feel like it strives to balance protecting existing investments with new services. The most salient changes about the bill:

1. Seattle defines uberX, Lyft, etc as Transportation Network Companies (TNC) and declares all drivers as "for-hire" drivers, which is a legal distinction that means Seattle can regulate them.

2. TNCs are taxed at $50k for first year. Second year is the greater of $50k or .35% of gross revenue.

3. No more than 150 drivers may be associated with each TNC at a time, and each driver can work only 12 hours per 24 hour period. Previously the law would have limited 300 drivers per TNC per quarter regardless of who was active, and this was "the cap." For comparison, there are 1100 taxicabs in the city.

4. Drivers can't double dip: They can't both drive for-hire cars and also do uberX on the side. They also can't work for both uberX and Lyft.

5. Rates may either be flat-rate between preset zones OR subject to RCW Chapter 19.94. RCW Chapter 19.94 defines appropriate measurement devices that may be used with commerce, which I think precludes most cell phones... uberX would need to install meters it seems and precludes surge pricing.

6. The insurance requirements are stricter than what uberX or Lyft provide today and are mostly in line with existing taxicabs.

7. There was a 30% increase in the cap on cabs at the same time.

8. TNCs have to report their activities to the city, which will be available to the public for inspection.

Don't have a dog in the fight, but interesting how the uberX page doesn't mention specifics of the proposal beyond "put hundreds of drivers out of business and effectively shut UberX down." Where are the links? The specifics?

The actual proposal may be found on the city's site [1]. It also would help to provide some context for the types of changes, which both an opinionated summary from the local newspaper [2] and somewhat impartial summary from a local tech site [3] do fairly well.

For the tl;dr who don't want to click away:

1. Seattle defines uberX, Lyft, etc as Transportation Network Companies (TNC) and declares all drivers as "for-hire" drivers, which is a legal distinction that means Seattle can regulate them.

2. TNCs are taxed at $50k for first year. Second year is the greater of $50k or .35% of gross revenue.

3. No more than 300 drivers may be associated with each TNC (it's a permit lottery regime, if you are curious), and each driver can work only 16 hours.

Yes, that means that each TNC is limited to 300 x 16 = 4800 hours of work per week. A previous proposal had a limit of 100 drivers [5]

4. Drivers can't double dip: They can't both drive for-hire cars and also do uberX on the side. They also can't work for both uberX and Lyft.

5. I can't find a cap on the number of TNCs that will be licensed, even though that seems to be one of the (perhaps past?) sticking points.

6. Rates may either be flat-rate between preset zones OR subject to RCW Chapter 19.94. RCW Chapter 19.94 [4] defines appropriate measurement devices that may be used with commerce, which I think precludes most cell phones... uberX would need to install meters it seems.

Details likely only I will find interesting:

1. TNCs have to have valid insurance for all vehicles, and this insurance looks like it is stricter than what uberX and Lyft currently have.

2. TNCs must have an office in Seattle that is open and personally staffed all business days between nine a.m. (9:00 a.m.) and five p.m. (5:00 p.m.) with toll-free number

3. The TNC shall submit to the Director a report detailing all rides that were requested but not accepted by TNC drivers. The report shall include the location and zip code of each rejected ride. There are penalties for discriminating against underserved zip codes.

4. 30% increase in the total number of taxicabs, including an immediate increase of 8% "today. "

[1] http://www.seattle.gov/council/issues/taxis.html

[2] http://blogs.seattletimes.com/opinionnw/2014/02/14/seattle-u...

[3] http://www.geekwire.com/2014/seattle-delays-ride-sharing-vot...

[4] http://apps.leg.wa.gov/rcw/default.aspx?cite=19.94

[5] http://www.geekwire.com/2013/sidecar-uber-express-disappoint...

Edit: Formatting and spelling

Similar to another poster, the only person admitted to MIT from my high school 10 years ago out of a class of 1200 from a wealthy suburb was the daughter of an alumnus who ran the interviews for the region. I just find it hard to believe Legacy doesn't play a factor even if there is no checkbox on the admission forms. The father stopped running interviews the year she got in.

Even Harvard, Stanford, and Yale each admitted 3 people that year (which, interestingly were different people -- it's as if they colluded to induce enrollment).

totally off-topic, but because of the SOPA nonsense I've slowly moved my 40-or-so domains to namecheap during 2013 when their renewals came up. I was otherwise ambivalent about which DNS service/registrar to use before that incident...

but thank you for helping the guy get his twitter account back and fixing up the internal controls.

Interesting story. It seems the case went to arbitration due to a clause in the Ilya Semin employment contract and thus out of the light of regular courts:

http://dockets.justia.com/docket/california/candce/5:2012cv0...

Mind elaborating, even if it's wild speculation and rumor? I haven't been following YHOO closely to know the backstory or context behind this individual.

This is a good question about the macro US economy. In general I agree with GP.

Fact: The Fed has injected large amounts of cash into the asset markets using http://en.wikipedia.org/wiki/Quantitative_easing . I've never added up the cash as a percentage of GDP or one of the Ms, but it always seemed significant (i.e. 5-10% of GDP, but this is debatable). I should caveat by saying that this cash never entered general circulation, which has meant treating it as part of the monetary supply is tricky.

Now, based on this fact of Fed intervention there are a few opinions:

1. While the Fed directly isn't buying equities (i.e. stocks, but this is as far as we know), its presence means that all the other cash holders have to seek out other investments to get inflation-beating rates of returns. There isn't hard data to support this, but it is the conventional wisdom of both people in the game and macro economists.

2. The magnitude of the impact on the asset markets is up for debate. I've seen numbers as low as -5% and has high as 60% of last year's stock market returns can be attributed to the Fed intervention. Some of the difficulty is that there was large federal fiscal stimulus impacting during this time, and counter-intuitively there is some argument that the Fed neutralized the fiscal stimulus to hold inflation rates constant. The important part is that there was a stock market surge, and it is not a result of retail investors pouring in money: It is a result of institutions balancing away from bonds to stocks (this is what the GP means by "supply-side"). It's just not clear if the institutions did it because they have confidence in the economy or if they were "forced" by the Fed. The "why" is opinion, and many people believe the fed is the "why."

3. On the micro side, seeing 20-something kids get 150k budgets to screw around for a year is maddening. "It's ok, VCs play the numbers game... we just need one tulip to pay 100x." There is too much money chasing "talent" right now, and should the correction to the asset market happen this year (as I predict from the fed's cessation) then we will see the startup bubble unwind.

You both are right! (yeah, yeah, cop out...)

Listen to this: http://www.econtalk.org/archives/2013/06/kling_on_the_th.htm...

Thanks, you're right. I don't know why I would have ever thought "!" was bitwise... only on a Saturday night.

It just goes to show that sleep is very important for interviews!

Agree on needing comments.

My C++ is a bit rusty, but I think the code is in fact checking if the number is divisible by 2 (i.e. n % 2 == 0).

I think it's using the bitwise and operator (single &) to AND each bit in n and (n-1) and then checking if the least significant bit is 1 or 0. The code would need to shift (<< or >>) to check if the number were a power of 2.

I thought there was another bitwise NOT operator, not the !, but I think, and this is the part I'm hazy on after getting home, that the ! applied to an int is intended to flip each bit. Here's why:

------------

n = 6 = 110

n-1 = 5 = 101

n & (n-1) = 110 & 101 = 100

!(110) = 001 => true

------------

n = 5 = 101

n-1 = 100

n & (n-1) = 101 & 100 = 101

!(101) = 010 => false only if the least significant bit is used for logic decisions... this seems non-portable for some reason, just like using the ! as a bitwise NOT. It may actually be that ! only looks at the least significant bit, but I can't find c++ docs to say one way or another.

Whatever the code actually does, this is exactly the kind of example to use as a poster child for adding just a few comments.

Thanks. We've been segregating authenticated vs non-authenticated traffic to different domains for a few years now (we had the same realization as moot), but I was unaware about this specific exploit related to TLS compression.

That said, it seems on nginx TLS compression was not enabled by default, so we are ok (for this known vulnerability).

> Don't forget to disable TLS compression and HTTP compression for pages containing session ids or CSRF tokens.

Dumb question: Is this general advice or is it specific to django due to the "BREACH" [1][2] https attack? It's not clear if it the underlying flaw is in using a CSRF token or something specific to django's implementation. I had never heard this before, so thank you.

[1] http://news.softpedia.com/news/Django-BREACH-Attack-Against-... [2] http://stacks.11craft.com/what-is-breach-how-can-we-protect-...

Really?

Exchange: http://msdn.microsoft.com/en-us/library/office/jj900500(v=ex...

Gmail: https://developers.google.com/gmail/gmail_inbox_feed (Search is only available publicly via SMTP and IMAP, which technically isn't HTTP, but the Gmail app is clearly using HTTP XHRs)

This isn't as serious of a proposal as some of the W3C documents on how XML and WS-* works with my name on it (among many, many other smarter people)... and I have a lot of sympathy for someone who had to deal with Win32 APIs (they are locally optimized but globally bad).

I have no love for XML, but the details tend to matter. And you are right that saying "use HTTP" is a bit hand-wavy. XML is great at serializing nouns when you want to enforce the schema of those nouns. It makes interop of nouns, verifying, quantifying, and some types of searches must faster and consistent. XML was a reaction to widespread RPC and endless bit-order compat that wasted so many lines of code. It comes from the same mindset as the people who made SQL -- "conforming to schemas is good and what most people want."

However, in the last 10 years we've seen that it isn't possible to conform to a single schema as requirements change, and that is why XML has generally lost favor to JSON. This is a similar reason why NoSQL wins in many cases over SQL.

HTTP, in contrast to XML, is a set of verbs (called methods) and identifiers (typically urls), which is similar to what a file system is. It leaves the nouns (the body in HTTP) to the application, but it does promote some properties (headers in HTTP) and have conventions for common properties (content-type). The big difference between HTTP and most file systems is that HTTP is stateless, whereas many file operations are stateful (get a handle to a stream, write to a stream, close the stream).

HTTP would work as the API for a file system because it provides pretty good addresses for both local and remote and relatively low-level operations.

HTTP also has the benefit of being widely adopted, even during the Cairo development, which would have solved the chicken-and-the-egg problem from the first essay.

Using HTTP as a file system has key drawbacks: Applications would have to be re-written to use both the new APIs and new mindset of possibly high-latency operations. You can't always assume that a particular endpoint will be available, unlike many assumptions about inodes.

So, do I think they should have done this? Maybe, there were a lot of variables at play. But, I don't think it is a crazy idea to use HTTP as the file system, and I predict we will see a popular -- nay, credible -- operating system use it within the next 5 years.

And I also think it's telling that even in the post-mortem hindsight, the author fails to see alternatives that were widely available in the industry because they weren't invented at Microsoft.

I love this read, and I would love to read entire books of people from the trenches making software. However, most of the specific details Hal cites are... well... dated from someone who learned the craft in the 1980.

This line struck out to me as especially myopic:

> Most of the world of commerce we are used to was made possible by the creation and growth of the concept of Structured Storage. The modern world of Credit Cards and ATMs is 100% predicated on this work. Amazon.com was in the realm of science fiction in the 1940s. By the 1970s the conceptual basis for everything you needed to create it was in place. It took until the 1990s for those concepts to mature sufficiently to let Amazon happen.

I can't put my finger on why this seems wrong, and it could be such a strong contrarian view I need a moment to accept it. I feel like the 1990s .com boom AND the modern social boom may depend on structured storage, but structured storage certainly isn't the sufficient condition.

Reading through Hal's prose, it struck me that HTTP is the very thing Hal set out to build, and it seems that since he was so focused on file systems he missed another obvious technology choice from which to draw. Would it have been dog slow for every application to make local HTTP requests to read files? Heck Yeah. Is it insane? Yeah. Would it have been slower than what they built? I don't know...

And HTTP was so well understood and supported it would have allowed applications to start to mix content from local and remote sources, what we effectively have with pure JavaScript apps today. But HTTP was a standard, and Microsoft from those days was allergic to standards. Alas, someone will eventually build a JavaScript-based OS that treats all files as HTTP endpoints.

And then we'll get photos to sync with metadata. Just saying.

It's also weird that they didn't explain the how behind this line:

> Instead of serving images directly from their original external host servers, Gmail will now serve all images through Google’s own secure proxy servers.

In most cases, the unique identifiers are embedded in the URLs themselves, so simply serving through a proxy is ineffective. Should I blindly trust that you, Google, did the right thing?

Edit: looks like Google isn't stripping out the query parameters AND it isn't proxying for iOS devices! This is by far the least effective set of decisions... http://blog.movableink.com/gmails-recent-image-handling-chan...

I wonder if this change is a result of backlash over the promotions tab. These type of referenced images are most commonly used in marketing campaigns and were from businesses likely to pay good money to AdWords. As a concession for fewer overall impressions, perhaps, these groups got Google to let them track easier? The whole thing smells fishy.

> It's unclear if Amazon has actually started using Kiva, though.

Yeah. They use them a lot. A lot, a lot. It was cheaper to buy the company than pay to outfit every FC. All newish fulfillment centers ( http://www.amazonfulfillmentcareers.com/amazon-fulfillment/l... ) are divided into "kiva" and "non-kiva" areas. I think there is only one FC that is fully "kiva," but it may be as many as 3 now. Details are NDA.

Yes, many public stocks on major exchanges are just other forms of currency. It just depends on whether the underlying asset is highly liquid (which implies easy to trade, confidence it will exist in short and long terms, etc). I would humbly submit not to get hung up on the word 'virtual' since the practice of using stocks as a liquidity source (and at times to actually print money) have been done a few times in the past.

My favorite example is from the 1890s: Amalgamated Copper

Summary: http://www.jstor.org/stable/1884999

Book describing the process of getting banks to print money by ficticously reporting assets: http://www.gutenberg.org/ebooks/26330

Had the author written the book today, he would compare the practice to quantitative easing or injecting liquidity: http://en.wikipedia.org/wiki/Quantitative_easing

The big difference? Amalgamated Copper was a private entity whose owners used fraud and banks to print them millions of dollars.