HBO Says No, for Now, to Fans Who Want a Web-Only Option - <AUTHOR> http://mediadecoder.blogs.nytimes.com/2012/06/06/hbo-says-no-for-now-to-fans-who-want-a-web-only-option/?src=tp

<comment><USER2> This is why Game of Thrones is the one of the most pirated TV shows of all time: [http://torrentfreak.com/whos-pirating-game-of-thrones-and- wh...](http://torrentfreak.com/whos-pirating-game-of-thrones-and-why-120520/)

People are willing to pay, and they're not responding to customer demand.

<comment><USER3> _People are willing to pay, and they're not responding to customer demand._

How many of these people don't have cable or satellite? Really now if you already have cable (and I know very few that don't) then you already have the ability to pay, and get HBOGo

<comment><USER4> I do not have cable or satellite. When I want to see something, I check Amazon, Hulu, or similar places. If I can't find anyone willing to take my money in exchange for a stream, I then consider alternatives that do not involve making contracts with cable/dish companies.

<comment><USER5> Its crazy if you think about it: there are dozens of teams working for free (probably pulling all nighters) to translate subtitles to brazilian portuguese so the other folks that don't speak english can see the shows only a couple days later that they appear in US.

They are truly fans of the series, but they're all pirating this content. But its hard for me to just say that they're motherfucking thieves.

If they could just sit back and pay x<=5 bucks to see this show with comfort - would they? I would.

</comment></comment></comment></comment><comment><USER6> Ok. That's fine. But I now fully consider piracy for HBO to be a business decision and I don't want to hear any moral condemnation and cries for government intervention from them.

<comment><USER7> HBO isn't some critical drug that you need to live, it's an entertainment channel. You don't have a need for HBO that gives you a moral right to make an unauthorized copy of it.

If you want to make a copy of it, fine, but don't try and pretend it's anything other than lack of self-control on your part by trying to gloss with a "moral high ground".

<comment><USER6> I'm not talking about self justification here, i'm talking about business and politics. Lately the entertainment industry has been campaigning for government intervention to clamp down on the internet because content producers can't make enough money because of piracy. To me, this argument clearly states that they believe they make more money from a premium price with a restricted supply that encourages piracy than they would from an easily available product that would reduce piracy. I am perfectly fine with them making this business decision. However, as a citizen who would like to have as little government intervention as possible while still protecting functioning markets, I see no problem here and don't want to hear about how they need government intervention to prevent content creators like them from going out of business.

<comment><USER8> _To me, this argument clearly states that they believe they make more money from a premium price with a restricted supply that encourages piracy than they would from an easily available product that would reduce piracy._

Do you also steal diamonds? Gas? McRibs? After all, those are also products who's supply is artificially constrained. I'm not trying to be inflammatory, but however you try and justify theft, it's still theft. The market _is_ functioning, you just don't like how it works right now.

<comment><USER6> Hrm, Very interesting response.

Software and media are both zero marginal cost products, so when someone pirates it, I don't consider it theft. Left to run rampant, piracy could create a situation where it wasn't viable to run that business anymore, which I would care about. However, the claim has long been countered by people saying that the business themselves are in a better position to deal with this problem without additional government involvement. I believe this article and the other from dcurtis clearly shows that the later is true for HBO.

Yes, the market is functioning, and I like it just fine. Piracy is creating a ceiling on how much a company can charge for their product while still making it widely available for enjoyment of people. Piracy in this case is serving as price discrimination allowing the most possible number of people to enjoy it while those who are able to afford it or care enough are paying for it. It appears as though the current market is doing a rather nice job of maximizing social benefit.

Would I steal gas or McRibs, no, those are both a clearly limited item. Now diamonds are a fun one I have never thought of. Rumor has it that there are warehouses full of diamonds they DeBeers keeps of the market to drive up the price of diamonds as a jewelry item. Hypothetically, lets say I had designed a new industrial laser than would help make the lives of other human beings better off, but I need a giant diamond that at current artificially restricted price doesn't make economic sense. In this case, yes, I think I would steal a diamond and not feel bad about it. But then again, although I am not a purist, many of my ideas about morality are utilitarian. Especially with zero marginal cost goods.

</comment></comment></comment></comment></comment><comment><USER9> Offering a complete streaming service might be a bad idea, but it's a shame they don't do like so many other content providers and offer individual episodes for sale via Amazon Instant Video. Many popular cable shows (and even shows from ABC/NBC/Fox etc.) are available for purchase on Amazon the day after they air, usually for $2 each. This option would avoid the technical difficulties and the added expense of operating their own web-based content delivery system.

</comment><comment><USER10> I think this makes complete sense for HBO, although as a consumer its pretty irritating. I'm hunting for the reference but I seem to remember reading about (UK) Sky signup accelerating after the launch of Sky Atlantic, which shows HBO content pretty much exclusively, their content brings people to providers. Until the cord cutters outnumber the cable subscribers its not going to change I'm afraid. Also the providers also have their own IPTV solutions so whats the benefit to HBO?

</comment><comment><USER11> Which would be tantamount to open warfare in the minds of the cable companies. (Incumbents like to over react when revenue they feel entitlement over is at stake.)

<comment><USER12> This is about HBO determining that it's better for their business to stay with the cable companies. The argument is laid out pretty well here:

<http://dcurt.is/hbo-forbes-journalism>

<comment><USER13> It's better for their business _now_. In fact, I think it's true that they will get less money as online-only than in the current scheme. But that's not important, because I think the current business model is going to go away. That is, I think they'll eventually have to have an online-only option, or they'll die.

</comment></comment></comment><comment><USER14> Their decision makes perfect sense, today. But, my guess is that cable subscriptions are decreasing, they have just hooked their little red wagon to a sinking ship. I think HBO are overlooking an opportunity.</comment>


Show HN: TerminusDB – An open source in-memory graph database - <AUTHOR> https://terminusdb.com/ <comment><AUTHOR> TerminusDB is an open source (GPLv3) full featured in-memory graph database management system with a rich query language: WOQL (the Web Object Query Language).

TerminusDB originated in Trinity College Dublin in Ireland in 2015 when we started working on the information architecture for 'Seshat: the Global Historical Databank', an ambitious project to store lots of information about every society in human history. We needed a solution that could enable collaboration among a highly distributed team on a shared database whose primary function was the curation of high-quality datasets with a very rich structure, storing information about everything from religious practices to geographic extent.

The historical databank was a very challenging data storage problem. While the scale of data was not particularly large, the complexity was very high. First there were a large number of different types of facts that needed to be stored. Information about populations, carrying capacity, religious rituals, varieties of livestock etc. In addition to this each fact had to be scoped with the period over which the fact was likely to be true. This meant we needed to have ranges with uncertainty bars on each of the endpoints. Then the reasoning for the data point had to be apparent on inspection. If the value for population was deduced from the carrying capacity, it is critical for analysis to understand that this is not a "ground fact". But even ground facts require provenance. We needed to store the information about which method of measurement gave rise to the fact, and who had undertaken it. And if that wasn't bad enough, we needed to be able to store disagreement - literally the same fact might have two different values as argued by two different sources, potentially using different methods.

On top of this we needed to be able to allow data entry by graduate students who may or may not be reliable in their transcription of information. So additional provenance information was required about who put the fact into the database.

Of course, all of this is possible in an RDBMS but it would be a difficult modeling task to say the least. The richness of data and the extensive taxonomic information makes using a knowledge graph look more appropriate. Given that Trinity College Dublin had some linked data specialists we opted to try a linked data approach to solving the problem.

Unfortunately, the linked-data and RDF tool-chains were severely lacking. We evaluated several tools in an attempt to architect a solution, including Virtuoso and the most mature technology StarDog, but found the tools were not really up to the task. While StarDog enforced the knowledge graph or ontology as a constraint on the data, it did not provide us with usable refutation witnesses. That is, when something was said to be wrong, insufficient information was given to attempt automated resolution strategies. In addition, the tools were set up to facilitate batch approaches to processing data, rather than a live transactional approach which is the standard for RDBMSs. Our first prototype was simply a prolog program using the prolog database and temporary predicates which could be used within a transaction such that running updates could have constraints tested without disrupting the reader view of the database. (We thought that over time the use of prolog would be a hindrance to adoption as logic programming is not particularly popular – though there are now several green shoots!).

Not long after this we were asked to attempt the integration of a large commercial intelligence database into our system. The data was stored in a database in the 10s of gigabytes keeping information about all companies, boards of directors and various relationships between companies and important people over the entire course of the Polish economy since the 1990s. This, unsurprisingly, brought our prototype database to its knees. The problem gave us new design constraints. We needed a method of storing the graph that would allow us to find chains quickly (one of the problems they needed to solve), would be small enough that we didn't run out of main memory and which would also allow the transaction processing to which we had grown accustomed. The natural solution was to reuse the idea of a temporary transaction layer, but to keep them around longer - and to make these layers very small and fast to query. We set about looking for alternatives. We spent some time trying to write a graph storage engine in postgres. Ultimately, we found this solution to be too large and too slow for multi-hop joins on the commercial intelligence use-case. Eventually we found HDT (Header-Dictionary-Triples). On evaluation this solution seemed to work very well to represent a given layer in our transactions as well as performing much better and so we built a prototype utilizing the library.

