Google is Forcing Routebuilder to Shut Down - <AUTHOR> https://medium.com/@andrewcmartin/google-maps-is-forcing-routebuilder-to-shutdown-615ce42f413a <comment><USER3> [posting on behalf of my colleague @ Google]

Hi everyone, Google Product Manager for Maps APIs here. We are not revoking Routebuilder's access to the Maps API. Unfortunately, we mistakenly sent a letter to Routebuilder saying that they were in violation of the Google Maps API terms of service. This was an error. Once the developer contacted us about this issue, we replied apologizing for the misunderstanding and confirming that we would not be revoking his access to the Maps API. (He contacted us on Friday, we replied on Monday, the blog post was published on the weekend.)

We're really glad he let us know so we could fix the issue and we encourage any developers that have issues in future to reach out to us so we can help. Developers who want to contact the Google Maps APIs team: Stack Overflow and our issue tracker forum ([https://code.google.com/p/gmaps-api- issues/](https://code.google.com/p/gmaps-api-issues/)) are both monitored by the Google Maps team weekly.

<comment><USER4> Hahaha. We have been through this with AdSense. Without the negative PR Google would have never replied. This is also a good lesson for the aspiring Play Store Android developers.

</comment></comment><comment><USER5> An oldie but a goodie:

 _Are You a Sharecropper? If you're developing software for the Windows platform, yes. Or for the Apple platform, or the Oracle platform, or the SAP platform, or, well, any platform that is owned and operated by a company. They own the ground you're building on, and if they decide they don't like you, or they can do something better with the ground, you're toast. They can ship their own product and give it away till you go bust, then start charging for it; and use secret APIs you can't see; and they can break the published APIs you use. All of these things have historically been done by platform vendors._

[https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePl...](https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePlace)

<comment><USER6> Too bad that's a very outdated way of thinking. Today there is just no getting around "Sharecropping". If you want your app in front of actual people you're going to use a platform owned by Google, Apple, Microsoft or Blackberry. Sure the web is still a place where you're not really a "Sharecropper" but compared to native solutions the web doesn't give you everything you need for a fully integrated and awesome user experience.

As much as I'd love for this to not be true it is and there isn't a way around it. Even if you used an abstraction so you never technically write code specific to Apple, Google, etc in the end it's still going to be deployed to their platforms via their stores. Unless, of course, your market is strictly the tiny niche of jailbreaks / manual installers of software.

<comment><USER7> Colo your hardware, run open source software, and don't tie in to external services. Most mobile apps can be mobile-web optimized, as a fallback if App stores shut you out.

I like native apps mostly for their speed, but unless you're doing something requiring a sensor on the phone, mobile web can do it all.

<comment><USER8> ...except get discovered by customers who look to the app store for trust.

<comment><USER7> I guess I'm in the minority, but I don't trust jack from the Android store unless I already know the vendor.

<comment><USER9> Really? If you don't trust app stores and you end up with malware on your phone, how do you expect to be able to write an incredulous blog post?

</comment></comment></comment></comment></comment></comment><comment><USER10> Just because Routebuilder was never called out for violating the ToS doesn't mean it wasn't. Nor is there a "statute of limitations" for violations. What's even more insidious is that the "duplicating GM functionality" is a) vague and b) a moving target. Just because Routebuilder wasn't violating a decade ago doesn't mean it's not violating now.

This is the risk you take building something on top of an API—access can be cut off at any time.

<comment><USER11> i think the point of the article, or at least our interest in it, is that this is a terrible business arrangement. if you can't look at past tolerance as evidence of acceptable use, then you effectively can't ever afford to invest in building a business unless you're lawyered-up

and that's bad for tech, and bad for america

<comment><USER12> Why is any other business obligated to help you invest in building your own business?

Obviously, Google and others who have innovated in the space can set the terms of service as onerous or ambiguous as they want to. You can choose whether or not you want to invest in building something around someone else's products.

Don't like the TOS? Develop it yourself or use another product.

<comment><USER13> There is a bunch of laws that govern what someone who has innovated, developed, and authored can and can't dictate; they're called "intellectual property laws". Even if they've collected it, Google does not own information about the road system; facts themselves, like "Road A exists at lat X and long Z", cannot be copyrighted.

See _Feist v. Rural Telephone_ for more on this. The only reason application of _Feist_ is generally limited in cases of online access is because we have a theory that accessing a publicly available database containing phone numbers is akin to accessing someone else's private property, and therefore they can dictate whatever they want under theories like trespass to chattels, whereas consulting a printed telephone book in your home is decidely not accessing the phone company's property.

This is a pernicious, subtle issue now that we're becoming so dependent on online access provided by someone else's servers instead of accessing printed documents that we possess in our homes. Possession is 9/10 of the law, as they say. We need to rethink how "possession" applies to digital resources.

Likewise, there are laws around how much access a private property owner must grant to members of the public, especially if that property owner is running a business that is generally accessible to the public. Private property owners are allowed to declare some people trespassers, but each jurisdiction has different laws surrounding what the public can do on private property and when a trespass is allowable. For example, California's state constitution guarantees the right to hold reasonable protests in private shopping centers that are generally accessible to the public, whether the property owner likes it or not.

No one is saying there is a requirement for another business "to help invest" in any other; there may be requirements not to interfere with someone else's business by attempting to block what is otherwise public and freely available access to non-copyrightable information.

IANAL.

Routebuilder is fortunate that OpenStreetMap has collected much of the same data and that they can just code against a different API and continue to operate.

<comment><USER14> _by attempting to block what is otherwise public and freely available access to non-copyrightable information._

Mapping data is not "non-copyrightable information".

<comment><USER13> "Mapping data" is too broad of a term, because it probably includes a lot of copyrightable information. However, the factual basics, like GPS coords, are not copyrightable.

<comment><USER14> An individual data point maybe not, but even something like "there is a road between X1,Y1 and X2,Y2" you can't just extract from Google Maps and put in OSM, at least not multiple times. There are surprisingly few generally usable data sources (some government datasets that have been put under open licenses, Microsofts permits to use Bing's aerial photography as a basis for OSM, ...)

<comment><USER13> I'm not sure if OSM really needs to be as cautious as they are. I don't see how you could argue that "Main St begins at X1, Y1" and "Main St end at X2,Y2" is a single copyrightable work instead of 2 separate non-copyrightable facts. The _sentence_ or _package_ which contains these two separate data points may be a unique work that qualifies for copyright protection, but the raw data points aren't once you separate them out.

Open-source projects have a history of being hyper-sensitive to these concerns so that they never have to waste time with lawyers lobbing IP claims. A certain distribution derived from the sources released by a prominent North American enterprise Linux vendor comes to mind, as does WINE's refusal to accept any code from anyone who has any relationship with or connection to Microsoft whatsoever.

<comment><USER14> But you can't really separate these datapoints, at least not in a legally safe manner. If you take a "work", reduce it down to the basic data it probably was created from and rebuild a basically identical work, how do you defend against the claim that you copied it? You could try to go through multiple steps, done by different entities, and hope to hide that way, but coordinating that makes you vulnerable again.

How could a project like OSM make sure that it didn't happen on a large, clearly violating scale (because many people make copies of small parts, recreating the larger, protected work), especially if it isn't established what an internationally safe standard is.

In practice, you are right, you can copy a single street from google maps to OSM. I bet some mappers in the history of OSM have traced screenshots of google maps or something. But that is only safe because it can't be proven, unless you are unlucky enough to copy a canary.

<comment><USER13> If all you have is a compilation of facts, then yes, people can copy the data points one by one, alter the format slightly, and have a wholly separate work that has no legally recognized parentage. This is why you don't see a lot of plain collections of facts for sale.

As far as I know, Google Maps is protected from scripts copying the data points out only by its Terms of Use, which the CFAA basically eval()s into law.

Google Maps won't disappear overnight because they do provide a substantial amount of beneficial proprietary data, like the illustrations and private aerial/satellite imagery (imagery from sources like NASA is public domain), their scripts that allow easy embedding, the ability to connect to one's Google account, and so forth. But there is no legal protection of the raw data points used to build Google Maps as far as I know.

Let me reiterate that I'm not a lawyer and no one should do anything based on my posts.

<comment><USER15> No protection for compilations of facts is not the case everywhere.

