Why Google stores billions of lines of code in a single repository (2016) - <AUTHOR> https://dl.acm.org/citation.cfm?id=2854146 <comment><USER2> I've worked with both a distributed repo model and a monorepo model and vastly prefer the distributed approach (given the right tooling). The trade-offs are complementary and no doubt with proper discipline you can try to maximize the benefits, while minimizing the downside. But here's what I don't like about working in a large monorepo:

1) Difficult to track changes to the code I'm interested in. Every day there are hundreds of changes in the repo and almost all of them have nothing to do with what I'm working on.

2) all sorts of operations take longer (pulling, grepping source, etc.) to support code I couldn't care less about.

3) Frequently have to update the world at once. Unless the repo can store multiple versions of the same module, then all the consumers have to be updated at once, even if it's inconvenient. Sometimes migrations are better done gradually.

4) Encourages sloppy dependency management. There are frequently unclear boundaries between software layers.

I'm sure people will say "if you're having those problems, you're doing it wrong" but the same thing could be said to people who find the distributed model problematic.

<comment><USER3> Software A version 1 consumes format F1 and produces format G1 data, and software B version 1 consumes format G1 and produces H1.

To upgrade format G2 we _must_ change both software A and B.

First, software B version 2 must accept both G1 and G2. To do this we may need to build software A version 2 and try them in a sandbox environment to gain confidence that ∀F1 we produce the correct G2. If F1 is complete, we may be able to do this exhaustively, but if F1 is sufficiently diverse, monte carlo simulation might be used.

Then, if there's a 1:1 relationship between A/B we can upgrade pairs.

If there's a N:M relationship, we need to upgrade all of the instances of software version B1 to B2 (at least within a shard). If you're running in a non-stop environment, this might have it's own challenges. Only then, can we _begin_ the upgrade from A1 to A2.

Now:

Something, somewhere needs to record what and where we are in this journey. It is relatively straightforward how to do this with a monorepo, but it is very unclear how to do it with a distributed repository:

Almost everyone I know punts and uses some other golden record (like a continuous integration server, or a ticketing system, or an admin/staging system), and like it or not: that's your monorepo.

<comment><USER4> You can also design software A to produce both G1 and G2 side by side, deploy it, and then develop new software B against G2, submitting bug reports to project A when there's a problem detected in G2.

If you're doing the multirepo strategy it's best imho to make the projects truly independent, as if they were developed by different companies. That way every project only needs to think about its own dependencies and consumers, and how to do migrations, without needing to have the big picture mapped out.

<comment><USER3> > You can also design software A to produce both G1 and G2 side by side

This can be impractical if G is a database table that is very large.

> it's best imho to make the projects truly independent, as if they were > developed by different companies.

One of our systems might cost £300k, so completely desynchronising them so that code paths can build both G1 and G2 simultaneously (allowing B to develop separately) means "simply" doubling the costs. That might put our team at a disadvantage against someone who figures out another way.

<comment><USER5> > This can be impractical if G is a database table that is very large.

If this is true, you _have no choice_ , and must run things side by side while you convert to G2. Or shut everything down to make the migration atomic, which is increasingly not an option.

<comment><USER3> > you have no choice

It depends on your database.

If you imagine a simple postgres or mysql server and an "alter table G..." then you're right.

If (however) G1⊂G2 then a document store or a column-based database can usually partition the table somehow.

</comment></comment></comment></comment></comment></comment><comment><USER6> Large-scale refactorings are actually pleasant.

My team owns a framework and set of libraries that are widely used within the Google monorepo. We confidently forward-update user code and prune deprecated APIs with relative ease — with benefits of doing it staged or all-at-once atomically.

It's imperfect, but maintenance in distributed repositories is infinitely worse. Still, I remember the earlier days of the monorepo and keeping Perforce client file maps; that was a pain! [https://www.perforce.com/perforce/r15.1/manuals/dvcs/_specif...](https://www.perforce.com/perforce/r15.1/manuals/dvcs/_specify_mappings.html)

<comment><USER7> How many people work on the repository tooling at Google?

I'm asking because i wouldn't know how to setup a mono repository at my 50 people Startup even if we deemed this to be necessary.

<comment><USER8> > I'm asking because i wouldn't know how to setup a mono repository at my 50 > people Startup even if we deemed this to be necessary.

Sorry if this is a really dumb question. If you only have 50 people I'm assuming your codebase isn't that big, so why can't you just make a repo, make a folder for each of your existing repos, and put the code for those existing repos into the new repo?

I imagine there's a way to do it so that your history remains intact as well.

<comment><USER9> Yes, there is. Move the entire content of each repo to a directory and then force-merge them all in a single repo. I did this a few years ago with 4 small mercurials repositories that belonged together.

</comment></comment></comment></comment><comment><USER10> Google's mono-repo is interesting though, in that you can check out individual directories without having to check out the entire repo. It's very different from checking out a bajillion-line git repo.

<comment><USER11> It's kind of interesting that nowadays people assume that version control system == git.

For a huge, non-open codebase there are some pretty large downsides to a fully distributed VCS in exchange for relatively few benefits.

<comment><USER12> Could you please elaborate? I've only used svn and git, and the largest codebases I've worked on have only been about 150k lines of code.

What are the other ones and the main differences, really curious

<comment><USER13> Perforce is really common in a few domains because it handles 1TB+ repo sizes cleanly, has simple replication, locking of binary files and a good UI client for non-programmers.

Was pretty much used exclusively back when I was in gamedev, not sure if that's still the case.

</comment></comment></comment></comment><comment><USER14> I work in a large company and I have used a central repository for six years and a distributed for six years. I think a central repository is better. The benefits are:

1) Transparency. I can see what everybody else is doing and if somebody has an interesting project I can find it quickly. You can also learn a lot from looking at other peoples changes.

2) Faster. To check out the source code for the project I now work on takes an hour in the distributed system, while it only took 5 minutes in the centralized system.

3) Always backed up. All code that is checked into the central repository is backed up. It has happened twice that employees have left and code was lost because they only checked it in locally.

Many have only used CVS or SVN, which are horrible. I rather use Git or Mercurial, but Perforce is really good.

<comment><USER15> > 1) Transparency. I can see what everybody else is doing and if somebody has > an interesting project I can find it quickly. You can also learn a lot from > looking at other peoples changes.

This doesn't require a _single_ central repository, just that all repositories live in a common location.

> 2) Faster. To check out the source code for the project I now work on takes > an hour in the distributed system, while it only took 5 minutes in the > centralized system.

What distributed repository management system do you use, and what centralized system did you use?

> 3) Always backed up. All code that is checked into the central repository is > backed up. It has happened twice that employees have left and code was lost > because they only checked it in locally.

As with point 1, this doesn't require a _single_ central repository, just that all repositories live in a common location.

<comment><USER16> I use git-svn to use a central repository. Let me list the advantages

1) Faster

There is no comparison. But let me count the ways

a) checking out stuff

It is faster than just downloading a directory using SVN.

b) just trying something out (ie. branch)

Creating a branch, making a few changes takes me seconds, and does not require me to change paths like it does for the svn victims I work with. Throwing it back out again takes seconds, and all operations are reversible for when I fuck up (which is often).

c) merging

Git's merging. Oh my God. In half the cases I just have to check stuff over, if that.

d) submitting

We use code review. Unlike most of the subversion folks I can easily have 5 co-dependant changes in flight (5 changes, each depending on the previous one) without going insane, and I have gone up to 13, not counting experimental branches. I observe around me that it takes a good developer to manage 2 with subversion. 5 is considered insane, I bet if I showed them the 13 were in flight at the same time they'd have me taken away as a danger to humanity.

2) always backed up

Subversion doesn't back up until you commit and people don't commit anywhere near quickly enough ... The way people lose code around here 99.9% of the time is by accidentally overwriting their in-flight code contributions (the remaining 0.1% involves laptop upgrades and overenthusiastic developers. Even then cp -rp will just copy my environment and just work, and yet the same is absolutely not true for the subversion guys).

Now with Git, I commit every spelling fix I make, every semicolon I have forgotten, on occassion separately, other times with "\--amend". And only then make my share of stupid mistakes, after committing, something that's technically not impossible on subversion but not practical, mostly because of code review ("just commit it" on subversion takes ~5 minutes in the very fast case (that requires a colleague dropping everything _that very second_ , AND can't involve any actual code changes, as that trips a CI run that takes 3 minutes assuming zero contention), and 20-30 minutes is a more typical time (measured from "hey, I'd like to commit this", to actually in the repository). Committing on git takes me the time to type "<esc>! git commit % -m 'spellingfix'". The subversion commit time means that developers often go for weeks without committing. Weeks, as in plural.

I get that a git commit isn't the same thing as a subversion commit. But it does allow me to use the functionality of source control, and that's exactly what I'm looking for in a source control system. Subversion commit doesn't allow me to use source control without paying a large cost for it, that's what I'm getting at.

So I have backups guarding against the 99.9% problem (and an auto-backup script that does hourly incremental backups for the 0.1% case). The subversion guys are probably better covered for the 0.1% problem. Good for them !

3) actual version control

Git's branches, rebase, merge, etc mean I can actually work on different things within short time periods in the same codebase.