Unfortunately, the HDT library exhibited a number of problems. First it was not really designed to allow programmatic access which was required during transactions and so we found it quite awkward. Second, we had a lot of problems with re-entrance leading to segfaults. This was a serious problem on the Polish commercial use case which needed multi-threading to make search and update feasible. Managing all of the layering information in prolog was obviously less than ideal - this should clearly be built into the solution at the low level. We either had to fix HDT and extend it. Or build something else.

We opted to build something else and we opted to build it in Rust. Our specific use cases didn't require a lot of the code that was in HDT. We were not as concerned with using it as an interchange format (one of the design principles for HDT) and in addition to the layering system, we had plans for other aspects to change fairly drastically as well. For instance, we needed to be able to conduct range queries and we wanted to segment information by type. HDT was standardized for a very different purpose and it was going to be hard to fit it into that shoe. The choice of Rust was partly one borne of the pain of tracking down segfaults in HDT (written in C++). We were willing to pay some upfront cost in development time not to search, oft times fruitlessly, for segfaults.

At this point our transaction processing system had linear histories. The possibility of tree histories, i.e. of having something with branching was now obvious and relatively simple to implement. It went on to the pile of things which would be "nice to have" (a very large pile). It wasn't until we started using the product in a production environment for a Machine Learning pipeline that this "nice to have" became more and more obviously a "need to have".