[https://en.wikipedia.org/wiki/Database_Directive](https://en.wikipedia.org/wiki/Database_Directive)

[http://ec.europa.eu/internal_market/copyright/prot- databases...](http://ec.europa.eu/internal_market/copyright/prot- databases/index_en.htm)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> I wrote this 1689 days ago: "Why should anyone ever use a Google API ever again?" [http://googlecode.blogspot.co.at/2011/05/spring-cleaning- for...](http://googlecode.blogspot.co.at/2011/05/spring-cleaning-for-some-of- our-apis.html?showComment=1306481143396&m=1#c3564212561169948866) Still true.

HN discussion: [https://news.ycombinator.com/item?id=2592399](https://news.ycombinator.com/item?id=2592399)

<comment><USER17> _Why should anyone ever use a Google API ever again?_

Because you get a free high quality Maps API to use for a decade? What else would you have used in 2006?

<comment><USER18> Back in 2006 a bunch of us were building OSM precisely so this wouldn't be a problem in the future. But I take your point.

</comment></comment></comment><comment><USER19> It should be quite easy to port your app to use leaflet.js[1] and openstreetmap/mapbox.

[1] [http://leafletjs.com/](http://leafletjs.com/)

<comment><USER20> I second this as a frequent user of leaflet and openstreatmap. I started using both about 2 years ago and it's remarkable how much progress has been made in such a short amount of time.

</comment></comment><comment><USER21> I used to provide support on the Google Maps for Work API (any opinions are my own etc.)

My best guess is that because the site is offering very similar functionality to what is provided by the Google Maps API Drawing Tools [1] is the reason you've been flagged. The Elevation chart appears to be the same as the sample provided in the API documentation [2].

Yes, you offer additional functionality with the sharing of the routes and other features on the site. The flagging of sites for TOS violations can be a bit peculiar at times.

For reasons that I shouldn't get in to, I'd guess you won't much of a reply if you try and discuss this notice by replying via email. I'm not sure who the current Maps API Developer Relations contact is but they would be your best bet for any proper discussion.

[1] - [https://developers.google.com/maps/documentation/javascript/...](https://developers.google.com/maps/documentation/javascript/examples/drawing- tools) [2] -[https://developers.google.com/maps/documentation/javascript/...](https://developers.google.com/maps/documentation/javascript/examples/elevation- paths)

</comment><comment><USER22> "One option for me would be to rewrite routebuilder to run on another mapping platform, but with an infant at home and a full-time job, I frankly don't have the time or energy."

\- Open source it (with or without the wrapper to Google Maps).

</comment><comment><USER23> Unfortunately I'd say the headline on the linked Medium.com post (by the creator of Routebuilder) is a bit misleading.

I feel for the author, but Google is not "forcing Routebuilder to shut down." Google is instead telling the owner of Routebuilder to find another API to use. Routebuilder can find another API, pay to license data, etc. There are alternatives rather than "shut[ing] down."

I know this probably sucks for the author, but this is the risk you take when building your product on top of someone else's API without a separate contract in hand--as many Twitter developers found out firsthand a few years ago. Their service, their rules.

<comment><USER24> Isn't that a bit of a semantic nitpick? They're telling him to rework his site (or his business model) in fourteen days. Whether they have the right to treat developers on their platform like crud or not, it doesn't change the fact that he is effectively being shut down.

<comment><USER23> If you had a dog walking service with a route that crossed my property without permission, and after some time I asked you not to do so, you might write a blog post trumpeting: "Property owner is shutting me down." But others might disagree.

There may be ways to preserve the viability of your dog walking service. You can enter into an arrangement with me to use my property (which might include a nominal fee), you can take a different route (inconvenient for you and your customers, but not my problem), etc.

If the only way you can run your dog walking service is to take a shortcut across my property without my permission, well, then the world is sending you a message about the viability of your business.

Again, the mere fact that you and your dogs have grown accustomed to crossing my property does not mean I'm "shut[ing] you down." And next time, maybe you should secure written permission _before_ starting a business based on the assumption that you'll have the right to use someone else's property forever without paying.

<comment><USER24> I definitely think we'd be in a much better place if people building on platforms had the ability to negotiate for some level of assurance of continuity. It's important for people to have confidence in the platforms they build on.

As an update, Google has backed down, and said they made an error, and they won't force RouteBuilder to shutter in the next two weeks. But it sounds like the developer has learned his lesson... as time permits, he's going to start working on moving to another platform.

</comment></comment></comment></comment><comment><USER25> I don't think Google is in the wrong here:

If you have a route between two points 'white dots' appear in the route, then you can drag and drop those around to manually change the route, to share the URL you can either copy the url at the top bar or just click the 'share' option inside the hamburger menu, which gives you a minified link.

In the end, although it's an inferior(?) implementation, Google allows you to do the exact same thing. I think the ToS call mentioned is essentially appropriate.

Although it is a bit of a dick move, but in the end it is their api.

<comment><USER26> It's a _vastly_ inferior implementation. Despite what the screenshot in the post hints to, the actual implementation only lets users connect the pins by straight lines. It doesn't follow roads and it doesn't do navigation. The reason for that is explained in the FAQ.

So it's more or less what anybody would do on day 2 of learning the Google Maps API, plus the save routes (cough...) thing. With that I don't intend to show disrespect for the author, because it has been going on for 10 years with people using it. Much better than anything I built for myself. I'm surprised that Google is going after him. If that "re-implements or duplicates" anything that Google does then almost everybody should receive a letter like that.

My guess is that the usage counter for this site eventually reached some limit (10 years for that), a program noticed and the legal department sent a semi automatic mail without an assessment of the service. Still it's probably in their right to do so and it's another reason to use Open Street Map to build this kind of services. Example: [http://cycle.travel/](http://cycle.travel/) which does real routing. Furthermore OSM has many offroad tracks and it could make happy the kind of people using routebuilder.

</comment></comment><comment><USER27> The most interesting part about this story for me is that Google reached out to them and didn't simply ban them without a notice or explanation.

<comment><USER28> But it's completely unilateral. They're ignoring him otherwise.

<comment><USER29> OP said:

> I have tried emailing the Google Maps team to plead my case, but my > correspondence went unanswered.

Where did they write?

How many times did they write?

How long ago did they write?

Did they try any other means of contact?

Did they try to go through, as only one example, linkedin and find someone that way (or any other way of researching a party that might be willing to help)?

It's unclear the effort that was put in here. Maybe it was maybe it wasn't. We don't have enough detail. Simply saying "my correspondance went unanswered" as much as we may think Google doesn't care doesn't prove that point.

I actually from time to time write to companies to try and sell them things. I put in effort and it appears that that greatly increases the chance that they will buy what I am trying to sell to them (meaning a decision maker not a clerk or the person who sorts thorough the spam). And email more than one time for that matter. And if it's really important try a phone call.

</comment></comment></comment><comment><USER30> open > proprietary: If you want routing (and elevation and a time-distance matrix) based on open data, via an API with liberal licensing, all based on open source code that you could run yourself if you wanted, you may want to take a look at Mapzen's Turn-by-Turn routing. We built it to get away from this kind of thing.

more here: [https://mapzen.com/projects/valhalla](https://mapzen.com/projects/valhalla) docs: [https://mapzen.com/documentation/turn-by- turn/](https://mapzen.com/documentation/turn-by-turn/) API: [https://mapzen.com/developers/](https://mapzen.com/developers/)

<comment><USER31> Mapzen seems like a good idea, but I can't help but wonder (with respect): Can a developer expect it to be here in 2026?

Seems like someone integrating against an API has the choice of "Use one from a big company with a proven business model and risk their TOS changing to have it taken away" vs. "Use one from a firm with only a few years of history and risk them going dark one day (or changing their TOS)."

In this specific scenario, I'm not sure that this solution would guarantee the developer could have avoided this failure mode.

<comment><USER30> A great question. That's why we make all the underlying source code open, including chef and docker config info for people to build it themselves if they want or need to.

[https://github.com/valhalla/](https://github.com/valhalla/)

We at Mapzen are explicitly designing our projects to outlast us (if necessary).

[https://mapzen.com/blog/our-magna-carto](https://mapzen.com/blog/our-magna- carto)

<comment><USER32> Id just like to say that I really like the design of your site, and logo in particular. Well done.

</comment></comment></comment></comment><comment><USER33> It took Google _a decade_ to decide this site was violating the Terms of Service. Routebuilder does one narrow thing, it's not like they've creeped into Google's territory over the years. Something's fishy -- someone on slashdot suggested that it could be because of google's new fitness trackers ([http://fit.google.com](http://fit.google.com)) that they're flushing out any sites at all similar. If that's the case, then sites like routebuilder should be grandfathered into the TOS.

<comment><USER34> I would call that business as usual, more than fishy - those megacorp (MS, Apple, Google) have a long track of killing competitors before entering their space if at all possible, even if that means acquiring the whole business to close it down.

</comment></comment><comment><USER35> Don't trust for profit organizations. Google might project itself as champion of open source but the reality is their revenue, is a result of standing on open source. Without gnu and Linux they will not even exist. When they needed google maps users they opened up. But given their profit motive they will have to shut down others which conflict with their profit. Its better to port service to something open source, like openstreetmap. Google is turning into, do every evil to generate value for shareholders. I think RMS fears of closed source js are true. It's like Windows Binary blobs.

<comment><USER36> I've tried using OpenStreetMap -- but it doesn't seem to know the names of places I go to, or sometimes even the area I'm in when I type certain city names.

maps.google.com works great though. I wish I wasn't supporting Google's massive operations but it _is_ convenient to use.

<comment> squeaky-clean Do you mean you're using the map on [https://www.openstreetmap.org/](https://www.openstreetmap.org/) to search for things? This map isn't really meant to be searched, and the usability is generally terrible, I'm not sure why they keep it up on the website. Zooming in over my workplace (in Miami, FL) and searching "Pizza" brings up results for Italy and Nigeria.

OpenStreetMap is a great datasource and set of APIs though, on which other people have built really useful map applications. But OSM itself is not an attempt to compete with all of Google Maps, just to provide high quality tiles, path/nodes and place database to developers.

<comment><USER18> Yep. osm.org's search is only a placename search, basically.

</comment></comment></comment></comment><comment><USER37> Could it not be moved to Mapbox or OSM directly?

<comment><USER38> From the article: "One option for me would be to rewrite routebuilder to run on another mapping platform, but with an infant at home and a full-time job, I frankly don't have the time or energy."

<comment><USER24> And Google's given him a mere fourteen days to rework around a different API. For a program so hinged on an API like this, I imagine the amount of work to do that is probably quite significant.

</comment></comment></comment><comment><USER39> Nul ne peut se prévaloir de ses propres turpitudes. No one can prevail that a successful lasting violation of law worth recognition of it as an accepted legal usage.

(Except if you are rich and have guns because when it comes to owning lands, occupying long enough a place is legally owning).

I do agree that the ToS are shit. They were since the beginning. What new brands are doing is called : claiming rights on the second creation.

They give you proprietary shovels with open API to rush for gold, and once you have taken the risks and you can make money they can decide to let you live or not.

People laughed at me 10 years ago with this topic.

Entrepreunariat is about being a jake of all trades. You cannot be weak neither in coding, nor economy, nor business, nor accounting, nor legal contracts. You skipped "the leg days" of business. Reading the contracts and evaluating the risks, assessing the uncertainties. And you failed.

Well. Blame it on you and your blindness. Don't appeal to my pity.

Vae Victis. That is the way of business, and you should take responsibility for your own bad choices and understand that with great power comes more painful arrows in the knees.

All people supporting your claims should rather also think of the consequences of sustaining unsound business practices. If you would win, it would be yet another loss for all of a fair competition on the market.

I actually love your idea and have a lot of respect for your realization. Building is great. Making lasting products and risk management is even more important.

So, please shutdown your site and share the depressing conclusions you will come to. Learn like a true entrepreneur, and go back to work with your newly acquired knowledge, and think of whether or not you can rebuild your product on better foundations.

Success is not what make business man. It is overcoming your failure. The only true capital of a business man is fortitude.

<comment><USER40> Well said, learn and look forward, that's the only way.

</comment></comment><comment><USER41> What's the whole story here? Is it because he created a way for people to create routes, and is not using the official Google Maps API method for creating/showing routes? If he just altered his app to use Google's approved method, would he be fine?

<comment><USER42> Google Maps already provides a way for you to share routes, Routebuilder is duplicating that functionality (even if it makes it easier) which is a violation of Google Maps' ToS.

<comment><USER43> > Google Maps already provides a way for you to share routes

Does it? Where?

Map Maker doesn't do what the article claims it does. It doesn't try to reproduce Routebuilder at all. It allows you to fix errors in Google Map's data, it isn't useful for creating new custom routes for specific purposes (e.g. races, sightseeing, etc).

<comment><USER44> Here is an example of a Google maps route from Providence to Boston for bicycling, [https://www.google.com/maps/d/edit?hl=en- US&mid=zH358fz1z920...](https://www.google.com/maps/d/edit?hl=en- US&mid=zH358fz1z920.kAlJZ89Jw4Kc)

</comment></comment></comment></comment><comment><USER45> Email from Google doesn't state what feature(s) they feel is replicated by the site, which is strange.

I wonder if it has something to do with elevation? For some reason it seems GMaps is very protective about elevation data; if the site recently gained some momentum and they noticed many elevation requests, maybe it could explain this sudden (late) reaction?

<comment><USER46> I'm not even sure how the site differs from a site like [http://www.gmap- pedometer.com/](http://www.gmap-pedometer.com/) (afaik it also allows the share the routes).

</comment></comment><comment><USER47> Currently your site is violating the terms of google map usage. you can not ask them to allow you to keep on violating their terms.

The better solution would be to write them the letter to allow you to implement the functionality of your own with in some specific time period (may be 1 month)

Then, Create your own solution on some open standards or tech I recommend you to use openstreetmap mbtiles([http://wiki.openstreetmap.org/wiki/MBTiles](http://wiki.openstreetmap.org/wiki/MBTiles)) I have worked with them, they are tricky but really great.

<comment><USER48> Why, exactly, _can 't_ he ask them if can keep on violating their terms?

I don't get this attitude, Google is well within their rights to shut him down. He's well within his rights to ask for forgiveness and to complain about Google if they don't.

They're a corporation, not some feudal lord that is owed fealty.

<comment><USER47> Google Map and its services are the intellectual property of google.They may setup any rules and terms they want for their service regulation(also to prevent any misuse of service).

<comment><USER48> Yes, yes. We all agree on that. By why are you saying that " you can not ask them to allow you to keep on violating their terms". Why is asking them for an exception forbidden?

</comment></comment></comment></comment><comment><USER49> Pretty sure that Under Armor's MapMyFitness webapp has a route builder that uses the Google Maps API as well

</comment><comment><USER50> I used to use [http://runningmap.com/](http://runningmap.com/) to plan out routes for short-distance running in my neighborhood; but they stopped updating the site and my guess is their API key had gotten revoked as well.

</comment><comment><USER51> "These people have forgotten that all application interfaces ... used to be "richer environments," and the users abandoned them by the millions, in favor of the browser, the moment they got a chance"

And then they abandoned the web browser in even larger numbers to download "apps," which provided a richer environment to interact with their portable personal computer (or "smartphone").

Web browsers absolutely suck for UI, and they're not redeemed by their lack of complexity. When there is a easy, viable, alternative to a web browser for a program to run on users's computers you'll see browsers dropped, and hopefully go back to what they were intended for - browsing interlinked documents.

</comment><comment><USER52> Hmm, what about the Gmap Pedometer? [http://www.gmap- pedometer.com](http://www.gmap-pedometer.com)

There is nothing on that site, or its forum, about any impending shutdown.

Been using that (on and off) for a very long time. The changelog goes back to mid-2005; just months after Google Maps was announced.

This site lets you build routes and save them as permanent objects that you can share links to. It's useful for runners, cyclists, etc.

Just trying RouteBuilder: looks like a knockoff of Gmap Pedometer, only capable of connecting straight line segments (doesn't follow roads). That is irrelevant though; both sites basically wrap Google Maps in the same way.

</comment><comment><USER53> This is the very early signs of a trend that is going to grow - the conversion of private conquest of the Internet into public goods.

Google has two huge advantages in search - they have scraped links off every web page, which can be replicated (see Bing, DuckDuckGo) and they have user behaviour visiting those pages (did they immediately return to results page after hitting ,#1?)

There are good arguments to be made that both data sets are public goods, and indeed that it was unfair to use user generated content / data without licensing

There are of course arguments to the contrary. but googles jewels are too valuable to be left alone for lomg

</comment><comment><USER54> I'm unclear as to how the Google's ToS are being violated. He's not reimplementing anything that Google has provided.

If I want to create a route from my condo down to the walking path, along the path to the high school, and back to my place there is not a way to do this within Google Maps.

I use this service quite frequently when traveling and my training schedule says "2.0 mile run" or whatever. I can create a circuitous route starting/ending at my hotel. Not a way to really do this in Google Maps. So, again, how is clause 10.4(c) being violated?

<comment><USER55> Maybe I misunderstood your example but I've always found this to be pretty easy in Google Maps. I just picked a random spot on the map where there was a park (with some walking paths) and made a custom route. Took longer to pick a location for the example than it took to make the map: [https://goo.gl/5TcdGz](https://goo.gl/5TcdGz)

<comment><USER54> I must be dense then. I'm unable to figure out how to do this.

<comment><USER55> Open Google Maps in a browser. Enter your starting location. Find points along your path, right click, and choose "add destination". Repeat until you have your path. Then you can click and drag the blue line of the path if you want to take a different route than the one that is auto-generated. If you choose "walking" instead of driving or transit it will include any walking paths in the database.

</comment></comment></comment></comment><comment><USER56> >One option for me would be to rewrite routebuilder to run >on another mapping platform, but with an infant at home >and a full-time job, I frankly don't have the time or >energy.

Just install UMap instead.

[https://wiki.openstreetmap.org/wiki/UMap](https://wiki.openstreetmap.org/wiki/UMap)

[https://github.com/umap-project/umap](https://github.com/umap-project/umap)

</comment><comment><USER57> Do no evil, except for fucking over developers left and right.

</comment><comment><USER58> I wonder how easily they could switch to open street map.

</comment><comment><USER59> Not a lawyer.

My gut feel is Google writes their TOS that are concrete enough to be enforceable at some basic legal level, but vague enough to be a catch-all enforcement.

It's crummy that Google is claiming that Routebuilder is violating their ToS, but not telling them _how_ it's violating or why they have deemed Routebuilder a violate of that specific ToS clause.

It definitely feels like large company bullying tactics, which are hard for small/medium and independent companies to fight, without investing (read: wasting) money on legal fees.

This is less about "oh if you don't like the terms, build it yourself" but rather the spirit of which Google was founded.

Facebook and Twitter have pulled this same nonsense as well: encourage all developers build their apps on top of their platforms, to help grow the active user base. Once they become critical mass/gate keepers, swing the doorshut for all except those who are willing to do _everything_ that they are asked of.

The kick in the balls is how Google built their organization on top of open- software, but now has adopted the same corporate policies that closed/proprietary software vendors like MSFT have used.

"Do no evil."

<comment><USER60> Once you're no longer the underdog, your views on the world shift 180 degrees :) But worry not, everyone is riding a "sine wave" \- Google comes, Google goes. There's some physics theory that applies here - entropy, I guess.

<comment><USER61> "What goes up must come down."

― Isaac Newton

</comment></comment></comment><comment><USER62> Just move on to Open Street Maps.

</comment><comment><USER63> Isn't this interesting.

Effectively Google are saying that they have rights over the design of the API interface.

Yet isn't that their argument in the Oracle Java case, that an API itself isn't a protectable thing?

<comment><USER64> No, this has nothing to do with intellectual property rights.

Google is not claiming any legal right to prevent anyone from creating something that looks like Google Maps. They're simply saying that they don't have to give you the Google Maps API for free to do so.

Also, this is about a user interface, not an API.

</comment></comment><comment><USER65> Well there are other apps that perform similar as op's, for instance the software Tyre - which they charge for by the way. Looks like you've gotten too popular...

</comment><comment><USER66> How is Routebuilder different from [http://www.gpsvisualizer.com/](http://www.gpsvisualizer.com/)?

</comment><comment><USER67> It used to be that Google didn't play dirty.

When did that change?

<comment><USER24> When Larry Page became CEO, basically.

<comment><USER68> When Google was no longer growing rapidly. The gravity crushed ideology.

<comment><USER69> Was that at the same time that they dropped their "Don't be evil" motto?

</comment></comment></comment></comment><comment><USER70> I can't tell how this Routebuilder thing is any better than just right clicking and 'distance to here'?

<comment><USER15> There is an option in the context menu on maps.google.com "Measure distance" that it overlaps with even more. No obvious way to share the measured Google path though.

</comment></comment><comment><USER71> For crying out loud. They have billions and billions of dollars of cash on hand. Just do the right thing and buy the company. It looks good for them, it looks good for you, it looks good for the ecosystem. Just buy them!

<comment><USER72> How would that be the right thing for Google? They don't need Routebuilder, and they don't need the PR boost. Google certainly doesn't need to set a precedent that any company that depends on their APIs can expect to be acquired if they violate their TOS long enough.

</comment></comment><comment><USER73> Anyone still finds Google relevant for anything? They are making sure nobody wants to be their friend again. Search got so bad in the past few years ("bbut our metrics show it's more relevant than evar!") that DDG doesn't even have to try. Sad.

Lately if I want to watch YouTube, I have to agree to their privacy policies. If I turn off everything, I have to do the same a few days later. Antipatterns everywhere...

What happened to you guys? We want the great old Google back please!

<comment><USER74> Sorry, but this is absurd. DuckDuckGo is nowhere _near_ Google in terms of revenue, brand trust, and most importantly: search result relevance.

<comment><USER73> The point is that DDG is now "good enough". I am also a bit unhappy they are embracing some approaches that made Google worse though... And Google - <USER2> only profitable part is their search + ads. If they let this slip, what would remain? A hollow shelf like when SUN imploded?

</comment></comment></comment><comment><USER75> This is exactly the reason why Playa's building Terms of Service that are friendly to developers. I got tired of people building great apps, only to have the platform shut them down, or worse, blatantly rip them off.

Our platform promises never to compete with anyone building working products on top of the platform. I want people to do well, grow a business, and build something with their time that works for them.

Playa is made by hackers, for hackers.

I asked for feedback on some of these concepts a couple of weeks back, add to it if you'd like and help lay down the foundation:

[https://docs.google.com/document/d/1AgYQ3f61Yrk_HXSbdZtCRyiu...](https://docs.google.com/document/d/1AgYQ3f61Yrk_HXSbdZtCRyiuIvikkHNqbBislGp03Ow/edit?usp=sharing)</comment>


Development used to be (15 years ago) - <AUTHOR> https://medium.com/@TheHosk/how-development-used-to-be-15-years-ago-41161dc28a1e <comment><USER2> "Fridays Friday was going down the pub at lunchtime. Having a pint and some bar snacks."

... It still is?

I mean, was. Before all this Coronavirus lockdown stuff.

I miss the pub. :(</comment>


StockTwits raises $800K round - <AUTHOR> http://howardlindzon.com/?p=4134

<comment><USER2> Huh?

I went to the stocktwits site a few days ago after hearing about their acquisition of chart.ly. I could not figure out what they did. I get a cute live feed of people talking about stocks and... that's pretty much it. Who throws 800k at an app that is basically a much less aesthetically pleasing skin of search.twitter.com with the search fields essentially prepopulated? I told myself I wouldn't be so quick to judge too, but after spending about 10 minutes on the site, I left with nothing more than a stream of strangers' opinions and expletives regarding specific stocks , and my following of their twitter account without permission.

I'm looking for any and all enlightenment as to why this is worth 800k.

<comment><USER3> They will be selling user behaviour analytics, this is a gold mine for hedge funds. My startup would be first in line for that data too.

<comment><USER4> yeah right... amateurs sharing stock tips in < 140 characters. A hedge fund goldmine for sure...

<comment><USER3> I think you didn't get it, hedge funds will be stealing money from these amatures, by knowing what's on their minds. Crowds, if you can predict them (or direct them), you can be rich.

</comment></comment></comment></comment><comment><USER5> _start searching real time discussions from the web's savviest investors._

I'm sure the web's savviest investors are just sitting around on Twitter pointing out their upcoming positions and next big moves in the market.

Other than that, I _do_ think this is a brilliant platform for generic real- time stock news (why is this stock tanking 10% in AH??). The Google Finance and Yahoo Finance message boards are often clogged with so much junk and spam there's nothing of value.

<comment><USER6> The funny thing is, there's probably 1000x as many investors talking stocks on IRC, as there are on twitter.

One of the biggest users of the Mibbit IRC widget is a share dealing community in Brazil.

<comment><USER7> Normally, I'm with you on the irc vs twitter thing, but twitter is centralized (meaning it's really easy to search all the data coming through) and its real time search thing is pretty good. Maybe it's something you could add to mibbit?

<comment><USER6> Yup, good point. I was mainly meaning if you want volume of users/serious traders, they're more likely hanging out on IRC, than tweeting afaik.

Saying that, opt in, publicly logged channels are in the pipe line for Mib :)

<comment><USER7> I'd guess they spend more time hanging out in expensive locales in NY and London, or at Gorat's, or other non-twitter, non-IRC, non-online places.

</comment></comment></comment></comment></comment><comment><USER8> I don't have enough industry experience to put any authority behind this statement, but investing in a company that has no profits and who's business model is based on using the API of another company with no profits seems like a bit of a dance at a dreamers ball. Isn't this _exactly_ the stuff bubbles have been made of?

I'm going to go ahead and assume they know something I don't. (They do have the $800k to invest in the first place, after all.)

<comment><USER9> VC's and the like are very bullish on twitter, ergo investment in things related to twitter, and undoubtedly pressure for many portfolio companies to somehow bolt twitter on to their app/service.

I happen to like twitter, myself, but I agree this is obviously a huge risk for anyone. At least they are building something that will generate revenue (assuming demand):

 _Stocktwits premium, which is coming very soon , is like Stocktwits, but with even more awesome (or as I like to say…'The Social Bloomberg')._

<comment><USER10> Does no one think that fool.com or TheStreet or Dow Jones or the FT or [pick 'em] will pick this up to show that they Get It(TM)? Really? Come on.

</comment></comment></comment><comment><USER11> Am I the only one who's a little scared that a company who relies so heavily on another companies' service, has got funding?

I wish them luck with their ongoing success of course, it's just worrying, that's all...

<comment><USER12> It's high stakes (lower because of the economy) acquisition-bait.

</comment></comment><comment><USER13> So this is essentially the pump-and-dump stock advice I've been getting by email for years, but condensed down to <= 140 characters and delivered realtime. Awesome!

</comment><comment><USER14> First of all there a billion 2.0 apps on the planet that have no biz model and they get plenty of funding. Sure its sad, but don't be mad! Second Stocktwits is built on twitter, and thats good and bad, good that its harvesting real time stock chatter that is wickedly addictive if your trading and you wanna know why a stock is blowin up or tanking. Get a few good ones to follow and you'll be on the cusp of a trend like the pros. The bad is mostly for stocktwits not so much you, they are built on twitter so they are at the mercy of it- meaning someone could hijack content pretty easily. BUT thats why they are going after bigger stuff which is to get behind a few champion traders and go subscription service for extended goodness. Ask anyone who pays for a stock info service, tips, super screeners or whatever, they pay thru the nose in general, and some swear by it. Once you get to know a few of the better traders on Stocktwits you'd pay as well. In all its not a bad product and someone in Wallstreet will gladly acquire it once it gets a bit more refined.

</comment><comment><USER15> He's been successful with other ventures and that how you build credibility with investors. Right now we're only seeing the beginning of what he is working on. Without knowing the entire story, its hard to make a judgement on his potential chances of success.

</comment><comment><USER14> now why they bought chart.ly other than the fact its short url domain sqwuating action.. who knows, they could of done better than that, but maybe it was a cheap short cut, but odds are the url was more than the actual service...</comment>


Why teenagers are moody, scientists find the answer - <AUTHOR> http://www.telegraph.co.uk/scienceandtechnology/science/sciencenews/5110820/Why-teenagers-are-moody-scientists-find-the-answer.html <comment><USER2> The article seems to imply that hormones don't have anything to do with it, but I feel like it's probably at least 50/50 with the maturing brain thing! Anyone else have any thoughts or links on this?

</comment><comment><USER3> This contradicts a theory proposed (separately, as far as I know) by Eliezer Yudkowsky and psychologist Richard Epstein. They argue that the troubles of adolescence are caused by the unnatural situation society places teenagers in - segregated in high schools, denied autonomy, and lacking responsibility.

As Yudkowsky puts it: "Physiologically adult humans are not meant to spend an additional 10 years in a school system; their brains map that onto "I have been assigned low tribal status". And so, of course, they plot rebellion - accuse the existing tribal overlords of corruption - plot perhaps to split off their own little tribe in the savanna, not realizing that this is impossible in the Modern World. The teenage males map their own fathers onto the role of "tribal chief"..." <http://www.overcomingbias.com/2008/07/rebelling- withi.html>

And Epstein: "Imagine what it would feel like—or think back to what it felt like—when your body and mind are telling you you're an adult while the adults around you keep insisting you're a child. This infantilization makes many young people angry or depressed, with their distress carrying over into their families and contributing to our high divorce rate. It's hard to keep a marriage together when there is constant conflict with teens. ... In most nonindustrialized societies, young people are integrated into adult society as soon as they are capable, and there is no sign of teen turmoil. Many cultures do not even have a term for adolescence. But we not only created this stage of life: We declared it inevitable. In 1904, American psychologist G. Stanley Hall said it was programmed by evolution. He was wrong. ... Dumas and I worked out what makes an adult an adult. We came up with 14 areas of competency—such as interpersonal skills, handling responsibility, leadership—and administered tests to adults and teens in several cities around the country. We found that teens were as competent or nearly as competent as adults in all 14 areas. But when adults estimate how teens will score, their estimates are dramatically below what the teens actually score. ... The adversarial relationship between parents and offspring is terrible; it hurts both parents and young people. It tears some people to shreds; they don't understand why it is happening and can't get out of it. They don't realize they are caught in a machine that's driving them apart from their offspring—and it's unnecessary. ... I believe that young people should have more options—the option to work, marry, own property, sign contracts, start businesses, make decisions about health care and abortions, live on their own—every right, privilege, or responsibility an adult has. I advocate a competency-based system that focuses on the abilities of the individual. For some it will mean more time in school combined with work, for others it will mean that at age 13 or 15 they can set up an Internet business. Others will enter the workforce and become some sort of apprentice. The exploitative factories are long gone; competent young people deserve the chance to compete where it counts, and many will surprise us." [http://www.psychologytoday.com/articles/index.php?term=pto-2...](http://www.psychologytoday.com/articles/index.php?term=pto-20070302-000002&print=1)

Of course, I don't have sufficient information to judge who is right, or whether the two theories can be reconciled. It would be interesting to hear Yudowsky and Epstein respond to Giedd's work, and vice versa.

<comment><USER4> Paul Graham states basically the same theory in "Why Nerds are Unpopular":

 _As far as I can tell, the concept of the hormone-crazed teenager is coeval with suburbia. I don't think this is a coincidence. I think teenagers are driven crazy by the life they're made to lead. Teenage apprentices in the Renaissance were working dogs. Teenagers now are neurotic lapdogs. Their craziness is the craziness of the idle everywhere._

<http://www.paulgraham.com/nerds.html>

</comment></comment><comment><USER5> April 1st is over.</comment>


America's DIY Phone Farmers - <AUTHOR> https://www.vice.com/en_us/article/d3naek/how-to-make-a-phone-farm <comment><USER2> I used to do this awhile back and yes it is true. You could make around $1,000-$2,000 per month in gift cards doing it with maybe 50-70 phones. Most apps being used were 100% passive. The only thing you needed to do was restart the phone every 24 hours. The apps would run and show ads to you and just loop over and over. So what about electricity costs? for running 70 phones 24/7 in a month, that was about $10 more in power. Each phone cost around $20 which I bought off ebay. These were phones where the screen was cracked, the IMEID was blacklisted and some I think were reported stolen as well. This was maybe 3-4 years back though. Over the years, the whole thing has come tumbling down. Now you'll make maybe $100/month and it isn't passive anymore, so not worth doing it but back in the day....we were banking it no doubt about it. Also, yes I would pay tax on all of it. The companies would send a 1099.

This was the guy who showed me how to do it. I just basically copied his routine exactly:

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

<comment><USER3> You have my support for bleeding advertisers (and paying taxes ;) ) but I do want to point out one thing which is sometimes overlooked:

 _> some I think were reported stolen as well_

If true, that incentivises phone theft. The only reason people steal phones is because there's a market. Every purchase of a stolen good directly incentivises that thief to steal once more. It's a very direct link. If you've ever had anything stolen, please break the chain and consider verifying somehow, some way, that your next purchase wasn't originally lifted off someone else. It can suck, especially if you've been a victim yourself and it's just unfair.

Other than that thanks for doing your part in poisoning the advertising well :)

<comment><USER4> > The only reason people steal phones is because there's a market.

From what I can tell, the protections put on newer phones by the vendors has massively crushed the stolen phone market. Modern phones are locked to a google or apple account and basically only usable as a) parts for repair or b) if you can phish the password from the original owner, you can unlock them.

Basically, discouraging people from buying used phones, lest they be stolen, is a way less effective mechanism for reducing theft than this kind of structural change.

<comment><USER5> The person you are replying to wasn't discouraging people from buying used phones generally, just ones that you have reason to believe are stolen.

</comment></comment></comment></comment><comment><USER6> This is straight out of 'Armageddon: The Musical' by Robert Rankin.

 _" On this particular morning, Rex sat in his homemade armchair, facing the flickering TV screen. His was the classic seated posture of the Active Viewer. Relaxed yet attentive, right thumb and forefinger about the remote controller, expression alert, eyes wide. But here all similarities ended. Rex Mundi was fast asleep._

 _His old Uncle Tony had taught him the technique when he was but a leprous lad, and there was no doubt that it did pay big dividends. It had already earned Rex sufficient rehousing credits to get him overground and he actually possessed a surplus of food and medico rations. His generosity with these made him quite popular and respected locally. But the greatest benefit to Rex was that it left him plenty of time to indulge in his own personal studies. These centred upon a book his Uncle Tony had bequeathed to him, a curious volume entitled The Suburban Book of the Dead. Uncle Tony had pressed-the crumbling tome upon Rex with the simple statement, 'Knowledge is power'._

 _Shortly after this, he had spontaneously combusted while watching his favourite game show. The way he would have wanted to go,' Aunty Norma put it. "_

<comment><USER7> Man I love Robert Rankin. I read the Brentford Triangle "trilogy" when I was in college in the 80's. I used to laugh almost uncontrollably on the bus when reading his books which prompted some funny looks from other passengers.

<comment><USER6> I think my favourite is still 'The Book Of Ultimate Truths'.

<comment><USER7> Cheers for the recommendation. Your previous comment has piqued my interest in Rankin again so I think I'll backfill the ones I'm missing.

</comment></comment></comment></comment><comment><USER8> I feel like the best strategy to combat this would be to create lightweight virtualization and automation tools that could be easily deployed by anyone, thereby destroying any company that comes up with these stupid strategies. Just burn the whole system down to the ground, salt the earth, and leave it to be a weird blip in internet history.

EDIT: I'm a guy who builds thing and occasionally takes a chance at trying to promote those things. I've been on the receiving end of a fair amount of ad- fraud. The tech press is full of stories of people who say they just "put a few ads out" and then took off with their products. It's almost a meme. But it's a filthy lie. It's a lie that you can navigate the ad-tech industry without making it your full-time job. It's a lie that the ad-tech industry is a good way to get attention for your projects. It's a lie that the ad-tech industry is interested in doing anything about fraud. I've dealt with Google, Facebook, Twitter, and Amazon, and in each case _at least half_ of the money I've spent has evaporated away to ad fraud. And then, when you bring it up on HN, you get the replies, "lol, that's just the cost of doing business." No. No no no no no.

The Amazon one was particularly bad, because it lead to me getting a ton of fake followers on Twitter, killing my ranking in their timeline view, requiring me to spend about as much as a total working week on block/unblocking people to kick them out of my followers list, just to get back to a good state. For $50 of advertising, I had to spend around $2000 of my time to fix the issue and got nothing real out of it.

<comment><USER2> Trust me, people have been trying to cheat the system with stuff like what you are saying. The advertising companies know how to detect that stuff quickly and ban the abusers.

<comment><USER8> That's what I'm saying, the ad exchanges say they know how to detect the cheats, but they don't actually do a good job of it. And it's not really in their interest to do so. They get paid equally for ad-fraud as they do for legitimate impressions. The person actually advertise the product or service gets shafted. But as long as there is a long tail of people like me when I first got started who don't understand the issue of ad fraud (and the complicit people who sing the praises of advertising to boost the idea that it's a good path), the ad exchange will keep raking in money, just like the people committing the fraud.

It's easy to look at this as "Farmers vs. Google AdWords" or whatever other ad exchange we might consider. But Google is just a middle-man. And as long as the system works for some definition of "works", they can capitalize on asymmetric information about the ad industry to bleed money out of small actors.

With online advertising, it's exceptionally easy to end up in a situation where everyone gets paid except you.

<comment><USER2> Oh yeah, I get you. Yeah, that is something the ad network has to deal with. Really crazy to think how much online ad dollars are spent as well. I think most of google's revenue is directly from advertising.

</comment></comment></comment></comment><comment><USER9> Anyone who helps to wreck the advertising economy is doing a valuable public service.

<comment><USER10> wreck? Such scams is effectively similar to shoplifting, CC fraud or just an additional tax/tariff - i.e. it increases the friction and expenses in the system and the most of the burden to cover it ultimately falls upon the weakest participant in the system - usually the consumer.

<comment><USER2> The difference is that these apps were offered as stuff like "play games, earn rewards." "watch videos, earn rewards" etc. so I don't know how it could even be remotely related to shoplifting or cc fraud...where those are so obvious.

<comment><USER10> >"play games, earn rewards." "watch videos, earn rewards"

"pay money, take the bagel". Violating such a contract by intentionally and knowingly skipping or falsifying the delivery of your part of the exchange looks to me like a fraud [IANAL].

<comment><USER2> The games had "auto advance" modes built directly in to them.

</comment></comment></comment></comment></comment><comment><USER11> Is there a way to do this without buying actual phones? If you could fool the app into believing an Android VM is a phone you could really scale it up.

<comment><USER2> No. The reason is because it is easy for the app developers to detect when you are using a VM. The ad networks also have a bunch of detection software running to find it as well. Same goes for using proxy/vpn. You will be banned very quickly for doing it. Do not even attempt it.

<comment><USER12> From the article: > One farmer said they do sometimes virtualize phones on their PC, but due to how resource intensive that can be on the computer, it works out as more cost effective to have a selection of cheap phones instead.

So I guess the answer would be yes, but it doesn't make a lot of sense/cents

</comment></comment></comment><comment><USER13> If someone's life is so desperate that doing this is worth the time investment, I can't begrudge them it. Likewise with those poor souls who survive and are thankful to eat rotting refuse from dumpsters. Perhaps the income will help them lift themselves up to the point they can pursue a more satisfying life.

<comment><USER2> I used to do phone farming. You don't understand how it works. After you setup your farming rig, all you had to do was put about 1 hour per day of maintenance into it, often times even less than that...and you would earn $1,000-$2,000 per month from it in gift cards.

All of the apps were passive, it just would loop over and over playing ads.

<comment><USER14> Curious about what maintenance was required: looking for new programs? Installing new programs? Actual interaction with phones? Culling broken devices?

<comment><USER15> Restarting crashed apps (ads can load their own awful code), tapping periodic "are you still watching", swapping between apps during certain hours for more revenue</comment></comment></comment></comment>


Google Think Tank Launches New Weapon in Fight Against ISIS - <AUTHOR> http://www.nbcnews.com/news/us-news/google-think-tank-launches-new-weapon-fight-against-isis-n682036 <comment><USER2> This is perhaps the most terrifying news item I've read this year.

But I'm not scared because Google has changed the search results for 300,000 people in a deliberate, measured, and successful attempt to change targets political views.

Rather I'm terrified that that the political climate in the US is now at the place that it is safe to openly talk about mass search results manipulation in the service of making sure people have the correct beliefs.

<comment><USER3> Right. That is fucking nuts.

I've yet to read his book, but I'll just leave this excerpt here

[https://wikileaks.org/google-is-not-what-it- seems/](https://wikileaks.org/google-is-not-what-it-seems/)</comment></comment>


Is the x86 Architecture Sustainable? - <AUTHOR> http://robert.ocallahan.org/2017/06/is-x86-architecture-sustainable.html <comment><USER2> Even ignoring CPU die size cost, there's another cost to legacy features: some of those features have register state, and contexts switching it is expensive. Simpler architectures can do crazy things like switching between threads in mere tens of cycles. X86: not so much. The OS needs to deal with DS, ES, FS, and GS, and the microcode needs to deal with CS, SS, and FLAGS. The segment registers are almost useless these days, but saving and restoring them is very slow.

Even x86's model of handling CPL (privilege level) isn't ideal. I've tried to push RISC-V toward a model where user and kernel code have entirely separate address spaces, which would let privilege handling move to the front end and potentially allow pipelining across privilege changes. Amusingly, x86's privilege mechanism is complicated enough that Intel implemented it wrong in a few CPUs with MPX, resulting in a bizarre erratum.

I would love to see x86 add a "clean mode" in which a lot of legacy features are inaccessible to user code. Then kernels could try to run programs in clean mode and, if they don't fault, context switching between clean mode threads would be much faster.

<comment><USER3> > The segment registers are almost useless these days, but saving and > restoring them is very slow.

Those are only saved/restored when switching between _processes_ not between threads. Context switching when dealing with threads is typically done in software, not in hardware, precisely so that registers that are not used (like the segment registers) don't get needlessly saved & restored.

Saving/restoring registers isn't even the expensive part of a context switch anyway. Switching address spaces, cache flushes/misses, etc... are all more expensive than saving/restoring registers.

<comment><USER4> > Those are only saved/restored when switching between processes not between > threads. Context switching when dealing with threads is typically done in > software, not in hardware, precisely so that registers that are not used > (like the segment registers) don't get needlessly saved & restored.

You are incorrect. Context switching is done for threads in HW. I think you are thinking of cooperative multi-threading (like pre-Windows 95, or nginx or node.js or V8) instead of true context-switching threading.

<comment><USER3> All you need for preemptive multithreading is IRQ#0 to generate an interrupt. That's the entirety of it.

Preemptive multiprocessing then needs paging and such to make isolated memory a thing as well, but still doesn't need HW context switching.

</comment></comment></comment></comment><comment><USER5> Oh for pete's sake, the die size cost for supporting the legacy x86 instructions is a fraction of a percent on a modern multicore CPU. This is because the translation hardware stays relatively fixed (in terms of size and complexity and transistor count), while Moore's Law keeps adding more hardware to each core and more cache, etc..

Take a look at this annotated die shot of an old Pentium 4:

[https://i.stack.imgur.com/QK4gm.jpg](https://i.stack.imgur.com/QK4gm.jpg)

Up at the top is the microcode memory and microcode sequencer. That's the hardware that's responsible for translating all those old, large legacy instructions. It's not really much space on the P4, and the P4 Northwood is a 55-million transistor CPU.

Nowadays, depending on if you're talking about a mobile part or a higher-end desktop or server part, the CPUs have between ~1.5 billion to 2 billion transistors.

Again, that microcode ROM just doesn't grow very much as you add instructions, even a ton of instructions. And this is, well, one reason why Intel just keeps adding instructions. It's practically free.

<comment><USER6> The whole impact of the architecture on the processor is to be considered, not just the size of the decoder. If the ISA was irrelevant (and the ISA does not just influence the decoder, it influences pretty much everything in various degrees) in modern days and even semi-modern days, Intel, with all its power (vastly superior to Arm, from a financing pov), would have come with something that does not suck in mobiles given how strategic this market is. It has not. In other words, you should not confuse the size of the lexicon with its associated comprehensive semantics.

It does not matter that adding instructions in that framework is not too costly. The framework itself is costly for some applications...

<comment><USER7> > Intel, with all its power (vastly superior to Arm, from a financing pov), > would have come with something that does not suck in mobiles given how > strategic this market is.

This market is a lot more price-sensitive than the desktop, laptop and server CPU market.

</comment></comment></comment><comment><USER8> I think many commenters here are viewing this only in terms of die cost. But the blog post is not about that: it's about the other costs that this complexity introduces! Each new feature interacts with all the others in complex ways, and each new feature requires significant new engineering efforts by anyone who has to interact directly with x86 assembly (I sketched a few of these use cases below [1]).

The same author has also written [2] about Intel's CET (their attempt to add control flow integrity (CFI) support at the CPU level):

> The tail end of Intel's document is rather terrifying; it tries to enumerate > the interactions of their CFI feature with all the various execution modes > that Intel currently supports, and leaves me with the impression that > they're generally heading over the complexity event horizon.

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

[2] [http://robert.ocallahan.org/2016/06/is-control-flow- integrit...](http://robert.ocallahan.org/2016/06/is-control-flow-integrity- worth.html)

</comment><comment><USER9> Surprised to see RISC-V is not mentioned. They take an interesting approach to extensibility where it's basically envisioned in the ISA from the start. Outside a core subset of features that programs can assume, you have to check each extension you need before you use it, so (in theory) it should be possible to drop deadweight extensions in future.

See "ISA Overview" here: [https://content.riscv.org/wp- content/uploads/2016/06/riscv-s...](https://content.riscv.org/wp- content/uploads/2016/06/riscv-spec-v2.1.pdf)

<comment><USER10> Agreed, but then again there just isn't any practical implementation available yet. If there was a raspberry pi like device, I think we would start seeing it mentioned more.

<comment><USER11> I'm guessing you mean workstation/server scale implementations? There is a shipping microcontroller implementation and has been for a while now.

</comment></comment></comment><comment><USER12> This is entirely anecdotal, but a coworker of mine worked at amd, and he once told me that amd did a study and found that instructions needed for backwards compatibility accounted for less than 1% of CPU die space. Big silicon manufacturers are pretty price sensitive and the decision to break backwards compatibility is a clear cut economic one. Clearly they have chosen not to break old software at the expense of continued architectural complexity and maintenance.

<comment><USER13> The problem isn't the hardware devoted to decoding or even executing instructions so much as the overall design and verification complexity. The existence of 286 call gates has implications throughout the memory subsystem and now when you're adding your TSX transactional memory instructions you have to think carefully about how they interact with call gates and whether you could be introducing bugs and make sure you have unit tests to uncover those bugs.

<comment><USER12> Yes, you're right. The silicon giants decided it was cheaper to fund that testing and verification work than to break backwards compatibility.

<comment><USER6> Except they occasionally miss some nasty bug in that area...

This is yet another danger to security.

</comment></comment></comment></comment><comment><USER14> At the risk of sounding like a broken record, I like what ARM did with AArch64. AArch64 is not entirely a clean break with 32-bit ARM, but it eliminated a lot of legacy mistakes and is generally a radical shift in the direction of a clean RISC design. Unlike x86-64, which piled 64-bit support on top of the existing ISA, keeping most of the legacy intact, AArch64 aggressively addressed problems such as conditional execution, PC-as-register, the small register file, LDM/STM complexity, barrel shifter complexity, etc. Most importantly, 32-bit mode is an optional feature not mandated by the ARM architecture, hopefully paving the way to dropping the legacy stuff entirely in the future.

<comment><USER15> ARM doesn't have to support legacy binaries in the same way that the wintel ecosystem does. I don't think it's really comparable.

<comment><USER14> Sure they do: people want to keep playing Candy Crush when they buy a new phone.

<comment><USER16> Candy Crush is compiled to more or less architecture-independent bytecode on Android and a dual (32/64bit) binary on iOS. So no worries wrt Candy Crush.

<comment><USER17> There's a lot more to CPUs than the size of their registers. The fact that those 32/64 bit binaries still run is exactly the kind of legacy support we're talking about.

</comment></comment></comment></comment></comment><comment><USER18> It is interesting that Intel finds it in this position. Their extend-extend- extend mantra (briefly interrupted in the Itanium until AMD pushed them back into it :-) has left them with a lot of "junk DNA" in their chip. That isn't horrible, the transistors are small and spreading them out helps avoid hot spots, but as pointed out it's also a waste.

But this is perhaps the first time in history that there is a realistic chance of them being replaced by an alternate ISA. The largest markets for "computers" (and by that I mean the ones that people compile on and develop systems on and run data centers on, have largely adopted open source (if begrudgingly) and that means you can get functionally identical software (but not performance identical) on different ISAs.

So at that point what keeps Intel alive is their volumes make it so much more cost effective than a bespoke architecture. And then there is ARM which is 'open' in the sense that anyone can get a processor architecture license, and 'high volume' as the basis for all of the compute appliances.

But that effort has been slow going[1] and continues to falter on corporate models that want to jump to the level of penetration today x86 has in a heartbeat rather than through measured evolution.

[1] [https://www.nextplatform.com/2017/02/01/arm-server-chips- cha...](https://www.nextplatform.com/2017/02/01/arm-server-chips- challenge-x86-cloud/)

</comment><comment><USER19> Wasn't there some dead weight dropoff† once with amd64, as a x86 CPU is unable to execute 16-bit code when in 64-bit mode?

IIRC that was a notable cause of DOSBox becoming slower when going 64-bit as it had to emulate the 16-bit CPU instead of just running on metal, as well as 64-bit Windows (7?) being unable to run old DOS and Win3x software.

With an increasingly rolling-release culture on software I can't wait for X-year support for hardware instruction sets /s. Wait, this is already happening for Android phones, where ARM SoC manufacturers just flip it at OS and phone vendors (Nexus 4, OnePlus X). I just realised Apple made a damn right call getting that under their control on that front.

† the metal may still be there though, waiting to be jettisoned as the market for 32-bit OSes goes away.

<comment><USER7> > as a x86 CPU is unable to execute 16-bit code when in 64-bit mode?

This is still possible, though unsupported by Windows and Linux (the latter one never supported 16 bit code).

<comment><USER20> 32 bit x86 Linux supported 16 bit code.

[http://man7.org/linux/man-pages/man2/vm86.2.html](http://man7.org/linux/man- pages/man2/vm86.2.html)

<comment><USER7> The vm86 syscall is for entering Virtual 8086 mode, which is indeed not supported in Long mode.

This mode was for example used under Windows 9x for implementing the DOS box.

But this is not what I was talking about. I am talking about 16 bit code in protected mode. This is/was used under Win16 and is supported in all 32 bit versions of Windows.

<comment><USER21> Win16 can run in 64bit mode as long as it is 16bit protected mode code. WINE uses that to run Win3.1 apps in 64bit Linux. For example:

[http://i.imgur.com/KtgLeWu.png](http://i.imgur.com/KtgLeWu.png)

(this is an old shot of mine and yes i used a XFCE theme to make it look like Win95 :-P)

<comment><USER7> > Win16 can run in 64bit mode as long as it is 16bit protected mode code.

Not under Windows: [https://news.ycombinator.com/item?id=14246521](https://news.ycombinator.com/item?id=14246521)

</comment></comment></comment></comment></comment></comment><comment><USER22> Interesting proposal for a forward compatible instruction set architecture by Agner Fog:

[http://www.forwardcom.info/](http://www.forwardcom.info/)

</comment><comment><USER23> This will no doubt raise hackles, but instruction set architectures are FAR less relevant than they used to be.

Fewer and fewer systems or people care about x86 vs ARM vs RISC-V. C has been the intermediate language of choice for decades now, and things like WebAssembly drive that care even lower. And if you really have to, you can binary translate.

x86's real problem is Intel's _business model_.

To compete today, you need processor IP you can integrate with other components on your die or system -- that's why ARM wins outside of the data center. In theory, Intel could sell x86 designs a la ARM, but that would completely break their business.

My bet: x86 gets squeezed between the rise of GPU vector supercomputing and ARM general purpose CPUs. Apple is already doing this in-house.

<comment><USER24> "Fewer people care about the ISA" _is_ one of Intel's "real problems". Intel having a near-monopoly on the x86 architecture is a lot less valuable than it used to be.

On the other hand, while it's true that languages and runtimes provide more portability these days, there's still important handwritten assembly, and the amount of investment in compiler implementations still gives popular ISAs an edge.

</comment></comment><comment><USER25> In a world where JIT become more and more common, I could see many legacy features being dropped at one point.

Alternatively, I wonder how feasible it would be, for a multi-core system, to keep one legacy core for incompatible processes and faster new-arch cores for running the main beef.

<comment><USER26> The current generation of new programming languages are all compiled to machine code (Rust, Go, Swift)

<comment><USER27> That's an implementation detail. Code written in these languages is generally trivially retargetable.

</comment></comment></comment><comment><USER28> The post posits that, to handle the burden of legacy instructions, an "obvious technically-appealing approach (is) starting over with a clean-sheet architecture".

The approach that immediately occurred to me would be have a layer that translates the legacy instructions into modern equivalents; without as much concern if they are slower to execute in their new form (they're legacy, after all, right?).

Of course, doing something like that is probably nowhere near trivial, the devil's always in the details.

But I bet this is already being done at the microcode level. Stepping things up to having a published agreement about which instructions were globally considered "legacy", and guidelines for _what_ their equivalents were, would go a long was towards allowing a general feeling that an ISA was evolving, rather than just accumulating weight upon weight.

<comment><USER3> > The approach that immediately occurred to me would be have a layer that > translates the legacy instructions into modern equivalents; without as much > concern if they are slower to execute in their new form (they're legacy, > after all, right?).

This is what x86 CPUs already do and have been doing for years.

It's also why Intel & AMD don't care about "x86 complexity" and it's also why even though people love to claim that a switch to RISC would improve efficiency/performance, so far there's really no evidence to support that.

Intel just plops their teeny-tiny (in terms of die space) x86-to-internal- microcode transactor on top of their new cores and calls it a day. As long as that translation layer isn't a bottleneck, which it rarely is, then Intel doesn't care.

<comment><USER24> It's not just about legacy instructions which can be decoded down to some microcode. It's about architectural _features_ like SGX, CET, MPX, TSX, VT --- plus the legacy stuff like segment registers and 286 call gates and virtual 8086 mode and so on and so on --- and how they all interact with each other, and how they increase the complexity of context switching, OS support, and so on.

<comment><USER3> OS complexity is because they choose to keep and value that backwards compatibility, just like x86 values backwards compatibility.

Linux could eliminate all that complexity tomorrow by just bulk removing x86 support and only running x86-64. All OS complexity eliminated. All context switching complexity eliminated.

</comment></comment></comment></comment><comment><USER29> > legacy compatibility features [...] those CPUs won't be as efficient, cheap, > reliable or secure as they otherwise could be [...] we can't rely on > increasing transistor density to bail us out.

Legacy features shouldn't have a large impact on transistor usage, and they should have almost no impact on efficiency (although that may involve design choices). Almost all of the transistors are going to be used to implement the cache, routing between the high level blocks (external IO, cores, shared cache), and routing between the various _micro_ architecture units.

Using Broadwell as an example, the CPU cores[1] only use a relatively _small_ amount of amount of area. However, even that is misleading, because most of the acre within each core is dedicated to the _micro_ architecture, which implements a far smaller set of micro-ops. Inside each core[2], the only place affected by legacy instructions is the decode stage (mostly in the "4-Way Decode" block in [2], probably less in the "PreDecode" block"), and a larger MicoCode ROM.

The legacy instructions might not be as efficient as they used to be in older CPUs; as low-priority instructions they may be implemented with less- convenient micro-ops that were designed for other, faster instructions. The software that uses those instructions was probably designed for a _far_ slower CPU anyway, so it's probably no important if those instructions are a "slow" when the CPU overall is much faster.

I agree that the interactions between instructions _might_ increase the difficulty of security, concurrency, or other higher-level concerns, but that will depend on the specific instruction. I'm not sure how large these concerns might be, unfortunately, so I cannot say if it's a serious issue.

> so their complexity ends up being "dead weight"

This sounds suspiciously like the unfortunate recent practice of labeling "old" things as "bad" or "holding back progress" and thus must be removed. In most cases backwards compatibility is a _very important_ feature that adds very _little_ cost. The low cost is possible because you can usually implement older features in terms of the newer features. This is true in CPU microcode, just like it's true in software.

[1] [http://i59.tinypic.com/2mrxso9.jpg](http://i59.tinypic.com/2mrxso9.jpg)

[2] [https://en.wikichip.org/w/images/thumb/a/a1/broadwell_block_...](https://en.wikichip.org/w/images/thumb/a/a1/broadwell_block_diagram.svg/850px- broadwell_block_diagram.svg.png)

</comment><comment><USER30> Would like to hear what someone with compiler writing experience has to say about this. Is it really that much of a problem?

<comment><USER8> I'm not sure compiler writers care that much; they don't have to support every x86 instruction and can restrict themselves to whatever subset produces fast code.

Where it really kills you are things that have to _analyze_ x86 binary code (e.g., binary static or dynamic analysis tools). Unless you cover every nook and cranny of x86, chances are you'll eventually encounter some program that uses one of these instructions and your analysis will break. And of course emulators like QEMU face the same problem.

This problem becomes especially severe in the context of malware – any instruction you forget to model becomes a way for a malicious program to evade your analysis.

</comment></comment><comment><USER31> It is not just the complexity but also the question of economics.

In general Intel on the server side is under pressure by specialized chips. Incremental spend will rather go into specialized silicon, SSDs and RAM than into CPU where it delivers more bang for the buck.

On the PC side people are looking for battery life - something Intel lags. Both Apple and Microsoft are eying the ARM universe causing Intel to recently fire a patent threat in the direction of Redmond and Qualcom.

From a volume perspective Intel is big but ARM with both mobile and IoT behind it has the momentum.

The tick-tock has slowed. New generations are becoming harder to manufacture.

Moore's law ending will assert itself in economic terms. Complexity is not your friend when the volume is increasing elsewhere and adding value becomes harder.

</comment><comment><USER32> AFAICT, infrequently used instructions are implemented with microcode. I would guess that each of these instructions have a cost of a few thousand transistors, on a chip with billions.

<comment><USER33> But aren't there thousands of those instructions?

</comment></comment><comment><USER34> Well there is a rumours that Intel is working on a cleaner and leaner x86.

[http://wccftech.com/intel-developing-new-x86-uarch- succeed-c...](http://wccftech.com/intel-developing-new-x86-uarch-succeed-core- generation/)

</comment><comment><USER35> The fun thing is that if they got rid of things like segmentation (make segment register instructions fault), 90%+ of modern x86 user mode code would still work.

</comment><comment><USER36> The biggest threat to x86 is containers. A new unit of work removes the lock in. Then also things like Android and ChromeOS in addition.

The other aspect is cloud providers have the data for the next generation of processors.

<comment><USER37> Containers must be native to the host architecture.</comment></comment>


Show HN: ClickShirt – Print custom shirts from the right click menu - <AUTHOR> https://chrome.google.com/webstore/detail/click-shirt/gdofnocbobegdnhigkcgachhjmfhfdci/details

<comment><USER2> Copyright law issues here?

You certainly don't have permission to sell T-shirts with my artwork on them..

<comment><USER3> I could download the image and print it myself, someone is making it easier. They don't even look to the image to see if it is copyrighted, porn or just Lorem Ipsum. I get you point but if they are a "we print anything you send our way" shop, how can they be liable for what I send them? I guess you can only blame the end user...

<comment><USER4> I imagine it would be similar to any site based on user generated content where they would first need to contractually prohibit users from uploading material that infringes on third party intellectual property rights and then they would need to have a policy in place to address any complaints by third party intellectual property rights holders that their right were being infringed. But it certainly wouldn't be a safe bet to just assume their off the hook entirely because it's too hard for them to determine infringement.

</comment></comment></comment><comment><AUTHOR> I took 2nd place at my first Hackathon this weekend. It seemed appropriate to post my hack here.

<comment><USER5> Great job with this project. I would try striking some kind of affiliate deal with sites likeImgur or get advertising on a meme subreddit. $25 might be a little high for an impulse tsirt buy, but it could get some hits.

<comment><USER6> One-off t-shirts are expensive. I recently got 8 t-shirts made by Custom Ink, and each one was $40. I didn't even choose the expensive American Apparel shirts, either.

Custom Ink is probably one of the more expensive companies (and I chose them because of their excellent customer service), but you get my point.

</comment></comment></comment><comment><USER4> How do you deal with image quality? I would imagine most images on the web are too low resolution to look good once printed on a t-shirt.

<comment><USER6> Would be cool if they did a reverse image search on Google to find the largest-available version of the image. No idea if that's available via API, though.</comment></comment>


Why Aren't University Lectures Broadcasted to the World? - <AUTHOR> https://danielmiessler.com/blog/why-university-lectures-not-broadcasted-world/?fb_ref=SOaLvH9fJr-Hackernews <comment><USER2> Well, lots of reasons. For starters, you have to consider the privacy of every person who appears on camera, including students and guest presenters. But let's assume a blanket waiver can be put in place (ha, good luck). Then you have to consider the chilling effects: will people want to have open discussions in lectures (for instance, to challenge a professor) if such questions (which may be read as dissent, or picked up on by outsiders to smear the speaker) are de facto recorded?

Then there's copyright, as university lectures may contain copyrighted video or audio that the university has licensed for educational purposes but not retransmission.

Let's also consider intellectual property, because guest speakers (who may have been paid for their contributions) may not be able to get speaking gigs as easily if a university has put their lecture online.

From a technical perspective, you also need capture and storage equipment. That's not just cameras and hard drives. You need someone to operate the equipment (e.g. framing shots, checking audio levels) because a catch-all wide shot of a lecture theatre is not very compelling or engaging. And all material has to be catalogued so it appears in the right place.

Many universities ARE taking the opportunity to provide lecture recordings because it burnishes their brand and provides a public service. But let's not pretend it's as simple as hitting record.</comment>