What was Google thinking(Contains text from the blog) - <AUTHOR>

This is the text contained in http://blog.mocality.co.ke/2012/01/13/google-what-were-you-thinking/blog as written by Mocality CEO You can follow the blog link to read the full story(of which I propose since it is of better quality) but just in case you can't access the site here is some of the contents that the blog contains.
Note: Some resources such as images might be missing and also I didn't have enough time to format the content properly
<comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=== Links to some of the resources contained in the blog </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=== https://s3-eu-west-1.amazonaws.com/mocality-wordpress/audio/douglas.mp3 http://blog.mocality.co.ke/files/2012/01/Incoming_Call-Redacted-20111221-1133502.pdf </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=== I'm very proud of the business that we've created here at Mocality, but I'm especially proud of two things:
1. Our crowdsourcing program. When we started this business, we knew that (unlike in the UK or US, where you can just kickstart your directory business with a DVD of business data bought from a commercial supplier), if we wanted a comprehensive database of Kenyan business, we would have to build it ourselves. We knew also that if we wanted to build the business quickly, we'd have to engage a lot of Kenyans to help us. So we built our crowd program that utilises M-PESA (Kenya's ubiquitous Mobile Money system) to reward any Kenyan with a mobile phone who contributes entries to our database, once those entries have been validated by our team. Over two years, we've paid out Ksh. 11m (over $100,000) to thousands of individuals, and we have built Kenya's most comprehensive directory, with over 170,000 verified listings. Personally, I regard the program as one of THE highlights of my 18 year career on the internet. 2. From day 1, we aimed to target all Kenyan businesses, irrespective of size. As a result, for about 2/3rds of our listed businesses, Mocality is their first step onto the web. That's about 100,000 businesses that Mocality has brought online.
Please bear these two facts in mind as you read what follows.
Our database IS our business, and we protect and tend it very carefully. We spot and block automated attacks, amongst other measures. We regularly contact our business owners, to help them keep their records up-to-date, and they are welcome to contact our call centre team for help whenever they need it.
In September, Google launched Getting Kenyan Businesses Online (GKBO). Whilst we saw aspects of their program that were competitive, we welcomed the initiative, as Kenya still has enough growth in it that every new entrant helps the overall market. We are also confident enough in our product, our local team, and our deep local commitment that we believe we can hold our own against any competition, playing fair.
Shortly after that launch, we started receiving some odd calls. One or two business owners were clearly getting confused because they wanted help with their website, and we don't currently offer websites, only a listing. Initially, we didn't think much of it, but the confusing calls continued through November.
</comment><comment></comment><comment></comment><comment></comment><comment>== The Forensic analysis </comment><comment></comment><comment></comment><comment></comment><comment>==
What follows is necessarily a little technical. I've tried to make it as clear as I can, but two definitions may help the lay reader:

    IP Address – the numerical id by which computers identify themselves online.
    User-Agent - When a browser requests a page from a webserver, it tells the server what make, model, and version of browser it is, so that the webserver can serve content tailored to that browser's capabilities. Webservers keep a log of both these details for every page requested, allowing us to do interesting detective work.
 If you're not interested in the technical details, you can always jump straight to the Conclusion.
At the start of December we analysed our server logs to look for a common pattern for the businesses that had contacted us with these confused calls. We found a single IP/ User-Agent combination that had accessed all these businesses:
</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=== IP Address: 22.214.171.124
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=
The user agent is unusual for Kenya: the stable version of Google Chrome released on 20 September 2011, running on 32-bit Linux. With the exception of this IP, it barely appears in our logs.
We looked up the ownership record for 126.96.36.199 via WHOIS.
</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>===== % Information related to '22.214.171.124 - 220.127.116.11'
inetnum:        18.104.22.168 - 220.127.116.11 netname:        Fixed_Wimax-Fiber-Rollout-Central-Kenya descr:          Fixed Wimax and Fiber  Roll out for Central Kenya Region country:        KE admin-c:        OC406-AFRINIC tech-c:         OC406-AFRINIC status:         ASSIGNED PA mnt-by:         ONECOM-MNT remarks:        Wimax and Fiber  Roll out for Central Kenya Region source:         AFRINIC # Filtered parent:         184.108.40.206 - 126.96.36.199 </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>===== So a Kenyan ISP. But how were they accessing us? We did some analysis. Graph of accesses to Mocality.com from 126.96.36.199
Of the 65,851 requests, there were 33,261 requests to a Business Profile page, i.e. accessing the contact details for a business.
Further details:

    No evidence of automated scraping, this appears to be a team of humans.

    Since 3 Nov, requests originate from a WIMAX connection in Nairobi (18.104.22.168). Prior to that, various addresses.

    Business profile requests are referred by Mocality search result pages having 100 results/page

    Peak rates are 2500 pages per day (1.73 per minute)

    The User-Agent originated from many different IPs starting on 4 September, started scraping on 12 October, abrubtly stopped on 29 October, resumed on 3 November from the Safaricom Wimax IP.

    Pattern of access is mainly 8am-6pm Weekdays, a few hours on Saturday, and never Sunday.
    No other non-robot (IP,User-Agent) combination has such a pattern of activity at that scale (2500/day).
 So a person or (judging by the access rate) team of people were systematically accessing our database, during office hours, and it looked like they moved into a new office over the weekend at the start of November. But who were they, and what were they doing? The Sting
We decided to find out. We made some changes to the site:
For visitors from the 188.8.131.52 address, we changed the code to serve slightly different content 10% of the time. Instead of the real business phone number, we served a number that fed through to our call centre team, where the incoming calls would also be recorded. Our team were briefed to act like the business owners for the calls.
We switched the new code on December 21st.
When we listened to the calls, we were beyond astonished. Results
I'd like you to meet Douglas. On this call (first 2 minutes) you can clearly hear Douglas identify himself as Google Kenya employee, state, and then reaffirm, that GKBO is working in collaboration with Mocality, and that we are helping them with GKBO, before trying to offer the business owner a website (and upsell them a domain name). Over the 11 minutes of the whole call he repeatedly states that Mocality is with, or under (!) Google.
Between 10am and 1pm on December 21st, we received 6 others just like it (from 5 different Google Kenya employees) before switching back to normal service. We estimate that this team were calling 20-25 Mocality business per hour, since 7 calls over 3 hours, only 10% of calls redirected: 7*10/3= 23.3. calls/hour)
On all calls, the same script is followed – A Google Kenya employee calls a Mocality business and tries to deceive them into signing up for their competing product, by claiming that we are working together.
It gets worse: Here's a complete transcript ( with translation of the kiSwahili portions) of a another call, in which the caller goes further, claiming that Mocality engages in bait-and-switch practices to try and charge businesses upto Ksh. 20,000 ($200) for their listings. Mocality has never and will never charge for listings. The irony: on the same call, the caller tries exactly that tactic for GKBO's hosting fees.
I have redacted the details (except first name) of both parties on the call, and highlighted key sections in YELLOW. What happened next?
Having gathered our evidence, and needing to wait for transcription and translation (as parts of the conversations were in kiSwahili (the local East African language)) of the recordings , and feeling pleased with detective work, we had a lovely Christmas break. I started writing this blog post.
So that we had the latest stats on our return to work, we re-analysed the logs, on Monday 9th January.
There were no further accesses from the IP address 220.127.116.11 after 4pm 23rd December. Co-incidence? or had someone realised we were onto them?
However, there were some NEW strange messages from business owners- they'd apparently been contacted by a call centre in India with the same promise of a website.
So we reran the whole analysis. We quickly identified a new IP/User-Agent combination.
 Results (2)