The fact that other developers are using subversion means I can have my own git hooks that I use for various automated stuff. Some fixing code layout, some warning me about style mistakes, bugs, ... (you'd be surprised how much your reputation benefits from these). Some updating parts of the codebase when I modify other parts, ... you have to be careful as these are part of the reason subversion is so slow (esp. the insistence on CI, I hear a CI run at big G, which is required before even code review can happen, takes upwards of an hour on many projects with some taking 8-9 hours)

<comment><USER17> The discussion wasn't really about SVN vs Git; you can have one or multiple repositories with either system.

<comment><USER16> You'd have the same problems with any other centralized versioning system the way companies use it these days (ie. with CI, and code review).

<comment><USER18> Not really. I work at google. I work on a leaf, so my CI takes < a minute. I also can send out multiple chained changes, in a tree, to multiple reviewers, and have them reviewed independently.

Certainly, CI takes a long time for certain changes, but those are changes that affect everything. You'd have the same problem in a multi-repo approach if you updated a repo that everything else depended on. At some point, you have to run _all_ of the tests on that change.

<comment><USER16> Cool. I've wondered about Google's CI a lot, but there are a lot of horror stories online. Most people are complaining about it taking an hour for simple changes (something called "tap", I wonder what that stands for).

Chained code review changes, I refuse to believe that in Google version control (which is perforce according to Linus' git talk at Google) chained changes are easy. Branching in perforce is literally worse than SVN, it's a bit more like the old CVS model, and they've sort-of tried to get the SVN copy-directory model forced into the design afterwards. Also the tool support (merges ...) is bad compared to subversion and stone-age compared to Git's tools.

The one reason I keep hearing for using perforce is that perforce allows the administrator to "lock off" parts of the repository to certain users.

I've done branches and merges in Git, Subversion and CVS (and I've had someone talk me through one in Perforce, but I don't really know). Google's branch/merge experience is very likely to be somewhere between SVN and CVS, and those can accurately be referred to as "disaster" and "crime against human dignity". It's certainly not impossible, but it's very hard and you can't expect me to believe (normal developer) people can reasonably do that in Perforce.

Also: what would happen if you send out 20 chained commits, 10 of which are spelling corrections, 5 of which are trivial, compile-fixing bugs (forgot semicolon, "]" that should have been ")", etc ...), 2 of which are small changes to single expressions and 3 of which introduce a new function and some tests. Perforce, like subversion and cvs doesn't have any way of tracking stuff unless you commit it and you can almost never commit without CI and code review, so would you track changes like that, or would you just leave them in your client untracked until you're ready for a code review ?

<comment><USER18> >Cool. I've wondered about Google's CI a lot, but there are a lot of horror stories online. Most people are complaining about it taking an hour for simple changes (something called "tap", I wonder what that stands for).

Well, like I said, its possible to do modify things that have a lot of dependencies, at which point you run a lot of tests, but that would be truish anyway. Consider the hypothetical situation where you're changing you're modifying the `malloc` implementation in your /company/core/malloc.c`. Everything depends on this, because everything uses malloc. If you have a monorepo, you make this change, and run (basically) every unit and integration test, and it takes a while.

Alternatively, if `core` is its own repo, you run the core unittests, and then later when you bump the version of `core` that everything else depends on, you run those tests too, but now if there's a rarely encountered issue that only certain tests exercise, you notice that immediately when you run all the monorepo tests, and can be sure that the malloc change is the breakage. If you don't do that, then you notice breakages when you update `core`, or maybe you _don 't_ notice it, because its only one test failing per package, and it could just be flakyness. So noticing it is harder, and identifying the issue once you've decided there is one is harder, and now you need to rollback instead of just not releasing.

>Chained code review changes, I refuse to believe that in Google version control (which is perforce according to Linus' git talk at Google) chained changes are easy. Branching in perforce is literally worse than SVN, it's a bit more like the old CVS model, and they've sort-of tried to get the SVN copy-directory model forced into the design afterwards. Also the tool support (merges ...) is bad compared to subversion and stone-age compared to Git's tools.

Google no longer uses perforce, we use Piper (note that this is a google develped tool called Piper, not the Perforce frontend called Piper, yes this is confusing, afaik, Google's Piper came first). Piper is inspired by perforce, but is not at all the same thing. (See Citc in the article). The exact workflow I use isn't piblic (yet), but suffice to say that while Piper is perforce inspired, Perforce is not the only interface to Piper. This article even mentions a git style frontend for Piper.

>Google's branch/merge experience is very likely to be somewhere between SVN and CVS, and those can accurately be referred to as "disaster" and "crime against human dignity". It's certainly not impossible, but it's very hard and you can't expect me to believe (normal developer) people can reasonably do that in Perforce.

Suffice to say you're totally mistaken here.

>Also: what would happen if you send out 20 chained commits, 10 of which are spelling corrections, 5 of which are trivial, compile-fixing bugs (forgot semicolon, "]" that should have been ")", etc ...), 2 of which are small changes to single expressions and 3 of which introduce a new function and some tests. Perforce, like subversion and cvs doesn't have any way of tracking stuff unless you commit it and you can almost never commit without CI and code review, so would you track changes like that, or would you just leave them in your client untracked until you're ready for a code review ?

So, Piper doesn't have a concept of "untracked". Well it does, in the sense that you have to stage files to a given change, but CitC snapshots every change in a workspace. Essentially, since CitC provides a FUSE filesystem, every write is tracked independently as a delta, and it's possible to return to _any_ previous snapshot at any time. One way to think of this concept is that every "CL" is vaguely analogous to a squashed pull request, and every _save_ is vaguely analogous to an anonymous commit.

This means that in extreme cases, you can do something like "oh man I was working on a feature 2 months ago, but stopped working on it and didn't really need it, but now I do", and instead of starting from scratch, you can, with a few incantations, jump to you're now deleted client and recover files at a specific timestamp (for example: you could jump to the time that you ran a successful build or test).

>Also: what would happen if you send out 20 chained commits, 10 of which are spelling corrections, 5 of which are trivial, compile-fixing bugs (forgot semicolon, "]" that should have been ")", etc ...), 2 of which are small changes to single expressions and 3 of which introduce a new function and some tests.

I'd logically group them so that each resulting commit-set was a successfully building, and isolated, feature. Then, each of those would become its own CL and be sent for independent review.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> So as someone who previously worked for Google and now works for Facebook, it's interesting to see the differences.

When people talk about Google's monolithic repo they're talking about Google3. This excludes ChromeOS, Chrome and Android, which ard all Git repos that have their own toolchains. Google3 here consists of several parts:

\- The source code itself, which is essentially Perforce. This includes code in C++, Java, Python, Javascript, Objective-C, Go and a handful of other minor languages.

\- SrcFS. This allows you to check out only part of the repo and depend on the rest via read-only links to what you need from the rest.

\- Blaze. Much like Bazel. This is the system that defines how to build various artifacts. All dependencies are explicit, meaning you can create a true dependency graph for any piece of code. This is super-important because of...

\- Forge. Caching of built artifacts. The hit-rate on this is very good and it consumes a huge amount of resources given the number of artifacts produced. Forge turns build times for some binaries from hours (even days) into minutes or even seconds.

\- ObjFS. SrcFS is for source files. ObjFS is for built artifacts.

This all leads to what is usually a pretty good workflow like the ability to check out directories if you want to modify them and just use the read only version if you don't. You can still step through the read only code with a debugger however.

Now Facebook I have less experience with (<6 months) but broadly there are four repos: www, fbobjc, fbandroid and fbcode (C++, Java, Thrift services, etc). At one point these were Git but for various reasons ended up being migrated to Mercurial some years ago.

The FB case (IMHO) highlights just how useful it can be to have one repo. Google uses protobufs for platform independence. FB uses GraphQL at a client level and Thrift at the service level.

So one pain point is that, for example, you can modify a GraphQL endpoint in one repo but its used by clients in others (ie mobile clients). There are lots of warnings about making backward-incompatible changes, some of them excessively pessimistic because deterministically showing something will break some mobile build in another repo is hard.

Google3 has less of these problems because the code is in the same repo. On top of that, Google has spent a vast amount of effort making it so the same build and caching systems can handle C++ server code as well as Objective-C iOS app code. Basically if you're working on Google3 you basically compile very little to nothing locally.

Engineers on Android, Chrome and ChromeOS however compile a lot of things locally and thus get far beefier workstations.

At FB the mobile build system doesn't seem to be as advanced in that there is a far higher proportion of local building.

IIRC the Git people seemed to reject the idea of large code bases. Or, rather, their solution was to use Git submodules. There was (and maybe is?) parts of the Git codebase that didn't scale because they were O(n). Apologies if I'm misspeaking here but I peripherally followed these discussions on HN and elsewhere years ago as someone from the outside looking in so I'm no authority on this.

The problem of course is that Git submodules don't give you the benefits of a single repo and I've honestly not heard anyone say anything good about Git submodules.

Just to stress, the above is just my personal experience and I hope it's taken as intended: general observations rather than complaints and definitely not arguing that one is objectively better than the other. There are simply tradeoffs.

Also, there are definite issues with Google3, like the dependency graph getting so large that even reading it in and figuring out what to build is a significant performance cost and optimization issue.

<comment><USER20> I have two main concerns when I see monorepos being used.

First, like in other areas, I see companies that want to "google scale" and blindly copy the idea of monorepos but without the requisite tooling teams or cloud computing background / infrastructure that makes this possible.

Second, I worry about the coupling between unrelated products. While I admit part of this probably comes from my more libertarian world view but I have seen something as basic as a server upgrade schedule that is tailored for one product severely hurt the development of another product, to the point of almost halting development for months. I can't imagine needing a new feature or a big fix from a dependency but to be stuck because the whole company isn't ready to upgrade.

I've read of at least one less serious case of this from google with JUnit

> In 2007, Google tried to upgrade their JUnit from 3.8.x to 4.x and struggled > as there was a subtle backward incompatibility in a small percentage of > their usages of it. The change-set became very large, and struggled to keep > up with the rate developers were adding tests.

[https://trunkbaseddevelopment.com/monorepos/#third-party- dep...](https://trunkbaseddevelopment.com/monorepos/#third-party- dependencies-1)

<comment><USER21> > I worry about the coupling between unrelated products.

I even worry about coupling among related products.

I could see monorepos working out well for a company that just does SaaS, and is able to get away with nice things like maintaining a single running version of the app, and continuous delivery.

Having mostly worked in companies that do shrinkwrap software or that allow different teams or clients to manage their own upgrade schedule, though, monorepo seems to me like a recipe for a codebase that is horribly resistant to change. Not just in the "big bang upgrades like JUnit4 are awful" ways described above, but also in a, "We never clean up old stuff, because most of the time when we try it breaks a bunch of other teams' code and we just nope out of that whole hassle, so barely-supported code sort of collects continuously, like dead underbrush in a forest that's never allowed to burn, until eventually it all explodes in a horrible conflagration," sort of way.

Seeing the list of things that Google keeps in a monorepo, vs things that Google keeps in Git repos, it seems like they might be thinking similarly. They've really only got a precious few products that typically run on non- Google-owned hardware, and apparently the major ones live outside the monorepo.

<comment><USER22> The dynamics actually played out very differently at Google. Because it was a monorepo with automated testing, if you didn't want other teams to break you when they change the dependencies, then you had better have a robust test suite.

Breaking changes would then lead to a discussion with your team, rather than your fruitlessly trying to binary search to find the commit that broke you.

Over time, the culture at Google became that all teams need to write tests at the unit, functional, and (usually) integration level.

</comment></comment></comment></comment><comment><USER23> I think that what is missing when using multiple git repos is the ability to make a code change that spans multiple projects. We're open to adding that to GitLab

<comment><USER24> This will help if you _don 't_ want to run a monorepo, but many in the industry consider a monorepo suitable for their organisation. The biggest blocker with Gitlab in my opinion is not being able to only run a job if some specific folder was modified ([https://gitlab.com/gitlab-org/gitlab- ce/issues/19232](https://gitlab.com/gitlab-org/gitlab-ce/issues/19232)).

<comment><USER23> I agree that functionality would be great to have. We planning it in the next 3 months but we also very open to someone contributing it earlier.

</comment></comment></comment><comment><USER25> I think the monorepo is better but it's really hard to pull off without Google-like tooling and engineering practices. Git + meticulous dependency tracking and strict versioning conventions is probably the better move for most companies.

<comment><USER26> +1, I really dislike the "Let's do it because Google does it" mentality in software engineering. Google operates at a scale and encounters problems that the average company would probably never encounter.

</comment></comment><comment><USER27> How would they do CI/CD if it's all in one big repo?

I suppose you could do it if you had a very strict rule where absolutely everything that could affect a "unit" was inside its own directory (but never and nothing higher up than that "project root").

So you could check which sub-directory is affected within a commit and so on.

<comment><USER28> Oh it works really well. One benefit is all tests affected by your target is run as you presubmit. The benefit is everything is at head so things like library bugs, security bugs are all handled naturally as part of the new releases. This usually happens twice a week for most server binaries.

<comment><USER29> So long as the presubmits are configured correctly, or someone ignores failures and force submits. :)

It's usually quite nice though, and changes that break lots of projects are rolled back quite fast. Usually.

<comment><USER28> As much as people hate, force submits are a fact of life.

</comment></comment></comment></comment><comment><USER30> If someone's interested, I made a summary of the paper a year back:

[https://www.extreg.com/blog/2017/02/googles-ultra-large- scal...](https://www.extreg.com/blog/2017/02/googles-ultra-large-scale- monolithic-source-code-repository/)

<comment><USER31> It's a good write up.

To me, Piper is a monolithic version control system which is geared towards good engineering practices.

As far as I know there are only two such systems in use today and the other one is very dated and older than a lot of things out there.

When people say they have worked in a monolithic repo, then they typically mean a 1 repo under one of the open source version control systems, but none of these actually do or support what is needed when working with a monolithic repo AND modern/good engineering practices.

For that specialised VCS is required and there is very few examples of that, none of which is in open source software.

Git probably could be made to do this kind of stuff, but it would require some extensions to the DAG as well as extend on it's already verbose command line set. But I think it is doable.

The question is who can do it? Most are probably under some strict NDAs.

</comment></comment><comment><USER32> What fraction of Google's code is in the monorepo these days? Android, Chrome, and ChromeOS are not, and those are certainly large projects.

<comment><USER33> I believe anything not open source, or reasonably expected to become open source.

<comment><USER28> Plenty of opensource projects are in google3(that frequently gets merged into external)

<comment><USER34> Yep. Projects use Copybara to import/export OSS code. [https://github.com/google/copybara](https://github.com/google/copybara)

</comment></comment></comment></comment><comment><USER35> I scanned this, the usual mono/multi arguments. All made moot by BitKeeper's nested approach:

[http://mcvoy.com/lm/bkdocs/nested.html](http://mcvoy.com/lm/bkdocs/nested.html)

in an open source system [http://bitkeeper.org](http://bitkeeper.org)

What nested brings to the table is the semantics of a mono repo with the advantages of a multi repo. The whole thing walks in lockstep, if you have a 3 week old version of the kernel and you add in the testing component (subrepo) then you get the 3 week old version of the testing component, all lined up with the same heads in the same tip commit.

I get it that git won but at least steal the ideas.

Edit: BTW, bk has a bk fast-import that usually works (it doesn't like octopus merges but other than that....)

</comment><comment><USER36> The lazy me thinks maybe 1 kitchen sink repo is better.

Here's my problem:

I can be working on multiple projects at the same time. Each project has multiple modules (core, api, www, admin, android, etc -- I use microservices on Google App Engine). Sometimes, some modules have "feature" branches. Oh, did I tell you I work on both Desktop and Laptop?

The problem is syncing. Before traveling, I need to make sure the projects/modules I'll be working on the go all have latest commit from Desktop.

My question:

Is there some "dashboard/overview" for all Git projects? So I can quickly tell, "Ok, all projects are at latest commit, and oh I'm working on feature branch for project X and Y."

<comment><USER37> There is a dashboard called github? Or what are you looking for?

I think if you want to make sure that all your changes are in, you need to do what most programmers do and learn to finish a programming session with a commit and push, just like you finish a sentence with a dot. Once you are used to it, the chance of forgetting are really low.

<comment><USER36> GitHub.com doesn't tell you if you have uncommitted, and even unpushed commit.

(the desktop app does, but you need to check one by one for each project)

</comment></comment></comment><comment><USER38> Does anyone have "aha" moments to share about working in a single repository?

Stuff that just made you say, "Great, I wouldn't have been able to do that if it was in separate repositories!".

<comment><USER39> Once, I noticed that a minor piece of how Google's Python system tests could be very slightly cleaner and more consistent. It would be a tiny change, it seemed very safe, and it was easily accomplishable with a short sed script, but it'd also be a backward-incompatible change across the projects of hundreds of teams and thousands of build targets. I was able to make that change with only a few commits and without needing to bother most of those teams.

These sorts of small, general, large scale cleanup commits are quite common at Google, and they're encouraged. They help keep the codebase healthy. There are special groups that review them so that all of the individual teams affected don't have to bother, and there are tools to manage the additional testing and approval requirements for such a change.

At my previous company, making such a change would have been a major undertaking. I never would have considered a refactor of that scale without a critical need. They had thousands of packages, each of which had its own repository and an incredibly complex web of build and runtime dependencies. It was a nightmare, and fiddling to find a working sets of versions of internal dependencies took up way, way too much of my time each day.

</comment></comment><comment><USER40> I wonder what do the bots commit in the monorepo. It is something that has been making me curious for a while.

<comment><USER41> Nothing too interesting. They're restricted so they can only update their own source code.

<comment><USER29> Except for that _one_ time. ZRH SRE has never been the same.

</comment></comment></comment><comment><USER42> The clear advantage of a mono repo over a mono-purpose repo is technical dept. The goal is that you never build up technical debt and immediately patch all references in an atomic change.

Example: Let's say you introduce a breaking change in lib A that is used in libs B and C. First problem is visibility, that A does not necessarily see that it is used in C and D. Second, you the build should break immediately and not until someone build C/D.

<comment><USER43> Tech debt isn't just breaking changes though, and mono repo does nothing to curb all the other types of tech debt: * Accumulation of FIXMEs * Partial refactors cut short after change in business reqs * Quick hacks near release time * "this could be done better if I had time" * Overdue re-architecture after accumulated changes and additions * Orphaned code * Commented out tests * etc etc

</comment></comment><comment><USER44> Can someone further explain how the pre commit phase works? I don't get how/why "pre commits" work without feature branches?

How are my changes shared with the reviewer, if I there is no feature branch? Is my local code uploaded to that review tool mentioned in the article? And then what happens if the reviewer requests changes?

I probably did get this completely wrong, so thanks in advance for pushing me in the right direction.

<comment><USER45> Perforce (the origin of Piper) has a concept of changelists. Some changelists are submitted (committed) while others are not. So the review works by uploading your changelist to Perforce, then pointing people to that changelist. It's like an unnamed feature branch that can't easily be rebased off of. Changelists do have a base, and you do a "g4 sync" to essentially rebase off of master. Does that make sense?

<comment><USER46> When people talk about making a single global change to update all clients when they change an interface, are they updating unsubmitted changelists too?

<comment><USER47> No.

Unsubmitted changes at Google usually come in one of two flavors, short-lived (abandoned or submitted within a few days) or perpetual. The latter flavor is often for "I think we might want this". It's not uncommon for those to be completely rewritten if they're actually needed. There's usually a preference for submitting useful things (with tests!) and flag gating them to cut down on bitrot.

I have seen exceptions -- I reported a bug in a fiddly bit of epoll-related code and an engineer on my team had a multi-year-old fix -- he hadn't submitted it because he wasn't confident he'd found an actual bug. The final changelist number was more than double the original CL number (unsubmitted changes get re-numbered to fit in sequence when they're submitted -- the original number redirects to the final submitted version in our tooling).

</comment></comment></comment></comment><comment><USER48> previous discussion: [https://news.ycombinator.com/item?id=11991479](https://news.ycombinator.com/item?id=11991479)

</comment><comment><USER49> The model that I've liked the most...

\- Monorepo for all the services code in the enterprise. (Java )

\- UI code is kept in their own repositories.

\- Enterprise Services are exposed using well defined stable rest-like APIs. (json, http, swagger, etc). We only exposed what is needed.

\- Within the services monorepo, services can call other services directly using regular java calls.

\- Services in the monorepo are refactored all the time. This is the advantage of using a strongly typed language like Java.

\- Several instances of the services run are a time, they scale horizontally. Releases are done one instance at a time.

\- We had good unit and integration test suites on the services.

Now I am working for a different company. We have hundreds of services deployed. No one knows what is running where. Or what the dependencies are. Once something is released, everybody is afraid to make a change as no one knows how that is affects other systems.

</comment><comment><USER50> So, monorepo seems to be great, but why don't we have open source tools to deal with that?

</comment><comment><USER51> How do they handle Android? It's one thing when you can just go "use the latest" for web service and another when you have N branches. I'm not sure a mono repo is as big of a benefit then.

<comment><USER52> Android Open Source Project is still in gerrit, where the code is stored as a set of many git repositories. There's a "repo" tool that adds a helpful layer of abstraction to make those git repositories (mostly) look like a single repository.

</comment></comment><comment><USER53> Doesn't this create a single point of failure for the development of the entire software ecosystem at google? What happens if something goes disastrously wrong with their repo? Does everyone twiddle their thumbs until it gets fixed?

Also, isn't this is the opposite of "separation of concerns"... code should be divided into small units of functionality that don't overlap. Minimise interdependencies. Eliminate unnecessary work. Is this the most efficient and future-proof approach?

<comment><USER54> Yes, when the system is down, it's really bad. Though it's an extremely reliable system as so many folks depend on it (note there's also lots of layers of tooling, so maybe you just need commits to work versus code review versus your local edits, etc.). In my experience, the worst things are actually when the build/test system is running slowly (thus blocking commits until tests are complete) or the bog standard "ugh, someone decided to force submit even though it said the tests were failing. Roll that back, please".

As for separation of concerns, there's actually a lot of scoping / visibility stuff precisely to avoid letting people depend on things they shouldn't. I think you now have to explicitly open up your visibility to let random other projects depend on you. A monorepo doesn't _require_ that you share, it just permits it.

<comment><USER53> Interesting. Every system is going to be down times, so I don't worry about that too much. I'd be more worried about a design flaw or bug that doesn't get exposed until you're painted into a corner and it's hard to escape.

Good point about the scoping. I suppose it really depends on how developers use it - do they default to sharing or not?

</comment></comment></comment><comment><USER55> There is a great talk by their C++ dev team about how a build everything from source, mono repo really helps with C++ change enablement

[https://m.youtube.com/watch?v=tISy7EJQPzI&t=2589s](https://m.youtube.com/watch?v=tISy7EJQPzI&t=2589s)

Personally, I'd have to agree that at a minimum a mono repo per distinct product role (server side in one mono repo, desktop software in one mono repo) is immensely valuable.

</comment><comment><USER56> I heard updating pager duty [on-call] commits used to be a mess --perhaps it was apocryphal, but if not, why not use a different system for the pager duty updates?

<comment><USER57> Using the existing thing was probably easier than anything else.

</comment></comment><comment><USER58> "The two are not mutually exclusive. I utilize what I call ensemble repositories that, for us, submodule the individual repositories" \- [http://disq.us/p/1hj9nmu](http://disq.us/p/1hj9nmu)

</comment><comment><USER59> I'm a bit disappointed that they don't back their publication with any numbers that compare the two approaches. I don't see the scientific value of what would also be a good click-bait blog post.

</comment><comment><USER60> Here is yet another tool for managing multiple repos as one: [https://supertanker.github.io/tsrc/](https://supertanker.github.io/tsrc/)

</comment><comment><USER61> I'm working on a project where we have two projects: a desktop app and a web backend. They each live in their own repo. However, this approach is proving tedious for us now, as every new feature often means two branches (one in each repo) which also means two separate pull requests when the feature is ready to be merged. Has anyone encountered this kind of issue, and is the solution to simply merge the two repos into one monorepo?

</comment><comment><USER62> The real reason is why any large enterprise does something unusual: "it has always been like that".

</comment><comment><USER63> So that developers can REUSE code.

</comment><comment><USER64> I develop an application that has a SPA frontend and an API backend. They can love inside separate repos but I prefer to keep them together because if I change the API signature, I'll also make the same changes in the frontend and they will deploy together at once.

</comment><comment><USER65> Good Google Talk video about it too.

<comment><USER66> Can you post the link? Thanks!

<comment><USER67> Could be this one: [https://www.youtube.com/watch?v=W71BTkUbdqE](https://www.youtube.com/watch?v=W71BTkUbdqE)

</comment></comment></comment><comment><USER68> Can anyone quickly summarize the article in a few pointers? I'm looking for benefits/drawbacks and trade-offs.

<comment><USER69> Just open up the pdf and look on the front page.

> Key insights

> Google has shown the monolithic model of source code management can scale to > a repository of one billion files, 35 million commits, and tens of thousands > of developers.

> Benefits include unified versioning, extensive code sharing, simplified > dependency management, atomic changes, large-scale refactoring, > collaboration across teams, flexible code ownership, and code visibility.

> Drawbacks include having to create and scale tools for development and > execution and maintain code health, as well as potential for codebase > complexity (such as unnecessary dependencies)

</comment></comment><comment><USER70> At this point I normally assume that if Google does something a certain way, or uses a particular proprietary technology, then it likely should NOT be used.

I work for a place that tried to model itself culturally after Google and Facebook and has had a lot of engineers moving back and forth. If Google is anything like us, then it creates wrong incentives to invent in-house stuff. See, in their expense scheme the salaries of engineers are not a huge deal. It's cheap to have people do things. There is also an incentive for an engineer to try and "leave a mark". There are also a bias to hiring new and unexperienced people, who fail to learn the existing tech and replace it with something different, simpler and less functional (by the time it matures, it becomes just as complex, however).

I live in Java world, so I am seeing Google reinvent (poorly) every bit of Java tech: DI (Dagger), build tools (Gradle), commons libraries (Guava) and the list goes on and on. Well, apparently, they also reinvented internally Git, Jenkins and the rest of the tools. The rest of us should probably NOT do it this way.

<comment><USER71> Gradle was not a Google invention. Dagger was invented by Square. Google invented Guice (Bob Lee now at Square) which was way better than Spring and J2EE. Guava is far better designed than Apache Commons.

Dagger2 was invented by Google for good reason because it works purely as an annotation processor without runtime bytecode classloader magic. That means it is easier to debug, faster to startup on mobile, and can be crosscompiled with j2objc and GWT/j2cl.

Much of the time in-house stuff is created to deal with scalability or maintain ability problems.

</comment></comment><comment><USER72> That's a 2016 article and it's called "Why Google stores billions of lines of code in a single repository".

<comment><USER73> Thanks, updated.

</comment></comment><comment><USER74> I'd like to see the world checked into an rcs.

</comment><comment><USER75> I guess you can't blame the weaknesses of Google's products (e.g. searching in gmail) on the repository system.

</comment><comment><USER76> Facebooks doesn't, y tho?

<comment><USER77> Doesn't it? [https://code.facebook.com/posts/218678814984400/scaling- merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at- facebook/)

</comment></comment><comment><USER78> "Why"? Because Google has billions of lines of code.

Does any company not store all their related code in a single repository?

<comment><USER79> We don't, and it's hell. I may make a change to X, but some other developer doesn't know it, and then one day when he makes a change to X and tries to pull those changes into Y, now he has to change the bits of Y which are affected by my changes as well as his.

I would _love_ to have a monorepo, although I'd advocate for branch-based rather than trunk-based development. Yes, merges can be their own kind of hell, but they impose that cost on the one making breaking changes, rather than everyone else.

<comment><USER80> That just means that no one makes big breaking changes even if they night be necessary.

</comment></comment></comment><comment><USER81> Because of course they do. Just like we all do. Everyone has a file they backup just because they might need to reference it. Index.txt is my cross.

In terms of sheer code. I hope they have some Jedi ai to cross reference it. If they don't they will. In fact we help everyday.

No point in burning the printing presses. We have to learn to get along.

Enjoy living, learning will come naturally as you pursue your interests. Those interests will change, growing, cultivating other fields of knowledge, grappling for your attention.

Culture you enjoy as only a human can, and cultivate it. Distribute and share it. As humans we are denying our own renaissance with a ministry of silly walks. Sometimes I think high school UN clubs are better at running the world. Why not. It doesn't seem to matter anymore.</comment>


DevArt. Art made with code. - <AUTHOR> https://devart.withgoogle.com/

<comment><USER2> What a confusing site, or is it just me?</comment>


Ask HN: What should I do if I found my self a target for a hacker? - <AUTHOR> What should I do if I found my self a target for a hacker who specifically targets me for about a month? I am looking for a checklist, so I am sure that I didn't miss anything important. Basically, I would like something more than just advice about changing all passwords to more secure. <comment><USER2> How is he targeting you? Is your system pawned ?

1\. First format your system and install any antivirus software ( assuming you on windows ).

2\. Reset factory settings on mobile

3\. Get new mobile number if it is easy

4\. Change password of all accounts.

5\. Enable 2 factor authentication whenever possible. This will help you for sure. Keep backup codes somewhere safe(may be flash drive or print them). In case u lose access to your phone/number those will come handy.( Don't delete accounts suddenly. Just Change passwords and enable 2 factor authentication ) So no one can impersonate you easily and you will come to know if anybody has accessed your account.)

6\. Don't click on any link in web foolishly. If there is any link just hover your mouse on it, it will show you address in bottom. If address looks suspicious, don't open link.

7\. Don't click on any link in your email. When you get any email alway check from what email address it came before clicking on link.

8\. Don't log in important accounts on public cafes, library computers etc. Access them from your system only.

9\. Also look for hardware keylogger device if you too paranoid

These points are not 100 % full proof. But none the less they will help you for sure. Remember hacking is not magic. You can not be hacked suddenly from nowhere. Always be vigilant.

</comment><comment><USER3>
      Huh?
      targeting your home PC?
      targeting your identity?
      targeting your online servers?

</comment><comment><USER4> \- Remove your most precious info from online accounts (e.g. everything in the real world, such as your physical address). Use PO boxes / mail forwarding / etc. for that

\- Create a new, anonymous email account and use that for accounts that you care about to minimize the chance of successful social engineering attacks

\- Depending on how serious this is and how much the hacker knows, consider warning your friends and maybe even colleagues about the situation

\- Obviously don't have anything visible to friends-of-friends or to the public on facebook, remove your public photos especially those that can be photoshopped into a fake id, etc.

I'm not an expert in this, just some ideas.

<comment><USER5> Not an expert but I have different email addresses for different thing, currently about 20 email addresses with different providers. I manage them with a password manager which I obviously recommend for your passwords.

This means the if say my social media account got compromised (not that I have a social media presence) then they can't use that email to compromise my banking or other types of accounts. I also have a number of "spam" email addresses for sign ups.</comment></comment>


Visa Launches PayPal Alternative - <AUTHOR> https://www.payclick.com.au/Home.aspx That's pretty big news. Some healthy competition in this space will probably be benefitial.<p>Although if Amazon and Google didn't manage to dethrone Paypal in this space, I wonder how Visa will approach the challenge. <comment><USER2> I've often wondered why the credit card companies haven't gotten into this business already. My bank (Bank of America) offers a program called ShopSafe, where you can generate temporary credit card numbers to use online. You can set the limit and expiration date, even for recurring transactions. The numbers are only valid for the first merchant that authorizes a charge.

I wonder why there hasn't been a credit card company that offered a version of this with the option to prepay or link to a bank account or existing credit card. That way people could shop online and merchants who are already set up to accept credit cards wouldn't have to modify their code to interface with yet another payment API. The credit card companies would still get money from the fees charged to merchants, and they could also earn interest on the balances users keep.

<comment><USER3> The iDEAL system is very good also. It works like this:

1\. You click checkout

2\. You are sent to your bank's website

3\. You login

4\. You get a screen that shows the amount you have to pay, you verify this

5\. You get an SMS with a code that you have to enter

6\. Purchase completed

The nice thing about this is that it's very quick and the seller doesn't get your credit card number; steps 2-6 happen on your bank's website. And there is no intermediary: it's just the seller's bank and your bank. There is nothing to set up, you just have to have a bank that supports it (almost all banks in the netherlands do) The nice thing for sellers is that chargebacks are not possible. This is a much saner way to do online payments.

<comment><USER4> What about for people without SMS?

<comment><USER3> They either buy a $10 phone, or they use another payment method. Or perhaps there are banks that don't require SMS authentication, but I don't want to be a customer.

</comment></comment></comment></comment><comment><USER5> _The amount of money held in a payclick account must be between $20 to $1000 and withdrawals to a bank account are not allowed. Payclick also supports recurring transactions_

WTFno. That's not a PayPal competitor. That's a way to _guarantee_ that you spend money - a credit card company's wet dream.

</comment><comment><USER6> this is a no way a paypal alternative. in paypal you pay to arbitary email. and in this "alternative" - you actually need to go thru some screening process to open seller account..

<comment><USER7> Seems glaringly obvious, the reason Paypal exists is the fluidity it gives to transactions. Visa could simply match features and clean up, but no.

</comment></comment><comment><USER8> As a Canadian who uses PayPal to pay for things directly from my bank account, I'll believe it when I see it. No PayPal "alternative" that I've heard of will let me do this.

<comment><USER9> Agreed, as a Canadian, we are usually a few years behind, and as for Visa, almost every time I use my credit card online I have to reset my "verified by visa" password, because I can't remember the password from the last 20 times I had to reset it, but luckily all it takes to reset it is the skill testing question of what is my mothers maiden name.

So I have to go throught this BS reset every time, and whenever someone wants to steal my credit card, all they need is my mothers maiden name.

What irks me though is that visa knows this is a security flaw, I wish I had the paper to link the fully explains what isn't immediately obvious.

<comment><USER10> When they ask for your mother's maiden name, you should map that phrase to "your password, unique to this company" in your head. Now it's not quite as insecure.

</comment></comment></comment><comment><USER11> Maybe I'm a little biased but being a payment solution and having a URL ending in Home.aspx shouts "Hack me!".

<comment><USER12> Good troll post, with the up votes it looks like there are other trolls here. If you're going to say something like this then please back it up with some data.

Visa is a financial giant within the credit card industry. I'm sure they have created a secure platform or they would be held liable for any mis- appropriated funds. Also, Visa would be aware of the fact that any bad press regarding a hacked platform would cause users not to use it. So I'm fairly certain they would have taken their time to implement a robust security design, even though you have misgivings about the .aspx URL.

</comment></comment><comment><USER13> From their FAQ's it appears this is available only in Australia:

Is payclick available to use outside of Australia? No. Australia is the first country to launch this new product.

<comment><USER14> Australia: Testing ground for new products, sideways move for past-it executives, and loads of pretty beaches. Come use our internet while we still have it.

</comment></comment><comment><USER7> Why bother re-branding? Visa must not put much faith in this venture, or at least wants to retain the option to dump it.

</comment><comment><AUTHOR> It is good to see some competition in this space.

Amazon and Google tried before, it will be interesting to see what approach Visa will take to dethrone Paypal.

</comment><comment><AUTHOR> I got my comment deleted on this thread. Is it forbidden to comment on the link you submit?

(The comment was neutral, nothing aggressive)

<comment><USER15> It wasn't deleted, you cannot submit both the link and the comment (see the FAQ)

</comment></comment><comment><USER16> it's pretty different; for one thing, they want people to use it to pay for downloadables. You can, ~in theory~ sell downloadables through Paypal, but just try selling $100k in downloadables and withdrawing the money from your Paypal account...

</comment><comment><USER17> If they make it any easier on developers it'll be a hit.

</comment><comment><USER18> I hope it's not worse than PayPal.

</comment><comment><USER19> well it's about fraking time</comment>


The Best Patent Rejection You'll Ever See (Featuring Borat) - <AUTHOR> http://www.theatlantic.com/technology/archive/2012/03/the-best-patent-rejection-youll-ever-see-featuring-borat/255180/

<comment><USER2> Maybe there should be a foundation supporting an organization that does nothing but invalidate patents by finding prior art?</comment>


Immutability Changes Everything - <AUTHOR> http://queue.acm.org/detail.cfm?id=2884038 <comment><USER3> At the database level, lets say I want to take this approach with postgresql, is using just one big table with no deletes or updates-in-place and just doing appends one way to go about this? (assuming space is not a problem) Or is one better off looking at stuff like datomic which has the immutability part already set up for you?

<comment> T-R I've been working on a functional/event sourced postgresql database for the past few years. The approach in general is great, but we're currently investigating alternatives for implementation (whether going to something like datomic, or writing a DSL to generate the SQL). It's doable on postgres, particularly with recent JSON support, but SQL is just too low level, so it's a lot of work:

\- Because you tend to be doing a lot of different aggregations over the same or similar data sets, the things you most want to re-use, like "group by" and "order by" clauses or a set of columns for projections or joins, happen to be the things SQL as a language doesn't give you the ability to abstract over.

\- A lot of what you want to do is a fold over the event stream, followed by a map into some format, then ultimately filtering down to just the data you want. This is an easy enough query to write, but to get reasonable performance, you need to be able to adjust the evaluation time of parts of this process/materialize intermediate results: you almost never want to do an aggregation over all of history on every read, you usually want to at least do the aggregation on write, and maybe do the `map` lazily on read. In SQL, this turns out to be a _significant_ amount of manual work/code for something that, conceptually, should basically just be a strictness annotation. What you'd really want, at the very least, are materialized views with the ability to automatically materialize on a per-row basis when dependencies change. The recent support for Upsert will make this slightly less painful, but even so, it's a lot of work, and a lot of space for bugs / stale de-normalized data.

\- What you need for playback to be performant is for your database to understand which events, or parts of events, commute with each other, so it can play them back in parallel, or at least optimize the query beyond just running a volatile stored procedure in a loop. There's no way to communicate this to postgres, so you have to model this explicitly yourself - you end up having to explicitly write 'live' code (e.g., an imperative function to update an account) that needs to produce the exact same results as 'playback' code (e.g., a materializeable query that produces the state of the whole accounts table from all user-related events).

To generalize, there's just no way to tell the database what constraints you're adhering to, so it can't do any of the heavy lifting for you - <USER2> generating code or query optimizations - and it won't do anything to make sure you won't break those constraints, either. Something that does know how you're using it, on the other hand, should at least theoretically be able to do all of this work for you and a whole lot more.

</comment></comment><comment><USER4> Pat Helland gave a talk on these ideas at the first RICON: [https://vimeo.com/52831373](https://vimeo.com/52831373)

</comment><comment><USER5> [https://news.ycombinator.com/item?id=8955130](https://news.ycombinator.com/item?id=8955130)</comment>


Recreating the 1918 Flu Virus That Killed 40M People - <AUTHOR> http://www.popularmechanics.com/science/health/breakthroughs/the-man-who-could-destroy-the-world-breakthrough-awards-2014

<comment><USER2> This is idiotic. Of course we should research viruses. Thoroughly. Of course it's dangerous. So is getting out of bed in the morning; so is driving to work. Not researching viruses is far more dangerous than what he's doing. Life is a series of risk assessments; this is a good one. Asking the question should be a formality for the journalist. Giving it more than a paragraph of coverage is exhibiting ignorance of the most basic level of medical understanding.

<comment><USER3> Well apparently more than a few domain experts agree with the thrust of the article - [http://www.nytimes.com/2014/10/18/us/white-house-to-cut- fund...](http://www.nytimes.com/2014/10/18/us/white-house-to-cut-funding-for- risky-biological-study.html?smprod=nytcore-iphone&smid=nytcore-iphone-share)

</comment></comment><comment><USER4> This article is okay, but it is a shining example of the recent, disappointing editorial shift at PM. It's always been aimed at a popular audience (haha), but recently, there is a focus on articles with a strong narrative and lots of relatable human moments (He likes jazz!), with little or no actual information.

I mean, the risk of different animal strains mixing in the wild is presented as the Hokey-Pokey, you put the bird flu in, you put the swine flu in, you shake it all about, etc.

There's also stupid misinformation presented about dangerous things; two I remember are a warning not to use an uninsulated tool to cut a live wire (especially for their audience, just don't do it!) and a warning to back off of ABS brakes if you need to steer.

<comment><USER5> Okay, I'll bite - what misinformation is there in warning people not to use an uninsulated tool to cut a live wire? Seems like good advice to me.

<comment><USER4> People simply shouldn't cut live wires (unplug, pull battery, etc.).

Whatever exceptions there might be aren't terribly relevant to the general readership of Popular Mechanics.

</comment></comment></comment><comment><USER6> Isn't humanity resistant to this virus now?

<comment><USER7> I gather we're not "immunologically immune" to it ... but then again a lot of olders seemed to have greater immunity to it.

Once you get the surface proteins replicated, you can test them against a bank of sera of current people and look for antibody reactions.

</comment></comment><comment><USER8> What could possibly go wrong?</comment>


Installing Linux on Windows 8 PCs: No easy answers - <AUTHOR> http://www.itworld.com/software/287946/there-will-be-no-easy-way-install-linux-windows-8-pcs

<comment><USER2> I bought a $300 eMachines EL1360G-UW11P for a home server to replace my 2001 vintage 800MHz P-III.

I installed linux but it wouldn't boot. Major bummer.

It wasn't clear that UEFI signing was at fault, but there was no other reason for it to refuse to boot the image. The install went fine right through the reboot. I re-installed linux trying several different things, all unsuccessfully. I also booted a "rescue" image and verified the install looked valid.

There was no way to turn off UEFI signing in the BIOS menus.

I went to the manufacturer's web site and found they had a "Linux BIOS" image. [http://support.gateway.com/us/en/emac/product/default.aspx?t...](http://support.gateway.com/us/en/emac/product/default.aspx?tab=5&modelId=4021) I was able to reflash the BIOS with the P01.C1L image, but I had to force it by looking at their "flash.bat" file adding a /X flag to the flash command in there.

With the "linux" BIOS image, the board booted linux just fine. Huh.

Lessons Learned:

* UEFI is a real risk. Most mainstream PCs nowadays boot linux out of the box. I lived through the times when I bought a new PC "at risk" because it might have chips that were not supported by linux. UEFI brings that risk back, but through _software_ , not hardware. Sucks!

* The hardware manufactures apparently are getting the "it must run linux" message, even for low end throw-away machines. Yeah!

* Reflashing BIOSes, especially when the user has to manually override "self protection" aborts, is _not_ something an unsophisticated user is going to be able to do. Sucks.

<comment><USER3> To be fair: downloading a .iso file, burning the image onto a blank disk, rebooting and entering bios setup, setting boot device order , inserting disk and rebooting again, partitioning disks and doing install process isn't something that an unsophisticated user is going to be able to do without significant guidance though.

The BIOS flashing does add an extra risk factor though, prepare for many "Linux fucked my PC!" rants from users who screwed up the flashing process.

<comment><USER4> You can skip most of those steps doing a network install with unetbootin, no cds or usb drives needed

      http://unetbootin.sourceforge.net/

<comment><USER5> I've used UNetbootin, and as far as I know, there is no way to do a netboot/install without any media.

I took a look at the site, and it doesn't appear to have any information about that. Are you aware of some functionality that isn't listed on the site?

For what it's worth, UNetbootin is a really nice way to create liveUSB drives that you can use to install Linux/BSD.

<comment><USER4> Select type "hard disk" (last row of options) instead of "usb drive". I've used it do to full network installs of centOS

<comment><USER5> I think we have different notions of what "network install" means. Yes, you can download packages from the web during the install (perhaps booting from a minimal install, as most net work installs do).

I was really more interested in netboot installs, where the machine downloads a boot image (via TFTP generally) and does the install from there.

In fact, no hard drive is needed in the machine if you want to just boot an image from a network share.

Apple uses a technology like this to reimage boot drives:

<https://en.wikipedia.org/wiki/NetBoot>

This is how it works in Ubuntu:

<https://help.ubuntu.com/community/DisklessUbuntuHowto>

</comment></comment></comment></comment></comment></comment><comment><USER6> > Every new PC sold with Windows 8 will be locked up tight with Microsoft's > UEFI ... secure boot on

Not that I don't agree that there's a potentially dangerous precedent here, but this is omitting a key detail. For x86 computers, MS's certification requires that users can disable secure boot. Of course, this is not true for ARM computers, hence the dangerous precedent.

<comment><USER7> I find it strange how people refer to a Windows RT tablet as an "ARM computer", but the iPad, Kindle Fire, Nook and a zillion other Android tablets(most of which have locked bootloaders, hello "Dangerous Precedent"!) are not referred to as ARM PCs.

It just shows how the terminology is changed to have a higher impact for an argument.

<comment><USER6> I'd attribute it to the software. iOS and Android are clearly meant to coexist with and not supplant a more traditional OS. To me, the dangerous precedent is that this new ARM computer comes loaded with "Windows", a label which connotes a more traditional OS, yet it can only run apps from MS's app store and cannot be booted into Linux. Yes, this is a slippery slope argument given that MS also provides the x86 version which can do all of those things, but I think the distinction will be lost on the general public.

<comment><USER3> I can't wait to hear all those stories of people who buy a "Windows" RT device and then find out they can't actually run any Windows software on it.

<comment><USER8> Microsoft has been through this already with the failed Alpha port of Windows. It should be interesting to see what plans they have to mitigate this.

<comment><USER9> Actually, x86 software ran fine on NT/Alpha; at one point x86 apps ran faster emulated on Alpha than natively on x86. (And emulated 68K on PPC was sometimes faster than native 68K.)

<comment><USER8> Was there an x86 emulator that shipped with NT/Alpha? I never heard about this before, and Google isn't being helpful.

<comment><USER9> <http://en.wikipedia.org/wiki/FX!32>

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> There should be an antitrust lawsuit against Microsoft.

"Secure boot" creates barriers to entry for operating system innovators. I don't see how this isn't an abuse of monopoly power to tighten the screws on a market threatened by disruptive competition; if antitrust laws can't help us here, I don't know why we even bother to have them.

Does anyone know the process in the USA for lodging antitrust complaints with the government?

<comment><USER11> Other operating system vendors are free to arrange with hardware manufacturers to include certificates for their operating systems. It's not an antitrust issue that other OS vendors were not able to get their act together in order to do so.

On top of that, they have the option of piggybacking on Microsoft's certificate. Microsoft will even subsidize the cost of getting a certificate from Verisign to allow that.

Finally, Microsoft is using their market power to force OEMs of x86 computers to include a way for users to disable Secure Boot and to add new certificates.

<comment> Tuna-Fish > Other operating system vendors are free to arrange with hardware > manufacturers to include certificates for their operating systems. It's not > an antitrust issue that other OS vendors were not able to get their act > together in order to do so.

For a lot of users, merely having the option of signing their images simply won't be good enough. Unless the signing keys are available to everyone, you cannot boot a self-compiled kernel on a secure boot system.

<comment><USER11> If you want to compile your own kernels and boot them without disabling Secure Boot, make your own self-signed certificate, add that to the certificate list the firmware maintains, and self-sign your kernel with your certificate.

</comment></comment></comment></comment><comment><USER12> Why has this issue resurfaced? What has changed?

I thought that the windows 8 certification for x86 _required_ that users should be able to disable secure boot.

<comment><USER13> Manufacturers might be satisfying that requirement by providing an unlocked boot image for users to flash themselves.

<comment><USER12> Then the problem is fraudulent manufacturers.

There can't be any universe in which that isn't a shortsighted and downright ludicrous move.

If anything we should be happy for the manufacturers that does that, it means we'd never have to consider them again.

<comment><USER14> >Then the problem is fraudulent manufacturers.

Or a certification standard that mandated that vendors do _something_ , but was highly nonspecific as to exactly how they were to do it.

<comment><USER12> AND a certification standard...

This would never be a problem without both fraudulent manufacturers and an unclear certification standard.

</comment></comment></comment></comment></comment><comment><USER15> Do people still believe this crap? It's not as if OEMs are being forced to make Microsoft the sole CA of machines they sell. The requirement for the logo is that the feature is _available_. Any OEM who doesn't provide options to enable/disable the feature or adjust trust options is crazy. I mean, come on -- what if your hard drive fails? These are desktop computers we're talking about. It's an open platform.

To be honest, I'm very excited for Secure Boot. It, combined with TPMs and disk encryption, will finally allow desktop computers to be a truly secure platform (barring opening up the ICs on the motherboard, anyway).

<comment><USER16> _It's not as if OEMs are being forced to make Microsoft the sole CA of machines they sell._

Here's Fedora's response (Matthew Garret mjg59):

"We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs."

<comment><USER17> But couldn't they have just signed the other distros' keys? (Naive question)

<comment><USER18> Yes, but that would make them responsible for any malicious code that any other distro used. That would mean they would have to do security reviews of every other distro if they wanted secure boot to remain secure, which is not feasible at all.

</comment></comment></comment></comment><comment><USER19> I find this really stupid on Microsoft's part. I operate a dual boot solely for the purpose of using Windows for gaming. With Steam potentially coming to Linux, I'll just drop Lenovo as my vendor of choice as go with a vendor who supports my OS of choice, Linux.

<comment><USER20> Unfortunately you'll still be missing out on lots of games, even with Steam for Linux. Initially, Steam for Linux will only be good for a few Valve titles and indie games.

<comment><USER21> But if enough people start giving up from windows since they are using it as a game only OS, game publishers will have to take action.

Yes it's a dream, but maybe one day... maybe one day...

<comment><USER22> I really don't see it happening ever. I have a lot of trouble seeing Linux distros be used by actual everyday consumers. I mean, it'd be cool if it happened, but the quality just isn't there.

</comment></comment></comment></comment><comment><USER23> "Secure Boot retains flaws in its design that will ultimately mandate that Microsoft's key is on every PC (because of core UEFI driver signing)"

And if this Microsoft key were to be found being used as part of an exploit, ala the previous Microsoft cert being used to sign Stuxnet?

Not that I am encouraging any specific behavior...

</comment><comment><USER24> "Most people today who want to run Linux on a Mac use the Compatibility Support Module (CSM), which provides BIOS emulation on the Mac. This method is messy, doesn't work that well, and I'm quite certain will fail miserably on Secure Boot Windows 8 PCs."

Am I missing something here, as I post this from Debian running on my work iMac? All I had to do was install rEFIt ( <http://refit.sourceforge.net/> ), install Debian, and let rEFIt detect it (I forget if it involved manual configuration, been a while.)

I think this is much ado about nothing, especially given that Microsoft seems to be insisting that manufacturers leave in the option to turn off secure boot. I also thought Linux had the capability to boot off of UEFI; is this not true?

<comment><USER3> It depends on the distribution. AFAIK you have to sign each version of the bootloader and for GPL related reasons you cannot do this with GRUB2 so Ubuntu are having to resort back to GRUB1.

This means that whilst you may be able to run big "brand name" distributions like Ubuntu or RedHat on a secure boot PC more obscure distros might simply not work at all (unless you turn secure boot off).

<comment><USER25> Actually you are allowed to use grub2. The issue would be if you sell a device with grub2 pre-installed, and no way to install a user version.

Also, the other distributions could simply use Ubuntu's signed bootloader (So could rootkits).

</comment></comment></comment><comment><USER26> Keeping free OSes off computers in the name of security is the same, to me, as censorship in the name of protecting children: stupid and unworkable.

</comment><comment><USER27> Behold the power of monopoly.

edit (lol, microsofties down voting this comment)

<comment><USER28> Behold, the power of oh shit Microsoft doesn't even have a presence in the ARM tablet world, let alone a monopoly.

<comment><USER27> Samsung sells a lot of their hardware with MS software on it and are dependent on favorable licensing terms. This business Samsung does with them overshadows all their other partners in terms of revenue.

<comment><USER28> And that's relevant to Microsoft ARM tablets how? x86 devices don't have locked bootloaders, and Windows ARM tablets don't exist, so the reason you were downvoted isn't Microsoft fanboys, it's that you're wrong and seemingly quite proud to be so.

</comment></comment></comment></comment><comment><USER29> So, what will happen with the millions of servers that run Linux? Also I would think the EU wouldn't be happy to see Microsoft lock their operating system on each laptop. Obviously some solution will be found.

On a related note, why don't Canonical start selling their own hardware? Most laptops are pretty crappy, I'm sure they could do better and having official support would be great.

<comment><USER28> System76 is pretty close to being the official Ubuntu vendor. Full support, custom hardware, and Canonical's nod of approval. They're the Lenovo (et al) of the Ubuntu world.

</comment></comment><comment><USER30> I'm still new to the UEFI thing and don't really understand the issue totally ... but would doing something like getting a System32 box (or building your own) and then installing Win8 do the trick? Obviously it still would have Windows code on it, but wouldn't that sidestep the hardware manufacturer issue? or something ...

<comment><USER31> Yes - the requirement is for manufacturers who want to use the Windows logo to indicate that their systems support Windows 8.

But many new Linux users start by installing Linux on a PC bought with Windows, so we definitely want to make that as easy as possible.

</comment></comment><comment><USER32> There is a very simple way to install Linux on any Windows PC: a VM. I'm not sure why more people don't do it. It gives you all the flexibility and strength of command line while the battery life/drivers/software support of Windows. Its easy to back up, transfer to other PCs, etc...

<comment><USER33> This assumes you want windows at all, and all the problems that come with it. Using a slow system that tends to decay as the base of your computing experience isn't something I'm interested in.

It would make more sense to have Linux as the base, and windows in a VM.

<comment><USER34> Accidentally downvoted you, but I fully agree. Most of my computers running Linux are not laptops and don't even have screens/keyboards attached. I can't think of a single reason I would ever want windows on them even as just some sort of ghetto hypervisor.

<comment><USER35> Nor can I, but I presume gamers could come up with a few.</comment></comment></comment></comment>


Trump Takes Aim at Western Monuments That May Hold Oil Riches - <AUTHOR> https://www.bloomberg.com/news/articles/2017-05-10/trump-takes-aim-at-western-monuments-that-may-hold-oil-riches <comment><USER2> I live very close to one of the National Monuments being discussed (Rio Grande Del Norte). It's a big tourist draw, not to mention it's wildlife and historical significance. Letting oil companies potentially put that in jeopardy to extract resources is really just a wealth transfer, putting the citizens at risk for the benefit of a few big oil companies.

<comment><USER3> It's not only wealth transfer, it's potential wealth destruction.

I only had a chance to spend a day in the area as I was driving through. This sounds cliché, but it's one of those places that makes you think. The immense beauty captured my full attention and for the rest of the drive, I turned my cell phone and radio off and sat in awe in a sort of mindless medication. Places like this truly are priceless, especially for city folk like. myself overstimulated by modern society.

It's unfortunate that some people look at wilderness only for what value can be extracted out of the land. It's not only wealth transfer, it's potential net wealth destruction.

Slightly off topic, but Trump recentl made a speech where he said that no one's religious rights will ever be violated again in this country. It reminded me of the Native American people trying to prevent the construction of the Dakota Access pipeline because it crosses through their waterways and some of their sacred lands. I know it's politics and what he said was code for allowing Christian organizations to discriminate against LGBT individuals and to also exclude birth control from their health care benefits, but it must be so disheartening to hear something a President say that and know that it doesn't apply to your religion, like he doesn't even acknowledge that you exist.

It's just depressing knowing that, if we incentivized correctly, our energy issues with high density fuels could be solved forever and forms of energy that require wasteful, polluting extractive and refining techniques will no longer externalize their costs

<comment><USER4> Basically: Destroying the wealth everybody can have for free, like beauty, truth and simple contentment, to sell cheap thrills that never quite satisfy. I don't care how cliché that _sounds_ , I'm tired of how well that cliché holds up in the reality I see.

And yes, I also think that it's ultimately a net negative, I'm not even sure the people who get wealthier and more powerful actually get wealthier and more powerful. Their thrills don't seem to last either, they kind of seem to get smaller, and apart from the destruction of the world around us basically everybody of us engages in and suffers from, some of them them also have a vastly bigger inner gulf to cross. I.e. to enjoy a sunset someone with a clean conscience only has to have the time and the sunset, but people with corpses in the basement still have to dig out from under those corpses and then get up the stairs and out the front door. There's a lot of shrillness these days, and I think exactly for that reason; people with mouths full of dirt screaming about how they wouldn't want to see a sunset anyway, how only losers would enjoy those more than the cold stone they're stuck under. A whole lot of posing going on.

FWIW, I don't think any of us are exempt, I surely am not. Yeah I didn't start a war of aggression yet, and so on, but I hurt others for various dumb reasons, and often failed to even try to make up for it for even dumber or no reasons. It's a matter of degree though, and I would not want to swap with people in even deeper shit.

</comment></comment></comment><comment><USER5> I'm sitting in my camper right now in the middle of Utah. Fuck these East coast pricks that have never even seen this land.

<comment><USER6> It's the local reps who are pushing this: "Representative Rob Bishop, a Republican from Utah who heads the House Natural Resources Committee, has focused his ire on Bears Ears"

I'm starting to think the tide has turned on people's desire to give land back to the states (see Chaffetz). Enough people have moved to Utah/Colorado for the outdoors that it's not going to be easy for the local establishment to sell off the land at a discount to their donors.

At least in the opinion of this east coaster...

</comment></comment><comment><USER7> Maps of the Bears Ears National Monument can be seen here [1][2], to give an idea as to what's being talked about.

It includes the area between the current eastern boundary of Canyonlands NP "below the rim" of the mesas like Hatch Point Mesa and Harts Point Mesa.

In this 2014 article from Moab Sun News [3], it is mentioned that oil and gas surveys are being done in Harts Point (up on the mesa; outside of Bears Ears NM and not visible from "below the rim"); as well as in Lockhart Basin, the area sandwiched between the Mesa and Canyonlands (and thus protected by the new Bears Ears National Monument).

A quote from the article:

 _Walt Dabney, Moab resident, and retired superintendent of Canyonlands National Park (CNP), said that he is "very concerned," about any possible development taking place below the rim in the Canyonlands Basin. While superintendent of CNP, he made a formal objection to the BLM, saying that there shouldn't be any leases down in the basin because of the, "certainty of compromising the national park qualities of Canyonlands National Park."

"When you stand on the rim, there is an assumption by anyone who looks into that basin, that they are looking into the park. "What they are really looking at is an illogical, political compromise that resulted in protecting only a portion of the basin. Any development placed in there will significantly diminish the quality of the park."_

On the map, this is the northwesternmost protrusion of Bears Ears NM; a relatively small area. It includes significant portions of land further south (beyond the southern boundary of Canyonlands NP), including the northern rim of Goosenecks, all of the Valley of the Gods, the Moki Dugway, the roads leading to Natural Bridges and Hite Crossing, all of the Dark Canyon Wilderness, half of the Abajo Mountains, and the like, forming a continuous protected area from the existing patchwork of protected land and adjacent BLM- or-private land that looks visually identical yet hasn't enjoyed the same protections. And remarkably, it does so in a way to protect viewsheds.

[1] [http://www.grandcanyontrust.org/sites/default/files/maps/res...](http://www.grandcanyontrust.org/sites/default/files/maps/resources/uw_BearsEars_Proclamation_8.5x11.pdf) [2] [https://upload.wikimedia.org/wikipedia/commons/a/a6/Bears- ea...](https://upload.wikimedia.org/wikipedia/commons/a/a6/Bears-ears-map.pdf) [3] [http://www.moabsunnews.com/news/article_7b85d6f0-3e77-11e4-a...](http://www.moabsunnews.com/news/article_7b85d6f0-3e77-11e4-aac7-001a4bcf6878.html)</comment>


Geocities-izer - Make Any Webpage Look Like It Was Made By A 13 Year-Old In 1996 - <AUTHOR> http://wonder-tonic.com/geocitiesizer/index.php

<comment><USER2> Recursion is fun: [http://wonder- tonic.com/geocitiesizer/content.php?theme=3...](http://wonder- tonic.com/geocitiesizer/content.php?theme=3&music=6&url=http://wonder- tonic.com/geocitiesizer/index.php)

<comment><AUTHOR> I was expecting more neon green and marquee banners leading my ISP to transition to 56k dialup followed by my exploding laptop

</comment></comment><comment><USER3> Hmm...doesn't seem to do anything: [http://wonder- tonic.com/geocitiesizer/content.php?theme=2...](http://wonder- tonic.com/geocitiesizer/content.php?theme=2&music=9&url=drudgereport.com)

</comment><comment><AUTHOR> I'm a big fan of the old school Hacker News [http://wonder- tonic.com/geocitiesizer/content.php?theme=3...](http://wonder- tonic.com/geocitiesizer/content.php?theme=3&music=8&url=news.ycombinator.com)

<comment><USER4> I prefer the spinning floppies, horned Bill Gates, and Alanis:

[http://wonder-tonic.com/geocitiesizer/content.php?theme=2...](http://wonder- tonic.com/geocitiesizer/content.php?theme=2&url=http://news.ycombinator.com/item?id=1300254)

I think I just signed HN's guestbook.

</comment></comment><comment><USER5> Am I already, at the tender age of 25, on enough in years that yesterday's bad taste stirs feelings of nostalgia today in my web weary heart?

<comment><USER6> I'm 22 and nostalgia was involved. So, yes.

<comment><USER7> I'm 35 and nostalgia was involved. So... I think I'm going to go be depressed somewhere now. :)

<comment><AUTHOR> I'm a 29 year old sucker for nostalgia.

<comment><USER8> 23, and I'm nostalgic for the time when simply _not_ plastering animated GIFs all over your website was enough to separate you from the pack.

</comment></comment></comment></comment></comment><comment><USER9> Google '96: [http://wonder- tonic.com/geocitiesizer/content.php?theme=2...](http://wonder- tonic.com/geocitiesizer/content.php?theme=2&music=7&url=google.com)

<comment><USER10> The funny part is that the 'spinning' hit counter is probably not spinning fast enough to match reality.

</comment></comment><comment><USER11> Or by a 25 year-old on myspace today.

</comment><comment><USER12> I had forgotten how oddly compelling that creepy dancing baby was. I hate it, but I can't help staring at it.

</comment><comment><USER13> The computer motif (complete with Bill Gates as the Devil) is particularly apropos for my school's website.

[http://wonder-tonic.com/geocitiesizer/content.php?theme=2...](http://wonder- tonic.com/geocitiesizer/content.php?theme=2&music=9&url=uwaterloo.ca)

<comment><USER14> another waterlooer! really like how the engineering page turned out.

</comment></comment><comment><USER15> Amazing! I've honestly been looking for a tool like this for years

</comment><comment><USER16> There is one thing this site seems to be missing: an "under construction" icon, preferably in the form of an animated GIF. :P Because of this omission, I can only give it 4/5 stars, just for reminding me of the days when something like <http://oreilly.com/catalog/9781565920637> was what passed for a way to find stuff on the internet.

</comment><comment><USER17> How did the 88x31 buttons ever come to be? Those things were all the rage, especially on designer's sites. Where did the size originate?

</comment><comment><USER18> Works particularly well for Daring Fireball. It's like looking at the website of Gruber's tasteless, comic-sans using, evil twin.

</comment><comment><USER19> apple.com:

[http://wonder-tonic.com/geocitiesizer/content.php?theme=2...](http://wonder- tonic.com/geocitiesizer/content.php?theme=2&music=4&url=apple.com/)

<comment><USER20> That was the first one I tried, too.

<comment><USER21> LOL, It even used an evil bill gates img: <http://wonder- tonic.com/geocitiesizer/images/Bill_Gates.gif>

</comment></comment></comment><comment><USER22> What's funny is the ads on boingboing don't really look out of place.

</comment><comment><USER23> Can't help but laugh at the Homestead ad served by Google. Very relevant indeed.

</comment><comment><USER24> Not enough black backgrounds, red bold text OR animated flames :(

</comment><comment><USER25> OMG, this makes me want to cry.

</comment><comment><USER26> Needs more blue ribbon.

</comment><comment><USER27> especially liked the "Campaign against frames" badge :)

</comment><comment><USER28> This is insane !

</comment><comment><USER29> This is my new favorite web page, it's genius! What goes around, comes around. I can't wait until 2015 when some comedian creates the web-2.0-izer to what has become of hackernews.

</comment><comment><USER30> I'd like to correct the title: Make any webpage look like it was made in Frontpage. Yeah.

<comment><USER2> I wonder how many younger HN'ers even really know what Frontpage is these days.

<comment><USER31> I'm in High School and I remember creating websites using FrontPage (and notepad of course). We even used FrontPage in elementary school, so I think most younger HN'ers might remember what it is.</comment></comment></comment>