Google Is 2B Lines of Code, All in One Place - <AUTHOR> http://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/ <comment><USER2> Just because people are talking about it: I work at MSFT, and the numbers Wired quotes for the lines of code in Windows are not even close to being correct. Not even in the same order of magnitude.

Their source claims that Windows XP has ~45 million lines of code. But that was 14 years ago. The last time Windows was even in the same order of magnitude as 50 million LOC was in the Windows Vista timeframe.

EDIT: And, remember: that's for _one_ product, not multiple products. So an all-flavors build of Windows churns through a _lot_ of data to get something working.

(Parenthetical: the Windows build system is correspondingly complex, too. I'll save the story for another day, but to give you an idea of how intense it is, in a typical _day_, the amount of data that gets sent over the network in the Windows build system is a single-digit _multiple_ of the entire Netflix movie catalog. Hats off to those engineers, Windows is really hard work.)

<comment><USER3> > single-digit _multiple_ of the entire Netflix movie catalog

Strange unit of comparison, although I may start using it.

<comment><USER4> Facebook gets a Flickr worth of photos every few days.

<comment><USER5> As someone who subscribes to ArchiveTeam's philosophy, it's going to be a dark day when the time comes to scrape Facebook before it goes under with that much data behind the scenes.

<comment><USER6> It's already backed up to Blueray. They'll just hand it over.

<comment><USER7> Yeah, right. How and who exactly would they hand that over to, given that there are privacy settings on the photos that people expect to have respected?

<comment><USER8> Sarcasm son....

<comment><USER7> You'd be surprised at how many people assume these bigcos are open to doing the right thing when they're shutting down.

<comment><USER9> Hey, I've still got my complimentary MySpace zip file kicking around somewhere.

<comment><USER10> I had a hard drive crash on me with all of my photos some years back and my "backup" strategy failed. Dumping a myspace backup got me some of my most precious photos back. Thanks MySpace!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I'm a google software engineer and it's nice to see this public article about our software control system. I think it has plusses and minuses, but one thing I'll say is that when you're in the coding flow, working on a single code base with thousands of engineers can be an intensely awesome experience.

Part of my job- although it's not listed as a responsibility- is updating a few key scientific python packages. When I do this, I get immediate feedback on which tests get broken and I fix those problems for other teams along side my upgrades. This sort of continuous integration has completely changed how I view modern software development and testing.

<comment><USER12> Could you tell something about the level of documentation? For instance, do you have to write a paragraph of documentation for every function that you add to the system? How about adding preconditions and postconditions, and other invariants?

Also, is the code that you add to the repository always inspected by other people? Is that done systematically?

<comment><USER13> It is mandatory that each code change is inspected for correctness, language style and approved by a code owner (all 3 may be the same person, or require multiple, depending on the situation).

<comment><USER12> But I guess the original programmer can never be the same person as those other 3 roles? :)

<comment><USER14> You always need to get at least _one_ other engineer to review your code.

OWNER and readability approvals may require additional reviewers but not always.

</comment></comment></comment></comment></comment><comment><USER15> So a monolithic codebase makes it easier to make an organization wide change. Microservices make it easier to have people work and ship in independent teams. The interesting thing is that your can have have microservices with a monolithic codebase (as Google and Facebook are comprised of many services). But you can also have a monolithic service with many codebases (like our GitLab that uses 800+ gems that live in separate codebases). And of course you can have a monolithic codebase with a monolithic service (a simple php app). And you can have microservices with diverse codebases (like all the hipsters are doing).

I'm wondering if microservices force you to coordinate via the codebase just like using many codebases force you to coordinate via the monolithic service. Does the coordination has to happen somewhere? I wonder if early adopters of microservices in many codebases (SoundCloud) are experiencing coordination problems trying to change services.

<comment><USER16> Google has _tons_ of services internally that talk via RPC. The monolithic repo means that it's much easier to hunt down and find people that are (say) using an outdated RPC method and help them fix their code.