We found another IP address and User-Agent that accessed two businesses that had been contacted:
IP Address: 184.108.40.206
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
WHOIS Information
NetRange:       126.96.36.199 - 188.8.131.52 CIDR:           126.96.36.199/16 OriginAS: NetName:        GOOGLE NetHandle:      NET-74-125-0-0-1 Parent:         NET-74-0-0-0-0 NetType:        Direct Allocation RegDate:        2007-03-13 Updated:        2007-05-22 Ref:            http://whois.arin.net/rest/net/NET-74-125-0-0-1
OrgName:        Google Inc. OrgId:          GOGL Address:        1600 Amphitheatre Parkway City:           Mountain View StateProv:      CA PostalCode:     94043 Country:        US RegDate:        2000-03-30 Updated:        2011-09-24 Ref:            http://whois.arin.net/rest/org/GOGL
OrgAbuseHandle: ZG39-ARIN OrgAbuseName:   Google Inc OrgAbusePhone:  +1-650-253-0000 OrgAbuseEmail:  email@example.com OrgAbuseRef:    http://whois.arin.net/rest/poc/ZG39-ARIN
OrgTechHandle: ZG39-ARIN OrgTechName:   Google Inc OrgTechPhone:  +1-650-253-0000 OrgTechEmail:  firstname.lastname@example.com OrgTechRef:    http://whois.arin.net/rest/poc/ZG39-ARIN
These new accesses were coming directly from Google's network.
The IP address 22.214.171.124 made 17,645 requests (15,554 to BusinessProfile.aspx). Activity really kicked off on 22 December 2011, with 8 different user agents mostly running Chrome on Linux: The top 3 are :

    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7 11249 64.268982
    Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 4247 24.264412
    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/10.04 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2 1000 5.713306
 Search for "tag=mo.request 188.8.131.52″ from 20 December 2011 to 9 January 2012. Found 17,049 requests
Graph of accesses to Mocality.com from 184.108.40.206
On 10th January, we re-enabled the Sting code. Again, within a couple of hours, we'd received calls from the new call centre to our dummy numbers.
Here is Deepthi, from Google India. On this call, you can hear her talking about her partnership with Mocality, and offering us a free website.
It looks like Google has now outsourced the Getting Kenya Businesses Online operation to India!
Conclusion
Since October, Google's GKBO appears to have been systematically accessing Mocality's database and attempting to sell their competing product to our business owners. They have been telling untruths about their relationship with us, and about our business practices, in order to do so. As of January 11th, nearly 30% of our database has apparently been contacted.
Furthermore, they now seem to have outsourced this operation from Kenya to India.
When we started this investigation, I thought that we'd catch a rogue call-centre employee, point out to Google that they were violating our Terms and conditions (sections 9.12 and 9.17, amongst others), someone would get a slap on the wrist, and life would continue.
I did not expect to find a human-powered, systematic, months-long, fraudulent (falsely claiming to be collaborating with us, and worse) attempt to undermine our business, being perpetrated from call centres on 2 continents.
Google is a key part of our business strategy. Mocality will succeed if our member businesses are discoverable by people via Google. We actually track how well our businesses place on Google as a key metric, and have always regarded it as a symbiotic relationship. We are in the business of creating local Kenyan content that Google can sell their adwords against. More than 50% of our non-direct traffic comes via Google (paid or organic). For us, the cost of going elsewhere is NOT zero.
Furthermore, we spend a very significant sum on advertising with Google Kenya. I wouldn't be surprised if we are one of their largest local customers, between Mocality and our sister site Dealfish.co.ke.
Kenya has a comparatively well-educated but poor population and high levels of unemployment. Mocality designed our crowd sourcing program to provide an opportunity for large numbers of people to help themselves by helping us. By apparently systematically trawling our database, and then outsourcing that trawl to another continent, Google isn't just scalping us, they're also scalping every Kenyan who has participated in our program.
I moved to Africa from the UK 30 months ago to be CEO of Mocality. When I moved, Kenya's reputation as a corrupt place to do business made me nervous. I've been very happily surprised- until this point, I've not done business with any company here that was not completely honestly conducted. It is important for global businesses to adapt to local cultural practice, but ethics are an invariant. As a admirer of Google's usually bold ethical stance around the world, to find those principles are not applied in Kenya is simply… saddening.
Someone, somewhere, has some questions to answer.
These are my personal top 3:

    If Google wanted to work with our data, why didn't they just ask?
    In discussions with various Google Kenya/Africa folks in the past, I'd raised the idea of working together more closely in Kenya. Getting Kenyan businesses online is precisely what we do.
    Who authorised this? Until we uncovered the 'India by way of Mountain View' angle, I could have believed that this was a local team that somehow forgot the corporate motto, but not now.
    Who knew, and who SHOULD have known, even if they didn't know?
 Stefan Magdalinski Nairobi, Kenya
email@example.com +254710103500 </comment><comment><USER2> Already on frontpage:

Here: <https://news.ycombinator.com/item?id=3460033>

And here: <http://news.ycombinator.com/item?id=3459966>

</comment><comment> Tim-Boss I hope its just a random error that keeps getting the discussions and links to this article killed and not something a bit more systematic... or "evil"....</comment>


MacBooks Enter a Golden Age of Anti-piracy Cruft: HDCP For All - <AUTHOR> http://www.techcrunch.com/2008/11/18/macbooks-enter-a-golden-age-of-anti-piracy-cruft-hdcp-for-all/

<comment><USER2> Open any LCD monitor. The ribbon cable which connects the VGA/DVI/HDMI decoder board to the LCD panel itself (a separate product, of which there are only a few manufacturers) carries an entirely unencrypted and fairly well-documented signal. With an <$100 FPGA, any HDMI monitor can be turned into a decryptor.

<comment><USER3> You're right that it's unencrypted, but I don't think it's well-documented. Every single panel manufacturer seems to have their own spec for carrying data to the LCD panel proper, and this is all proprietary and not-published. Short of someone reverse-engineering the data it's not quite SO easy to get your data.

<comment><USER2> All you need is an oscilloscope. (My 1979 HP 300Mhz scope would do fine, had I more free time.)

</comment></comment></comment><comment><USER4> I would be sooo pissed if the movie i downloaded wouldn't play on my regular TV or projector I setup or something. I don't understand why they would require encryption for an analog out? Even a digital out. The movie-cracker people do everything in software anyway, so it seems like there's really no point in encrypting the transmission link.

<comment><USER5> Movie crackers won't necessarily be doing everything in software for long; several major software media components --- like iTunes, Windows Media Player and Windows protected media pathways --- remain effectively unbroken. DRM is steadily improving, to the point where the "analog gap" is becoming more important.

<comment><USER6> Don't they remain unbroken only because there are currently paths of lesser resistance? And iTunes is already routinely hijacked to strip DRM from the iTunes Store.

<comment><USER5> iTunes is _not_ "routinely hijacked". The current incarnation of iTunes DRM hasn't had a published break since iTunes 6, several years ago.

The conventional wisdom maintains that all DRM schemes can be broken, and that's true, if you ignore cost. It is far from proven that all DRM schemes can be broken with costs proportional to the rewards.

<comment><USER7> The current iTunes DRM for music has been broken. Google Requiem.