As with any technical product of this nature there are many different paths we could have followed, after spinning out from university and attempting to pursue a strategy of implementing large scale enterprise graph systems with some limited success, we decided to shift to open source and become TerminusDB ([https://github.com/terminusdb/terminus- server](https://github.com/terminusdb/terminus-server)). Potentially a long road, but a happier path for us. We also decided to double down on the elements in TerminusDB that we had found useful in project implementation and felt were weakest in existing information architectures. These are the ability to have very rich schemas combined with very fine-grained data-aware revision control enabling the types of Continuous Integration / Continuous Deployment (CI/CD) used extensively in software engineering to be used with data. We think that DataOps, basically DevOps for data or the ability to pipeline and reduce the cycle time of data, is going to become more and more important for data intensive teams.

The name 'TerminusDB' comes from two sources. The Roman God of boundaries is named Terminus and good databases need boundaries. Terminus is also the home planet of the Foundation in the Issac Asimov series of novels. As our origin is in building the technical architecture for the Global History Databank, the parallels with Hari Seldon's psychohistory are compelling.

To take advantage of this DataOps/'Git for data' use case we implement a graph database with a strong schema so as to retain both simplicity and generality of design. Second, we implement this graph using succinct immutable data structures. Prudent use of memory reduces cache contention while write-once, read-many data structures simplify parallel access significantly. Third, we adopted a delta encoding approach to updates as is used in source control systems such as git. This provides transaction processing and updates using immutable database data structures, recovering standard database management features while also providing the whole suite of revision control features: branch, merge, squash, rollback, blame, and time-travel facilitating CI/CD approaches on data. Some of these features are implemented elsewhere, the immutable data structures of both Fluree and Datomic for example, but it is the combination that makes TerminusDB a radical departure from historical architectures.

In pursuing this path, we see that innovations in CI/CD approaches to software design have left RDBMSs firmly planted in the past. Flexible distributed revision control systems have revolutionized the software development process. The maintenance of histories, of records of modification, of distribution (push/pull) and the ability to roll back, branch or merge enables engineers to have confidence in making modifications collaboratively. TerminusDB builds these operations into the core of our design with every choice about transaction processing designed to ease the efficient implementation of these operations.

Current databases are shared knowledge resources, but they can also be areas of shared destruction. The ability to modify the database for tests, for upgrades etc is hindered by having only the single current view. Any change is forced on all. The lack of fear of change is perhaps the greatest innovation that revision control has given us in code. Now it is time to have it for data. Want to reorganize the structure of the database without breaking all of the applications which are using it? Branch first, make sure it works, then you can rebase master in confidence. While we are satisfied with progress, databases are hard and typically take a number of years to harden. It is a difficult road as you need to have something which works while keeping your options for progress open. How do you eat an elephant? One bite at a time.

We hope that others will see the value in the project and contribute to the code base. We are committed to delivering all features as open source and will not have an enterprise version. Our monetization strategy is to roll out decentralized data sharing and a central hub (if TerminusDB is Git for data, TerminusHub will be the 'GitHub for data') in the near future. Any cash that we generate by charging for seats will subsidize feature development for the core open source database. We are not sure if this is the best strategy, but we are going to see how far it takes us.

<comment><USER2> > the linked-data and RDF tool-chains were severely lacking.

I'm curious if you evaluated any of these solutions and if yes why you found them lacking:

* Jena

* RDF4j

* Blazegraph

Also, why not SPARQL? And if your query language is based on triples, why not Turtle for serialization instead of JSON-LD? JSON-LD is not very human friendly to write by hand, imho.

<comment><USER3> We evaluated Jena (we actually prototyped the first system in Jena) and RDF4j. At the time we didn't look into Blazegraph. In beginning the project we began to develop hypotheses of the kinds of features we would need. Namely the ability to check the instance data against a very complex and evolving schema. The need to do schema and instance updates in a single transaction. The need to recieve a program interpretable "witness of failure" (a refutation proof) so that automatic strategies could be undertaken to correct failures in certain cases.

As we went forward we also acquired the collaboration and time-travel requirements to facilitate large team data curation - which aren't present in these offerings.

As for SPARQL, it's essentialy a messy and truncated datalog. It just seemed a bit silly not to use an actual datalog! Then as I've said elsewhere, we needed to be able to do fast time-window queries which CLP(fd) is excellent at and which SPARQL doesn't support.

JSON-LD is most definitely not human friendly, and turtle is certainly better. In our interface you can manipulate the schema in turtle as it's far clearer.

The advantage of JSON-LD is as an interchange format. With turtle you are pasting together strings. With JSON-LD libraries for querying the database are just functions which build JSON-LD. It also simplifies parsing on the opposite end.

But in addition JSON-LD + strong schema give you a way to treat segments of the graph as documents! We can use our get_document word and you'll get back the JSON-LD fragment of the graph associated with an ID. JSON-LD was carefully designed so that this bidirectional interpretation is possible.

</comment></comment></comment><comment><USER4> This looks really great. It's interesting to see that 99% of the source code is Prolog. I'm curious to know what advantage--real or perceived--did Prolog provide over some other, more mainstream language?

Also, @ggleason, based upon your experience with other languages, would you still use Prolog if you had to do the whole thing over again?

<comment><USER3> Prolog implementations are very efficient at implementing back-tracking, so if you end up using a lot of back-tracking it definitely makes sense. My first prototype was started in java and it was a nightmare. Secondly, for writing the query compiler, prolog was just such an elegant language.

SWIPL has a large enough and nice enough library that it makes it feel similar to other dynamic languages (python, etc.) in terms of implementing run-of-the- mill glue code.

I'm very fond of prolog as the implementation language for the constraint checking, and especially CLP(fd). I think CLP(fd) is such a killer feature, that once people start using it in their queries, they're going to wonder how they got-on before.

I would like prolog to be a lot more feature-mature for the current age however. It needs a bigger community to help flesh the language out! So many things could be made better - better mode analysis, better type checking and simply more libraries.

<comment><USER4> Thank you so much for your response. You may have convinced me to have another look at Prolog. I stumbled upon it 15 years ago, but never used it for any real project. I just remember really loving its declarative style.

</comment></comment></comment><comment><USER5> Interesting project. Out of curiosity, why did you compare against kdb+ since the models are very different? KDB is mostly used for in-memory time-series while your seem to be a graph-oriented DB. Also, why did you choose to build your own language instead of using an existing one [1]?

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

<comment><USER3> The reason is that we were positioning to deal with customers who had financial data which was stored as time-series. We aren't hoping to compete with kdb+ on speed (which would be hopeless) but we have a prototype of Constraint Logic Programming [CLP(fd)] based approaches to doing time queries which is very expressive and which we hope to roll out in the main product in the near future on hub.

The graph database is still in its infancy and there are a lot of graph query languages about. We played around with using some that already exist (especially SPARQL) but decided that we wanted a number of features that were very non-standard (such as CLP(fd)).

Using JSON-LD as the definition, storage and interchange format for the query language has advantages. Since we can marshall JSON-LD into and out of the graph, it is easy to store queries in the graph. It is also very simple to write query libraries for a range of languages by just building up a JSON-LD object and sending it off.

We are firmly of the belief that datalog-style query languages which favour composibility will eventually win the query language wars - even if it is not our particular variety which does so. Composibility was not treated as centrally as it should have been in most of the graph languages.

<comment><USER6> Composeability is front and center in GQL, so you may want to consider it.

<comment><AUTHOR> We will 100% consider it and have been engaging with the community about the best approach. Cypher is by far the biggest graph query language and they seem to have the most weight in the conversation so far, but we are going to try to represent datalog as far as possible. Even if woql isn't the end result we think datalog it is the best basis for graph query so we'll keep banging the drum (especially as most people realize that composability is so important)

</comment></comment></comment></comment><comment><USER7> 1\. Do you support JSON-LD Framing?

I have a set of JSON-LD documents which I would like to query across and for each result return a nested JSON object for display in a user interface. For example, let's imagine I was querying an employee database to find employees with the job title "Software Developer" and for each matching Employee return the following nested structure:

      {
        @type: "Employee",
        @id: "employee:bob",
        name: "Bob",
        job_title: "Software Developer",
        email: "email@example.com",
        manager: {
          @type: "Employee",
          @id: "employee:alice",
          name: "Alice"
        }
      }

I can see how I could write the filter based on the pattern matching syntax but I don't see how I could gather the data to produce the result (which in reality might be much more deeply nested.)

2\. Have you benchmarked against RedisGraph?

They seem to have achieved very good performance from building atop of GraphBLAS.

<comment><USER3> 1\. We do support framing. Our documents are defined using a special superclass called "terminus:Document". Anything in the downward closed DAG up to another "terminus:Document" is considered part of that document. You can ask for some number of unfoldings of the internal documents by passing a natural number - in which case you will frame the underlying documents. We might extend this framing to allow more sophisticated approaches later if there is interest.

2\. We have not performed benchmarks against RedisGraph. We intend to do benchmarks in the future but are currently focusing on collaboration features rather than raw speed.

I had just come up with some methods of using GPUs to speed up graph search when I saw the RedisGraph whitepaper and that they had already done it. I have to admit I was more than a little jealous! It's a good idea.

We'll look at the approach again in the future - our next steps are exposing CLP(fd) in our query language.

<comment><USER7> So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc.

I think it's definitely worth supporting differing depths of reference embedding along different paths. Ideally though you want want to select which properties are included as when you get to several levels of embedding the resulting document is very large and often you only need a subset of properties expanded for the embedded documents.

Additionally it can be very helpful to embed along reverse references (parent.children from the reference stored as child.parent.)

Concrete example, take this page on a scientific data portal: [https://www.encodeproject.org/experiments/ENCSR807BGP/](https://www.encodeproject.org/experiments/ENCSR807BGP/)

The JSON-LD document representing that object itself is: [https://www.encodeproject.org/experiments/ENCSR807BGP/?forma...](https://www.encodeproject.org/experiments/ENCSR807BGP/?format=json&frame=object) and many reference paths are expanded to generate the JSON required to construct the UI: [https://www.encodeproject.org/experiments/ENCSR807BGP/?forma...](https://www.encodeproject.org/experiments/ENCSR807BGP/?format=json) (this is larger than it needs be as the entire referenced document is embedded rather than just the necessary proeperties.)

While pre-generating the deeply embedded document means fetching it is fast, as the site has grown keeping them up to date becomes challenging so I've been looking at options for embedding dynamically.

<comment><USER3> "So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc."

That's correct.

"I think it's definitely worth supporting differing depths of reference embedding along different paths."

Yeah, path unfoldings were something we were thinking about but ended up on our very tall stack of things we want to do. You can generally get around it just by calling the get_document API on the client end from javascript, although it is true this will be much slower.

</comment></comment></comment></comment><comment><USER8> "AI Code Generation"

I see this mentioned in the product comparison chart, but no mention of what that actually means.

<comment><USER3> Frankly I think this should be removed. Marketing sometimes get overzealous in trying to present what makes us special.

<comment><AUTHOR> Yes, we need to delete that. And actually think about all the product comparison categories again.

Too many parts!

<comment><USER9> Yeah, two of the categories for MongoDB are wrong, for example..

<comment><AUTHOR> Which two? On ACID, I hear the arguments on Mongo Atlas since they integrated the wiredtiger tech (to basically become a RDBMS), but still not ACID. The other is cloud native I suppose? Again, have moved along and we gave the a balanced score.

<comment><USER10> MongoDB has full ACID support in the Database.

<comment><AUTHOR> Mongo does not provide durability by default

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Maybe a stupid question, but does it persist data on disk as well or is it a pure in-memory approach e.g. for analytical workloads?

<comment><USER3> Not a stupid question! The database is in memory but we journal all transactions to disk, so it is persistent. In fact it's so persistent that it never goes away. We have an append-only storage approach allowing you to do time-travel. You can query past versions, or look at differences, or even branch from a previous version of the database.

<comment><USER12> I read about append only storage when I was studying log structured file systems. Is it somehow similar?

<comment><USER13> Yes, although with databases as against log files, you also need to be able to somehow append 'deletes' and updates to existing records as well as just adding new records. The advantages of doing so is that it greatly simplifies transactional processing and makes it much more parellelisable - because you never change any existing data, just add new records on top. Blockchains have similar 'immutable' characteristics. The other reason why append only storage is desirable is that it allows you to time travel simply by backtracking through the append-logs and you can then do stuff like reconstructing future states by replaying all of the append events that got you there.

There are a variety of databases and database management systems that try to do this - most of them run into problems with the meta-language needed to describe updates and deletes to, for example, SQL Tables or something similar. This is a hideously tricky and detailed problem because there are all sorts of ways in which an SQL table can be changed many of which have implications for all sorts of other bits of data and you have to capture all of this in your 'update' append log.

On the other hand, if like TerminusDB, you use RDF triples as an underlying language, then the problem is pretty trivial - every update can always be expressed as a set of deleted triples and a set of added triples.

<comment><USER12> But, wouldn't an append only database demand substantially more storage which would also increase at a faster rate? How is that handled given we won't be able to fit the database on a single disk?

Also, I wanted to understand how databases work and wanted to build one from scratch. Is there any website/tutorial/blog you think could help me out? Thanks a lot!

</comment></comment></comment></comment></comment><comment><USER14> Congrats Gavin and crew! Know y'all have been working on this for a while, it's awesome to see it coming along.

</comment><comment><USER15> Looks cool, and being written in swi-prolog is a nice bonus.

This is not a criticism, but I am curious why a new query language WOQL was designed and implemented instead of just using SPARQL. It seems like it would be not too difficult to write a converter between WOQL and SPARQL.

Also, swi-prolog has excellent semantic web libraries with SPARQL support.

<comment><USER3> We debated using SPARQL initially, and even had a test implementation leveraging the version shipped with SWI-prolog. However we found SPARQL to have a number of short comings that we wanted to see addressed.

Firstly, there were features. Tighter integration with OWL and schema- awareness was something we wanted to build in at a low level. We also wanted to leverage CLP(fd) for time and other range queries. If we were going to need to fundamentally alter the semantics anyhow, it didn't seem that important to start with SPARQL. Other features that are coming down the pipes very soon are access to recursive queries and manipulation of paths through the graph.

Secondly, we wanted better composability. One of the real strengths of SQL as a language is that it is very easy to compose language elements. By contrast SPARQL feels quite ad-hoc, mimicing some of the style of SQL but losing this feature.

Lastly, we wanted to have a language which would be easy to compose from Javascript, or python. Javascript, because we live in a web age, and python, because it's the choice for many datascientists. JSON-LD provides a nice intermediate language in which to write queries in either of these languages. No need to paste together strings! And then, because of the choice of JSON-LD, we can naturally store our queries in the graph (and even query our queries).

<comment><USER15> Good answer, thanks for that! I am working on a commercial product to help people form SPARQL queries, and I must admit pro-SPARQL bias. Your decision makes a lot of sense.</comment></comment></comment>


Ask HN: (In)validate our idea: hosted remote logging for mobile apps - <AUTHOR>

Hey there, first time posting on HN and we want to get your feedback.
We want to build a hosted logging service for mobile apps. This means that you can finally store and retrieve all your logs in one place.
We are iOS developers, and we think that having insight into what your users are doing in real-time would be incredibly helpful, especially when providing customer support/troubleshooting.
We know there are services such as Testflight and Crashlytics that have basic logging capabilities, but they aren't really focused on logs.  These services don't allow you to search, archive, and manage them in a developer friendly manner.
What do you guys think? Is it worth pursuing? <comment><USER2> I want a service that boosts my App Store Rankings. Can you build that?

<comment><USER3> I want a service that prints money.Can you build that?</comment></comment>


Samsung Cortex-15 Dev Board - <AUTHOR> http://www.arndaleboard.org/wiki/index.php/Main_Page

<comment><USER2> Sigh, its a cool board, at $100 it would be game changing, at $250 its just another evaluation kit. The continued lack of docs on the ARM GPU is extremely annoying.

<comment><AUTHOR> It is a lot harder to work with these phone and tablet type chips. ARM have open sourced the Mali driver code but you still need the DDK, which requires a license. The reverse engineering efforts on GPU command streams are also a labour of love from Lima etc.

And it would be twice as good if it cost half as much.

</comment></comment><comment><USER3> Combine this board with a 256GB SSD and WiFi, and you have a prototype for a puck sized PC. Add some apps, to allow you to use a laptop or a netbook as an input device, and there might be a compelling product developed on here.

</comment><comment><USER4> Its the same price as a Chromebook, although it does have more ports, ethernet, serial and jtag useful, but pretty similar hardware spec I would guess.

I can't see any power consumption figures which is annoying.

<comment><AUTHOR> I do believe that it's closest siblings are Chromebook and Nexus 10. Graphics benchmarks are slightly under the Nexus 10 but that could be due to a number of things. [1]

For me the main interest are the schematics and fudging a quad core when it arrives. As well as having all the peripherals available for development choices.

[1][http://www.glbenchmark.com/phonedetails.jsp?benchmark=glpro2...](http://www.glbenchmark.com/phonedetails.jsp?benchmark=glpro25&D=Samsung+Arndale+Board&testgroup=overall)

</comment></comment><comment><USER5> $250, plus you'll need a power adapter.

Mali GPU, so that is closed, but has a reverse engineered open source driver.</comment>


More Productive Git - <AUTHOR> https://increment.com/open-source/more-productive-git/ <comment><USER2> Put this in your bashrc:

        source /usr/share/bash-completion/completions/git

And you can type "git br<tab>" to write "git branch", "git checkout fun<tab>" to write "git checkout funky-feature", "git log --na<tab>" to write "git log --name-only" etc.

Pretty much every time you press <tab> somewhere while writing a git command, it does the right type of completion. And hitting <tab> multiple times lets you toggle through the options. So you learn git along the way.

This was one of my most enjoyable productivity jumps when it comes to using git.

<comment><USER3> On debian this is the default behavior.

<comment><USER4> Same in Ubuntu.

Bash completion on Ubuntu/debian is out of this world. I can do things like

lxc exec <TAB>

and get a list of currently running containers.

<comment><USER5> Fun fact: Ubuntu is a derivative of Debian!

<comment><USER4> Yeah, but they also have added some stuff that is not part of standard Debian.

</comment></comment></comment></comment></comment><comment><USER6> The very first factual claim in the article is wrong:

"The most basic usage is: git reset useful_func.clj This will replace the useful_func.clj in the current working directory with the last committed version in the repository HEAD."

Not a good start. What it actually does is reset the path "useful_func.clj" in the index (AKA staging area) to the HEAD state. It doesn't touch the working directory.

<comment><USER7> It's not clear to me if the author actually understands how staging works and how that affects the commands they suggest. They claim that stashing takes staged changes and then note that after stashing the working tree will be clean. That suggests the post is being dumbed down or the author is misunderstanding things.

Git guidance should almost always start with a brief introduction to the concepts you believe the audience doesn't know or fully understand. To begin with reset and not properly explain the index will just end up being confusing, especially with brief references to hard, soft and mixed resets later on!

<comment><USER8> I see this so often with power user tools. All power user tools are tools that you can only use reasonably well with some basic understanding. They are made not to be understood in the easiest fashion but to handle all complexities of a problemset as efficiently as possible. Therefore it sometimes seems harder to use from the outside, but actually the hardness comes from the problem it solves, not the tool.

So yeah, if you really want to use git well, learn its internals. It takes some time but actually not even hard. After reading the Git Book once I was even able to implement my own git (of course without performance considerations).

</comment></comment></comment><comment><USER9> There's an article like this every week or so.. I don't get it. Git isn't __that __hard.. You can pretty much get by 99% of use cases with like four or five commands.

<comment><USER10> > Git isn't that hard.

It's not, but if you don't use it mostly every day, or if you decide to "Delete repository and clone again" every time there's a problem, you won't ever get to learn how to fix it.

The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.

The term `checkout` is multiplexed to do more things than I would've guessed.

<comment><USER11> I find the staging area useful. It especially helps when you only want to commit a change in part of a file or just generally reviewing a commit before it's a real commit. And also to double check I'm not going to be uploading any secret keys (which seems to happen to people more often than it should).

<comment><USER12> The staging area is incidental. It's yet another place in which your code can be, and it confuses users. This is why Gitless has removed it.

[https://gitless.com/#vs](https://gitless.com/#vs)

You don't need the staging area to select hunks into a commit. The selected hunks could go straight into a commit. Selecting hunks is a different thing than putting the selection into an extra intermediate area between working directory and commit.

You don't need an extra intermediate area to review a commit. Commits are flexible and modifiable, so you can review the draft commit, modify it as necessary, and then publish it.

<comment><USER13> I always assumed it was there as an analogue of the state tracked by a UI such as TortoiseSVN's Commit dialog, or (though it's a lot longer since I lasted used it...) Perforce's changelists view. It's a list of files you've got checked out or modified: you tick the ones you want in the commit, right click to delete files or revert, double click to get a diff, that kind of thing. Between each deletion/reversion/diff/etc., the state of the tickboxes is retained, so you can sort of just fool about until you've got what you want.

But this sort of multi-step thing is often a pain to do from the command line, I find: unless you have some way of tracking the state between commands, it's no fun working through this list of items, building up a to do list that you then have to get done at the end with one uber command. And the staging area is this way of tracking the state when it comes to putting together your commit.

The gitless examples look to have many common possibilities licked, though, and perhaps that will suffice for most cases?

</comment></comment></comment></comment></comment><comment><USER14> Since started using Magit in Emacs, I found myself using the command line Git less and less. I can perform most Git commands with couple key strokes. Having a UI with integrated workflow with Git is pretty nice.

<comment><USER15> Despite using git for nearly a decade, I never became "good" at it until I started using Magit. Emacs is worth learning for Magit and org-mode alone.

<comment><USER16> Vim zealot here. Been tempted by org mode. This comment pushed me over the edge--I'm gonna give Emacs a try. _Winces and waits for the world to explode_

<comment><USER17> Long time Vim user here as well. I started my transition to Emacs few years ago. Along the way I discovered Emacs Doom distribution, which is specifically created for Vim users (and similar to Spacemacs, but lighter), and I never looked back.

</comment></comment></comment></comment><comment><USER18> One mistake that I saw several times is cherry picking or merging another branch into the current one, then realizing later that you didn't need those changes yet, and you _revert_ the merge commit. Later, if you actually want to merge the other branch into the current one you will get in trouble as it's already "up to date", as the current branch is ahead. Even worse, if you instead merge the current branch into the other one, all your changes done in the other branch will be reverted. The takeaway: don't revert something if you don't actually want to revert that code. I am pretty bad with git, by I assume the correct way to reverse the initial merging would be to remove that merge commit entirely, using git reset.

<comment><USER19> You can just revert the revert commit.

<comment><USER18> Biggest issue is the first part, when it's "already up to date", so then when you merge the feature into the current branch and think it's merged, it will actually be missing, so you might forget to revert the revert, or not work anymore because of new commits/conflicts.

<comment><USER19> I honestly can't say I have ever had this problem. I also don't understand how you could forget to revert the revert? And why would new commits matter? Sure you may have conflicts, but you would have had them anyway if you hadn't reverted.

We've had to revert commits on our master branch after several commits have been added on top before, and we've never had an issue just checking out a branch off master and reverting the revert commit.

I feel like there are workflow things you could be doing to avoid whatever problems you're encountering possibly?

<comment><USER18> You can easily forget if someone else (not yourself) did this (they merge the branch and reverted it), later when you try to merge the branch it could be successful, without any merge conflicts, but still won't lead to the expected changes.

<comment><USER19> OK I suppose that is more likely, but I still think this is easily-avoidable through process. If you're closely-enough involved with a ticket that you were going to be the one merging it, I think it's reasonable to expect that you have an idea of things that have happened in the story.

</comment></comment></comment></comment></comment></comment><comment><USER20> I found one article, only one, that did more than anything to help me understand git. Can't find it anymore. :-( But it had to do with reflog and how _any_ command could be undone since nothing was truly destructive, and how reflog actually had the edges in the graph and you just needed to know how to repoint them to the right nodes. Or something. This is probably one of my least helpful HN comments.

edit: It _might_ have been this one: [https://hackernoon.com/https-medium-com- zspajich-understandi...](https://hackernoon.com/https-medium-com-zspajich- understanding-git-data-model-95eb16cc99f5)

<comment><USER21> > _any command could be undone since nothing was truly destructive_

As the article mentions,

        git reset --hard

will blow away uncommitted changes in your working tree.

</comment></comment><comment><USER22> One of the most common issue I faced when I started learning git was diverging local and remote branches, franatically searching how to fix it and giving up 2 hours later.

<comment><USER23> Yes, that has been my experience as well. Starting a new repo that has a remote tracking branch has been a source of constant frustration for me. I routinely mess up some incantation and then have no idea how to fix it. The mental overload is high enough with local branches, but I still don't quite follow what it means to have a tracking branch, it seems to complicate the nice and simple mental picture I have of the local repo as a DAG.

<comment><USER24> When you fetch from a remote repo, the state of the branches in that repo has to be recorded somewhere locally in your repo. That's what remote tracking branches are. So if the remote called origin has a branch called master, and you fetch, git downloads the commits you don't have and then updates .git/refs/remotes/origin/master to the commit ID of whatever master is on origin.

That's all it is.

Basically you have a DAG just like you think. But git needs some way to label some of the nodes in that DAG. It calls those labels "references" or refs, it records them under .git/refs/, and there's basically just three kinds: local branches (refs/heads/<branch_name>), tags (refs/tags/<tag_name>) and remote tracking branches (refs/remotes/<remote_name>/<branch_name>). There's also the reflog which is a change log of the local branch refs, and a special log for HEAD which keeps track as you switch which branch is currently checked out.

Note: if you start poking around under .git (and you should in a toy repo!), you might not find exactly these files. For performance reasons, git sometimes combines the refs into a single file called packed-refs.

</comment></comment></comment><comment><USER25> For many of us git should be a multiplier - spend time doing your code and experiments in a safe way, because git, used well, will protect you. As such, learn the tool! Pro Git[0] is great, and you learn the how, but more importantly the why of the tool, so that you can make git a multiplier.

[0][https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2)

</comment><comment><USER26> > We then tell git bisect to run the command lein test on each commit until > the command exits with a 0 exit code, indicating that we've found the first > broken commit.

According to git-bisect(1), "the script should exit with code 0 if the current source code is good, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad."

</comment><comment><USER27> Doesn't look right if an article starts by introducing git reset and git reset --hard.

<comment><USER28> What makes you say that? I use that command nearly every day.

<comment><USER27> There is something wrong with your workflow if you have to use git reset --hard nearly every day.

<comment><USER29> Why in the world would you say that? I check out a branch, I write some code, it doesn't do what I want, I do a git reset and try again.

If you aren't using git reset that means you're either a genius coder who doesn't make mistakes, or you are a coder who would rather keep going down a bad path instead of just starting fresh. Some people find it easier to just start fresh.

<comment><USER30> For me, it's never the case that new code I'm writing is SO devoid of value I'd rather pretend I never wrote it, but that's what a reset does. Rather, I keep iterating until I've made clear progress, then commit.

</comment></comment></comment></comment></comment><comment><USER31> More productive Git is faster & easier with good git aliases. These help novices and experts alike.

I maintain a large free list of Git aliases, and community feedback is always welcome.

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

<comment><USER12> Here's another one:

[https://gitless.com/](https://gitless.com/)

</comment></comment><comment><USER32> > A common workflow is: > Mess up your Git repository. > Google some error > messages and read cryptic > > posts. > Try a few fixes. > Tear hair out. > > Delete repository and clone again.

You don't have to be a genius to use git, I've never experienced anything like this, even though I've worked in 15-20 member teams with lots of conflict and all that. Read the docs and use it as it is suggested. I don't think it is that hard... I feel like this scenario is just not from real life

<comment><USER33> It totally is, but probably not for people working with as many as 15-20 others who can help out!

</comment></comment><comment><USER34> The most productive I've ever been with git is when I've done `hg --config extensions.hggit= clone git.example.org/repo.git` and got on with my work.

</comment><comment><USER35> There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world?

Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got out of the Dark Ages.

It's time for an intervention. It's time to take seriously the friction and frustrations it creates. Yes, it has redeeming qualities. But it's time to stop looking past those and do something about them (other than another article such as this one).

<comment><USER36> I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git.

Git is a tool for creating and navigating a directed acyclic graph of revisions. It's fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that they occasionally attended data structures and algorithms class.

I understand not taking a day to learn git, I really do. It's hard to find the time to learn everything that comes your way at work, and you're not exposed to the practical challenges that augment documentation as part of learning if you try to crush it out all at once. But, if someone can't learn git, I don't know what to do with them. We're not cranking out websites in an agile, typewriter-pool style open-office, sweatshop. I need people that can learn things at least as complicated as git, because they're gonna have to keep up.

<comment><USER35> > "Git is a tool for creating and navigating a directed acyclic graph of > revisions. It's fine to chuckle and make fun about how esoteric that sounds, > but at the same time I expect people that work on my team to rise to the > challenge of proving that they occasionally attended data structures and > algorithms class."

And those can (read:should) have a visual representation, yes? Why are we still typing archaic/cryptic commands - read: wasting brain cycles that could be better spent - for what are ultimately manipulation of something best represented visually?

It's time to move on. I'm sure someone will fax you when the time comes. Hopefully, you can keep up :)

<comment><USER37> There are visual tools for git though, so what's the problem?

\- Gitk

\- Tower for OS X

\- Github

Besides, some people enjoy using CLI tools the obvious reason that they're simple to use and can be used programmatically with minimal overhead.

</comment></comment></comment></comment><comment><USER38> I got shamed a few times in a new role awhile back in part [imo] because it was assumed I was 1000% git-fluent. The way I've started to view svc ticks is similar to how I view grammar knotsies. In the end the idea is to communicate, not to make other people feel like dunces.

</comment><comment><USER39> My pro tip for 'more productive Git':

Read the Git documentation thoroughly. Most people don't, and then wonder why they have no idea what's going on when a project they're put on uses Git for version control.

</comment><comment><USER40> If you really want more productive Git, stop playing the Git Adventure Game!

When you poke at your repo on the command line, you never get to see it as a unified whole. All you can do is try a command, see what it prints out, and try to make a mental model of what this all means.

A good Git GUI will _show_ you the state of your repo and unify all of the scattered concepts of the command line like the index, the reflog, and stashes.

SmartGit is my favorite. I've also heard good things about Tower, although it's only available on Mac and Windows, not Linux. (SmartGit supports all three.)

A couple of examples from the article:

> _The process of a cherry-pick is brief. First, we identify the SHA for the > commit or commits you want to pick, using git log or the like. Next, we > check out the branch we want to apply the commit(s) to. We then pick the > commits._

      git cherry-pick d8119f49cd4fd6b0366c5ca3af205f9c25af89ba

In SmartGit, you see the commit you want to pick in the log, right click it, and select Cherry-Pick.

> _Another common issue is committing and then discovering you missed > something in that commit. Sure, you could make an edit and add another > commit, but sometimes you want to maintain all related changes in a single > commit. In this case, you can use the git commit --amend command to fix it > up._

> _Let's say you've edited useful_func.clj and then committed it._

      git add useful_func.clj
      git commit -m "Added even more useful function"

> _But you forgot to commit your code and document your new function. Instead > of editing and committing again, you can amend. Make the required changes to > the useful_func.clj file, then add it again:_

      git add useful_func.clj

> _But instead of running a normal commit, run an amendment._

      git commit --amend --no-edit

> _This will amend your last commit with your new changes and commit it. The > --no-edit flag tells Git not to launch the editor and skip amending the > commit log message. If you want to update the commit log message too, you > can omit this flag._

In SmartGit, you use the same Commit dialog as a normal commit. It's on the menu, or Ctrl+K (Command+K on Mac) will take you right there. The Commit dialog has an "Amend last commit" checkbox which is normally unchecked. Simply check that box and it will do an amended commit. You can either keep the previous commit message that is displayed in the dialog, or edit it right there.

A couple of other topics the article doesn't touch on...

What about the index? In SmartGit, you can either use the index or ignore it as you see fit. I rarely use it myself. The Commit dialog just does the right thing when I ignore the index, committing my working tree changes directly. And if I do want to use the index, it's easy to get to from the same dialogs.

One of my favorite features in SmartGit is how it handles the reflog. Instead of printing out a list of hashes and poking through them to find the one you need, simply click the Recyclable Commits box in the log view. Now every commit in the reflog shows up as part of the normal commit log tree. You can work with these commits just like any other.

It does the same thing with stashes. Click the Stashes checkbox and they show up in the commit log too. (I wonder how many Git users realize that a stash is simply another commit by a different name?)

Maybe you're not sure exactly what was changed between two fairly distant commits? Click one of them, and then Ctrl+click the other. Now the Files panel shows you exactly which files were changed between these two commits and the exact differences.

I could go on for a while, but what I really wonder is why so many developers are reluctant to even _try_ a Git GUI like SmartGit. It is so much more powerful and productive than the command line adventure game.

<comment><USER8> > When you poke at your repo on the command line, you never get to see it as a > unified whole. All you can do is try a command, see what it prints out, and > try to make a mental model of what this all means.

Or simply learn to use the git commands right. Then it shows you everything the UI tool would show.

I recommend everybody adding this to their ~/.gitconfig

        [alias]
            lol = log --oneline --graph --decorate
            lola = log --oneline --graph --decorate --all
            lols = log --oneline --graph --decorate --all --max-count=10

Then you can simply do a `git lol` or `git lola` to get the same result as your fancy UI is showing you. And it also works via ssh. If you've manually typed that alias in a few times you will also remember it and have it readily available when you ssh into a customer server etc.

</comment></comment><comment><USER41> I am not the best programmer around but i gotta sat Git is a disaster to work with. I find it incredible complicated for such a simple task.

</comment><comment> francis-io I often use this to get to the root of a git repo. Put this in your ~/.bashrc

alias r='cd $(git rev-parse --show-toplevel)'

</comment><comment><USER42> Any interface that forces you to manually visualize a complex internal structure rather than show you the internal structure itself is a design smell.

Any interface that forces me to manipulate such a complex structure with obscure textual commands rather than a drag and drop interface is a design smell.

The git graph structure is not amenable to command line. When I do "git log" it lies to me. I see a linked list for what is essentially a graph.

<comment><USER43> The command line shows you _part_ of the graph: you choose which part it shows you based on what options you pass it.

<comment><USER42> Without options it returns something that is implied to be a linked list. Try it. Anything merged into the current branch is shown as part of a single long list. It implies sequentialism in places that are parallel.

</comment></comment></comment><comment><USER44> thanks for telling me about 'git amend'. I frequently screw up and fail to add the files I want or as soon as I commit I remember I needed to change something else. So my projects all have strings of commits that are a few seconds apart.

<comment><USER8> `git amend` and `git rebase -i` are two core features of git. It's okay if especially interactive rebasing takes some time to get used to. But it should certainly be part of every users standard tool set.

</comment></comment><comment><USER45> Why does the article link to the version 1 of the _Pro git_ book instead of the v2?

[https://git-scm.com/book/en/v2/](https://git-scm.com/book/en/v2/)</comment>


Google App Engine Answers Critics with New Release - <AUTHOR> http://blog.programmableweb.com/2010/12/07/google-app-engine-answers-critics-with-new-release/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ProgrammableWeb+%28ProgrammableWeb%3A+Blog%29

<comment><USER2> As I cannot find any reference to it in this, the FAQ or other posts on the subject, I guess it is safe to assume this is still Python 2.5 based, correct?</comment>


Automatic Pinhole Lego Camera - <AUTHOR> http://www.youtube.com/watch?v=fVdrjynRFSs

<comment><USER2> Would love to see a 25mp digital back on that thing for ultimate nerdery.</comment>


"Robots" Guarded Buddha's Relics in Ancient India - <AUTHOR> https://theconversation.com/robots-guarded-buddhas-relics-in-a-legend-of-ancient-india-110078 <comment><USER2> The types of 'android assassins' are tulpas. They're similar to the Jewish tradition of Golem, which is imbued rock and clay to an automaton. Other terms would be thoughtforms, egregores.

The belief behind them is that they are 'energy beings' (think of energy as spiritual and not em/strong/weak/gravity). And one can 'encode' simple ideas or actions on them, like "Protect this grave" or the like.

<comment><USER3> Even warnings written on a wall cause emotions that change the very chemistry of one's body.

</comment></comment><comment><USER4> The ideas in this article are considerably less irritating than I thought it was at first. Essentially:

* "In 300 B.C., two Greek ambassadors, Megasthenes and Deimachus, resided in [North India]"

* "Did they bring plans or miniature models of automatons and other mechanical devices?"

* Is the origin of a legend about robots guarding the remains of Buddha inspired by these automatons the Greeks brought from the West to the East?

It's still all conjecture, takes far too long to get to it's point, and copy- paste is disabled on the site, but it's not another "Ancient India invented the internet"[0] howler

[0] [https://www.bbc.com/news/world-asia- india-43806078](https://www.bbc.com/news/world-asia-india-43806078)

</comment><comment><USER5> They lost me at ancient robot assassins chasing robot makers who tried to escape.

<comment><USER6> That's where they got me.

</comment></comment><comment><USER7> probably a typo here, the "robots" are referred as "bhuta vahana yanta". "Yanta" is not a word in sanskrit, it should be "Yantra" which means machine.

Edit : My bad, it does means machine in pali which is the defacto language of the early buddhist sect.

<comment><USER8> Does it literally translated to soul carrying machine, or am i completely wrong

<comment><USER7> Bhuta means multiple things in sanskrit, it can mean deities, spirits, what is conscious, or comes into existence. In pali's context it is correct since bhuta in pali means something that has an animated in nature, which i believe is a better translation since pali was the dominant language during the reign of Asoka & Ajatshatru. On a different note, pali and sanskrit, though have almost the same vocabulary and inferences, may have different meanings for similar contexts.

</comment></comment></comment><comment><USER9> I was first imagining spring-loaded or lever-based traps like in the Indiana Jones movies.

Obviously the ones in the movies were made up for entertainment value, but does anyone know if these sorts of traps have ever been encountered in a real archaeological site?

<comment><USER10> It's a pity that the major regions that link the greek/roman thought of the 'west' to the Indian/Asian cultures of the 'east' are today places of conflict resulting in destruction, both intentional and collateral. How much of archaeological knowledge has been lost to post ww2 wars in Afghanistan, Iran, Syria?

<comment><USER11> And in fact ISIS actually specifically targeted many of those sites either for plundering for artifacts to sell to fund their operations, or for demolition. It really is a shame, some of the sites are thousands of years old... gone in an instant.

</comment></comment></comment><comment><USER12> The story of treasures guarded by dormant robots evoked Laputa, Castle in the Sky by Studio Ghibli. Its a city in the sky, like in Gulliver's travels and a legend to aviators. Giant robots wake up to guard it. I wonder if Japan also picked up the lore.

The machines that could efficiently cut down many men evoked Enthiran (same word as yanthra in Tamil), about an android falling in love like Bicentiennal Man but at one point building a mega gun with his magnetic powers. [https://www.youtube.com/watch?v=F-V_Vp_J9b0](https://www.youtube.com/watch?v=F-V_Vp_J9b0)

<comment><USER13> Also thinking about the Golem. Similar ideas.

</comment></comment><comment><USER14> I love this and I don't care if it's bullshit. Such a great story.

</comment><comment><USER15> Relevant: [https://en.wikipedia.org/wiki/Tipu%27s_Tiger](https://en.wikipedia.org/wiki/Tipu%27s_Tiger)

</comment><comment><USER16> I wonder if this has some connection to the terracotta warriors of China?

</comment><comment><USER17> Hellboy 2: The Golden Army

</comment><comment><USER18> Let me explain, because someone downmodded my snarky response earlier.

\- How do the androids see? There isn't any cogent explanation of sight until the last 100 years. If there is some principle of sight discovered earlier, why didn't we see other simpler devices from the same era?

\- How do the androids know what they see?

\- How do the androids know who revealed the secrets? How do they know their address, or where they are right then?

\- How do they act? Where do they get the energy from? How is it stored?

\- How do they walk? Boston Dynamics has been beating its head for quite some time now. Someone who can read those old documents, please reveal the secret, and relieve them of their confused misery.

If they are anything they must be glorified rat traps. I am not trying to be offensive, but this article just offends any rational thought.

<comment><USER9> All of the sources mentioned in the article describe the Romavisaya as a "legend". It's unclear whether or not it has a real connection with any ancient device, although some of the sources suggest that the legend was inspired by ancient technology (which would have been _much_ more limited than the devices in the story).

This article refers to the account as a "story", "legend", or "tale" deriving from "oral traditions". Since all of the actual robot content is repeatedly said to come from a "legend", I don't think the article's author is trying to convince you that this actually happened historically!

<comment><USER18> Harry Potter, then?

</comment></comment></comment><comment><USER19> It says this at the end: "This story was first published in The Conversation", but does not provide a link, usually required for content reposted from The Conversation. A search found it [1]

[1] [https://theconversation.com/robots-guarded-buddhas-relics- in...](https://theconversation.com/robots-guarded-buddhas-relics-in-a-legend- of-ancient-india-110078)

</comment><comment><USER20> Why is the BS posted here?

<comment><USER21> Because it's a legend that has real and interesting historical connections to the relationship between India and the West. I think that it's reasonable to assume that many readers here aren't familiar with the history and cultural exchange that influenced or led to these tales.

<comment><USER12> I'm loving the myth Buddha is depicted with curly hair from Greek style. And Stoic philosophy, developed in Greece and popular with Roman elite was developed from Buddhist teachings.</comment></comment></comment>


Privacy is Power: Why the fight for privacy matters - <AUTHOR> https://journal.standardnotes.org/privacy-is-power-f0a064ab36ea#.9op3ljljh <comment><USER2> Best part of the article: explaining how privacy is a public good.

TLDR: privacy isn't just about "keeping secrets" or having "something to hide".

Privacy for a whole population is power. Once a population has lost its right to privacy, once people's conversations and movements are monitored, they're rendered powerless. It becomes easy to strip away their other rights.

\--

Worst part of the article: the recommendations at the end.

The author lists a kitchen sink full of privacy tools including Telegram, which the entire infosec community agrees is terrible. Do not use Telegram.

Use Tor, use Signal.

<comment><USER3> > Worst part of the article: the recommendations at the end.

> The author lists a kitchen sink full of privacy tools including Telegram, > which the entire infosec community agrees is terrible. Do not use Telegram.

> Use Tor, use Signal.

Usability, or lack of annoyances, will always trump security and privacy. Tor is way too slow for most purposes. In my experience, I don't believe it can be a generic mass solution (people in most places around the world already have slow connections - sharing that with others would be the last thing they'd want to do, even though more people running Tor means it gets better, on average, for everyone).

Signal is way too deficient on features and usability compared to Telegram. I want to get out of Telegram and use Signal, but it's at least a few years behind Telegram in various ways (speed, features, lack of good desktop options, relying only on phone number with no usernames or other ways to add/establish contacts, and more). By the time Signal catches up, I believe Telegram would be far ahead again. For messaging and privacy, what would be better to have is a decentralized system that has good usability, multi-device support and can become popular.

<comment><USER4> If you're prioritizing features and usability, WhatsApp is considered more favorably than Telegram.

<comment><USER5> WhatsApp is owned by Facebook.

They almost certainly do not have privacy as a central focus beyond its utility as a marketing bullet.

It's just more embrace, extend, extinguish.

Facebook is doubling down on Messenger. They don't want to support multiple messengers. As soon as they can find a way to convert those pesky privacy- conscious Europeans to Messenger, WhatsApp is dead.

<comment><USER6> They may not do it for the best reasons, but they do have a better implementation than Telegram and, the most important, Watsapp is private by default.

Telling people to move from Watsapp to Telegram nowadays is bad advice. for any point of view.

</comment></comment></comment></comment></comment><comment><USER7> Those who are privacy conscious must first take the step towards self-hosting. They are many interesting approaches that are trying to make self-hosting practical. They make it trivial to run your own mail server, keep your contacts/calendar/files/notes. Why trust yet another mail/cloud company (yahoo, anyone?)? There are promising existing projects out there (like cloudron.io, sandstorm.io, yunohost). Go try them out today. The projects are open source and have issue trackers where you can contribute even if you are not a developer. Such solutions will empower the average person in the future.

<comment><USER8> Self-hosting has a severe metadata tradeoff. Suppose that you and I each self- host a mail server. Now we e-mail each other to talk about how great decentralization is and how much we both hate wiretapping.

With self-hosting and SMTP, there is now a very clear TCP metadata record showing how my home IP address connected on port 25 to your home IP address. Maybe the next day you write back, and there's another nice clear metadata record showing your address connecting to me. Now any ISP between us, and anyone who can tap the ISPs' cables, knows that you and I are corresponding.

If we were both using Gmail, this metadata pattern would pretty much not appear at all: we would each make an HTTPS connection to Gmail and exchange a bunch of data, and while in principle my upload would be matched in size by your download, it would be extraordinarily noisy in many ways and hard to correlate in practice. On the other hand, Gmail would know everything about us.

Having Gmail know everything about us is clearly terrible and not a good privacy solution. However, having all of the ISPs be able to learn our detailed correspondence patterns and relationships is _also_ clearly terrible and not a good privacy solution. So, self-hosting being a clear privacy win for messaging will require a lot of technical improvements on the metadata front. It isn't a clear win in this respect today; it most likely depends on whether you see ISPs (and people who can compromise or coerce them) or Google (and people who can compromise or coerce them) as a bigger risk overall.

<comment><USER9> I feel like using something like TOR would help here: it would create a background noise of other traffic while also providing a way for _other_ users to not have to connect directly to the remote server.

So I ask: is there a way to provide an _optional_ TOR endpoint? e.g. can I have an MX record with high priority that points to a .onion address, and then have a backup (with lower priority) that points to the normal global IP?

<comment><USER8> Currently there is no support for this in MTA software. If it were supported, you could imagine having somewhat better privacy properties for e-mail with other people who also used this particular setup. However, if you simply re- decentralize your e-mail using today's e-mail technology, you won't get those benefits in the short term.

<comment><USER9> Why would you need software for it _in_ the MTA? Use a local resolver with tor's dns option + automapping

</comment></comment></comment></comment></comment><comment><USER10> Largest issue with privacy is that in my experience generally speaking that the average person does not see privacy as a priority, or worse, questions the need for it.

<comment><USER11> There's a third possibility, which is that people are rationally aware that the cost of preserving privacy on the individual level significantly outweighs the benefits most of the time (rather like not buying insurance), and that in any case the technological, economic, and political asymmetries between individual and corporate/governmental actors are so huge that it's pointless anyway.

I use Tor some of the time. I would like to use Tor all the time for everything, but the reality is that using Tor is slow as mud so for 98% of my browsing activities I use Chrome, even though I know I'm giving away a lot of information about myself in the process.

Likewise, I live in a house. I can lock the doors and windows, but the reality is that any determined individual or group could easily kick in the door and enter the house. Do I spend a fortune rebuilding and reinforcing the structure so that I can have a front door like a bank vault, or do I invest a bit of money in simpler security options and cultivate good relationships with my neighbors?

It's not that people don't care about privacy (though not everyone does), but that subconsciously most people realize they can't possibly win an arms race and so opt for greater quality of life at the expense of security.

<comment><USER12> > _" There's a third possibility, which is that people are rationally > aware..."_

I agree that this possibility exists but I also think it's a _tiny_ minority of people online. There's enough info out there to demonstrate that people _aren 't_ rationally aware of many things (although they may believe they are).

In the current example, I'd bet that most folks don't even understand how much info they reveal online and what can be inferred about them. The very reason the house analogy exists is because it's tangible and 'real-world' but it's not really a fair comparison. If people had the option to live in a fortress, that still had windows and easy access for approved people, and didn't look too different, they'd likely take it. Such options either don't exist or are too expensive.

<comment><USER13> This.

Also: peer pressure. As a non-Facebook user, I get questioned about why fairly often, and my family makes passive-aggressive noises about missing pictures and whatnot.

And here, any time this comes up, someone thinks they're being clever by pointing out _other_ intrusive systems of surveillance (like cell phones) that I surely must be unaware of or inconsistent about.

My theory regarding some (certainly not all) people in the latter group are well aware of how much they're giving up and don't like the idea that other people are doing better at maintaining privacy, a bit like the drunk pushing a drink on someone trying to get sober. A lot of other people are simply unaware of the power of the data they're giving up, or believe that since "everybody else does", it can't be that important.

Social cues are really important.

<comment><USER14> Even as a non-Facebook user, if you were to _only_ post on HackerNews all of the time, a lot could be inferred about you. Apparently, the value of sharing exceeds the cost in privacy. There are many types of thoughts of that people would share on the internet, some more revealing than others (e.g. "Today is Friday" vs. "I am 190lbs"). Some people must be very skilled at posting inert content which does not in any way tie to their personal lives, others may not be -- or simply don't care, or believe the sharing value to be very high, etc.

In terms of psychology, UI/UX design and engineered content could try to maximize the likelihood of getting a user to post emotionally-charged or revealing content.

<comment><USER13> Of course. Facebook (or Google, for that matter) isn't magic, just in possession of a really intrusive nose for others' business and the war chest to do something about it.

Detectives, private or otherwise, are sometimes very skilled at doing the same thing in conversation (of course, this is not automated and very expensive). This isn't news.

What is news is the scope and automation. The surveillance-entertainment complex is unhealthily healthy.

</comment></comment></comment></comment></comment></comment><comment><USER15> I found [https://prism-break.org](https://prism-break.org) a good list of software/services helping our privacy.

<comment><USER16> Also:

\- print a letter on a laser printer, drop it off at any USPS pickup box. No return address. Strong 4th amendment protections

\- write in a journal with a pen

<comment><USER15> >print a letter on a laser printer

but be careful, just for a case:

[https://www.eff.org/pages/list-printers-which-do-or-do- not-d...](https://www.eff.org/pages/list-printers-which-do-or-do-not-display- tracking-dots)

<comment><USER17> This jumped to my mind immediately with the laser printer mention!

</comment></comment></comment></comment><comment><USER18> here is a stupid argument for privacy that i just invented based off of the article's mentioning of 1776:

if the british colonists had no privacy, the american revolution would never have happened. troublemakers would have been either nipped in the bud, or never even thought that they could successfully challenge the existing power structure.

what god-fearing amurican is going to argue against privacy when you frame it as a patriotic issue? sure, there's no logic or graceful rhetoric here, but who needs logic when you have emotional arousal?

those of us who have enough brain cells to rub together need to start thinking about how to slam the idiots with arguments they can't get around while maintaining a veneer of nationalism. "you're unamerican if you're against privacy, because we needed privacy to execute the most hallowed event in our civic religion: revolution against the british." that kind of garbage.

it's time to discard clean argumentation and jump into the mud-- it's the only way to make people care about an abstract issue that people have been taught to disregard like privacy.

<comment><USER19> You've just come up with a variation on the theme of "First they came..." [1] by Pastor Martin Niemöller (1892-1984).

> First they came for the Socialists, and I did not speak out—

> Because I was not a Socialist.

> Then they came for the Trade Unionists, and I did not speak out—

> Because I was not a Trade Unionist.

> Then they came for the Jews, and I did not speak out—

> Because I was not a Jew.

> Then they came for me—and there was no one left to speak for me.

The deeper reasons for privacy are historical, political, and ultimately may become a matter of life or death. It wouldn't be surprising, history is full of precedents.

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

</comment></comment><comment><USER20> It would be nice to see the issue of privacy, especially in regards to data privacy, evolve beyond a black and white matter. Privacy is important it allows for a bubble of safety and security in our lives. On the other hand, there is real value and utility through data, but often at the expense of privacy.

I think that the trade-off between the utility of data and privacy can be explored in such a way that everyone benefits. Ensuring a balance of power in regards to privacy between individuals, government, and private entities is a worthwhile, but difficult, venture. Data is a good medium for this discussion because of its increasing value in an age where we're collecting more than we can use. Government and society can benefit from data driven policies and public datasets (ala data.gov). Individuals can regain control and benefit from a collective use of data. Corporations already hold and make profits on massive monopolies of user data, but often liability involved with private data preempts sharing.

I think these kinds of conversations will need to be tackled and absorbed by the wider audience before it can have a real impact. In any case, it will be interesting to see what direction privacy as an issue goes toward. Personally, I will be continuing to be more aware of the issue and use products that have privacy in mind.

</comment><comment><USER21> Why is "very few people care" an argument _against_ privacy solutions? There are so many niche markets in this world. Not everything needs to be a billion dollar business.

<comment><USER22> Its the inverse of network effect.

A few years ago I bought a GPG card and used it to encrypt long term backup media. I created a key, did the whole PGP thing, etc.

It was cool and all, but it's value from a communications perspective is zero. I have about 2,000 contacts that I keep track of... and exactly two had public keys. The value of that network is near zero, because I really don't transmit anything via e,ail that has a high value justifying the considerable hassle.

At work, we have the ability to use Microsoft rights management to optionally encrypt email or attachments. It is easy as pie -- literally press a button. In some cases Outlook will nudge you to do so! With nearly 400M messages, less that 20k were protected, and most of those were for a pilot using policy based encryption.

</comment></comment><comment><USER14> People aren't paranoid enough. Being paranoid carries so much negative stigma, it feels that we are selecting _against_ it. Try to a remember the last time you revealed your paranoia _and weren 't_ a complete buzzkill. But hey, you can fear what you know. You can even fear what you know you _don 't_ know. But you can't fear what you _don 't_ know you don't know!

</comment><comment><USER23> "Missed any? Shoot me a message on Twitter: @bitario"

I don't have a Twitter account, but if the author happens to be reading this (or if anyone wants to shoot a message to him), I use Threema for secure messaging. I love it. But I admit to not having used the others so I can't comment on how it ranks against the competition.

[https://threema.ch/en](https://threema.ch/en) [https://play.google.com/store/apps/details?id=ch.threema.app...](https://play.google.com/store/apps/details?id=ch.threema.app&hl=en)

<comment><USER24> What's the advantage of this over, say, Signal?

<comment><USER25> Is signal previous name textsecure ? Those who dropped SMS support of their secure texting application so now it requires a data plan to be remotely useful.

That's about when Openwhisper / Signal lost me, I'm not gonna trust them with anything anymore. Also worth mentioning that all communication go through a single point of failure central server, it requires a phone number to register and is not available outside the worst privacy offender device: smartphones.

</comment></comment></comment><comment><USER26> The simplest argument for privacy: if the powerful value it, so should you.

<comment><USER27> The slightly more complicated truth: people with power have different problems and threats.

<comment><USER28> True. But then, keeping within the frames of parent's argument, if you want power (you do), you want privacy.

</comment></comment></comment><comment><USER29> Sort of ironic to see bitcoins being hacked away due to lax security with the phone system, too. Ud think after mitnick, it wouldnt be possible, but our leadera today are actively choosing to ignore history's lessons, and we enable them.

Privacy and Security are the battlefields of today, and the wars of tomorrow. It'll hurt Badly when that impending 1984 world rains down on us, very soon. That said, we'll win, eventually. :o)

<comment><USER30> I'm not so optimistic.

I don't believe people will ever get their liberties back when they are finally all taken away. :(

Our naive and apathetic population will find out eventually.

<comment><USER29> Society is a sleeping giant. Aslong as food and shelter are there, people will stay dormant.

But eventually, one of these two things will be taken away. Maybe food. Maybe the security of shelter... Look at North Korea, defectors left and right, despite the horrors. Though ill admit to the difficulty of localities. Horrors can be committed, and sustained, upon a minority, while the majority sleeps, we enable north Korea, but only because it's a local, distant horror.

Bur when the majority is fucked.. The hackers, the rebels, the adamant few WILL fuel the fires of revolution.

But ill admit again to the sophistication of our current system and it's cruelty. It will delay improvement. It's a cat/mouse scenario. We're the cat, and we're sound asleep for now. Trump and the falling apart of the EU will shake the house though. Or maybe they wont, but stench of war is in the air.amd the higher ups, no matter how sophisticated, are only human.

It's important not to give in to desperation and paranoia. Education (math, science, history, art) will help keep the population capable and give them the tools to transform society when the day comes where we must act.

</comment></comment></comment><comment><USER31> It's nice to have a private notes app, my bigger concern is about what happens as the entire ecosystem becomes increasingly monopolized.

Any platform enhanced by ML powered by proprietary data will create huge barriers to entry for potential competitors. Even if privacy becomes important to consumers, app alternatives with have to at least match the mainstream version in 100 other ways. As much as Google has contributed to ML tooling and research, their data will ensure that services like Duck Duck Go stay obscure.

Network effects, economies of scale and the dynamics of VC funding will all exacerbate this as well.

<comment><AUTHOR> You're right in that it's hard to create a new billion dollar privacy company. But there are plenty of opportunities to create "small businesses" focused on privacy. Basecamp sized companies. In fact, that's the advantage small founders have now: is to not be big, but be intentionally small.

<comment><USER31> Yeah, that's true, I do dream of a future where more people are creating toy apps for their friends and family with no intention of scaling. Udacity has strayed a little bit from this with their focus on ML courses, but SMBs are absolutely preferable in my mind.

EDIT: also why I love FOSS.

</comment></comment></comment><comment><USER32> I have in recent months become increasingly aware of this, and have taken steps towards being more private online but I am not completely there yet. Though I do run Linux, stay shy of social media and use Signal for messages, I still lacked a better email provider. (And I am still looking into which VPN to get)

This article was the push that I needed to also finally ditch my old (hotmail) account and switch to protonmail. When you have a lot of communication going on with an email account I feel like the change is not that easy, but it'll be worth it.

<comment><USER3> Last year I looked at various services for email and finally switched to posteo.de. It's cheaper than Fastmail and Protonmail listed in this article, promises privacy and the company has a lot of good ideals and actions that I like.

I needed IMAP and didn't want to be locked in to one provider if I ever wanted to move out (Protonmail's IMAP is just now in beta, more than two years after the request was made by people, and all users are tied to Protonmail because there is no export of all mails or non-Protonmail-app mechanisms to retrieve mail).

The lack of custom domain support in posteo (for privacy reasons - what it calls "data economy") was a concern for me on portability, but it's a compromise I decided to make.

</comment></comment><comment><USER33> It's not that privacy isn't locally good if it could be had, it's that or can't be had, and letting only some people (more powerful) have privacy is actively bad.

Just like we have to prepare for the post labor society, we have to prepare for the post privacy society. It's not about what we'd like to be true, it's about what's actually true.

</comment><comment><USER34> Whenever I ask questions about people's attitude towards privacy they also end up with, I have nothing to hide, and all counter examples are vague and not directly applicable. I'm working on turning the privacy talk around, to frame it around the loss of freedom, Freedom from criminals, Freedom of relationship, Freedom of self expression, Freedom from profiling. We can then explore which freedoms are relevant to the individual and which are not.

Freedom from criminals: Computer systems are not secure. The more we share online the bigger the danger when the data is leaked. A very real concern that is often overlooked is that governments and companies are incapable of keeping our data secure. By collecting addresses, medical data, bank information we are all exposing ourselves to risks of having our identity, money and medical information stolen or to be held for ransom.

Freedom of relationship: Private conversations can be made public, your opinions and interests can be made public without your intention. For example facebook changing their privacy settings suddenly makes your private links shared, or private matters suddenly appear where you don't intend them to be. Like product adverts showing up at work, sharing our private purchases with colleagues.

Freedom of self expression: We loose control of when content goes public. Suddenly our ideas and works can be shared without our consent or credit even without our knowledge. An art sharing site suddenly uses our work in private folders for advertisements because they now have access to them. When uploading on line we lose control of our data and if they are taken there is little recourse.

Freedom from profiling: Decisions are made about you without your direct input affecting the news you see, the products you are advertised, and the prices you are offered. Governments have started placing us on lists along with real criminals based on where we have been, who we have met, and what we have seen. We have no control of the profile that is made on us and we have no access to it.

We, those worried about privacy, can see the overlaps between the loss of freedoms, but by presenting them in these forms it makes for conversations that continue beyond I have nothing to hide. Depending on who I am talking to I can question into which freedom they are comfortable losing and which they are not.

Personally living in a 1st world country with an stable and amicable democratic government my greatest concerns are freedom from criminals and freedom of self expression.

<comment><USER35> Just use Snowdens quote: saying you don't need privacy because you have nothing to hide is like saying you don't need free speech because you have nothing to say.

To be honest, I actually ran a very private setup (Copperhead OS, Protonmail, MacBook with all non-draconian privacy settings turned on) for about 2 years, but in the end I realized I was gaining (almost) nothing compared to just Google's services, and losing a whole lot in terms of ease-of-use and integration. All in all its the same thing with privacy as it is with security: you can create all the good systems in the world, but if its a hassle, you'll run into privacy/security fatigue soon and the whole system becomes moot because you'll be the weakest link and start bypassing your own systems.

</comment></comment><comment><USER36> I really like this stance, I think this argument needs a little more sharpening so that it generates action from people who not in our bubble outside of the tech scene.

</comment><comment><USER37> Really enjoyed this post, seriously, thank you.

</comment><comment><USER38> Does anyone know what the title image comes from and/or why it's relevant? I really like it!

<comment><USER39> It's the cover art to an edition of The Martian Chronicles. See:

[http://www.michaelwhelan.com/galleries/descent/](http://www.michaelwhelan.com/galleries/descent/)

</comment></comment><comment><USER40> Civilization is the progress toward a society of privacy --Ayn Rand</comment>


How Elon Musk Learns Faster and Better Than Everyone Else - <AUTHOR> https://medium.com/accelerated-intelligence/learn-like-elon-musk-fe8f8da6137c <comment><USER2> There are plenty more polymaths than there are billionaires. There are even more people that work 80+ hour work weeks.

Face it: there is no one reason that someone rises to that level of success. And if your model for achieving that success doesn't include a statistically improbable amount of luck, then your model isn't worth the time to explain it.

All of these efforts to explain that level of success put up a delusional impression that there is some set pathway, some formula, to achieveing it. There's not.</comment>


Show HN: RainBar – Background rain for the desktop - <AUTHOR> https://lockyy.com/posts/os-x/rainbar-raining-on-the-desktop

<comment><USER2> This looks cool - any chance you'll release a pre-built version?

<comment><AUTHOR> I've attached a link to a prebuilt version at the bottom of the post, you can get it here [https://github.com/Lockyy/Rainbar/releases/latest](https://github.com/Lockyy/Rainbar/releases/latest)

<comment><USER2> Derp. Thanks!

<comment><AUTHOR> Glad to help! Hope you like it.</comment></comment></comment></comment>