(Just one example of how it's useful even when things are mostly services.)

<comment><USER17> This discourages you from ever making breaking changes to an API. On the face of it that sounds good but sometimes you do have to make breaking changes. My guess is that there are many duplicate projects in the Google code base for when a breaking change is needed. This is a way to sidestep the problem.

<comment><USER18> I think sometimes it's actually the opposite. I was able to make a breaking change to an API and update all of the callers to use the new one in a single commit.

Tests would run on all the clients and, since in my workspace the server was updated simultaneously, I could be more sure it would work.

<comment><USER17> That's fine for small breaking changes like an API being renamed, but some times breaking changes require actually refactoring code which is hard/impossible to do without intimate knowledge of a codebase.

Think python 2->3 or Angular 1->2\. These types of changes do happen, and I bet they happen at Google. I don't think anyone is rewriting a downstream app when they make these changes. Most likely they are doing something like forking the library and renaming it, which is just another form of versioning.

<comment><USER19> A talk and a paper on how we do large-scale refactoring in the C++ parts of the codebase

[https://isocpp.org/blog/2015/05/cppcon-2014-large-scale- refa...](https://isocpp.org/blog/2015/05/cppcon-2014-large-scale-refactoring- google-hyrum-wright)

[http://research.google.com/pubs/pub41342.html](http://research.google.com/pubs/pub41342.html)

</comment></comment></comment></comment></comment></comment><comment><USER20> I will say that I saw and experienced many things that changed my definition of 'large' at Google, but the most amazing was the source code control / code review / build system that kept it all together.

The bad news was that it allowed people to say "I've just changed the API to <x> to support the <y> initiative, code released after this commit will need to be updated." and have that effect hundreds of projects, but at the same time, the project teams could do the adaptation very quickly and adapt. With the orb on their desk telling them at that their integration and unit tests were passing.

I thought to myself, if there is ever a distributed world wide operating system / environment, it is going to look something like that.

<comment><USER21> The solution to the excessive API change problem is to force whoever changes the API to fix all the consumers himself before the change is accepted.

The Linux kernel generally uses this policy for internal APIs for example.

<comment><USER22>
      > The solution to the excessive API change problem is to force
      > whoever changes the API to fix all the consumers himself
      > before the change is accepted.

This doesn't seem scalable. Let's consider the case of one api endpoint being changed by one developer, to add a new param to a function call. Further assume that this impacts hundreds of projects.

Does it really make sense to make one developer update those hundred projects? Not only will it take forever for it to get finished (possibly never if there are new consumers of this api coming online frequently), but the developer of the core api may not have any experience in the impacted consumers of this codebase. I think the end result of this policy would be nothing once written _ever_ would get updated, and new apis would just be added all the time (api explosion).

<comment><USER23> It maybe isn't scalable, but that's part of the benefit. If you want to make a change to a widely-used API, it's going to be a lot of work, and it's not going to be a lot of work for the users of the API, it's going to be a lot of work for _you_ because _you_ are required to do it yourself. This prevents a lot of API churn unless the benefit is clear and sufficiently large.

If it was any other way you'd rapidly reach a useless equilibrium where random engineers were demanding that thousands of other engineers fulfill unfunded mandates for what might turn out to be negligible benefits.

<comment><USER24> That's one extreme. Another extreme is that you have the API versioning from hell, where you can never get rid of technical debt because any and all API changes will break someone, somewhere, who has no reason to migrate, so you're left keeping ancient code on life support indefinitely.

</comment></comment></comment></comment></comment><comment><USER25> Xoogler here. There were tons of benefits to Google's approach, but they were only viable with crazy amounts of tooling (code search, our own version control system, the aforementioned CitC, distributed builds that reused intermediate build objects, our own BUILD language, specialized code review tools, etc).

I'd say the major downside was that this approach basically required a 'work only in HEAD' model, since the tooling around branches was pretty subpar (more like the Perforce model, where branches are second-class citizens). You could deploy from a branch but they were basically just cut from HEAD immediately prior to a release.

This approach works pretty well for backend services that can be pushed frequently and often, but is a bit of a mismatch for mobile apps, where you want to have more carefully controlled, manually tested releases given the turnaround time if you screw something up (especially since UI is really inefficient to write useful automated tests around). It's also hard to collaborate on long-term features within a shipping codebase, which hurts exploration and prototyping.

<comment><USER26> Could you elaborate how the single repo model causes that thing you said in the last sentence?

</comment></comment><comment><USER27> Its interesting that they compare LoC with Windows. I suppose that this article wants us to be amazed at those numbers. However, my experience with Google's products indicates a gradual decline in performance and a simultaneous gradual increase in memory bloat (Maps, Gmail, Chrome, Android). Which ironically, FWIW, hasn't been the case with Windows. I have noticed zero difference in performance going from Windows 7 to 8 to 10.

<comment><USER28> I'd have to disagree with this. First the baseline: windows is _very_ slow. Second I found later versions slower. Third (and most maddening) every version of windows I've ever used has gotten slower over time (including not installing new s/w and defragmenting).

<comment><USER29> Windows is slow? Compared to what? In what task? Running a game? Boot time? Opening Firefox?

I have problems with Windows, but it's the fastest desktop os I think, mostly because it's graphics stack is way the best of all. Running a number crunching C code is exactly the same on Windows or Linux. (See all the benchmarks on the Internet.)

<comment><USER30> It's really not that fast. The filesystem is a total dog (MFT contention) to the point that manipulating lots of small file is up to two orders of magnitude slower than ext4. This is made bearable thanks to SSDs being on the market. Also the amount of friction getting stuff built and running and maintaining it is detrimental to general productivity meaning you piss execution time out of the window regularly just fixing stuff.

Note: windows programmer for 19 years now. Only because of the cash.

<comment><USER27> I can't say I'm surprised to see people eager to point out how Windows sucks. And sure, maybe it does. However, the fundamental point you're missing is that I don't think that Windows was ever positioned as this OS that was designed for every single type of workload out there (not withstanding marketing noise). Windows is a very general purpose OS meant for general purpose 'mainstream' things. Things that hundreds of millions of people might want to do. Specialty workloads are simply not what Microsoft is ever going to invest any significant amount of time in - unless they see some money there. In that sense, Windows would probably be a far better OS if users could modify it to suit their needs, but thems the breaks. Linux seems to fill that void for some.

The disadvantage of NTFS which you point out, isn't because of a fuckup. It's not designed for your use case. You might even find Microsoft telling you that themselves here :- [https://technet.microsoft.com/en- us/library/Cc938932.aspx](https://technet.microsoft.com/en- us/library/Cc938932.aspx)

As to your point about productivity, I can't comment without knowing specifics. As a primarily C++ programmer, I haven't run into any Windows showstoppers that prevented me from shipping. I have run into showstoppers with their dev tools, but I see them as separate from the OS.

<comment><USER31> At least you don't ever really _need_ to defragment ext4, unlike NTFS.

<comment><USER32> Can you solve all the problems in ext4 that NTFS claims to solve? No you cant. I am not saying either of the systems is perfect nor either of them is horrible. They are perfect for the use cases they are designed for. If somebody had a file system structure that was unusual(say lots of small files) to NTFS, I think it was his mistake in treating it as a black box.

<comment><USER30> The problem is that a large number of small files is a very common use case. Even Windows itself consists of lots of small files i.e. the source code and WinSxS.

It should handle general scenarios consistently. We've had a few minor versions of NTFS and now ReFS. ReFS should solve this but it doesn't as it's a copy and paste of the NTFS code initially rather than a complete reengineering effort.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> "The two internet giants (Google and Facebook) are working on an open source version control system that anyone can use to juggle code on a massive scale. It's based on an existing system called Mercurial. "We're attempting to see if we can scale Mercurial to the size of the Google repository," Potvin says, indicating that Google is working hand-in-hand with programming guru Bryan O'Sullivan and others who help oversee coding work at Facebook."

Why Mercurial instead of Git?

<comment><USER34> Because Google and Facebook are using Mercurial over Git internally.

 _Edit:_ And for those that are just shocked that git isn't the answer.

Facebook: [https://code.facebook.com/posts/218678814984400/scaling- merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at- facebook/)

Google: [http://www.primordia.com/blog/2010/01/23/why-google-uses- mer...](http://www.primordia.com/blog/2010/01/23/why-google-uses-mercurial- over-git/)

<comment><USER35> Well, Piper conforms to the Perforce API-ish, and Android and Chrome are both on Git.

Mercurial was pushed internally as being the "better" (for some dimension of better) between it and Git back in 2010, but I think even the most hardline Mercurial fans have realized that in order to meet developers in the middle in 2015, we need to use Git for our open-source releases. We have a large investment in Gerrit [1] and Github [2] now.

So the Mercurial comment is probably entirely based on scaling and replacement for the Piper Perforce API, rather than anything externally facing.

[1] [https://www.gerritcodereview.com/](https://www.gerritcodereview.com/) [2] [https://github.com/google](https://github.com/google)

<comment><USER36> Though both Android and Chromium still build in a way more similar to that for a monolithic repo. They use repo and depot_tools, respectively, as abstractions on top of Git in order to clone and manage all their Git repositories together as if they were a single large repository.

</comment></comment></comment></comment><comment><USER37> Comparing "Google" to Windows isn't really a fair comparison. I'm sure all of the code that represents products that Microsoft has in the wild far exceeds 2B lines.

<comment><USER38> Note that this is just the monolithic repository. Google also has other non- piper repositories containing hundreds of millions of lines too :P

For example, android and chrome are git based.

Note also that when codesearch used to crawl and index the world's code, it was not actually that large. It used to download and index tarballs, svn and cvs repositories, etc.

All told, the amount of code in the world that it could find on the internet a few years ago was < 10b lines, after deduplication/etc.

So while you may be right or wrong, i don't think it's as obvious you are right as you do.

<comment><USER39> I'm still trying to figure out why having everything dumped in one big pile is something worth bragging about. I'd far rather have code sorted well into proper repositories.

<comment><USER40> So much is shared, though, right? Which is why Android is sorted into proper repositories but still has the 'repo' front-end wrapper to make sure you're getting the right versions of everything you need.

If I wanted to change something fundamental, like I found a 10% speedup in Protobuf wire decode by changing the message slightly, there are likely very many services that all need it.

Everyone at Google operates on HEAD. You're not allowed to break HEAD, and pre-submit/post-submit bots ensure you don't and will block your submit.

<comment><USER39> From my perspective, at least, this design seems to explain why Google websites are so frequently broken in the ways different services integrate. Because Googlers edit shared resources that affect products they don't personally work on, and they just trust automated tests, which almost certainly miss a lot of the edge cases I encounter.

I admit that I'm not an expert at large software development, but this seems to nearly fully explain Google's declining code quality.

<comment><USER38> "I have literally no idea what i am talking about, but here's something that i believe fully explains every problem i have ever encountered" :)

</comment></comment></comment></comment></comment></comment><comment><USER41> One humorous side-effect of having all that code viewable (and searchable!) by everyone was that the codebase will contain whatever typo, error, or mistake you can think of (and convert into a regular expression).

I remember seeing an internal page with dozens of links for humorous searches like "interger", "funciton", or "([A-Z][a-z]+){7,} lang:java"...

<comment><USER42> > "([A-Z][a-z]+){7,} lang:java

Yeah this one was my favorite of the code search examples, there are some really good ones in there.

<comment><USER43> Can you explain this? It looks to me like a regexp that searches Java source for words 7+ characters that start with a capital letter?

<comment><USER41> It searches for CamelCase identifiers that are made of seven or more "terms", where each term is a capital letter followed by one or more lowercase letters.

E.g., ProjectPotatoLoginPageBuilderFactoryObserver.

(Disclaimer: I just made it up. Not an actual Google project name.)

"lang: java" is not a part of regexp; just a Google code search extension that searches for Java.

</comment></comment></comment></comment><comment><USER44> Direct link to talk (The Motivation for a Monolithic Codebase ):

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

<comment><USER45> This is crazy :D I have never heard tools and workflows like this.

</comment></comment><comment><USER46> I am unable to believe that Google has 2B lines of original code written from scratch at Google.

Maybe they are counting everything they use. Somewhere among those 2B lines is all the source code for Emacs, Bash, the Linux kernel, every single third- party lib used for any purpose, whether patched with Google modifications or not, every utility, and so on.

Maybe this is a "Google Search two billion" rather than a conventional, arithmetic two billion. You know, like when the Google engine tells you "there about 10,500,000 results (0.135 seconds)", but when you go through the entire list, it's confirmed to be just a few hundred.

<comment><USER47> Google has been around for 17 years and employees roughly 10,000+ software developers. I think it's reasonable to assume that the 2B LOC metric is accurate...

<comment><USER48> Windows has been around for 35 years and Microsoft had 61,000+ employees (ok, that's not only software developers and they don't work only on Windows) in 2005; and it's only ~50M LOC. I don't think the number of years + developpers really show something; you don't write new code everyday.

<comment><USER49> You pointed it out yourself, but I think you underestimated its importance: Microsoft works on many other things. Office, XBox, Windows Phone, Exchange, SQL Server, .Net, etc. I suspect Microsoft's total line count is similar to Google's. The difference, however, is that it's not _one_ codebase.

</comment></comment></comment></comment><comment><USER50> "LGTM is google speak for Looks good to me" \- actually common outside of Google.

<comment><USER51> SGTM

</comment></comment><comment><USER52> In the spirit of "You didn't build that," I wonder how many lines of code comprise the binaries that Google binaries run on? Windows, Linux, network stacks, Mercurial, etc, etc.

I also wonder if there's a circular relationship anywhere in there.

<comment><USER53> It's turtles all the way down, and also includes all the hardware and people.

</comment></comment><comment><USER15> The CitC filesystem is very interesting. This is local changes overlaid on top of the full Piper repository. Commits are similar to snapshots of the filesystem. Sounds similar to [https://github.com/presslabs/gitfs](https://github.com/presslabs/gitfs)

</comment><comment><USER54> I really wish there was a tendency to track all change/activity and not just total size; maybe like the graphs on GitHub. _Removing things is key for maintenance_ and frankly if they haven't removed a few million lines in the process of adding millions more, they have a problem.

Having a massive code base isn't a badge of honor. Unfortunately in many organizations, people are so sidetracked on the next thing that they almost never receive license to trim some fat from the repository (and this applies to all things: code, tests, documentation and more).

It also means almost nothing as a measurement. Even if you believe for a moment that a "line" is reasonably accurate (and it's tricky to come up with other measures), we have no way of knowing if they're measuring lots of copy/pasted duplicate code, massive comments, poorly-designed algorithms or other bloat.

<comment><USER55> The article claims 2 billion lines of code across 25000 engineers, which boils down to 80k lines of code per engineer. I'm not sure what to think about that.

It seems to be in a reasonable order of magnitude for C++/Java-type languages compared to projects that I have seen, but it does imply a significant chunk of code that is not actively being worked on for a long time (which is not necessarily a bad thing - don't change a running system and all that).

</comment></comment><comment><USER56> The comparison of Windows to all of Google's services is pointless and misleading.

It's like comparing the weight of a monster truck and the total weight of all the cars at a dealership...

</comment><comment><USER57> Assuming these numbers are right...

(15 million lines of code changed a week) / (25,000 engineers) = 600 LOC per engineer per week

Is ~120 LOC per engineer per workday normal at other companies?

<comment><USER58> Elsewhere in this thread it's mentioned that Google makes use of large-scale, automated refactoring tools: [http://research.google.com/pubs/pub41342.html](http://research.google.com/pubs/pub41342.html)

Would be interesting to know what percentage of the total LoC touched are typically from that kind of automated refactor. Depending on the codebase, you can touch a _ton_ of lines of code in a very small amount of time with those tools.

</comment></comment><comment><USER59> I imagine that there's a lot of Java and C++. I do like Go but it makes you wonder if a more expressive language that requires a fraction of the code would be helpful. Maybe Steve Yegge will see Lisp at Google after all.

<comment><USER60> He claims to have stopped using it (#5):

[https://sites.google.com/site/steveyegge2/ten- predictions](https://sites.google.com/site/steveyegge2/ten-predictions)

</comment></comment><comment><USER61> Some questions that immediately come to my mind:

\- What is the disk size of a shallow clone of a repo (without history)?

\- Can each developer actually clone the whole thing, or you do partial checkout?

\- Does the VCS support a checkout of a subfolder (AFAIK mercurial, same as git, does not support it)?

\- How long does it take to clone the repo / update the repo in the morning?

Since people are talking about huge across-repo refactorings, I guess it must be possible to clone the whole thing.

Facebook faces similar issues as Google with scaling so they wrote some mercurial extensions, e.g. for cloning only metadata instead of whole contents of each commit [1]. Would be interesting to know what Google exactly modified in hg.

[1] [https://code.facebook.com/posts/218678814984400/scaling- merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at- facebook/)

<comment><USER62> Most of these questions are answered in the talk. The tl;dr is that you don't clone or check out anything at all: instead, you use CitC to create a workspace, and the entire repository is magically available to you to view or edit.

This model precludes offline work, of course. But that's not much of a problem in practice.

<comment><USER61> I did not follow the links in wired article, and didn't realize there was a link to a youtube talk. Thanks for tl;dr, need to watch the video!

</comment></comment></comment><comment><USER63> What? This is surpassing the mouse genom complexity. See this charts for comparison: [http://www.informationisbeautiful.net/visualizations/million...](http://www.informationisbeautiful.net/visualizations/million- lines-of-code/)

</comment><comment><USER64> Really interesting article. Sounds like a great solution to the problem in git of submodules. Definitely worth looking at. Thanks for posting OP.

IMO this system would best be suited for large companies, but I could see the VCS that they are developing being used by anyone if it gets a github-esque website.

</comment><comment><USER65> Yeah, but it's only like ~200 lines rewritten in Lisp.

<comment><USER66> A serious question about Lisp and Google, is Lisp used within Google, and if so, in what projects and why?

</comment></comment><comment><USER67> Looks like someone's going to have to update this: [http://www.informationisbeautiful.net/visualizations/million...](http://www.informationisbeautiful.net/visualizations/million- lines-of-code/)

</comment><comment><USER68> This hurts just thinking about what the build, test and deploy systems must look like.

<comment><USER69> Well, for build take a look at bazel, although attach it to a cluster of machines that can all read from Piper.

</comment></comment><comment><USER70> For those interested, the source analyzer Steve Yegge was working on called GROK has been renamed Kythe. I don't know how useful it turned out to be for those 2B LOC. [http://www.kythe.io/docs/kythe- overview.html](http://www.kythe.io/docs/kythe-overview.html)

Steve Yegge, from Google, talks about the GROK Project - Large-Scale, Cross- Language source analysis. [2012] [https://www.youtube.com/watch?v=KTJs-0EInW8](https://www.youtube.com/watch?v=KTJs-0EInW8)

</comment><comment><USER71> What I'd like to know and no one seems to mention:

What's the experience like for teams _not_ running a Google service and instead interacting with external users and contributors, e.g. the Go compiler or Chrome.

<comment><USER62> Many larger external projects are hosted in other repositories (Chrome and Android are well-known examples).

Smaller stuff (like, say, tcmalloc or protocol buffers) is usually hosted in Piper and then mirrored (sometimes bidirectionally) to an external repository (usually GitHub these days).

<comment><USER71> Thanks, but I guess I was asking more about how this affects the other development characteristics described. You still have to deal with the massive repository and infrastructure, but if you're Go, for example, and you want to change an API 1) you can't see the consumers because many or most won't be Google-internal, and 2) even if you could see them, you can't change them. Even the build/test/deploy systems are somewhat compromised because you can't rely on all builders of your components being Google employees and having access to those resources.

So in these scenarios, what does Google's infrastructure buy you, if anything? And if it doesn't buy you anything, how does that influence Google culture? Are teams less willing to do real open development due to infrastructure blockage?

<comment><USER72> Working with multiple source control systems, multiple issue trackers, and multiple build systems has its challenges.

It's true that you don't know about all callers if you're working on open source software. There's no magic there; you need to think about backward compatibility. (On the other hand, if it's a library, your open source users can usually choose to delay upgrading until they're ready, so you can deprecate things.)

The main advantage for an open source project is that, though you don't know about all callers, you still have a pretty large (though biased) sample of them. If you want to know how people typically use your API's, it's pretty useful. Running all the internal tests (not just your own, but other people's apps and libraries) will find bugs that you wouldn't find otherwise.

There were changes I wouldn't have been confident making to GWT without those tests, and bugs that open source users never saw in stable releases because of them. On the other hand, there were also changes I didn't make at all because I couldn't figure out how to safely upgrade Google, or it didn't seem worth it.

</comment></comment></comment></comment><comment><USER73> Really? This article sounds very over simplified, but I haven't worked at google so I wouldn't know. I'm assuming if you want to change some much depended on library, there's a way to up the version number so you don't hose all your downstream users. That's the way it worked at Amazon at least. Also, I wonder why the people in the story think Google's codebase is larger than that of other tech giants, not that it really matters.

<comment><USER69> Google mostly works at HEAD. Very little is versioned, and branches are almost unheard of.

In general you change the much depended on library _and all of its consumers_ (probably over time in multiple changes, but you _can_ do it in one go if it really needs to be a single giant change).

</comment></comment><comment><USER74> What are the best practices to follow in a single-repo-multiple-projecrs world? Some people recommend git submodule, others recommend subtree.

How do you guys manage alerts and messages - does every developer get a commit notification,or is there a way to filter out messages based upon submodule.

How does branching and merging work?

I'm wondering what processes are used by non-Google/FB teams to help them be more productive in a monolithic repo world.

<comment><USER75> Generally branching isn't really a thing at Google. Work is done at the code review level per change list ("CL"). Most changes happen through incremental submission of reviewed CLs, not by merging in feature branches. Every CL must run the gauntlet of code review, as well as can not usually be submitted without passing tests. There are rare cases where branching is used, but not commonly.

As for notifications, the CL has a list of reviewers and subscribers. If you want to see code changing, you watch those CLs. Most projects have a list where all submitted CLs go.

<comment><USER74> Can you explain this a little more - what is a CL vs a changeset...and what do you mean by watching changelists. It sounds like you're subscribing to specific commits...but I'm talking about more at a project/directory level within the monolithic repo.

<comment><USER76> Changelist is Perforce-speak for changeset. Because each CL gets an individual review before applying to the codebase, there is no merge process -- there is no branching/merging.

There is a solution for project/directory-level CC / review requirements. I didn't see it discussed in the talk, though.

</comment></comment></comment></comment><comment><USER77> The comparison bewteen the total LOC across _all_ of Google's products against just one of Microsoft's is a bit unfair.

</comment><comment><USER78> The comparison with windows really is just here to provide a something to compare for casual reader, it's not really that good. An OS is a huge project. But google has hundred of different project, apis, library, framework... Even unix with an "unlimited" source of developpers does not reach that point.

</comment><comment><USER79> I remember somebody wise had said once: "Every line of code is a constraint working against you."

</comment><comment><USER80> How do the monolithic repository companies handle dependencies on external source code?

Are libraries and large projects e.g. RDBMS generally vendored/forked into the monolithic repositories, regardless of whether the initial intent is to make significant changes?

<comment><USER81> There's typically a subdirectory called third_party, with subdirectories for each vendor, product and version. If the team is smart, they will also enact a rule saying "only one version". If you're really, really smart, local changes are kept as a set of patches, keeping them separate from the imported tar file.

So, for source deliveries:

      third_party/apache/httpd/2.4/release.tgz
                                  /patch.tgz
                                  /Makefile (or other config)
      third_party/apache/httpd/2.2/release.tgz
                                 /patch.tgz
      ...

<comment><USER82> For example, here is Chromium's third_party directory:

[https://chromium.googlesource.com/chromium/src.git/+/master/...](https://chromium.googlesource.com/chromium/src.git/+/master/third_party/)

</comment></comment></comment><comment><USER83> Are the source of piper and the build tools also in the mono repo and also developed/deployed off the head branch? Seems like a random engineer could royally fubar things if they broke a service which the build system depends on ...

<comment><USER23> You said "developed/deployed" as if it were the same thing. Even if you somehow checked in the giant flaw, bypassing all code review and automated testing, it's not like that would suddenly appear in production. Google isn't some PHP hack where you just copy a tarball to The Server. Binaries of even slightly important systems typically go through many stages of deployment, first into unimportant test systems, then usually very, very slowly into production with lots of instrumentation and of course, quick and easy methods of rolling back to the previous release.

<comment><USER83> I see - it was something of a half baked thought but in my defense I wasn't trying to suggest that I thought the head was automatically deployed to production ... Deployed to testing round 1 ... N is still a "deployment" isn't it ...? The shared boilerplate for how that magic works in a scaleable way for so many different projects must be quite complex and itself hard to test ...

</comment></comment></comment><comment><USER84> Even if the numbers are off, the assumption that 40M lines of code take less effort to write than 2B lines of code commits the fallacy that effort is proportional to number of lines of code. Come on, Wired, you can do better.

</comment><comment><USER12> Is this article saying that all developer employees have access to the "holy" search algorithm internals? I can hardly believe that to be true, given the fact that SEO is a complete industry.

<comment><USER85> Once upon a time it was all in one repository. Shortly after I started there in late 2005, the "HIP" source code (high-value intellectual property, I think it stood for) was moved to its own source tree, with only precompiled binaries available to the rest of the company.

Looks like there is a Quora question that mentions this too: [https://www.quora.com/How-many-Google-employees-can-read- acc...](https://www.quora.com/How-many-Google-employees-can-read-access-all- of-the-source-code-for-Googles-search-engine)

</comment></comment><comment><USER86> How frequently Google does [https://en.wikipedia.org/wiki/Code_refactoring](https://en.wikipedia.org/wiki/Code_refactoring)

</comment><comment><USER87> Those are mind-boggling numbers.

Although I kind of doubt that "almost every" engineer has access to the entire repo, especially when it comes to the search ranking stuff.

<comment><USER35> FWIW, apart from the previously mentioned sensitive stuff, we give engineering interns the same level of access we give full-time engineers. We keep things open because it makes things faster; we have an excellent code search tool that's great for navigating through the Piper repo (e.g. finding subclasses, finding uses of an API) which really speeds up dev time.

When we're not talking about the sensitive stuff, there's not much magic to what many engineers write every day, it's the same "glue technology X to technology Y" stuff you see everywhere, so I don't think there's any value to hiding that in the name of secrecy.

<comment><USER88> How are changes that affect sensitive code handled? Are the owners of that code on the hook for making any API updates that the person pushing the change can't make?

<comment><USER35> Having never worked on the secret sauce, I honestly don't know. There is a small team of people who tend to do many of the global refactors, I might expect that they are given special permission.

</comment></comment></comment></comment><comment><USER89> A giant repo works for Google, and works for Facebook, and Microsoft, but it's bad for the development community at large.

If you start centralizing your development you're killing any type of collaboration with the outside world and discouraging such collaboration between your own teams.

[http://code.dblock.org/2014/04/28/why-one-giant-source- contr...](http://code.dblock.org/2014/04/28/why-one-giant-source-control- repository-is-bad-for-you-and-facebook.html)

</comment><comment><USER90> With 2 billion lines of code I would consider the problem of developers stepping on each other's toes essentially solved.

</comment><comment><USER91> What I find most distressing is that their Python code indents with two spaces... This is so wrong, Google.

</comment><comment><USER92> If they were to recompile all of it on a standard desktop PC how long would it take? A week?

</comment><comment><USER93> I wonder how close the "piper" system is to the code.google.com project.

<comment><USER38> I worked on code.google.com, i can tell you the are 100% unrelated.

piper grew out of a need to scale the source control system the initial internal repositories were using

code.google.com was a completely separate thing supporting completely different version control models, and a very different scale (very large number of small repositories, vs very small number of very large repositories)

</comment></comment><comment><USER94> Am I the only one who initially read 28 instead of 2B ? :)

<comment><USER94> downvoter: laughter is good for your health.

</comment></comment><comment><USER95> What is a "line of code"? out of the 2b lines of code google has, how much of it was auto-generated? how many of those lines are config files? This is a very silly article that has little to no value.

</comment><comment><USER63> So they do not suffer on git submodules I guess

</comment><comment><USER96> Cool , How much front and back end each ?

</comment><comment><USER97> How many lines is duckduckgo? :-)

<comment><USER98> Can't be that many, given they outsource the actual search engine to third parties.

</comment></comment><comment><USER99> OMG it's all in one file? OMG OMG it's all on ONE LINE????!!!

</comment><comment><USER100> Now I know why my google plus page takes half a day to load.

</comment><comment><USER101> lol git clone [http://urlto.google.codebase.git](http://urlto.google.codebase.git) ...

I wonder how much time it takes to clone the repo, provided they use git.

<comment><USER102> It's 80TB. You don't clone, just ask for views.

</comment></comment><comment><USER103> This explains quite some things.

Still, this is not a very forward-thinking solution. Building and combining microservices – effectively UNIX philosophy applied to the web – is the most effective way to make progress.

EDIT: Seems like I misunderstood the article – from the way I read it, it sounded like Google has a monolithic codebase, with heavily dependent products, deployed monolithically. As zaphar mentioned, it turns out this is just bad phrasing in the article and me misunderstanding that phrasing.

I take everything back I said and claim the opposite.

<comment><USER104> That's why Google is so unsuccessful at scaling technical solutions, unlike you they're not forward-thinking.

<comment><USER103> No, it's not that they are unsuccessful, it's that they are unable to maintain it properly. Already today they have tons of open security issues.

Or think about April 1st, when they set a Access-Control-Location: * header on google.com because someone wrote the com.google easteregg.

Read the post from the SoundCloud dude from yesterday to find out how to do software management properly (hint: modularization is everything)

<comment><USER105> Do you have a source for the easter egg security issue? Haven't read about it anywhere, and can't seem to find anything either.

<comment><USER103> Here is one: [http://arstechnica.com/security/2015/04/no-joke-googles- apri...](http://arstechnica.com/security/2015/04/no-joke-googles-april-fools- prank-inadvertently-broke-sites-security/)

The issue was that they wanted to load the page – with the user logged in, etc – on com.google. For this they implemented an explicit URL parameter that would allow this.

<comment><USER106> > _Attackers could have seized on the omission of the X-Frame-Options header > to change a user 's search settings, including turning off SafeSearch > filters_

The horror!</comment></comment></comment></comment></comment></comment>


Ask HN: Do seniors feel that preserving their legacy is important? - <AUTHOR> I'm thinking about building a site to allow people to preserve their legacy and I was wondering, do seniors feel that it's necessary to preserve their legacy for future generations? Do you have more that you'd like to share with your children/grandchildren that you feel they don't know?<p>And on the flip side, do you, as someone with elderly parents/grandparents, feel that you'd like to know more about them? <comment><USER2> Reminds me of: [https://en.wikipedia.org/wiki/Things_to_Do_in_Denver_When_Yo...](https://en.wikipedia.org/wiki/Things_to_Do_in_Denver_When_You%27re_Dead)

"Trying to go straight, ex-gangster Jimmy "The Saint" Tosnia runs Afterlife Advice in Denver, where dying people videotape messages for their loved ones."

</comment><comment><USER3> Why is a website a good medium for preserving someone's legacy?

<comment><AUTHOR> Well it all depends on the reason you're preserving your legacy. For the most part one would preserve their legacy for their children/grandchildren. Today's generation are more than ever more technologically driven. Think to yourself, do you think that a 8-18 year old want to pick up a book or go on an interactive journey of their grandparent's life.

Secondly, the second you put your legacy on paper, that's it. You can no longer update it with more memories. It's frozen in that state. With this website, they'd be able to continuously update it with stories, photos, etc.

Maybe "preserving their legacy" wasn't the correct term to use. On this website, the person will be directed down memory lane prompted to answer questions, add stories, family members, friends, childhood memories, photos, etc.

Additionally, children, parents, and relatives will all be able to link up their own personal accounts to build an accumulated family legacy.

But your point is valid, however. The older generation do like tangible items which is why an additional feature of the website would be to generate a memory album book from the information they've already provided.

<comment><USER3> The general theme of my feedback will be the following: (1) don't automate something that people aren't already doing manually, and (2) the cloud has the wrong mix of pros/cons for this type of project.

> _Secondly, the second you put your legacy on paper, that 's it. You can no > longer update it with more memories. It's frozen in that state._

But it isn't frozen. You can change it or add onto it.

You can think of "preserving your legacy" as a low-read, low-write data type. Once someone does this, they aren't likely to go back and edit it. They may add onto it with photos and whatnot, but they probably won't make changes to old content on a regular basis.

> _With this website, they 'd be able to continuously update it with stories, > photos, etc._

To the extent people already do this (I have personally never seen it), they can just as easily use Facebook as a "digital scrapbook" so to speak. They can post all these types of content now, and their family already have access to it.

> _Additionally, children, parents, and relatives will all be able to link up > their own personal accounts to build an accumulated family legacy._

It seems like people largely preserve their memories as photos with captions. Again, it's something they do on Facebook, and they don't have to convince relatives to use it. All their relatives (especially older ones) already have accounts and previously-made connections.

> _The older generation do like tangible items_

I actually disagree. I don't think they care that much about tangible items. I do think they have a sense of how "long-lived" a medium is. They likely don't think of Facebook photo albums as something that will last for 20 years.

But that's not something any digital property can solve. People know that the web is ephemeral, and the content disappears as soon as the backing entity runs out of money. You'd have to establish some kind of trust to guarantee you'd be around for decades, similar to what graveyards do.

</comment></comment></comment><comment><USER4> Been working on this a fair bit. Contact me.</comment>


Stop Spam With MotionCAPTCHA jQuery Plugin - <AUTHOR> http://www.paulund.co.uk/stop-spam-with-motioncaptcha-jquery-plugin

<comment><USER2> How does this actually stop spam? Any automated bot would just do the POST or whatever is behind the HTML form, without actually loading up the page with this script, and since there's no server-side verification of the user input, it would merrily go through.

<comment><USER3> The motionCAPTCHA author seems to be hilariously clueless. Read through the comments on the site from a year ago. A bunch of people, including Aaron Swartz, point out that it misses the fundamental point of a CAPTCHA (being a task that's easier for a human to carry out than a program) and his response to each is some variation of "you need to read the README more closely", or "I'll have a more production version that uses a regular PHP fallback out in a month".

I've been checking in every once in a while to see if there was actually a "secure", "production" version deployed. Figured I could throw together a bot to defeat it in a few minutes and that would be good for a laugh. Doesn't look like there has actually been any development done in a year though.</comment></comment>


Ask HN: Social placemarking to share places with your friends. Ideas to Tagcrumbs.com? - <AUTHOR> http://www.tagcrumbs.com

<comment><AUTHOR> There are already many services who claim to provide social placemarking? What are the key points for this kind of location-based service?

Mobile, easy mapping interface, visualizations, search, filtering, community?</comment>


Approaching Access Control on the Web (Part I) - <AUTHOR> https://www.ory.sh/api-security-cloud-guide-overview.html <comment><AUTHOR> Hi there! From experience we know how hard auth* systems can be. There are a million ways to get what you want. We also see the issue that developers usually start with a least-effort approach (username + password) which needs refactoring later on. The intention of these articles is to give you an overview of what exists and help you choose the best approach with as much information as you can get. We hope that this saves you some time. If you haven't heard from us before, I welcome you to check out our open source products which are all related to auth*: [https://github.com/ory](https://github.com/ory)

We will plug some of these (and other) open source products in the articles, but we really want to teach you something. There is so much SEO-optimized onboarding (for expensive blackbox SaaS) content with little substance on this topic. We really hope this helps you!

One last thing: We hope it's ok that the other parts are not ready yet. Aeneas (author of the guide) is trying to push out one ~ every month! Getting this content right is a lot of work :)

Cheers!

<comment><USER2> Have you looked into using Macaroons[1] at all for distributed systems? I used them for a client's multi-site intranet a while back, and it made some of the very complicated parts very simple. I'm just wondering why they never seem to have caught on.

[1] [http://hackingdistributed.com/2014/05/21/my-first- macaroon/](http://hackingdistributed.com/2014/05/21/my-first-macaroon/)

<comment><USER3> Because they have a lot of complexity that, for a code they runs a part of auth logic, is really dangerous.

For example, verification of third party Macaroons requires building a directed graph, that needs cycle detection. No implementation that I've checked does this instead allowing only one level of nesting.

Third party caveats have more problems, if a third party would issue them they need to be standardized but there is no such standard. Worse, even the underlying byte format is not standardized instead there is this de facto standard of using "variable op value" format. But what variables are supported? It needs to be specified or the third party macaroon would be invalid.

If we talk about byte formats Macaroons are serialized using another custom format. Compare this with base64 and JSON used by JWT.

Then there are certain "programming shortcuts" in implementations [0].

I've spent some time implementing Javascript library to build and verify Macaroons from the paper (that is also inconsistent with the de facto implementations) but ultimately I've decided to just use limited subset of JWT. It's just simpler.

[0]: [https://github.com/nitram509/macaroons.js/blob/master/lib/Cr...](https://github.com/nitram509/macaroons.js/blob/master/lib/CryptoTools.js#L51)

</comment></comment></comment><comment><USER4> I recently found out about TLS client authentication via client certificates. It seems like a really secure mechanism for authentication that just doesn't have a standardized UX/API for initial cert exchanging and multiple device registration. I am hesitant to rely on a 3rd party SSO provider to remain available. I would much rather rely on a decentralized technology like the TLS certificate network.

<comment><USER5> I did use client side certificates for a while. It's a real pain to get the certificate installed, as it is different per OS and browser.

And I wouldn't call it 'really secure', I'd say it's just as secure as any other client side secret.

<comment><USER3> > And I wouldn't call it 'really secure', I'd say it's just as secure as any > other client side secret.

Only if you store the cert in a file, but you can store it on a smartcard (e.g. Yubikey) or a TPM.

</comment></comment></comment><comment><USER6> Really nice.

> But authorization does not require authentication, and neither does > authentication require authorization.

Can you give an example on this?

* There are a handful of typos scattered through the text, about 5-10 errors

* As I was into learning mode, in the middle of the article I didn't initially notice that the server product you recommending was your own. I think a clarification there is in place

* Server-Side Distributed Applications, I don't have a solid conviction but I can't really see how multiple systems with multiple parallell accounts is a common, viable or even realistic situation...

<comment><USER7> "Authorization" answers "does the entity have permission to access the requested resource?"

"Authentication" is "is the entity is who it says it is?"

"Entity logging in" is an example of authentication. Is the entity trying to log in the entity it claims to be? An example claimed identity is a username, and example proof of authentic claim is a correct password.

"Entity trying to read data" is an example of authorization. Does the entity trying to read the data have permission to read that data? Checking an access control list against a username is an example of checking authorization.

How are they different, and separate?

I claim to be a user and supply a password. My claim is authenticated and I successfully log in. I have requested access to zero resources and thus no authorization has occurred.

A hacker steals my session while I'm logged in and requests my sensitive data. The system sees the request came from a username that is on the access control list for the resource and authorizes the hacker to see my data. No check on my actual identity (authentication) occurred, only a check whether the provided identity is authorized.

<comment><USER6> Thanks for shedding more light on this.

</comment></comment></comment><comment><USER8> you missed a main point in your opening paragraph. Security is best not implemented as a custom solution. There are so many things to get wrong and if you do get even a single detail wrong, it could break the entire implementation.

</comment><comment><USER9> At the very least, webapps should abstract out registration and login processes into a middleware, instead of building their own. This will make it possible to trivially implement single-sign on and sharing auth infra across various tools - especially open-source.

</comment><comment><USER10> JWT with a split cookie seems brilliant to me. Good write up here: [https://medium.com/lightrail/getting-token-authentication- ri...](https://medium.com/lightrail/getting-token-authentication-right-in-a- stateless-single-page-application-57d0c6474e3)

By splitting the JWT across two cookies, rather than using a single cookie or having the JWT stored in the browser local storage, we are able to meet our requirements...

</comment><comment><USER11> Nice! I've been looking for something like this for ages. If I could make a wish, I'd love to see some sort of interactive stuff, or at least visualisations of for example username/password -> cookie exchange. To make it easier to digest. Not everyone prefer to learn by reading :)

<comment><AUTHOR> Hey! That's a great point. John (our designer) is currently on vacation but he will create some animated SVGs which make this easier to digest!

We were also thinking to have an interactive "decision map" where you start with what type of application you develop (e.g. prototype, distributed app, ...) and step-by-step come closer to a recommendation from us. We might also include some software in the last step to guide you to the right pieces. Would that be something you'd like to see?

<comment><USER12> That would be great :)

</comment></comment></comment><comment><USER13> Ory's great, and glad to see they're integrating more with other technologies, e.g., [https://www.ory.sh/api-access-control-kubernetes-cloud- nativ...](https://www.ory.sh/api-access-control-kubernetes-cloud-native/).

</comment><comment><USER14> OP: Hi! Anyone ever tell you your logo looks strikingly similar to Palantir's?

It was enough to make me wonder if Ory is a Palantir offshoot, which doesn't appear to be the case.

<comment><AUTHOR> Never :) No affiliation with Palantir!

<comment><USER14> Well, I suppose I'm the first.

If I can inquire further: are you open to discussing ORY's revenue model? I love organizationally-backed open source projects pertaining to security as there's a less than savory trend in this space for tools to go unsupported after original maintainers have moved on, but I have a bad habit of loving them less when I can't quite nail the business model of the primary entity supporting the projects. I see consulting is likely some part of it, and my guess is there's a product ORY is working on which will monetize an extension of either/both Hydra and Oathkeeper in the future, but hopefully you can see why I'm asking for a more definitive clarification and are in a position to shed some light.

<comment><AUTHOR> Hi, mostly consulting, sponsorship and paid additions to the open source ecosystem. In the future we'll offer managed cloud services. We're not doing open core though, if that's what you're getting at :)

<comment><USER14> Sponsorship, e.g. Patreon? [https://www.patreon.com/_ory](https://www.patreon.com/_ory)

Thanks for the insight!

<comment><AUTHOR> Yes, but we're also moving to open collective for this. Patreon is more for individuals while open collective is for open source collectives.

</comment></comment></comment></comment></comment></comment><comment><USER15> This is actually super useful.

What made you guys just decide to give out this? What's in it for you I mean?

</comment><comment><USER16> This looks great. Looking forward to the coming parts.

</comment><comment><USER17> Recommendation for the owner of the site: The line-height is set too high. It should be max. 1.7

<comment><USER18> Use a monkeyscript to set by yourself ?</comment></comment>


Police Must Respect the Right of Citizens to Record Them - <AUTHOR> https://www.eff.org/deeplinks/2015/04/police-must-respect-right-citizens-record-them

<comment><USER2> "While an officer surely cannot issue a 'move on' order to a person because he is recording, the police may order bystanders to disperse for reasons related to public safety and order and other legitimate law enforcement needs."

Hmm. That looks like a loophole the size of "stop resisting" or "I feared for my life."

I'd be willing to bet that the future holds a notable number of court cases which will turn on the question of whether an officer was justified in requesting dispersement for "public safety reasons"... maybe even as standard operating procedure.

Still, this is an improvement.

<comment><USER3> If your video proves that the circumstances don't warrant "public safety" concerns, that could be overturned. ;)

<comment><USER4> Please make sure your device is uploading the video as you record it before you try to make a court case out of yourself.

It's no fun spending a night in the drunk tank only to discover that your phone was mysteriously wiped in the night.

<comment><USER3> I actually meant "if told to leave the scene while recording, make sure to record the request and then comply", which wouldn't normally be a circumstance where you'd be arrested.

You're certainly right about uploading as you record wherever possible though.

<comment><USER4> I can't cite the exact case, but I think there's been at least one case where someone did that and were still arrested, because they didn't comply with the implicit request - "stop filming me, citizen" \- quickly enough.

I could be wrong, and this might be a memory I made up. :/

</comment></comment></comment></comment></comment><comment><USER5> Im just kinda musing out loud here but I wonder if there is any synergy to be had between the right to record police and the need for grand jury reform wrt police prosecution. The two causes could reinforce each other. Also reminds me of a lyric:

In Orwell's hell A terror error coming through But this Little Brother Is watching you too

</comment><comment><USER6> The police have to know they can't win this battle and should throw in the towel and capitulate. Particularly when live broadcasting services are taking off.

<comment><USER7> > The police have to know they can't win this battle and should throw in the > towel and capitulate.

The police has already won this battle; that is why this EFF page exists.

In the last decade or so, the police has successfully and powerfully militarized itself, became (again[1]) progressively more violent, began (again[1]) handling protests and dissent more and more harshly. They won this battle, partially with the help of the congress and the intelligentsia, which imported the policies that were being applied abroad (again), and they will do their best to win the next one --the one where they need to be put back to their place (of "a good cop does not enforce the law, s/he serves the people").

Looking at the current political atmosphere, where no real choice exists and politics is but money laundering, they will most probably succeed in winning that war too (again[1]).

\----

[1] Just a reference to the Black Rights Movement in 1960s and the society's failure to change the institution (the police) successfully consequently, specifically during the 1970s.</comment></comment>


San Francisco considers banning cashless Amazon stores - <AUTHOR> https://sf.curbed.com/2019/3/20/18273994/amazon-cashless-store-ban-vallie-brown-sf <comment><USER2> The principle they're being banned on is because they're cashless, not because they're automated. The logic is sound - unbanked people exist, including in San Francisco, and without a bank account these stores are inaccessible.

<comment><USER3> Then the practical solution is to pass a law requiring them to have a machine to load a card with, not banning them outright.

This policy is needlessly destructive.

<comment><USER4> > _the practical solution is to pass a law requiring them to have a machine to > load a card with_

This wouldn't work with Amazon's grab-and-go vision. If someone loads $5 of cash on a card and walks out with $20 of product, what do you do?

<comment><USER3> AFAIK these stores employ security/loss-prevention (and stockers as well, just not cashiers). There's people at the door in the videos I saw. How do they stop people from stealing?

<comment><USER5> Security is enforced inbound. You can't enter without an account. You can grab "anything" you want and it's charged to the account.

</comment></comment></comment></comment></comment><comment><USER3> _According to Brown, as many as 50 percent of black and Latino households in San Francisco go without a bank account_

This stat is hard to believe. Does anybody have a link to the actual study? Most national studies (like the FDIC one) put this number around 5%. My wife works in the restaurant industry, and most all of the illegal immigrants have bank accounts, smart phones, use direct deposit, etc.

<comment><USER6> According to the article, the data the city is using is from 2005. It is likely access has increased in the past 14 years.

<comment><USER3> The article doesn't link to the study and I can't find it. "As many as" could mean anywhere from 1 to 50%. Smells like deception, but I could be wrong.

<comment><USER7> There's a PDF ([https://prosperitynow.org/sites/default/files/resources/Bank...](https://prosperitynow.org/sites/default/files/resources/Bank%2520on%2520SF%2520case%2520study%2520electronic%2520version%2520FINAL.pdf)) that says that an analysis with those figures was done by Matt Fellowes at the Brookings Institute, which is interesting because it doesn't mention any polling or details, so who knows how those numbers were generated.

<comment><USER3> Thanks! Their numbers seem to be far off from the FDIC studies, despite them claiming they corroborate national averages.

Looking at the FDIC study from 2009, ~20% of Black/Hispanic households in California were unbanked, and when looking at citizens the number is ~7%.

</comment></comment></comment></comment></comment><comment><USER8> The recent attempts at banning cashless stores is addressing the symptoms without considering the root cause. The two main reasons to ban cashless stores revolve around privacy and access to the un/underbanked. Privacy is a legitimate concern, but what are we doing to solve the crisis of folks who don't have access to a bank? There are some policy papers floating around regarding postal banking and programs of a similar nature, but none of these proposals are getting legislative traction.

</comment><comment><USER9> Instead of worrying about a store that gets very little foot traffic lets worry about the homeless encampments, human poop, needles, piss bottles etc. that flood the city.

I agree, if there is a huge shift in stores to cashless we have a possible issue at hand if the unbanked are truly that high. BUT I don't see this kind of shift in stores anytime soon.

There are a lot bigger problems to tackle in this city that none of city government wants to take on. But sure lets spend time talking about these Amazon stores.

</comment><comment><USER10> Don't pay attention to this. It's a political side-show by a Supervisor trying to rally her base.

This is in the same vein as the "ban corporate cafeterias" shenanigans last year. It won't fix anything and the politicians yammering about it don't actually care about this.

It's all a game.

The real solution, of course, isn't saving jobs that don't pay enough money to actually live in the city. It's building housing. But that's politically difficult, so we get this.

<comment><USER11> This is not an isolated political stunt. A lot of cities and states are now enacting similar measures.

</comment></comment><comment><USER12> This is dumb. Imagine there's a totally cashless economy that keeps out the unbanked. But then a merchant could price gouge the unbanked. But then there'd be competition for this high margin unbanked business. But then the merchants would compete for the unbanked by lowering their margins. But then equilibrium would be hitting the unbanked up for precisely the inconvenience overhead of dealing with cash. Unless unless unless someone interferes with the market in a regulatory way. Or gets impatient waiting for the inefficiency to right itself. Sheesh.

</comment><comment><USER13> Can't they place a machine in the stores where people can deposit cash and get a loaded card to purchase things with?

Cash is legal tender and should always be a possible method of purchase at physical locations.

<comment><USER14> The whole premise of Amazon stores is to just grab stuff off the shelf and leave.

If someone feeds $1 into the machine and gets a loaded card, can they just walk out with $20 worth of merch? With a credit card you just get charged for whatever you took and you pay later.

</comment></comment><comment><USER15> FWIW, more and more cities are trying to ban cashless stores. Philadelphia became the first city to ban cashless stores citywide earlier this month [1]. Would be interesting to see if NYC and SF both ban them as well.

[1] [https://www.phillyvoice.com/philadelphia-ban-cashless- stores...](https://www.phillyvoice.com/philadelphia-ban-cashless-stores-first- us-city/)

</comment><comment><USER16> How about solving this through store credit cards? Put a machine outside Amazon store. Insert cash -> Get loaded card. Sorted!

</comment><comment><USER17> There are so many unbanked people in the U.S. that I wonder whether local governments should step in to address the problem, because the private market has clearly failed to serve these people.

<comment><USER18> > There are so many unbanked people in the U.S.

How many?

> local governments should step in to address the problem

What do you suggest they do?

<comment><USER17> [https://www.fdic.gov/householdsurvey/](https://www.fdic.gov/householdsurvey/)

8.4M unbanked people. A publicly-owned bank might do them a lot of good, especially in areas that are underserved by credit unions.

</comment></comment></comment><comment><USER19> I've been to that store and it's clearly a test bed, not a real store. There are employees who stand there and answer questions. The ceiling has hundreds of cameras which I assume they plan to use for some sort of AI tracking to determine who took what. For the time being, I'd bet they are mechanical turning it, since there is a 10 minute delay between leaving the store and being charged.

</comment><comment><USER20> So the problem isn't a lack of cashiers but a lack of cash. It seems like the problem could be solved by having a few smartphone-like devices that you can shop on and take to an automated cash machine at the end. Then you'd just need a supervisor to make sure people weren't walking off with the merch, which they probably have anyway.

</comment><comment><USER21> Is there any limit to what laws cities are authorized pass? I'm surprised this is even legal. If you push the reasoning further, could they also ban ATMs? Banks? Uber, AirBnB, Eat24, any cashless service? To be honest, I feel like this has more to do with protecting local merchants than protecting the unbanked.

</comment><comment><USER22> I don't disagree really, but I thought Amazon had a service where you could add to your Amazon wallet using cash?

<comment><USER23> How are you going to add cash to your amazon wallet (let alone use it), if you don't have a smartphone?

<comment><USER22> They give you a barcode that you can use to fill your wallet.

</comment></comment></comment><comment><USER24> From the article it comes down to an equity issue; some people do not have cashless service and that means they cannot shop at an Amazon store. If it's true that 50% of black and latino families go without a bank account, banning cashless stores feels like the equity equivalent of banning plastic straws.

</comment><comment><USER25> This is exactly one of the problems we as a crypto ATM company solve. Allows a lot of unbanked folks to convert the little cash they earn to digital currency or cards. You wouldn't believe the reasons why people can't get bank accounts...

<comment><USER26> I don't see how cryptocurrency solves this - if you exchange your cash for a cryptocurrency then there are even fewer ways to spend it than when it was cash.

If you exchange your cash for (say) a Visa gift card or some similar reloadable card then you can use it wherever Visa works, which is many places (a lot of which would also accept cash) including online stores.

And if the laws are changing to prevent cashless stores from existing then you can just keep your cash as cash.

</comment></comment><comment><USER27> Makes a lot of sense, you have to accept cash unless you want to give out for free.

</comment><comment><USER28> So they're going to shut down Blue Bottle too?

</comment><comment><USER29> That's ridiculous. Why should Amazon even care about selling to people that only have cash ?

</comment><comment><USER30> Just add one cashier.</comment>


Python has brought computer programming to a vast new audience - <AUTHOR> https://www.economist.com/science-and-technology/2018/07/19/python-has-brought-computer-programming-to-a-vast-new-audience <comment><USER2> dupe: [https://news.ycombinator.com/item?id=17569756](https://news.ycombinator.com/item?id=17569756)

<comment><USER3> That's 4 months old and the discussion is locked on it.

<comment><USER4> From the official FAQs[0]:

 _If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok._

252 points/261 comments probably qualifies as "significant attention".

[0] [https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html)

</comment></comment></comment><comment><USER5> Python was my first programming language love. I had a few false starts: Logo when I was very young, which I found too useless. Perl, which made no sense to me as a middle schooler. Actionscript came close, I was eventually able to create a Flash game in high school, but the API was still too arcane for me to actually _like_ it.

In college, Processing.js was what I used in the Intro to Programming class, which was fun, but like Logo, not powerful enough. Java (why do I have to type so much?) and C (why do I have to worry about memory allocation?) for the intermediate courses. But I never really enjoyed a language until one of my upper division classes had us work in Python.

Finally, a reasonable language. Easy to pick up, but very powerful once mastered. Easy to read, quick and concise to write, thanks to the syntax and interpreter. A massive amount of open sources packages to choose from, for nearly any programming task you can think of. A sane blend of functional, object-oriented, and procedural features.

Python was the language that made me actually enjoy programming. Thanks GVR!

<comment><USER6> > _why do I have to type so much?_

As someone who came to it from Ruby, that is often my question about Python :)

<comment><USER7> I'm a Python developer (web back) who occasionally does some fixes on legacy RoR project and I always ask myself why does Ruby needs so much sugar. Also it does not look very consistent to me, but it's probably because I get to practice only once in a couple of months.

After Java, CPP and Node, Python looks to me as the greatest of all. Syntax is just comes to you and usually does not produce problems. And Python even right now has so many areas of application, and does it without much compromises, that I wonder why would I want to change anything.

<comment><USER8> I programmed in python for years, am starting to code in javascript/node and am really liking it. Typing in python is weird, i much prefer flow/typescript. Async in python has a history of being weird, from twisted, to yield from, and finally to async/await (which still has some issues, but is much better). I thought javascripts "callback hell" actually made sense, promises made it easier, and now async/await which works great. Pip has a long way to go to catch up to npm/yarn (i cant believe im saying that). Virtualenvs are weird, even though node_modules can be bloated i think its a lot more intuitive.

Anyway, long winded answer that i think i prefer node after a lifetime of python

<comment><USER6> pipenv replaces pip and virtualenv, and is actually decent.

<comment> xkcd-sucks Pipenv looks good on paper, but it is a total trap. Pipenv breaks differently on every single release. The user experience is absolutely hideous.

I am currently in my third hour of getting a pipenv+pyenv python project running. I started the project this past summer, and have reinstalled it three times. Each time I have spent 3-6 hours getting pipenv working, and each time the errors/problems/workarounds are completely different!!!!!!

<comment><USER6> All I know is it works well on our projects.

I'm not the one doing any dirty work though...

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> As a part of my college curriculum most students are required to take a programming course; I got put into the Java course. Although I was good at it, I hated every minute of it because it felt like I was fighting the computer to make things work.

I played around with PHP in order to make hacks on WordPress themes, which again I hated due to system-fighting.

I learned base R (pre RStudio/tidyverse) for stats classes, which I hated even more than the previous two since everything felt combersome.

Then just for fun I installed Linux on my laptop and experimented scraping APIs with Python with only a few lines of code and I got _hooked_.

Nowadays I use primarily Python for both work and personal projects. If I had _started_ with learning Python, I would have had a much different career path!

<comment><USER10> Java has some advantages over python in a teaching environment.

Writing a basic hello world function you'll learn about types, return values, references, imports and access modifiers, all in three lines of code.

Java is also excellent for building stuff like various linked lists to see how the lists and arrays we all take for granted actually work behind the scenes.

The confines of Java's strictness is also a really great sandbox in which to teach best practices without students ever getting in danger, because java will tell them every time they do.

I know a lot of teachers really struggle to do it well, but going through public void X, word for word can be extremely useful in teaching. For one, it's very easy to spot who knows what is happening and who is just copying stuff to make it work.

I think python is quite terrible for teaching beginners, but it's certainly fun to write. These days, I think JS and Node is more fun than python but that's mostly because it's where a lot of the fun is happening, I certainly could do without all the {s and ;s.

<comment><USER11> I disagree. Those three lines of code are three lines of utter black magic to a beginner. Things are only useful insofar as they solve a problem, and the beginner hasn't yet encountered the problem solved by types yet, so there's no reason to teach them.

<comment><USER10> Well, after the first programming lesson, they are no longer magic. In python, they are never demystified.

<comment><USER11> Right. Let's learn 50% of all the mechanical aspects of programming in one lesson. Those just serve to get in the way of initial learning, general program flow and logic.

<comment><USER10> Those few topics aren't close to being 50% of the mechanical aspects of programming. What are you even on about?

Furthermore they are all easily explainable concepts that any CS student will be able to grasp once they reach their first programming language course.

I'd say most of the concepts are easy for non-CS students as well. Access modifiers, especially public and private aren't hard concepts, are they? Yet they are insanely important to your basic understanding of what a function does. Private is like singing in the shower, you're doing it for you. Public is like signing at a concert hall, there you're signing for the audience.

Return values are values functions return, your can think of them as the result a calculator gives your when you ask it to add 2 and 2, here the return value is 4.

Types are typically the first thing you explain anyway, including when you teach python.

Maybe you could get people writing complicated functions faster in python, but why would you want to? The purpose of teaching programming isn't to have people writing code as fast as possible, it's to teach them to understand what the hell it is they are writing, so they'll know why they do it.

</comment></comment></comment></comment></comment></comment><comment><USER12> A 5 year old can do bit of Python programming :). Start terminal, type Python and then type 2 + 3. Watch them getting kick out of typing huge numbers and Python spitting out the answers.

<comment><USER3> Same with Haskell or ML family languages.

<comment><USER13> Ahhhh, but then they will ask how to print things and you'll have to explain monads :)

<comment><USER3> I thought we were talking about a REPL instance. Have you already explained how to use a command line and what files are and how to run them? stdout?

<comment><USER14> You need none of that in a jupyter notebook.

<comment><USER3> Jupyter supports Haskell too though. As well as OCaml and Scheme...

</comment></comment></comment></comment></comment></comment><comment><USER3> I found this article to be profoundly weird in a lot of ways. It's not quite suffering from the "igon value" problem, but gosh does it come close. It's hard to measure programming language popularity, and most estimates I've seen have Python neck and neck with JavaScript with regards to popularity. Plenty of other languages have simple syntax and are easy to read, the only thing I would say Python has that is clearly superior is availability of packages and community support, (and even then JS has got to be close there) which are undoubtedly huge, but I think it's fallacious to assume that those reflect intrinsic technical worth.

<comment><USER15> >Plenty of other languages have simple syntax and are easy to read

As easy as Python? That's a very high bar. We all agree (I hope) that JavaScript requires linters (plural) to write well. Rust/Scala/Haskell have unpleasant learning curves. Java is verbose and clumsy. Basic and Pascal have fallen into disuse. Go may be simple, but it's syntax is more symbolic and less English-like than Python. Don't get me started on Perl and the lisps. C/C++/PHP have more footguns than features.

I'm not a Python die-hard, but it's obvious that it's superior when it comes to ease-of-use and learning curve. It's very similar to how people write pseudocode.

<comment><USER3> I will argue that learning curves are similar with Ruby, SmallTalk, ML, and Scheme to Python. Logo is the original teaching language, and I think is similarly easy. It's my belief that people exaggerate the learning curve of Haskell, but whatever, I'll grant you that.

If your criteria for readability is "English-like" I think you're missing a lot of what makes Python so readable in the first place. It is not very English-like at all. Compare to say COBOL, which actually had English-like readability as a design goal and was by all accounts an unmitigated disaster. AppleScript has a similar reputation for being a "read-only" language because of how difficult it is to pick up from reading it. What makes Python readable is having a small number of concise syntax constructs that compose into complex programs, the same things that make functional code readable. The presence of words vs operators is probably important, and Haskell tends towards the latter, but the ML family doesn't, and Lisps are plenty readable if you keep them simple. There's a reason that SICP and HTDP use Scheme, the latter using a gradually larger subset to make it less intimidating.

</comment></comment></comment><comment><USER16> Python was not the first programming language I wrote a program in, but it was the first one I _actually ran_.

When I was a kid I wanted to make games, I picked up a book on C from the library. I wrote a simple interactive fiction type game but with never managed to compile it.

When I tried out python a couple of years later I was blown away. I could actually write and run programs. I wrote a mandelbrot set generator and I was hooked. _This_ is what programming is supposed to be like, I thought to myself.

</comment><comment><USER13> Biggus Uptickus</comment>


New book about Hustling - <AUTHOR> https://www.thunderclap.it/projects/35844-hustle?locale=en <comment><AUTHOR> I'm launching a new book about hustling. It's about what the word "hustle" really means--and why it's important. Thought the HN community might appreciate it.</comment>


X86/ARM Emulator - <AUTHOR> http://www.codeproject.com/Articles/478527/X86-ARM-Emulator

<comment><USER2> Looking at the screenshots reminds me of days when low level debuggers were common and useful.

pfix and pfix 86 plus (of which google can find no more than 2 mentions for me!) .. Turbo Debugger was ok too. I miss the easy low level access that those tools gave me -- when I had to choose between source level debugging and low level debugging, I chose the low level ones. Partly because it was much easier to reason about the low level parts (no C++ virtual inheritance and template proliferation craziness, libraries were smaller and simpler), but mostly because they were so much faster and gave a complete picture.

Nowadays, you get no choice - gdb for low level debugging is awful, and the MS debuggers aren't much better.

<comment><USER3> For Windows there is OllyDBG [1], it is simply the best (with tons of plugins and scripts) for user-mode assembly debugging, but doesn't work in kernel- mode.

[1] - <http://ollydbg.de/>

<comment><USER2> Thanks. It's been a while since I've done low level windows - SoftICE was still usable then (barely, but usable. It was Win2K driver development on an Athlon 800Mhz...)

For anyone interested, a quick google of OllyDbg for linux leads to this list: [http://ubuntuforums.org/showthread.php?t=608123&highligh...](http://ubuntuforums.org/showthread.php?t=608123&highlight=ollydbg)

</comment></comment></comment><comment><USER4> Why not just use qemu?

<comment><USER5> For the same reason I wrote DSemu and jsGB: an educational experience. I only half-expected to get an emulation to the state where it would emulate commercial games and/or professional demos; the main motivation was to understand how a system works by simulating it, and to gain experience at multiple levels of the architecture at once.

Writing a system emulator in JS/HTML5 is a great way to learn the system being emulated, how to quickly and efficiently read assembly and/or opcodes for the processor under emulation, and acts as an introduction to HTML5 with it.

<comment><USER6> I'm currently re-learning how a computer works under the hood and implementing my own little emulators after forgetting everything from university/school.

I plan to write a GB emulator too one day.

I'm a Java programmer by day job but I find it dull so this is my "hobby" at the moment</comment></comment></comment>


Google wants to hire the "Killed by Google" author - <AUTHOR> https://mobile.twitter.com/killedbygoogle/status/1250068526381051907 <comment><USER2> This title is clickbait. Google sent him one of thousands of generic recruitment emails.

More accurate title: "'Killed By Google' author receives Google recruiter spam".</comment>


New Orleans May Face an Unprecedented Weather Situation This Weekend - <AUTHOR> https://slate.com/business/2019/07/new-orleans-may-face-a-storm-surge-on-an-already-high-mississippi-river-this-weekend.html <comment><USER2> Hurricane Katrina had a huge impact on my worldview. Much more than events like the 9/11 attacks. I generally concluded that putting your safety or security in the hands of governments, or really any institution, was a potentially fatal mistake.

And I'm not just talking about natural disasters. My interest in something like Bitcoin as opposed to banks is attributable to the hurricane Katrina response (the 2008 financial crisis being just a later example of centralized failure).

I'm fairly confident in my position, but I hope to be proven wrong on this one. I never want to see anything like the results of Hurricane Katrina ever again.</comment>


If MongoDB is unreliable, are services like YC S11 Parse unreliable? - <AUTHOR>

After reading http://news.ycombinator.com/item?id=3202081 and http://schmichael.com/files/schmongodb/Scaling%20with%20MongoDB%20%28with%20notes%29.pdf<p>I start to wonder if using services like Parse for your backend is a bad idea? <comment><USER2> Parse is very unsecure because you essentially give the user full read/write/delete access to all of its data as no logic is run server side but clientside. That means any scriptkiddy can change all data as it likes.

That has nothing to do with MongoDB, but with the cirtical design flaw of Parse to trust the client not to send fake data.

<comment><USER3> My initial intuition is that such an egregious oversight can't possibly be real for a YC11 company, can anyone validate this? Does Parse _really_ provide no way to set document fields writable, readable and so on?

<comment><USER4> In Parse you can authorize/de-authorize client permission to get, find, update, create, and delete for each table</comment></comment></comment>


Ask HN: Lightweight 17-inch laptop for programming? - <AUTHOR> I'm looking for a portable 17-inch laptop for programming. The best candidate so far is the MSI GS73VR 6RF [1]. It's < 2.5 kg, quad-core 45 W CPU, Full HD @ 120Hz, ports, etc. are exactly what I'm looking for. No optical drive. Perfect.
The thing is I don't need a GeForce 1060, the Intel HD Graphics 530 is more than enough for a text editor. It has 3 fans that run all the time and battery life is much less than desired.
If I could swap the discrete GPU (and it's cooling) for a larger battery, I would buy this in an instant!
Are you aware of any 17-inch laptops that fit those requirements?
[1] http://www.notebookcheck.net/MSI-GS73VR-6RF-Notebook-Review.172138.0.html <comment><USER2> Out of interest, why is 17" the requirement? While there are laptops that have screens that size, they're not as portable as one might think. Laptops with screens that size tend to be used by video editors, photographers, anything that involves manipulating photos and videos really, so a powerful graphics card is pretty much part and parcel of that.

I used to have a 17" PowerBook years ago and I can tell you, if you're wanting portability then a 17" machine is not it. Machines of these size tend to be used in the field when needed, so it's not typically expected you'll be carrying one around day to day–they're more a "need to head to a shoot, take the 17" and put it in the truck so I can edit video while we work" type of deals.

More importantly, you'll find that many places where you'd normally be able to use a laptop are no longer an option, simply because of the gargantuan machine you're carrying (coffee shops, airplanes - many places you would expect to use a laptop tend to be uncertainties with a 17" laptop). If you're going to be carrying this around for any length of time then your back is also going to let you know just how painful this is.

As pointed out on the thread, the rise of 15" hi-res screens provides many of the benefits of the real estate of the 17" without the drawback of the extra bulk - provided you're eyesight is pretty good.

</comment><comment><USER3> I doubt that such a beast exists because 17" laptops are a niche product.

1\. The sweet spot of that niche is games with CAD a somewhat distant second and both of those uses demand GPU's these days.

2\. The size and weight and form factor of a modern mobile GPU probably does not make replacing it with a battery a viable option. If it were, putting in another battery would add significant weight.

3\. Lightweight laptops will tend to run their fans more (or use lower power processors) because the mass and volume of the case is not available as a heat sink.

Personally, I'd look at Dell Precision 7000 series. They can be ordered online with Linux out of the box (at least in the US) and therefore enjoy long term support. In terms of processors, they come with just about whatever one's wallet can cover.

The current 17" model: [http://www.notebookcheck.net/Dell- Precision-7710-Workstation...](http://www.notebookcheck.net/Dell- Precision-7710-Workstation-Review.158505.0.html)

The older m6800 may also be available online in the US: [http://www.notebookcheck.net/Review-Dell- Precision-M6800-Not...](http://www.notebookcheck.net/Review-Dell- Precision-M6800-Notebook.105108.0.html)

<comment><USER4> yeah the 7710 is just awesome

</comment></comment><comment><USER5> Portable 17 inch laptops seriously do not exist. It's just too girth-y a dimension to reconcile any semblance of portability. I would seriously look in to the rMBP 15" computers (especially now that new ones are imminent, you might snag one secondhand on the cheap!) or Dell XPS 15. Your back and shoulders will thank you!

<comment><USER6> They exist and they are usable as a portable machine. Luggable may be a more fitting category though.

</comment></comment><comment><USER7> Take a look at System76, especially if you're considering running Linux.

[https://system76.com/laptops/kudu](https://system76.com/laptops/kudu) [https://system76.com/laptops/oryx](https://system76.com/laptops/oryx)

<comment><USER8> Why?

The laptops I know work mostly fine on Linux.

<comment><USER9> Well, you said it: _mostly fine_.

 _Mostly_ shouldn't be good enough. With System76 (and for that matter, Zareason) you'll have zero worries during OS upgrades, and never _ever_ have to think about drivers. The laptop will just work.

<comment><USER8> I've never thought of drivers on my previous laptop and current desktop. And my brother's laptop too (these are all low to mid range though).

<comment><USER9> Perhaps this is less of a problem today, but at the time I made my first purchase from System76 (2012), the sudden absence of video and sound issues after every other system update came as a welcome relief.

</comment></comment></comment></comment></comment><comment><USER10> [http://www.santech.eu/c57-series](http://www.santech.eu/c57-series)

<comment><USER3> The 17" model is 3.1kg and has a pretty substantial GPU. Not a criticism, that's pretty much the reality in the 17" market.

</comment></comment><comment><USER11> one thing to consider is that, because laptop screen resolutions are higher than they used to be, you may be fine with a smaller screen. Maybe take a look at a 15" one with high resolution?

<comment><USER12> A friend just bought a 15-inch LG gram notebook: 1080p screen, i7 CPU, 8 gigabytes of RAM, 512-gigabyte SSD, and it weighs 980 grams--just over two pounds. An i5/4G/256G version also exists.

It is not a super-fast machine, and _definitely_ see reviews on the web and YouTube as it's not in the same league as a Thinkpad, but if an HD screen and light weight are priorities, it's worth investigating. Fry's Electronics has them on display.

A representative review: [https://youtu.be/Aub6RCHmpHg](https://youtu.be/Aub6RCHmpHg)

<comment><AUTHOR> Thanks, this is a very interesting machine. I didn't like the sound of "tablet-class performance" or the sight of the screen bending like a sail.

Good luck to your friend.

If we can have a 1 kg 15.6 inch,

why not 2 kg 17.3 inch?!?

</comment></comment></comment><comment><USER13> HP Spectre is great. The HP Envy line is cheaper, but also has the numpad.

</comment><comment><USER4> i've got a 17in dell 7710 and am happy with it. it's not exactly lightweight though

<comment><USER3> Was cleaning out recently and pitched my Satellite 1805-S203 I bought in '01\. Out of the box, it weighed over seven pounds [1]. Back in the day, I threw it in the bag and thought nothing of it. The 7710 doesn't weigh much more...though the same cannot be said for the power brick, with the emphasis on 'brick'.

[1]: [https://www.cnet.com/products/toshiba- satellite-1805-s203-13...](https://www.cnet.com/products/toshiba- satellite-1805-s203-13-3-celeron-128-mb-ram-15-gb-hdd-ps181u00cfche/specs/)

</comment></comment><comment><USER14> Lenovo has brought back its 17" Thinkpad series (P70).</comment>


'Pushback': Resisting the life of constant connectivity - <AUTHOR> http://www.washington.edu/news/2013/10/21/pushback-resisting-the-life-of-constant-connectivity/

<comment><USER2> My Android phone broke down month ago, I am practically offline since than. Twitter, IM and other stuff was constant source of distraction.

Now I have 'dumb' phone, I only miss GPS and flash light. I still do read twitter, but only every second day together with RSS and log files. My IM has constant status 'Do not disturb unless it is on fire'. Only paying customers have now privilege to interrupt me, we mostly schedule meeting anyway.

60% raise in productivity, I am less tired and I even got time to read a book.

<comment><USER3> _I only miss GPS and flash light_

This is about where I was too. Bought a car GPS which is good enough for me and has no monthly service fees, and mounted a couple flashlights inside my car.

</comment></comment><comment><USER4> "Pushback" isn't such a great name for this specific phenomenon, since it's already a general business-jargon term for any kind of opposition to something that someone is trying to get you to do. As in: "I'm getting pushback from the customer on delaying the release date."

</comment><comment><USER5> I canceled my mobile contract in March and haven't looked back since. I've become more familiar with my surroundings, more focused conversations with my peers, and have overall experienced a better quality of life.

The first few weeks were pretty tough; life without GPS made it an absolutely requisite to study the route to your destination before departing, and I did have a constant urge to check a device to see if anyone "needed me" yet. This feeling became negligible after the first month, to vanishing entirely by about three months in.

Sometimes, it helps to gain perspective.

<comment><USER3> No cell phone entirely?

 _life without GPS made it an absolutely requisite to study the route to your destination before departing_

I've found this has helped me learn more about the layout of the towns. When I follow GPS, I may as well be in a maze with the lights off- I get to my destination, but I don't know where I am or where anything is.

</comment></comment><comment><USER6> s/pushback/moderation ? People not using technology is not really new, is it? Perhaps hyper-connectivity is, but people often ditch modern conveniences and "discover" life or whatever. I've used paper to design every piece of software I've written in the last few years.

I got my phone stolen a while back and ended up using a simple phone for a few days. It was amazingly refreshing to not constantly check email or read "news" when bored. Firing off quick emails all the time isn't any more efficient, and really detrimental to my mind. Unfortunately, I can't seem to convince other people to pace themselves.

Get a low-end Android phone and connect it to a separate email account (for travel documents or whatnot). Maps and Wikipedia will function, but it'll be generally useless as a time-wasting device.

</comment><comment><USER7> All things require balance. I think we could use a little more 'pushback'. Online connectivity does not provide the same quality of interaction as real life connectivity. Although it clearly has its place.

</comment><comment><USER8> Recent but relevant: [https://www.youtube.com/watch?v=OINa46HeWg8](https://www.youtube.com/watch?v=OINa46HeWg8)</comment>