<comment><USER5> Ah, I didn't see 1.8.1. Thanks. And you're right, Brahms broke iTunes 7.

</comment></comment></comment></comment></comment></comment><comment><USER8> Does anyone else think that this is incredibly creepy? If this goes on unchecked, it's just a matter of time until you're not allowed to code unless you have a license from the RIAA...

<comment><USER9> Well you are not allowed to code for the iPhone unless you have a license from Apple.

I wonder when they will do the same to their desktop computers. It is not as if companies haven't tried that scheme (see Microsoft "certified software" and stuff like that).

<comment><USER7> You can code without paying for the dev certificate. The SDK is a free download.

You just can't put apps on the app store or your phone without having a cert. There's a slight difference.

<comment><USER9> Well I guess even in the future we will still be allowed to play air guitar, as long as we don't whistle along with the tune.

</comment></comment></comment></comment><comment><USER10> Great. Now we have to get modchips for our laptops too?

</comment><comment><USER11> You can find more MacBook hacking stories here - <http://www.applemacbook.com/mods>

</comment><comment><USER12> The irony is if you're geeky enough to connect your computer up to a big display to watch movies etc, you're certainly geeky enough to circumvent a little popup warning.

<comment><USER13> HDCP is implemented in the video card. The output is encrypted and the HDCP certified device decrypts.

However, ultimately the OS either enforces it or doesn't. And the OS has been pretty weak so far.

Addenda: I'm not talking about iTunes, I'm talking about the OS, which iTunes uses to display video.

<comment><USER14> No need to hack iTunes, just download the movie in a DRM-free format. I've heard that there are places on the Net that has things like that, something with pirates and a bay?

But sure, if the Blu-Ray replacement happens to have a working protection system they might finally pull it off. Too bad for them that the last part of the delivery chain will always be unprotected, unless they find a way to put HDCP in Eye 1.0 wetware.

<comment><USER15> > Too bad for them that the last part of the delivery chain will always be > unprotected, unless they find a way to put HDCP in Eye 1.0 wetware

That won't help you record it if there is sufficient pressure on the small number of manafacturers of recording devices:

I would imagine it would be possible to create something like a EURion for video and audio.

<http://en.wikipedia.org/wiki/EURion_constellation>

<comment><USER16> I think it would actually be a lot harder to apply something like EURion to video or audio, because of user expectations. Video and audio recorders are not expected to duplicate an existing artifact but to make a record, something you usually only get one chance to make. A EURion measure would be prone to abuse, breaking the user expectation that the given event had been correctly recorded.

The obvious example: What if a guy robbed a bank wearing a EURion t-shirt? None of the security cameras would record him, unless you had some exception for security cameras. And once you have an exception for security cameras, do you have an exception for, say, home security cameras? If so, anyone will be able to get a circumventing camera; if not, a lot of people will be upset.

<comment><USER15> I don't know how varied the possible DRM policies are, but it would seem possible to implement a 'generation counter' for DRM'd media which would restrict the number of copies.

e.g. the output of a video camera could be tagged with "allow 3 copies only". Each DRM-aware copy produced would decrement the # of allowed copies. The copied file would have an allowed-count of 0.

If a EURion-like image triggered this mode on the camera then that would probably be sufficient for manufacturers to avoid liability, but still serve to effectively close the "analog hole" (not really analog, but hey).

Yes, it all does seem unlikely. But so does tagging of printer output with yellow dots and EURion, and DRM in general.

<http://en.wikipedia.org/wiki/Printer_steganography>

<comment><USER17> It wouldn't work. This has all the problems of DRM in addition to all the problems of pattern recognition. Not a chance.

<comment><USER15> The problems of DRM are the ones facing us right now. Sure, individual implementations are buggy. If there's pressure, that'll improve over time.

The basic technical approach of the current DRM systems is sound, which is why they're a problem. High quality implementations would restrict people.

In terms of pattern recognition, you're not exactly doing facial recognitiion. The hard part would be putting a signal in there which was:

\- distributed through the whole picture (so you can't just mask off the logo in the corner)

\- sufficiently unobvious to humans threshold so that quality doesn't go down too far. Dunno about this one, apart from the fact that we have a _lot_ of bandwidth here to hide a signal

\- could survive basic disruption attempts by 'hackers' (colour filters etc)

It is a fairly tall order, but so is convincing the entire PC parts industry to put crypto in all their components against the interests of their customers.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> HDCP only matters to people who support DRM with their money.

Disclaimer: Not me.

<comment><USER19> My thoughts exactly. I only purchase media that is DRM-free. Amazon's MP3 store for instance. If they want to make more money they can start by offering more content as DRM-free because otherwise I'm not buying…

<comment><USER9> Is Amazon DRM free? Doesn't it encode the name of the buyer in the MP3? (I honestly don't know, it just seems likely they do that).

<comment><USER20> Encoding the name of the buyer in the MP3 is not DRM. It doesn't restrict your usage of the media in any way. If they do that, I fully support it.

<comment><USER9> It restricts your ability to sell the MP3. I can sell a CD, which to me factors into the price (assuming I could sell the CD for half of the new price eventually).

<comment><USER21> Color me unimpressed. Encoding a buyer's name is fair game. You still have full control of the info you got.

<comment><USER9> I didn't say that it is not fair, but I think it definitely is DRM. So maybe it is an example of fair use of DRM.

I still prefer my MP3s name-free, but that only means that I would pay more for name-free than for named MP3s.

<comment><USER22> DRM stands for digital rights management. Encoding your name doesn't manage your rights in any way.

<comment><USER9> Maybe it doesn't enforce them, but suppose the police scans my computer and finds lots of MP3s signed to Matt Maroon, would it really not matter? (Honestly I don't know - but if it doesn't matter, why encode the name to begin with?).

<comment><USER22> Honestly my argument was more semantics. It's not DRM. It's something else, and certainly less odious. All they're doing is creating a way to track illegal activity.

I wonder what the laws are on selling the track and then deleting it though. Is that as legal as selling a cd, or do you get sign some sort of legal agreement when you purchase the track? I've never purchased a single track online so I don't know much about that.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Want to be a VC?  Try Being an Early Adopter First - <AUTHOR> http://jonathancavell.com/wordpress/technology/2010/03/want-to-be-a-vc-try-being-an-early-adopter-first <comment><USER2> "Wanna be a VC? Just follow Techcrunch!"</comment>


They're all doing it wrong: tablet ads - <AUTHOR> http://www.naelshawwa.com/pretty-bad-tablet-ads/

<comment><USER2> Though the post is correct in many instances, I think only the first Apple ad is a good example of Apple's marketing. The other two ads show the product in use, but don't give that 'I want to do that' feeling. Possibly because they aren't explaining it.

The Xoom add is HORRIBLE. I don't think that Blackberry ad was ever an officially released Playbook ad. I'd say the newer playbook ads are similar to the second and third ipad ads in the post, as they don't give the viewer enough interest. <http://www.youtube.com/watch?v=pBwxJAqypAI></comment>


Just ship it - <AUTHOR> http://scene-si.org/2015/06/23/just-ship-it/

<comment><AUTHOR> Just to add it here: I am interested in your opinion and experience about shipping software and getting clients. I know I have much to learn (or unlearn as it were) to hack out MVPs to gauge interest & monetize it if there is some. Any self-published self-made person on here can give valuable advice or share experience. I am listening ;)</comment>


Ask HN:  Where is a template for corp docs used to form LLC - <AUTHOR>

I am starting a company with a colleague and would like to make sure I have my points covered.
An attorney is in order, for sure.  But I would like to review a sample doc or even an outline of the points that need to be covered.
Does anyone has a resource for this?
Many thanks!
AD <comment><USER2> What you are probably looking for is an Operating Agreement.

Ask google to show you: "operating agreement llc California"

I don't have anything to share unfortunately.

EDIT: Also think carefully if an LLC in the correct type of entity vs corporation. Investors generally prefer an corp vs and LLC and you will likely need to change the type if you raise money but it's not that large a deal I'm told.

</comment><comment><AUTHOR> We are based in California.</comment>


New green tech generates electricity 'out of thin air' - <AUTHOR> https://phys.org/news/2020-02-green-technology-electricity-thin-air.html <comment><USER2> From the linked Nature abstract:

> The devices produce a sustained voltage of around 0.5 volts across a > 7-micrometre-thick film, with a current density of around 17 microamperes > per square centimetre.

How good is that? They talk about powering smart watches with this, and other personal electronics. So it sounds like it's within range of a useful amount of power?</comment>


How Chromium Works - <AUTHOR> https://medium.com/@aboodman/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b <comment><USER2> Chromium continuous build infrastructure engineer here.

As he says, this is slightly out of date: we forked WebKit to make Blink in 2013, and actually merged Blink into Chromium proper just this week! It is no longer managed by gclient/DEPS, but instead developed alongside Chromium in the same repository. But many other things (pdfium, v8, webrtc, and tons of smaller libraries) are still pulled in via DEPS in exactly the way described.

I'd just like to say this about our development, testing, and release process: it really really works. We keep moving fast, everyone knows what's going on throughout the codebase because everyone is working on master, and there are never any big ugly merge conflicts to resolve when new features land.

There are, of course, problems with the system. We don't have enough resources to run every test for every commit, so they end up batched and we have to rely on humans and heuristics to determine which CL in the batch to revert. The set of configurations on the try-bots doesn't exactly match up with the set of configurations that are run against tip-of-tree. And flaky tests are, of course, a perennial problem for everyone. But we're working on making all of these better, and huge progress has been made in the last couple years.

Ask me anything if you have any questions about our build and test infrastructure!

<comment><USER3> This is only tangentially related to the topics covered in the article and your comment, but I'm curious about the Chromium project's decision to mostly use static linking.

I've always found it interesting that Chrome is shipped mostly as one big binary (or on Windows, two: chrome.dll and chrome_child.dll), whereas IE and Safari use several (one for the rendering engine, one for the JS engine, one or two for networking, etc.). My guess is that Chrome uses one big binary to minimize startup time, since the OS can just map that binary into memory and go. Am I correct about the rationale? Another way to ask the same thing is this: what would be the downsides of using a component build for releases and not just for development? If you used a component build for releases, you'd have greater parity between dev and production, and that's generally a good thing.

I also notice that there are a few modules that get their own DLLs, at least on Windows. For example, in Chrome 45, we have chrome_elf.dll, libegl.dll, libexif.dll, and libglesv2.dll; I'd think these libraries could be statically linked just like the few hundred others. Are there good reasons for these exceptions? Or are these just little details that tend to get overlooked given the rapid pace of development?

<comment><USER4> Like Aaron mentioned, the renderer was originally split into a separate DLL because we hit the limits of Microsoft's linker at the time. Later, we ended up relying on that split for disabling win32k inside the sandbox (otherwise we would have had to deal with a bunch of broken USER and GDI initializations).

As for the remaining DLLs, it mostly comes down to licensing concerns. We don't include proprietary code in our main binaries, and in order to simplify IP concerns it's often best to split such code into other DLLs. For example, you asked about libegl.dll and libglesv2.dll, which I believe include a licensed copy of the SwiftShader library.

It's also worth pointing out that the performance impact of having a single, static binary in Windows is much less significant than it used to be. So, were we starting Chrome today I'm not so sure we'd make the same decision.

</comment></comment></comment><comment><USER5> I've contributed to Chromium recently and was amazed by how quickly and painlessly everything was.

I expected to run into a lot of problems with building, missing dependencies etc. but it just worked. This despite the fact that the fully checked out source is 37Gb!

I can highly encourage beginners to take a stab at contributing to Chromium, you can learn a lot.

</comment><comment><USER6> This was a positive read! About the stress and modularization. It's important that developers feel they are an important part of the team. But if they are working for free, it needs to be fun and not feel like work. Interacting with others are fun! But not if it gets out of control. So when you modularize, you should try to make a balance for human interaction in mind. Maybe keep the number of module interaction down below five at any given time, example: When a new feature is added, max five modules should need updating.

Sometimes we forget that we are making software for humans, by humans, and not for compilers and computers.

</comment><comment><USER7> How does Google get away with not ever supporting previous releases? Don't customers demand this?

<comment><USER2> A nit to pick here: Google releases Chrome, not Chromium. We only provide Chromium as a source repository, not binaries. Other independent entities (such as Linux distros) can provide releases of Chromium, but Google does not.

That said, Google doesn't support previous releases for security reasons. We are constantly improving the security profile of Chrome, and hackers (both black hat and white hat) are constantly finding exploits in older versions. (The same is true for all the other major browsers on the market.)

If you want to use Chrome on a previous/older release, please don't. If you want to use Chromium on a previous/older release, also please don't, but you can compile it yourself if you're so inclined.

And for the most part, no, customers don't demand stable old releases of Chrome. They've learned how bad of a security and usability mistake that is from IE6, and they don't want to repeat past mistakes any more than we do.

<comment><USER8> > And for the most part, no, customers don't demand stable old releases of > Chrome. They've learned how bad of a security and usability mistake that is > from IE6, and they don't want to repeat past mistakes any more than we do.

I suspect that there are lots of enterprise customers that _haven 't_ learned that ( _encountered_ it, but not _learned_ it), but they probably aren't _Chrome_ customers, since they are still using IE.

<comment><USER9> While we acknowledge some people might think they want this feature, it's been something we've been unexcited about helping them with it for the reasons stated. Having the ability to quickly deploy security fixes is fundamental to Chrome's ethos. This is as close to a point of religion for the Chrome team as you can get.

<comment><USER10> I suspect IT customers actually wanted something in between the two extremes. Your existing IT customers may feel okay about it now, but could change their minds if, for example, a fairly drastic UI change is pushed out.

</comment></comment></comment></comment></comment><comment><USER11> feature toggles: do you use them?

my experience with projects that do trunk based development, i.e. a single branch and time-based releases, is that not all features can be ready when the release bell "rings", and something is necessarily half-baked. So you end up enclosing some code into "if (FEATURE_READY) {...}" so that it's there, but it isn't executed until a few releases later.

This carries some problems, like the explosion of the quantity of toggles over time, dead code that nobody cleans up, etc.

<comment><USER2> As the article states, Chromium uses run-time checks (feature toggles) extensively. This lets half-baked features land and start undergoing testing before the feature is ready to be shown to the world.

But we don't say "oh no, this feature isn't ready, let's wrap it in checks". The feature is wrapped in checks from the very first commit, so that everything stays stable on master and on any release branches which are cut from master.

Then, when the feature is ready for prime-time, the developers working on it go through and remove the checks. So they don't accumulate in the codebase.

<comment><USER12> Don't you end up with exponentially many combinations to test?

<comment><AUTHOR> The feature team is responsible for ensuring their in-progress work is sufficiently tested. This usually means that all their tests are run from the beginning of the features life. So, we don't end up testing every combination of features, but instead the union of all features.

With good software design practices we don't usually find bugs that only occur with some specific non-total combination of features. But of course it does happen.

The article isn't a way to make provably correct software; it's a way to keep the wheels on a massive, fast-moving project -- barely :).

<comment><USER12> Sure, which is why I'm interested - I work on a massive, fast-moving (proprietary) project, and team and feature branches are a vital part of the workflow, and merges seem less costly than the risks of feature flags.

(Of course, the Knight incident being fresh in our minds, our assessment of those risks might not be entirely objective)

</comment></comment></comment></comment></comment><comment><USER7> >We run a public buildbot that constantly runs new changes to our code against our test suite on every configuration...

In perforce terminology how is this done? You could use branches, but you could also shelve the change and have the build-bot unshelve it and test.

>We also have a commit queue, which is a way to try a change and have it landed automatically if the try succeeds

What happens if the change becomes incompatible due to other changes over the course of running the test? I assume the commit just fails in this case..

<comment><USER2> Well, we don't use perforce (we use Git), so I assume you're asking for your own benefit.

The buildbot masters watch the source repository for new commits. When they see a new commit appear, they tell all of their builders (each one representing a different build configuration) to do a build+test sync'ed to the new commit hash. The builders check out the repository at that revision, compile, and upload the binaries for the testers. The testers then download those binaries, test, and report results. Then we have a display (build.chromium.org) which shows the results of the compiles and tests on each configuration for all of the recent commits.

It's actually pretty rare for a patch to become unlandable while the tests are running. But if it does, it just sends a message to the owner of the change that says "Hey, your patch failed to land due to merge conflicts. Please rebase and fix them, then try again."

</comment></comment><comment><USER13> Maybe it's time to try chrome again, it felt heavy and memory-hungry for me and I always ended up with using FF solely.

</comment><comment><USER14> Can you click this link for me? [http://a/%%30%30](http://a/%%30%30)

</comment><comment><USER15> how chromium works after google jumped in: ignoring users and maximizing google monetization.

e.g. [https://code.google.com/p/chromium/issues/detail?id=84177](https://code.google.com/p/chromium/issues/detail?id=84177)

(i also tried to find all the commits or issues where all the 3 ways to disable sending referrer headers were removed over time, but obviously, there are no issues and the commits are probably mixed up with other things)

<comment><USER16> \--no-referrers works just fine....

<comment><USER15> that one have been in and out the code base several times</comment></comment></comment>


Evaluating an Industry that Doesn't Exist - <AUTHOR> http://www.fightaging.org/archives/2009/11/evaluating-an-industry-that-doesnt-exist.php

<comment><USER2> "The sudden cracking in 2005, referred to by geologists as a "mega-dike intrusion", opened up a rift over 20 feet wide in places."

Scientists seem to be the only group that don't have to worry about their terms being PR (politically correct). Science terminology trumps social word transformations.</comment>


First look: Qt 5 makes JavaScript a first-class citizen for app development - <AUTHOR> http://arstechnica.com/business/news/2012/04/an-in-depth-look-at-qt-5-making-javascript-a-first-class-citizen-for-native-cross-platform-developme.ars <comment><USER2> I've used Qt for a few years, and I feel like the move away from C++ is a mistake. I don't see the advantage of QML over HTML and Javascript.

<comment><USER3> I wouldn't really call this a "move away from C++", necessarily. In practice, you end up writing your backend in C++ and your frontend in QML; the backend proffers data models the QML then pours into a user interface.

As for the advantages of QML over HTML and JavaScript - well, a sane layout model for one, proper support for modules/packages, ...

<comment><USER4> Exactly.

I have been writing a QML application the past couple of months. I have written a lot of real time C++ then tied it together with QML. It has given me a flexibility in how the components interact, being able to change functionality with little effort has allowed me to have low turn around when the design has evolved.

The application is such (embedded hardware with video playing) that not many solutions have both the agility and performance that QML offers me.

Gee sounds almost like marketing copy, but it is true!

<comment><USER2> Could the same thing be done using plain HTML inside a QWebView?

Honestly, I should probably look into it a little more before asking questions like these, but so far I've just got the impression it's not worth the time...

<comment><USER5> No, the same thing can't be done using plain HTML (+ Javascript and CSS). You can get result that visually and functionally looks the same but it will be very hard to get desired result (it is not worth the time), e.g. have you ever tried to get window height in HTML and do something with that? Actually I would love if I could use QML instead of HTML in browser in some cases. HTML and QML has quite different purpose: HTML is for documents that can be styled using CSS, while QML is for UI. Web apps could benefit from QML a lot if we could use it in browser. However I guess there is no interest for that most probably, because with FireFox you can write web apps using XUL for at least 6 years already (if not more) - the only problem is that apps will not be cross- browser.

</comment></comment></comment></comment></comment><comment><USER6> Cross-platform mobile development isn't still mature enough, and for Nokia it would be a winning move to create a great tool that allowed developers to easily create apps for iOS, Android, and then whatever OS will run on Nokia phones.

<comment><USER3> Over at KDE, we're hosting the development of an Android port of Qt, dubbed Necessitas. There's also a port to iOS underway elsewhere.

</comment></comment><comment><USER7> Did anyone notice the similarity to the announcement made with Windows 8 i.e. JS becoming a 'first class citizen' when developing apps ... [http://www.readwriteweb.com/hack/2011/09/build-2011-html5-js...](http://www.readwriteweb.com/hack/2011/09/build-2011-html5-js- first-clas.php)

seems like MS and Nokia are both trying to attract JS developers.

</comment><comment><USER8> I hope they will at least look at XUL to try and understand what is good and what is suboptimal in that space.

This sounds like a great thing (less C++ means wider availability of potential developers), but I will be really sad for my industry if QML ends up running into the same landmines that XUL has already uncovered.

</comment><comment><USER9> Didn't GTK3 kind of already do that?

<comment><USER3> Not that I know of. Gnome Shell makes heavy use of JavaScript, but in a way unrelated to GTK+ itself. JavaScript bindings are of course also nothing new in the Qt world; KDE has had KJSEmbed for many years to write KDE/Qt apps in JavaScript, and Qt itself offers QtScript to generate ECMAScript bindings to Qt APIs for years as well.

Qt 5 goes quite bit beyond simply allowing you to access traditional C++-style APIs from JavaScript, however, it essentially implements an all-new UI toolkit based around a declarative language dubbed QML that is actually JavaScript and lets you jot down UIs and their behaviors in a sort of JSON-plus-logic fashion.

</comment></comment><comment><USER10> Any thoughts on how this development would affect PyQt which provides Python bindings to Qt ?

</comment><comment><USER11> a good call</comment>


Show HN: A/B testing baked into RequireJS - <AUTHOR> https://github.com/tonyhb/require-abtest

<comment><AUTHOR> If you're still using RequireJS and not browserify I built this to help out with A/B tesing.

Saves us from writing boilerplate JS code in our app — we just A/B test different modules and functionality by adding "test!" in front of our dependencies. Hopefully it can help you, too.</comment>


New app by Secret: Ping - <AUTHOR> http://iamping.com/

<comment><USER2> So... a landing page that tells me nothing, with nothing but links to the app store. Going against my usual behavior, I click the link to the app store and I get two useless screenshots and a description of "You're going to like me."

I think I'm getting old, because I just don't get it.

<comment><USER3> It is my personal mantra that if a startup has a particularly unintuitive UI/UX behavior, it's a form of "growth hacking" that my feeble brain cannot comprehend.

</comment></comment><comment><USER4> An app that further abstracts the problem of simply being alerted to interesting things happening in the world that you might be interested in. This sort of thing seems like an inevitable consequence of a rapidly expanding network filled with free, lightweight content that is usually not very important. People can't even be bothered to visit Buzzfeed or Upworthy anymore, even on a feed reader. Don't blame them.

</comment><comment><USER3> This is essentially a pivot by Secret after the original app failed due to the removal of submitting your own photos and meaningless polls. The app ratings have cratered: [http://i.imgur.com/qjLLlFb.png](http://i.imgur.com/qjLLlFb.png)

Case point: there is _zero_ mention on the website that this app is made by Secret.

EDIT: I downloaded the app. This is literally the entirety of the app: [http://i.imgur.com/6SETNaT.png](http://i.imgur.com/6SETNaT.png)

I wish I could retract my upvote now.

<comment><USER5> Yeah I was a huge fan of Secret in June and now I don't even open it.

</comment></comment><comment><USER6> Wow that is an obnoxiously useless landing page and description. Here's some actual information on it: [https://medium.com/@bn/introducing- ping-7f9403352764](https://medium.com/@bn/introducing-ping-7f9403352764)</comment>


America's Wind Energy Future Looks Seaward - <AUTHOR> https://www.nrel.gov/news/features/2017/americas-wind-energy-future-looks-seaward.html?utm_source=NREL+News&utm_campaign=45bf66e49f-EMAIL_FS_Offshore-Wind_2017_10_30&utm_medium=email&utm_term=0_807f77e7f4-45bf66e49f-282463161 <comment><USER2> The US has a ludicrous amount of sparsely settled farmland in the interior. Why not just build more windfarms there? That dramatically reduces the cost and technical challenges. Yes, there are transmission losses to factor in, but at least based on the wikipedia article it seems like those aren't necessarily dealbreakers.

[https://en.wikipedia.org/wiki/Electric_power_transmission#Lo...](https://en.wikipedia.org/wiki/Electric_power_transmission#Losses)

Is there anyone with expertise in the subject that can weigh in?

<comment><USER3> Energy created in unequal bursts is highly inefficient to transport long distances - those sparsely populated places are not necessarily where you need to be getting _to_. Getting those bursts of electricity intermittently is not ideal and utility companies wouldn't be running towards the opportunity

<comment><USER4> Is it, though? China built some high capacity long-distance transmission lines for wind with relatively low losses. Obviously costs are higher if the line is only used for 6h a day but that doesn't mean that transmission isn't efficient.

<comment><USER3> I should have specified that I meant economically inefficient. It may be technically efficient, but the low load factor (I would be surprised if wind is more than around 20-25% operational) would make transmission line that much more expensive to install than a similarly sized facility with a higher load factor

</comment></comment></comment></comment><comment><USER5> A lot of interesting engineering research into floating offshore wind is being done at University of Maine. They have some prototypes producing power. Understanding the characteristics of the carbon composites has, AFAIK, been the major limiting factor in their more widespread production.

[https://composites.umaine.edu/offshorewind/](https://composites.umaine.edu/offshorewind/)

<comment><USER6> They desperately need to get a proven production model into the water. There are working fields already deployed: [https://arstechnica.com/science/2017/10/first-floating- wind-...](https://arstechnica.com/science/2017/10/first-floating-wind-farm- built-by-offshore-oil-company-delivers-electricity/)</comment></comment>


Ask HN: How are you making JavaScript websites (not webapps) - <AUTHOR> There are plenty of great frameworks for single-pages applications (Angular, Ember, Backbone, ...) that each offer their own interpretations on how to develop. Take Ember for example (only because I am familiar with it). It provides you with all of the scaffolding and plumbing you need for most SPA requirements. It is opinionated on how to structure and build your application and offers tools and abstractions to do so. I like this as it takes a huge number of decisions out of the process when building a new app so that you can concentrate on being productive.
When building vanilla websites though, you are largely left to develop that structure yourself. These websites need Javascript but aren't entirely powered by Javascript. You can use tools and libraries (Grunt, gulp, bower, SASS, coffeescript, ...) but how you use them is really up to you. When the website gets large enough, these home-made solutions generally get complicated and difficult to maintain. There doesn't seem to be a framework or approach aimed at plain websites that don't want single page functionality.
How are you creating your website frontends? <comment><USER2> I am using giant which is new in market and very robust [http://blog.codesupport.info/category/giant/](http://blog.codesupport.info/category/giant/)</comment>


Ask HN: Common or important programming compromises - <AUTHOR> As a beginner-intermediate programmer, I'm starting to get a feeling that a better programmer is someone who is more consistently aware of the consequences of the decisions that they're making when they code. In other words, someone who has reduced their unknown unknowns.
Examples that I've come across personally are knowing the consequences / differences between: An array and a hash table (I come from a non-compsci background, and was exposed very late to hash/dictionary structures); An operational vs a relational database, and when to (de)normalise your data; Using a new language better suited for the job vs the upkeep of adding another language to the codebase.
To the collective experience of HN: what are some common or very importance consequences that you've come across?
P.S. please don't feel limited to technical details. I haven't been exposed to the start-up or internal political side much, but wouldn't mind picking up hints and details <comment><AUTHOR> A compromise I haven't figured out yet:

When is it better to import a library for a function vs copy just the source code for that function (with attribution, of course).

<comment><USER2> If you think the function may improve in the future, import the library, if not; copy the code. Remember that you will not go back later to see if there is a new version to copy in.</comment></comment>


Houston floods show risks of ignoring science and letting developers run rampant - <AUTHOR> https://qz.com/1064364/hurricane-harvey-houstons-flooding-made-worse-by-unchecked-urban-development-and-wetland-destruction/ <comment><USER2> The whole thing gets crazy when you realize the federal government was basically subsidizing development in these high risk flood areas. The federal flood insurance rates were not properly evaluating the risk to insure these areas. They were using older flood maps which don't account for changes in urban sprawl and global warming

[https://www.vox.com/2017/8/26/16208230/hurricane-harvey- floo...](https://www.vox.com/2017/8/26/16208230/hurricane-harvey-flood-damage)

<comment><USER3> You may be correct about the subsidies. I don't know enough about it. What I do know is a 1-3% increase in insurance premiums wouldn't have changed the behavior of home buyers here. All along I thought my house was in a 100 year flood plain (plane?). This week I found out it's not even in a 500 year flood plain.

<comment><USER2> I'm certainly no expert

My back of napkin math says they are $48k short per household.

But ya, Harvey would have been devastating regardless of past insurance policy pricing.

</comment></comment></comment><comment><USER3> Yes pouring concrete damn near anywhere along the gulf coast is destroying a wetland area. You caught us red handed. Guess how much difference it would have made if the Houston area didn't have a single cubic yard of concrete. We got a fuck ton of rain. Who the fuck are these people?

Developers "run rampant"? Really let's have an in depth look at how our understanding of storm water dentition and runoff has evolved over the past 50 years of explosive growth here. Let's analyze building codes and how they've evolved here. Nah, let's just use this as a stick to beat our pet issue with.

We've had three 500 floods in 12 years.

Seriously. Fuck off. Everybody wants to project their pet issue onto us. These people don't care what's actually going on here, what our actually challenges are and what we've been trying to do about it for the past 50 fucking years.

<comment><USER4> "These people" cannot comprehend what 3 feet of rain does to a city, because nothing like this has happened in recent history.

</comment></comment><comment><USER5> I was told in the Netherlands they have large areas designated to be flooded in case of any emergency. People still live there, but know that they are in the flood zone. I can't find a map of this at the moment though.

<comment><USER4> Great idea!

I would like to see what happens to their dyke system when 3 trillion gallons of water pours in. Don't think it would end well.

<comment><USER6> I think you mean dike. You may still be able to edit it.

<comment><USER4> Probably

</comment></comment></comment></comment><comment><USER7> Using this storm as an opportunity to promote your pet belief is in amazingly bad taste.

The least the author could have done is waited until all the bodies were identified.

<comment><USER8> I tend to disagree. This is the moment in which people are most likely to read and perhaps even listen. It's amazing how fast people want to and will forget about it if they weren't directly impacted. This is when it is most relevant.

<comment><USER9> Except these aren't particularly valid issues. Even with a pristine Katy prairie Harvey would still have caused total mayhem. 800 year floods are an insurance problem not a zoning problem.

</comment></comment></comment><comment><USER10> I'm not sure why this was flagged specifically but changing the title to say "Real Estate Developers" might help.

</comment><comment><USER4> Should we restrict human expansion and destruction of coastal wetlands? Is it smart to live in a place where flooding is the norm, and it's costs must continually be subsidized by local, state and federal government? Is it fair to spend federal dollars necessary to rebuild Houston?

These are interesting questions - but the fact is that 20-50 inches of rain fell along the Texas coast the past 4 days. No amount of eco circle jerk or voting is ever going to prevent a disaster like this. Even the article says the amount of water shed run off affected by expansion is a drop in the bucket compared to the total amount of rainfall Harvey will produce. This did not just affect Houston either - but multiple counties along the Texas coast all the way to Louisiana.

Should we not rebuild San Francisco when the next big earthquake hits? Should we not rebuild New Jersey or New Orleans when they get hit by another hurricane? Where do we draw the line on rebuilding large cities after natural disasters?

I don't have good answers here - we are all still trying to recover in Houston at this point. Like Angersock said, the sooner we recover the better for people like QAPereo. We are pioneers in Houston - space, heart surgery, oil and gas to name a few - why not rebuild?

<comment><USER11> None of that. It just means being smart about city planning like the Netherlands.

<comment><USER4> Hurricanes don't affect the Netherlands. No amount of planning can prevent devastation from a storm that drops three feet of water in your front yard.

You seem uniformed about what is going on here. This hurricane was bigger than Rita, Katrina, Sandy - and those were real beasts. Maybe you are uninformed because national news coverage of this storm is limited compared to others like it - there have been few deaths because as Texans we have done a damn good job dealing with it so far.

<comment><USER11> It's not all or nothing, it's a continuum. Decisions about city planning can make things better or worse. There were things done wrong that made it worse.

For example, building homes in a reservoir [1] seems like an obvious bad idea. Do you really want to defend that?

[1] [https://plus.google.com/+BrianSlesinsky/posts/GwxF2yM3QmC](https://plus.google.com/+BrianSlesinsky/posts/GwxF2yM3QmC)

<comment><USER4> It is a continuum, and we are way to the right on a log scale in terms of event intensity.

I agree we can do certain things like require people to have flood insurance.

Neat reference, but you are misquoting it. The homes are not built in a resevoir. They are built in a 100 year flood plain artificially created by earthen dams designed to protect the city.

<comment><USER11> Isn't that what a reservoir is? You build a dam and everything behind it floods. (Typically anyone living there already gets bought out.)

Apparently not all the land behind the dam was bought when it was vacant, people built houses there, therefore these reservoirs can't be allowed to fill all the way during the storm, and they have to release water sooner than they would have otherwise.

(Or at least that's what ProPublica seems to be saying. Other news reports say differently.)

</comment></comment></comment></comment></comment></comment><comment><USER12> Yes let's blame the floods on lack of zoning regulations. Not a hurricane. Houston is too affordable, needs to be gentrified and regulated so no one can afford to live there like San Francisco.

</comment><comment><USER13> If our species were slightly better than a self-important ape that wears pants, we'd:

        a. give everyone with property damage ~$20,000
        b. void their mortgage or lease

So now they can afford to relocate, or they have some money to start rebuilding, they have no debt and the banks who decided to not require flood insurance can go choke on their bad decision and risk assessment.

That's cheaper than the inevitable $120+ billion dollar bailout that's on the way. And it would help people make the saner choice which is to migrate out of Houston which gets flooded in some way or another pretty much every year, even with wet lands in place.

And maybe the no longer bailed out banks will require, across the board, flood insurance. Which should match the actual risk of future floods.

<comment><USER9> As a resident Houston for 25 years, I can count on one hand the number of times flooding has caused anything but minor inconveniences to the city as a whole. There will always be a slightly inflated risk pool here but it's not nearly as bad as you make it sound.

And I will gladly go on record as willing to subsidize 800 year floods in any part of the world, the inevitable Big One in California, the next Mt St Helens, and so on. Expecting the market to manage black swans is unrealistic.

<comment><USER13> Harris County Flood Control District claims three 500 year floods the past three years. That this is by far the worst of the three, doesn't make 500 year floods in Houston "black swan" events. Their own web site makes it sound worse than I am. [https://www.hcfcd.org/flooding-floodplains/harris-countys- fl...](https://www.hcfcd.org/flooding-floodplains/harris-countys-flooding- history/)

<comment><USER9> Those aren't "claims", those are based on the historical record of the floodplain here. And those floods are a reflection of huge weather events not poor planning on the city's part.

And that site is only talking about the typical spot flooding that Houston is prone to which causes (again) a slightly inflated risk pool.

You're way overstating your case here.

<comment><USER9> And yes, 3 500 year floods in 3 years qualifies as a black swan. There are simply no models that predicted this.

</comment></comment></comment></comment></comment><comment><USER14> It shows not only the dangers of ignoring science but of promoting an irrational alternative in its stead. Like a war, a hurricane is something you cannot pretend is not happening; it's a true test of your reality versus reality, and in places like Texas and Louisiana they've been found wanting. People are free in this country to believe whatever they want, and those same people are free to vote. What they are not free from are the consequences of holding those beliefs and casting those votes.

<comment><USER15> What I _believe_ is that my city came together in a time of great stress and has been prevailing.

What I _believe_ is that my city's people decided that it was more important to have growth and to bounce back than to limit itself in the face of known weather.

What I _believe_ is that we are richer and more diverse because of the lack of zoning and because of aggressive (if irresponsible) development, and that more people had better lives than would have if we'd said "oh well i guess we should give up".

What I _believe_ is that none of the people who haven't lived here for years have much useful to say that isn't just virtue signalling and apocalyptic rubbernecking.

And lastly, calling our people irrational while you enjoy the fruit of our labors in the form of cheap gasoline, cheap imports, and good cancer care I _believe_ is extremely tacky.

<comment><USER16> Would you please not post rants like this to HN, regardless of how tacky other people are?

<comment><USER14> Again, no need to be rude in getting your point across.

</comment></comment></comment></comment><comment><USER17> "Après moi le déluge! is the watchword of every capitalist."

\--Karl Marx

</comment><comment><USER18> Hilarious to learn this week that the federal government eats a net loss while subsidizing correlated flood risk.

</comment><comment><USER15> Isn't this exactly what Google did a month ago? </s>

(I know, I know, different type of developers. But still. :P

</comment><comment><USER19> Yes, we should make sure everything is totally proof from any possible disaster, no matter how unlikely or how little economic sense it makes. For example, we should make sure cities can survive not only 500 year floods, like in Houston, but 1 million year floods and direct asteroid strikes up to 1km in diameter. However, I think even when we do this, eventually a city will be hit by a 2km diameter asteroid, and qz.com will blame developers.

<comment><USER20> Why are there adults that make slippery-slope arguments?

<comment><USER19> It's not a slippery slope argument at all.. My point is that there is some optimal amount of investment in disaster preparedness, and if you make that optimal investment, and despite that a disaster overwhelms you, you still acted rationally and optimally. Investing more than is optimal is stupid.</comment></comment></comment>


Show HN: Make randoapp descriptions. - <AUTHOR> http://empitchen.appspot.com/

<comment><AUTHOR> "An app to innovatively follow that creepy guy at the bar — for geeks"

</comment><comment><AUTHOR> "horrendously professional lending for your Vax/VMS device"

</comment><comment><AUTHOR> github : [[https://github.com/humanarity/empichen](https://github.com/humanarity/empichen)]

"An app to vibrantly teleport your house — for humans"

</comment><comment><AUTHOR> "horrendous blockchain — made with malbolge"</comment>


My husband raped two women and I had to answer for his crimes - <AUTHOR> http://www.vox.com/2016/1/13/10737742/husband-rapist <comment><USER2> I've read a number of stories like this over many years. The basic outline is the same. A woman meets a man who committed some unspeakably vile crime in his past, but now he appears to be fully reformed and a model citizen. She falls in love with him and marries him. Then he commits another unspeakably vile crime.

That's just my observation. I don't know what, if any, conclusions can be drawn from it.

<comment><USER3> Stories of "A woman meets a man who committed some unspeakably vile crime in his past, but now he appears to be fully reformed and a model citizen, and in fact he is" are probably less newsworthy, so there's a selection bias in play here.

I say that with the same agnosticism that you related your observation. I don't know whether such stories exist at all, or if they're a majority or a minority compared to the recidivist stories.

</comment></comment><comment><USER4> I'm not sure that the punitive justice system can be blamed for guilt by association social stigma and victim blaming. If anything, having a clear actor to blame for the crimes would seem to protect them from any guilt or stigma as a matter of agency. This gets to the notion of being "tainted" or purity based morality, which is something different all together.

</comment><comment><USER5> Am I crazy or was this already posted on Vox earlier this year? The date says today but I swear that this is older than that.

<comment><USER6> You are not crazy. I also read this earlier this year. The URL is dated 2016-1-13 and archive.org confirms this publish date. Not sure if the listed date is a bug or deception by Vox.

<comment><USER2> I wonder if that's why someone decided to flag this story.</comment></comment></comment>


Phil Schiller Advances to Apple Fellow - <AUTHOR> https://www.apple.com/newsroom/2020/08/phil-schiller-advances-to-apple-fellow/ <comment><USER2> Last step before retirement I fear. Will miss him, the App Store got significantly better for developers when he took it over.</comment>


A deep dive into Linux namespaces, part 4 - <AUTHOR> http://ifeanyi.co/posts/linux-namespaces-part-4/ <comment><USER2> I first learnt of network namespaces from configuring WireGuard. They offer a very neat way of ensuring all traffic uses your wg interface, in brief:

\- create a new netns, call it 'physical' say

\- move your physical device's interface to 'physical'

\- create wg interface in 'physical'

\- move wg interface to init ns

It works because it 'remembers' where it was created and remains bound to it for sending encrypted packets over the physical device, but is now the only interface available to processes by default (i.e. without a superuser making them use 'physical' ns directly).

Not long enough; want to read more: [https://www.wireguard.com/netns](https://www.wireguard.com/netns)

</comment><comment><USER3> These are really good posts - I've been mucking about with namespaces recently at work and I wish I had known about this series before today, I wouldn't have had to go figure out a bunch of stuff the hard way!

I hope some future part covers the nsfs and bind mount thing for persisting namespaces past a specific process. It took me way, way to long to catch this passage in the man page:

        Bind mounting (see mount(2)) one of the files in this directory to somewhere else in the filesystem keeps the corresponding namespace of the process specified by pid alive even if all processes currently in the namespace terminate.

It's not that it's hard to understand, it's just poorly highlighted in most namespace discourse that I've seen. Persisting namespaces was very much a mystery to me - I had to break down and read the source to understand how the ip command persisted network namespaces before I understood the importance of that sentence.

<comment><USER4> LWN has a very good series on namespaces and cgroups.

<comment><USER3> Oh, good pointer - thanks!

</comment></comment></comment><comment><USER5> Wondering, if it's possible to build "application firewall" on top of namespaces. Only thing I'm missing on Linux.

<comment><USER6> IPtables/netfilter can already filter traffic by process. I don't think you need namespaces.

</comment></comment><comment><USER7> If you are interested in network namespaces, you might want to take a look at VRF in Cumulus Linux.

</comment><comment><USER8> Recent pet project: I wanted multiple network clients to access the internet concurrently, each through its own separate VPN session, established on demand and without elevated privileges.

The first part seemed like a simple enough idea until I remembered that traditional IP routing is based on destination address alone. Although I could establish multiple VPN sessions, give each one its own network interface, and configure each client to bind to a different interface (and therefore send packets with a different source address), the routing table had no way to know that it should send CLIENT_A's packets to the server via IFACE_A and CLIENT_B's packets to the same server via IFACE_B.

Policy-based routing looked like a promising solution, but it would require hooking the VPN startup sequence to find each new tunnel interface as it was created, using elevated privileges to install a special routing policy for each interface, and reliably cleaning up the routing tables when each client was done. This seemed overly complicated, and a poor fit for unprivileged users.

Linux namespaces, along with tools that are already in the debian/ubuntu repos, let me do everything I wanted. I ended up writing a couple shell scripts that create N namespaces, give each one a veth connected to a shared bridge device with internet access, establish a namespaced VPN session via each veth, and let the VPN take control of its namespace's default route.

That by itself would have been enough, since any network client running within a namespace is at the mercy of that namespace's routing table, and therefore goes through its own VPN session. I went a couple steps further, though: I added firewall rules within each namespace, to prevent any leaks if the VPN failed or a routing mistake crept in. I also decided to launch a lightweight proxy server in each namespace instead of running my network clients directly within, allowing me to conveniently start and stop my network clients outside of the namespaces and independently of the namespace setup/teardown process.

With the addition of user namespaces, the steps that would normally require root can be run as a fake uid 0 by an unprivileged user. With the help of lxc- user-nic, the one privileged operation that must be run outside the namespaces (adding each veth to the bridge) can be done by an unprivileged user as well. With the help of dumb-init (or tini), stopping the parent process of any namespace automatically cleans up everything within, including the routing table, firewall rules, veth, VPN, and proxy.

This arrangement solved all the problems I set out to solve, and the exercise was a good way to get familiar with namespaces. I might some day convert my hackish shell script implementation to python, perhaps with a little GUI, and see if I can combine it with Firefox containers. Per-container or per-tab VPN sessions in a web browser would be neat.

Related: [https://github.com/mozilla/multi-account- containers/issues/3...](https://github.com/mozilla/multi-account- containers/issues/313)</comment>