The Forged 'Ancient' Statues That Fooled the Met's Art Experts for Decades - <AUTHOR> http://www.atlasobscura.com/articles/etruscan-forgeries-met-museum-art <comment><USER3> This reminds me of one of the very best pieces of television I ever saw: BBC's Horizon documentary about The Mystery of the Persian Mummy: [http://www.bbc.co.uk/science/horizon/2001/persianmummy.shtml](http://www.bbc.co.uk/science/horizon/2001/persianmummy.shtml)

The first half is breathless excitement on the part of historians who believe they've found an artifact that changes their understanding of an ancient culture, then it suddenly pivots into a murder investigation. Gripping stuff.

</comment><comment><USER4> There's an interesting small exhibit in the Frick Fine Arts Building at the University of Pittsburgh. In it, there are several copies of Italian masterpieces. The artist, Nicholas Lochoff, was commissioned by the Russian government in 1911, to go to Italy and produce near perfect replicas of the art to be sent back to Russia for display and viewing. According to the histories, he worked so meticulously that only a handful of the copies were sent back by the time of the Russian Revolution in 1917. He was then unable to return to his home country and cut off from financial support, he started to sell off these paintings, almost the entire collection of which is now in that building.

In the same area, there are two completely original statues made in the style of 14th century Italian marbles. They aren't copies at all, but were made in the early 20th century by Alceo Dossena. Dossena sold his works through an art dealer who unscrupulously sold them off as original 14th century works, some of which ended up in museums. When Dossena found out about this, and discovered the vast sums they were sold for (compared to what he earned) he publicly revealed the situation and sued his dealer.

Here's a picture of some of the area in the building including the statues [https://upload.wikimedia.org/wikipedia/commons/c/c7/Frick_Fi...](https://upload.wikimedia.org/wikipedia/commons/c/c7/Frick_Fine_Arts_Building_- _Pitt_-) _IMG_0767.jpg

What I found really fascinating is how this one exhibit really challenged ideas of authenticity in art, what was a legitimate copy, what was illegitimate, what was passed off as original and so on.

<comment><USER5> _In it, there are several copies of Italian masterpieces._

I've often wondered why museums and universities don't do this more often. Make up a list of the 50-100 most important works of art in the western canon, make really great copies of all of them and distribute them to museums around the world so that more people can actually experience these works for themselves. The only option today is to either look at tiny photos of the works (which is a terrible way to study and appreciate art) or to spend a massive amount of time and money traveling the world (which is totally unrealistic for most people).

</comment></comment><comment><USER6> A related aside: while forgeries - deliberate imitations to mislead and deceive - are exciting, they only represent a very tiny portion of art attribution questions. In reality, these tend to deal more with discerning between artists working in the same period, rather than those attempting to fool the eye at several centuries' remove.

For example, the Rembrandt Research Project infamously set out to identify genuine vs. fake Rembrandt paintings in his corpus of known works under the false assumption that there would be a lot of 18th/19th/20th century forgeries. In fact, most of the "non-Rembrandt" cases they found were not later imitations, but instead works done by his own students or contemporaries - or works co-produced by Rembrandt and another. The result - <USER2> the project's original false assumption - proved revolutionary for our understanding of artistic studio practice from the period, but failed to locate many "forgeries" as such.

A review (paywalled, sorry!): [http://www.sciencedirect.com/science/article/pii/02604779899...](http://www.sciencedirect.com/science/article/pii/0260477989900228)

And a Met exhibition: [http://www.metmuseum.org/art/metpublications/Rembrandt_Not_R...](http://www.metmuseum.org/art/metpublications/Rembrandt_Not_Rembrandt_in_The_Metropolitan_Museum_of_Art_Aspects_of_Connoisseurship_Volumes_I_and_II)

</comment><comment><USER7> Anecdotal: I had a literature professor that would relate the time he was at the Louvre and a crazy guy pulled out a knife and dashed for the Mona Lisa (this is before it was behind glass) - they were able to grab the man before he damaged the painting. Since then he ceased to believe in the authenticity of the art in musuems.

<comment><USER8> I've been peripherally involved in the restauration of a Mondriaan after it was damaged by some knife wielding idiot and I can guarantee you that the art is real.

<comment><USER7> >I've been peripherally involved in the restauration of a Mondriaan after it was damaged by some knife wielding idiot and I can guarantee you that the art is real.

After which the display was permanently replaced by a copy? ;)

More seriously, though I don't say I believe it, surely it is an interesting point. For example when I visited the Palazzo Barberini in Rome, there were maybe a dozen other visitors total, one musuem worker per ~ 4 halls, and nothing was under glass.

How sure are you of your ability to distinguish the original from an expert fake? The Met's experts apparently couldn't for decades. I'd wager the number of people in the world that can tell a real Carvaggio from an expert forgery number in the double digits.

<comment><USER8> I'm sure that's true. But considering there are 100's of employees in your average museum and such a conspiracy would require just about all of them to be in on it I don't see how it could be kept a secret.

There are fakes in museums, but those are actual fakes where the museum isn't in the know either. Estimates run as high as 20(!)%.

But a museum that would have an exact duplicate of the art on display for the majority of their art would be incapable of keeping that a secret and likely would not be looked at favorably.

FWIW I was good friends with the ex-curator of the Rijksmuseum in Amsterdam and have visited their vaults, and have been behind the scenes in the Tate Gallery in London. The only thing I've been able to establish with any certainty is that at least those two museums have far more art than they could ever display and that I'd hate to see their insurance bills.

I did not come across an army of master forgers working hard to make new old works or copies of works which I knew were on display.

<comment><USER9> > _I 'm sure that's true. But considering there are 100's of employees in your > average museum and such a conspiracy would require just about all of them to > be in on it I don't see how it could be kept a secret._

Actually such a "conspiracy" wouldn't require more than a few to be on it. Why would the guys guarding the spaces, or the people selling tickets and merchandise, the cleaning staff, the canteen workers, the secretaries, etc need to be "on it"? Those are the majority of the "100s" of workers.

Just the director, a few of the people in the administration, the curators, and the ones putting up the paintings (or, actually, not even them).

<comment><USER8> And the insurers, the people that move the real paintings around, the people that store the real ones and so on.

It's about as likely as a faked moonlanding. But then again, those too have their believers.

<comment><USER9> > _And the insurers, the people that move the real paintings around, the > people that store the real ones and so on._

So, like 10 people? And even if it was 20 or 100 what's the great rush to expose this? It's just something you don't talk about. It's not even that interesting.

We have crews of 1000s of people not leaking tv series and film plots.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Orson Welles's last movie was a pseudo documentary on forgery:

[https://youtu.be/gIVgUjj6RxU](https://youtu.be/gIVgUjj6RxU)</comment>


Taking the 'D' Out of CRUD with Soft Updates - <AUTHOR> http://scottsmerchek.com/2015/08/04/taking-the-d-out-of-crud-with-soft-updates <comment><USER2> There was a very interesting presentation this year at PGConf New York with something similar [1], but where the history table has the _same name_ as the normal table, but lives in a separate history schema. Also there is a timetravel schema whose tables again have the same name, but are views of the history schema, with an extra WHERE filter to only show rows that were active at a given time. So by changing your schema_search_path and setting the "current_time" setting you can easily query the whole database as if it were some other time! I haven't tried this out yet, but it looks to be very compatible with an ORM like ActiveRecord. This is something I've been looking for for a long time.

[1] [http://www.hagander.net/talks/tardis_orm.pdf](http://www.hagander.net/talks/tardis_orm.pdf) (pdf)

<comment><USER3> That seems like a really clean way of building the abstraction.

Are the only downsides the overhead of writing to the extra schema and the space required? Anyone know how bad the hit would be for the writes?

With this setup it seems like you don't lose much by trying it. No interruption to the current db, you have the extra data if you want it, you can always cull to free up space and you can remove the whole thing at any point.

Or am I missing something?

<comment><USER2> I agree it seems pretty great.

One big pain point would be if the schema changes over time. What if you add a new NOT NULL column? What if you remove a column? What if you change the type of a column? What if you remove a table? What if you add a new CHECK constraint? Some of these things get mentioned in the video linked by 'tvon, but they are mostly passed over.

<comment><USER3> That's a good point. I guess in terms of the constraints you wouldn't mirror those to your history schema anyway?

The changing schema is not so easily solved. Again, you could be a little looser with it. Don't remove columns from the history table (just mark as nullable). Adding columns would be a similar thing.

I guess I'm thinking of the use case of wanting to get a bit of extra history of free vs the "needs to be auditable, 100% correct, user queriable" scenario.

</comment></comment></comment></comment><comment><USER4> He is talking about Effective Dating except in his version he can never use it. If you don't need to reference past for future dates then his idea is nice since it keeps the primary tables smaller and the SQL easier to handle.

Effective Dating: [https://talentedmonkeys.wordpress.com/2010/05/15/temporal- da...](https://talentedmonkeys.wordpress.com/2010/05/15/temporal-data-in-a- relational-database/) [http://www.cs.arizona.edu/~rts/tdbbook.pdf](http://www.cs.arizona.edu/~rts/tdbbook.pdf)

I did a college project with this where you pick the data and the system will show you how the database looked at that date/time. The past was read only, but the future was editable. The SQL Selects are quite annoying and the data grows very fast.

<comment><USER5> I personally believe that the majority of CRUD projects actually need Temporal databases. I've come to realize that--in my 12 year career--every project I've worked on was in some way covered by at least one form of government regulation (whether Sarbanes-Oxley or HIPAA) that required the ability to audit change. The problem is, most organizations (at least the ones I've worked for) don't know that they are covered by these sorts of regulations, because most places are sub-100 employee consultoware shops that are just reimplementing ERP for small B2B clients who also don't have much visibility on their regulatory coverage.

That's not even getting in to user requirements. Users almost always eventually want to know what the past data looked like. They always say at the outset of the project that they won't need it, and they always change their mind a year in. And they never understand why you can't "just get it back. You said we had backups."

It's kind of the Wild West out there.

<comment><USER6> Commenting to voice my agreement. Modeling and querying temporal schema in a traditional RDBMS is difficult so most developers don't even try to do it (and, when they do, they do it badly).

<comment><USER5> Yep, that's exactly right. So many shops live and die off of new college grads who--at best--only know relational algebra and nothing about optimization. I've seen a rare few people coming out of college who could design a schema that didn't completely destroy their data, but it's been rarer still to see anyone of any experience level in that environment who knows anything about making it work in a performant manner.

</comment></comment></comment></comment><comment><USER7> Another approach that is often used for these things is now generally referred to as Event Sourcing. You'll see it mostly associated with Domain Driven Design (DDD) and Command Query Responsibility Separation (CQRS), however it is a technique that has been widely used for decades prior to either of those terms being made popular.

In particular, it has been used in banking applications for quite a long time.

<comment><USER8> While I use event sourcing w/ Akka persistence, I find it is not a panacea for the problems that the blog post may reference. I find that oftentimes people store the resulting state in memory which may become unwieldy. And if you're storing it on DB/disk (not to be confused w/ storing your events/snapshots) you're basically back to the way traditional CRUD works except you have a stream of events if you need a new data structure from scratch. Also, many times event sourcing offers eventual consistency which, while it is obviously preferred to develop your app that way for scalability reasons, not all apps can do that and need atomic state.

<comment><USER9> For atomic updates we implement this via CAS-like semantics. A caller who obtains a point-in-time aggregate view of an object (equivalent to the 'R' in CRUD) is also given the sequence number of the latest event. They can then conditionally push new events into the object's queue and request a rejection if the current sequence id is not equal to the one they have. Since we use Redis for the queue, the event pushes have a consistent view of the queue at the time of the attempted push.

<comment><USER8> While scalable, this basically turns it to bidirectional by adding a side- channel for conflict resolution which can add system complexity. This is why many event sourcing approaches recommend making the event represent the mutation (e.g. count + 1) instead of the result (e.g. count = 15)...when it does have to be atomic, I just give up and use a centralized place like you have with Redis. Such is life with atomic, distributed systems...they can only be so distributed and still reject conflicts in real time.

<comment><USER9> Most of our events do in fact represent the state change as the mutation.

However I see no complexity issue with how we implement CAS semantics. Its 100% equivalent to any other implementation with all the implications -- reduced concurrency being the primary issue.

We avoid this at all costs for most objects and, like you suggest, resolve conflicts by de-duping events or combining state changes to the final aggregate.

</comment></comment></comment></comment></comment><comment><USER10> I've used this approach, but although there are pros and cons I come down against the idea of using triggers to record the history records.

Triggers make things happen sort of "by magic" and it's easy to be confused by their behavior and how they impact transactions. You also need to remember to disable them if you ever want to do some kind of bulk update/correction that you _don 't_ want recorded in the history.

My approach is to use stored procedures for the updates, and make the history tracking explicit in that code. Overall this is easier to manage, with fewer gotchas.

<comment><USER11> How do you deal with future developers acting on the table? Triggers ensure that later on I don't develop some new code and forget to update the history (and does all your code deal with inconsistent/damaged history).

Perhaps if you're using some sort of abstraction layer then you can make sure that only developers who've read the docs and are aware of semantic links between tables which aren't enforced by the database then this can be mitigated?

</comment></comment><comment><USER12> We do the same thing except we don't keep the version number in the main table since we have no reason to ever display that unless we're looking at the history anyway. We have a history table with two JSON columns representing the before and after state, so we don't need to keep columns in sync. (Technically the before state might be redundant, but it makes comparisons simpler). I really like this idea of using triggers, though. We handle it at the ORM event level so the DB isn't entirely self-sufficient.

There have been many times where having the version information has helped us to debug and fix problems. We've had customers call us, freaking out because they accidentally deleted something, or confused because somebody else in the company changed something. We can tell them exactly when, what and by whom the data was changed and easily restore it.

</comment><comment><USER13> It'd be nice if we could see a Postgres patch that works exactly like Oracle's Flashback [1]. You can simply do: SELECT * FROM TABLE AS OF '2015-07-01 08:05:04' and it works as expected.

This article is just reinventing Kimball's Slowly Changing Dimensions Type 4 [2].

[1] [http://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_...](http://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm)

[2] [https://en.wikipedia.org/wiki/Slowly_changing_dimension#Type...](https://en.wikipedia.org/wiki/Slowly_changing_dimension#Type_4)

<comment><USER14> Postgres used to have timetravel built in, but there's still a basic timetravel implementation in the contrib: [http://www.postgresql.org/docs/9.4/static/contrib- spi.html](http://www.postgresql.org/docs/9.4/static/contrib-spi.html)

</comment></comment><comment> bink-lynch We implemented a "point-in-time" database architecture to accomplish similar behavior based on this document:

[https://www.simple-talk.com/sql/database- administration/data...](https://www.simple-talk.com/sql/database- administration/database-design-a-point-in-time-architecture)

The article describes two columns, dateEffective and dateEnd. If dateEnd is null, the row is still effective. When the row has been updated or deleted, the dateEnd field is set.

This was implemented in a regulated industry where we had to show the state of the system at given points in time. It worked well for this purpose.

</comment><comment><USER15> During 2004-5, I designed and implemented a K-V object store on the top of BerkeleyDB. It served as the persistence layer for a number of applications my then company developed for regulated industries.

The approach was very similar. The current versions of objects were stored in a set of tables, while old versions were stored in separate tables. In order to reduce bloat, I employed a few fairly simple compression techniques. They were reasonably good. On desktop-class machines with a Pentium processor, 256 MB of RAM and spinning hard disks, searching a million objects completed in single digit seconds.

Later, I added bit-mapped indices with dynamically self-adjusting bucket sizes that were determined based on locally-weighted densities along their respective dimensions. They reduced search time on a million objects to tens of milliseconds, with full history searched.

The obvious downside was that there was no SQL for ad hoc queries! So, a command line shell was provided with Ruby as the language, talking to a C API behind the scenes.

All in all, the system worked and scaled very well.

</comment><comment><USER16> I don't understand what the 'version' column is for. You can get the sequence by just looking at the 'version_on' attribute. Deletes are already restricted on that table and it wouldn't solve concurrency issues since it's generated by the trigger.

<comment><AUTHOR> Concurrency issues can be solved by restricting the UPDATE to the version passed in by the application.

If I think I'm updating version 2 of an entity, then only update that version, otherwise throw an error.

I've updated the post to address this scenario.

<comment><USER16> I don't see the update in the post. If you pass the version in an UPDATE statement it will get overridden by the trigger.

 _NEW.version := OLD.version + 1;_

<comment><AUTHOR> The version is part of the WHERE clause in the UPDATE statement. Therefore, it is only possible to update the version of the entity that you were updating. If the entity is updated before your statement, it would not succeed in updating the row.

Is there a different concurrency issue I'm not seeing caused by updating the version in the trigger?

<comment><USER16> Yes, you're right. I didn't notice the WHERE in the UPDATE statement. That makes a lot more sense now, thanks!

You still have the issue of someone setting the version explicitly in an update statement without a WHERE clause which checks for the current version. But I guess as long as you enforce not doing that it's fine.

</comment></comment></comment></comment></comment><comment><USER17> I rarely do a D in prod. I've built a generic trigger function for postgres and proc for sql server that will do the auditing in K-V format on every table.

And I call a proc to add the stuff to the table to create the audit tables and triggers.

Works well. I also capture information like the host and session references in an audit batch record that points to the audit detail.

I also employ the insert only table for some very special datasets where looking up the history in a quick manner is important.

</comment><comment><USER18> Completely offtopic, but the site loads 1.1 MiBs worth of a grinning man at a resolution of 2446x2446, which is then rendered as an icon at 91x91 pixels.

<comment><AUTHOR> Totally noticed this in google analytics, earlier. Whoops. It's now fixed!

</comment></comment><comment><USER19> I do something similar because we have drafts (first drafts and drafts of existing records) in our system. My question is whether there is any downside to maintaining drafts and historic revisions in the same table opposed to maintaining it in a separate table as the OP does. Thoughts? Bloat and table optimization come to mind as potential problems, but it does make it easier to query for records.

</comment><comment><USER20> Could you get rid of the is_removed column again (by copying the delected row to the history table) so the main table again has only the currently active rows and simplify queries? (Moot if both tables are merged and views are used as suggested by others.)

Is it common to name timestamps _on, like version_on? That doesn't seem very clear to me. What's the rationale?

</comment><comment><USER21> Oh, please, my eyes hurt so much. Please, please, please change that "WHERE boolean_column IS FALSE" to "WHERE NOT boolean_column". Thank you ;P

</comment><comment><USER22> the problem seems only half solved - the author does not show how they select (only) the most recent record.

as soon as the app needs to generate a list of f.e. active users, this can get nasty pretty quick. sure, one could use an aggregate like max(version), but once there are joins or lots of records involved, this could become a performance hit...

EDIT: the records are kept in a separate table, so my arguments are moot.

<comment><USER23> Why? They're modifying the main table, which isn't growing with each update. The changes are simply tracked in the history table.

<comment><USER22> oh right. small but important detail... thanks for pointing it out to me.

<comment><AUTHOR> Valid question though, I've updated the post to be more explicit and added a couple more query examples.</comment></comment></comment></comment>


8 Grams of Thorium Could Replace Gasoline In Cars - <AUTHOR> http://hardware.slashdot.org/story/11/08/12/172229/8-Grams-of-Thorium-Could-Replace-Gasoline-In-Cars

<comment><USER2> This is fake or a scam!

There are same interesting quotes in the original article: <http://wardsauto.com/ar/thorium_power_car_110811/>

First, this is not a nuclear reactor: (at the end of the article)

       This means no nuclear reaction occurs within the thorium.
      It remains in the same state and is not turned into uranium 233,
      which happens only if thorium is sufficiently super-heated
      to generate a fission reaction.

It says that thorium has a lot of energy, not that they can extract it: (in the middle of the article)

      Because thorium is so dense, similar to uranium, it stores
      considerable potential energy: 1 gm of thorium equals the energy
      of 7,500 gallons (28,391 L) of gasoline Stevens says.

And the explanation of how it works doesn't make any sense: (at the beginning of the article)

      The key to the system developed by inventor Charles Stevens,
      CEO and chairman of Connecticut-based Laser Power Systems,
      is that when silvery metal thorium is heated by an external
      source, it becomes so dense its molecules give off considerable heat.

The entire story sounds very similar to the presentations of the perpetual moving machines, or the cold fusion: a promise of a lot of cheap energy, but not a working prototype that produce more energy that it consumes.

</comment><comment><USER3> Actually, there's a great reason why large, resource-constrained countries like China have declared that they will begin developing thorium-based nuclear energy - the technology has the potential to be clean and safe.

Thorium is great because to generate a reaction, you also need that energy input (a laser). There's no chance for a meltdown because if the power turns off, you lose the laser and the reaction stops dead in it's tracks.

Thorium was abandoned mostly in the 60s because governments wanted uranium- based technology with it's nasty by-products (namely, plutonium for bomb production!). So, arguably the better, cleaner thorium technology was abandoned. Such goes geo-politics during the Cold War!

Don't discount the small-scale applications in a car or other vehicle either. It's 50 years away, but a thorium-based small-scale reactor is possible.

<comment><USER2> There is some research in thorium reactors, but they work in a very different way.

The thorium reactors are _fission_ reactors. The process is a little more complex, but eventually the atom split and gives a lot of energy. It doesn't need any heat to produce the nuclear reactions. (Some projects uses molten thorium salts, but it is for _mechanical_ reasons, not for _nuclear_ reasons.)

There is also research in _fusion_ reactors, for example with deuterium or tritium. It is a very different process. They need a lot of heat to make the atoms collide and produce the nuclear reactions. (Some models use laser to heat and contain the atoms.)

The two types of reactors are very different, and the fuels can't be interchanged. So it's very strange that they use lasers to heat the thorium.

</comment></comment><comment><USER4> Radioactive cars? What could possibly go wrong?

Joking aside, it's a neat idea, but from the article it sounds like the kicker is this:

"Stevens admits that his biggest hurdle isn't the thorium and laser aspects of the system, but the mini turbines which have to be made small enough to fit inside a vehicle while generating enough electricity"

<comment><USER5> Mini turbines are going to be expensive. High rpm turbines have to be pretty damn close to perfect not to fly apart. Not only that, they are very noisy. I hope they can engineer their way out of the hurdles they are going to come across.

If they can put these in cars, maybe they can be put in homes too.</comment></comment>


Ask HN: Is there a vscode extension as solid as Sublime SFTP? - <AUTHOR> Remote editing is a very large part of my coding routine, and Sublime SFTP is  an awesome answer to the problem of editing locally, but syncing with a remote server on save.  The VSCode extensions I've tried don't seem to work as well.  Anyone have a favorite solution to this?  The main problems are not wanting to embed passphrases in config files, and not syncing on save reliably.  There are some other parts of VSCode that I really like though, so it's tempting to dabble. <comment><USER2> would rmate for vscode ([https://github.com/rafaelmaiolla/remote- vscode](https://github.com/rafaelmaiolla/remote-vscode)) be any use?

</comment><comment><USER3> Not an extension, but sshfs?</comment>


Chinese man changes road markings for faster commute. Real World hack? - <AUTHOR> http://www.scmp.com/news/china/society/article/2122252/chinese-man-repaints-road-markings-make-his-commute-quicker <comment><USER2> Link goes to a scam warning page on android.</comment>


Microsoft: "Android is free like a puppy" - <AUTHOR> http://gizmodo.com/5446513/microsoft-compares-android-to-an-adorable-puppy <comment><USER2> And Windows Mobile is free like the plague...

</comment><comment><USER3> Puppies grow up.</comment>


Virgin Trains USA, formerly Brightline, files to go public - <AUTHOR> https://www.miamiherald.com/news/business/article221806725.html <comment><USER2> On behalf of the UK I apologise to anyone inflicted by virgin trains</comment>


"Everyone Will Be Profitable Except Facebook" - <AUTHOR> http://web2.sys-con.com/node/964895 <comment><AUTHOR> And then there are things like this: "MySpace: Yes, Facebook Kills Our Traffic, But At Least We Make Money!" [http://www.businessinsider.com/2009/1/myspace-yes- facebook-k...](http://www.businessinsider.com/2009/1/myspace-yes-facebook- kills-our-traffic-but-at-least-we-make-money-nws)

There should be some browser plugin so that when you're reading an article with data from a particularly clumsy analyst or journalist, errors like this are highlighted.</comment>


Questions I'm asking in interviews (2013) - <AUTHOR> http://jvns.ca/blog/2013/12/30/questions-im-asking-in-interviews/ <comment><USER2> Note: Article is from 2013.

Discussion from when it originally appeared:

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


Academic Torrents, a distributed system for sharing enormous datasets - <AUTHOR> http://academictorrents.com/ <comment><AUTHOR> I find amazing such a huge compilation of datasets. It's great to train and learn how to manage fat data.</comment>


Google Ends Support for Glass Explorer Edition - <AUTHOR> https://www.engadget.com/2019/12/06/google-ends-support-for-glass-explorer-edition/ <comment><USER2> The Google Glass is (almost) dead. RIP in advance. Long Live the Apple/FB/Snap Inc/North AR Glasses!</comment>


Regional Rapid Transit for the Bay Area - <AUTHOR> http://www.jakecoolidgecartography.com/regional-rapid-transit-bay-area.html <comment><USER2> I have a copy of the U.S. Army Corps of Engineers master plan for the SF Bay Area, 1960-2020. It's a slip case of documents and maps.

Highlights:

\- Five freeways up the Peninsula - US 101, I-280, Skyline (CA 25), Pacific (CA 1), and one out in the bay on stilts.

\- Another Bay Bridge at Candlestick

\- Possible second bridge to Marin - Alcatraz-Angel Island-Tiburon route.

\- Fill in everything south of the Dumbarton Bridge to make new land.

\- The north bay was to be for heavy industry. To support the Mare Island shipyards, Marin County to get steel mills.

\- The peninsula was for "business machines". They got that right.

<comment><USER3> All of that sounds great - but what's the ecological impact of infill for Dumbarton and south areas?

Sounds like it'd never pass with today's impact awareness.

<comment><USER4> Nothing passes in the Bay Area with todays attitude. There will never be good transportation here because too many don't want anything to change near them (which is ironic living in SV).</comment></comment></comment>


Spectrum is joining GitHub - <AUTHOR> https://spectrum.chat/spectrum/general/spectrum-is-joining-github~1d3eb8ee-4c99-46c0-8daf-ca35a96be6ce <comment><USER2> I didn't know Spectrum until today. It looks similar to Gitter.

As I understand it, it means we now have at least three "slack-like", well- backed, open-source, community-centered chats: \- Gitter, now owned by GitLab; \- Spectrum, now owned by GitHub; \- Mattermost, independent, but fully integrated within GitLab.

That's great to have credible alternatives to the proprietary behemots that are Slack, Discord and others, but I wish they were able to federate somehow, so that as a user, I don't have to have an account and a browser tab on each instance of each platform, with slightly different user interfaces and features (in addition to my IRC client).

I remember there was a suggestion for Gitter to use the Matrix protocol at some point, but it doesn't seem to have gained much traction. That would be so awesome to have all of them using it, so that one could keep all their discussions in the same place (eg. same mobile application, same user-chosen chat client…).

<comment><USER3> I like Gitter, the Scala community is on Gitter.

However I wish they'd fix their IRC bridge, which has some issues, like not reporting the full list of users, which is driving me insane.

Speaking of Slack-like, the best alternative remains in my opinion good old IRC. I'm a user of [https://irccloud.com](https://irccloud.com) for always-on presence on IRC and it has better clients than Gitter.

<comment><USER4> Personally I'm really annoyed with Scala community's obsession with Gitter. It's such an inferior tool.

Gitter search UI is the worst, and search itself is useless, often returning no results when you can spend an hour scrolling to find what you want manually.

This is inexcusable when Gitter is your project's de facto Q&A place instead of more structured places like StackOverflow or Github issues.

And so the users are left with a messy stream of collective consciousness that is impossible no search or navigate effectively.

<comment><USER3> Chat works better than forums.

Speaking as a library maintainer, I've got GitHub issue that stayed there for _months_ before I replied. That's because my time as a contributor is very limited and I get fatigue when replying to too many support tickets.

And you'd think, oh wait but there are other people willing to reply. But not really. Forum, email groups, even StackOverflow only work when the projects you're talking about are insanely popular.

This is because of two reasons:

1\. people with problems are bad at describing those problems — this is why StackOverflow answers often don't answer the freaking question, but rather try to guess what the author wanted, a trend that's driving me insane, because I often want the answer to the question being asked and not something else; whereas on a chat channel, people have conversations, which helps clarify the intent

2\. people are afraid of being wrong; but chat is more casual, so in my experience more people end up participating

Chat has other benefits. You can have off topic conversations, you can make jokes, you can make friends. I do wish Gitter had threaded conversations. They promised it at some point but nothing came of it.

Also, I do like Discourse ([https://discourse.org](https://discourse.org)). It does a good job to mix some chat features with forums. Scala has Discourse forums, like for example [https://users.scala-lang.org](https://users.scala- lang.org) ... but the Scala Gitter channel is way more popular.

And one final thought: I know communities that have virtually no meaningful online presence. You might be annoyed at our choice for using Gitter, but at least you've got some chat channels to go to.

<comment><USER5> > Chat works better than forums.

I've never had much satisfactory help from chat. I think I've never quite understood the social element of it. Do I wait for a pause? Do I make friends first? Just ask my question and wait?

Ask a question and hang around for half hour to see if anyone replies?

And in the meanwhile 6 different conversations, statements, off-topic chats and other noise is scrolling past me completely ruining any focus I had.

I find them utterly hateful things when I'm in problem-solving mode. Maybe they are more fun when you're in a "sort of working" mode but that's not when I need help.

<comment><USER3> Gitter sends you an email when you're being mentioned.

Our experiences are wildly different.

On Gitter, on the channels I hang out, I think I got answers to my problems in 99% of cases.

</comment></comment></comment></comment></comment></comment><comment><USER6> I spent a fair bit of time trying out many of the different chat systems out there for our tech community. In particular I looking for solutions that could do a half decent job of combining synchronous as well as asynchronous communication. The main benefit of implementations that manage to pull this off is being able to handle real-time chat but also make it easier to catch up with the conversation history if you've been away from the conversation for a while. Other criteria I was looking for were sensible threading, mobile friendly, persistence of history and private channels. Integration with voice or video chat was a bonus.

Amongst others I tried: Mattermost, Rocket.chat, IRC(Cloud), Gitter, Discord, Slack, MS Teams, Twist, Hangouts Chat.

Two stood out, both open source (Spectrum wasn't when I started looking):

Spectrum: [https://spectrum.chat/](https://spectrum.chat/)

Zulip: [https://zulipchat.com/](https://zulipchat.com/)

These two along with Twist (proprietary) manage to deal with the threading and hybrid sync/async. Both the above also have exceptionally helpful people behind them.

The other special mention goes to Matrix ([https://matrix.org/](https://matrix.org/)) and Riot ([https://riot.im/](https://riot.im/)) as their persistence syncing and federation work is impressive. Their threading and hence async story isn't as well developed yet though ([https://github.com/vector-im/riot- web/issues/2349](https://github.com/vector-im/riot-web/issues/2349)).

<comment><USER7> Slack has threads. I don't know why nobody knows this. And unlike Zulip they aren't mandatory, which is a bit nicer for small channels.

<comment><USER8> I think plenty of people knows Slack has threads. Threads in Slack are secondary and are mostly meant for having conversations that people don't care about. Zulip has a much superior threading model. Each and every conversation is a new thread and has a topic. This model makes it extremely easier to catch up and participate in conversations. Once you get used to the threading model of Zulip its hard to tolerate threading model like Slack which is really inefficient and time wasting.

<comment><USER6> > Once you get used to the threading model of Zulip its hard to tolerate > threading model like Slack which is really inefficient and time wasting.

This!

I got a bunch of our community to try out many of the different chat systems out there. Zulip was an interesting one as there were two points that really changed their perception of it as a platform:

1\. When they were told there was a "Night Mode" \- aesthetics are important! (something Slack arguably got right, IMHO beyond that it's just fancy IRC).

2\. After around 5-10 minutes of playing around the penny drops as to why the stream and topic "zooming" is implemented in the way is it. Usually a "Holy Cow" moment.

Once you "get" it, going back to anything else feels like going back in time.

</comment></comment></comment></comment><comment><USER9> I quite often take a look at the code of Spectrum: [https://github.com/withspectrum/spectrum](https://github.com/withspectrum/spectrum).

It's my go-to (with [https://github.com/Automattic/wp- calypso](https://github.com/Automattic/wp-calypso)) to get an idea of how they solved a particular issue in their React app.

I'm really thankful to them for open sourcing their product. I wish more companies would go this way.

Anyway, congratz to Max (also author of Styled Components) and the rest of the team!

<comment><USER10> Thanks for the kind words! For reference, we open sourced everything back in April: [https://spectrum.chat/spectrum/general/announcement- spectrum...](https://spectrum.chat/spectrum/general/announcement-spectrum- goes-open-source~556b4915-7269-46a7-96e6-f38446d14146)

</comment></comment><comment><USER11> I had to read the title multiples times to truly believe what I was reading.

« Microsoft is Acquiring Spectrum through GitHub ».

Regardless of what the title says this is what my brain keeps reading.

At first it seems like a nonsense, but after all it makes perfect sense.

Microsoft must repay the inversement in GitHub, it was an expensive acquisition. Best way to do this ? Probably to bundle GitHub Enterprise with Spectrum.

It makes sense as GitLab have Gitter but GitHub has nothing to manage communities.

<comment><USER12> I wonder if there is any tool to help correlate sequences of events in the news like this. So much of understanding this is understanding the Microsoft acquisition of Spectrum. It feels like you have to have a constant memorized list of what happened to everyone in at least the last 5 years to understand why something happened, and then try to correlate it to other peoples' strategies. Would be nice to have a little timeline of events related to each "entity" so that you could see all the connections.

</comment></comment><comment><USER13> I really like Spectrum, I tried to get other people to join it but my "friends" are always stuck on Discord and Reddit. So finally, I only lurk it occasionally.

However I don't understand why GitHub would acquire Spectrum: what do they have to win from this? Doesn't GitHub already have their own "forums" for communities per Git org?

I tried to use these git forums/board ([https://github.com/orgs/lnug/teams/](https://github.com/orgs/lnug/teams/)), sadly it never ever really get going... I also blame GitHub's notification system which is absolutely badly implemented and confuses new-comers.

Back in the day we hyped-up and used Gitter for our community ( [https://gitter.im/lnug](https://gitter.im/lnug) is where I am at ). Now I wonder, is this why GitHub would want to buy Spectrum? To show GitLab they also can do community threaded discussions a-la-IRC ?

I am confuse, friend.

<comment><USER14> I don't know of any forums built into GitHub? They have issues and the wiki, but that's as much as I've ever used/heard of.

<comment><USER13> Here is a edited screenshot for reference: [https://i.snag.gy/MYzudj.jpg](https://i.snag.gy/MYzudj.jpg)

</comment></comment></comment><comment><USER15> This is the first time I've heard of Spectrum, anyone mind summarizing the key features/differentiation? It looks similar to Slack or Discord, with a focus on discoverable open communities as opposed to private organizations, and threaded conversations being a key feature?

<comment><USER10> Hey, co-founder here. We've really been focused on threaded, public-by- default, search-indexed conversations. We've found this to be super helpful for large, async communities so far, and the search-indexing is really great for organic discovery and preventing too many duplicate questions that someone might ask in a synchronous chat app. But we also support private communities, private channels, direct messages, public community/user profiles, and more. We've seen these things be really useful for content and community discovery.

<comment><USER16> I have a project within my corp where we need to collaborate with other companies on a shared project. We want to do this privately and right now run our own rocketchat stuff to do this. However we are open to hosted solutions.

I was unaware of this product until now, I figured I'd give it a spin to see what was available now and hope for some cool github integration in the future.

However the public-by-default stuff is a bummer. I know there are ways to make things private and perhaps its just me not spending enough time with the product but even if I make a private community it always has a _public_ general thread that I can't delete.

The public general thread is the default for any new thread or conversation so I can see that it will be easy to unintentionally create a thread that was intended to be private as public.

I understand why you want public-by-default, to increase engagement and community building but there are many businesses using Github and could use this tool if they were sure that they could keep stuff buttoned down.

So perhaps you guys could add a "business" or "private first" context that could be used for folks like me to ensure that while operating in that context I am operating as private-by-default.

Also, can you give any hints to what integrations might come?

<comment><USER10> Hey there - if you selected 'private' during the community creation flow, everything in that community will be private. However, there will still exist the concept of "public" and "private" channels, however those scopes are still constrained by the community settings. For example, a private community with a public general channel means everyone who has access to the community can see those conversations. But if you have a private channel in a private community, only a subset of authorized community members will be able to see those threads.

<comment><USER16> Ok, then this text in the "general" channel settings is very confusing:

 _Anyone on Spectrum can join this channel, post threads and messages, and will be able to see other members. If you want to create private channels, get in touch._

Also, it would be helpful if i could tell at a glance which communities I was in were private vs public. I can't even tell from the communities setting page if I selected private or not on creation (I did, but i'd still like to see that noted)

Thanks, looking forward to seeing how this gets integrated

*I'd love to see documents/media added to threads added to the repos (optionally perhaps)

</comment></comment></comment></comment></comment><comment><USER17> For those who, like me, have never heard of this before:

Spectrum is a real-time chat service where each conversation has a permalink.

<comment><USER18> Not to be confused with the other Spectrum which is a real-time chat service and forum

[https://robertsspaceindustries.com/spectrum/](https://robertsspaceindustries.com/spectrum/)

[https://starcitizen.tools/Spectrum_(module)](https://starcitizen.tools/Spectrum_\(module\))

<comment><USER19> Or the other Spectrum, formed from the merger of Time Warner Cable and Charter.

<comment><USER20> Or the other Spectrum, the magazine of the Institute of Electrical and Electronics Engineers, which has been published since 1964...

<comment><USER21> Or the instant messaging transport, which is what I thought this was related to when I first saw it. :)

[https://spectrum.im/](https://spectrum.im/)

<comment><USER22> Or the 8-bit Z80-based 1980s computer that was huge outside of the US (when the US was mainly Commodore 64 focused) (1) and of Google Doodle fame (2)

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

2 - [https://www.google.com/doodles/st-georges-day-the-30th- anniv...](https://www.google.com/doodles/st-georges-day-the-30th-anniversary- of-the-zx-spectrum)

</comment></comment></comment></comment></comment></comment><comment><USER23> I am very happy to see this. It is a well-polished product that I would use any day over alternatives like Discord, which lots of OSS projects seem to be shifting to. Congratulations to the team.

</comment><comment><USER24> The site has slowed to a crawl as the HN audience hugs it to death. Unfortunate that they didn't anticipate the increased interest and allocate more capacity accordingly.

<comment><USER17> Growing pains are to be expected. They're probably working feverishly to scale as we write this.

</comment></comment><comment><USER25> The first time I loaded this, I got an error, "We couldn't find a channel with this name." In the console, ServiceWorker errors on Google Analytics (blocked), and a bunch of unhelpful "Unhandled (in react-apollo)" errors with long stack traces that I shan't reproduce here. A reload fixed it. Curious and a little concerning. But even then, the document has no title or favicon, which is… _what!?_ (OK, when I looked back five minutes later, after much scrolling through several pages of comments at the end, it did eventually get a document title, but only eventually.)

The big image at the top of [https://spectrum.chat/features](https://spectrum.chat/features) is also broken.

</comment><comment><USER26> I've never used this product, but I might now, since the article indicates that all their services are now free.

</comment><comment> L-11 To write a dissenting comment:

Zeit (the company behind `now`) recently killed their 10,000+ member Slack server in favor of Spectrum. Their reasons were (a) Slack isn't designed to support communities, (b) they were having to answer the same questions repeatedly, (c) those answers weren't being indexed by Google, and (d) there is very little abuse prevention in Slack.

Another way of phrasing (d) is that they seemed to want to have greater control in shutting down conversations (for better or worse).

Lopping the head off a 10,000 member community seems like a bad idea, and that was only reinforced by the outcome. People regularly complain about Spectrum on Zeit's spectrum. Threads go unanswered, sometimes for weeks. And every conversation is forced into a threaded model. There's no way to have a single, shared chatroom that everyone is posting to. (Or if there is, it's not the default, and defaults matter.)

The nice thing about Zeit's old Slack channel was that if you were facing a crisis with `now`, you could post in #now and their support staff would take care of the problem almost immediately. But more than that, you could _see_ that _other people 's problems_ were being taken care of immediately. That strengthened my brand perception of Zeit and made me want to recommend `now`.

I still recommend `now`, but losing out on real-time support felt like a major blow. When my payment details lapsed, all of my `now` deployments were shut off immediately. I updated my payment details, but the deployments were still offline. I felt somewhat foolish posting a Spectrum thread like "Hey, I know I was supposed to be paying you, but I didn't. Now I did. Will my deployments come back online, or do I have to re-deploy everything?"

I didn't want a conversation like that to be indexed in Google for all time, public for all to see. And while there may be a DM feature in Spectrum, the benefit of Slack is that you can get a sense of who's who right away. It's obvious who the support person is, because they are the ones fielding everyone's questions each day. And you can just shoot them a quick message for one-off questions.

No doubt that gets annoying. But from an outsider's perspective, it's hard to understand why the trade-offs are worth it.

Meanwhile, Discord seems to be gaining traction in the developer space. There are a lot of interesting programming communities springing up, like The Coding Den. Many open source projects are starting to offer a Discord presence by default. And there are a lot of benefits with this model: All the upsides of Slack (and then some), minus some Slack integrations that you might miss (which you can use Slack for anyway), and without forcing every conversation into a threaded async model.

All of that said, please note that this comment is written as an outsider's perspective with relatively little Spectrum experience. Maybe I'm just using Spectrum wrong. But the benefit of the Slack/Discord model is that you end up feeling like a community, rather than a disparate set of posts that are basically tweets.

<comment><USER27> Spectrum has no concept of channels or topics?

<comment><USER10> We do have the concept of channels within communities. Channels can also be optionally private.

</comment></comment></comment><comment><USER28> This seems more like discourse, a forum than slack, chat?

One thing that often happens in chat is general talk like weather. Would that go in a topic here too?

<comment><USER29> There seem to be two things. Each community can define channels so I guess you could have an 'offtopic' one. The other is that there are dedicated 'watercooler' threads e.g. [https://spectrum.chat/react?thread=257957e0-ef20-4757-b25e-8...](https://spectrum.chat/react?thread=257957e0-ef20-4757-b25e-82156b89131a)

</comment></comment><comment><USER30> I know nothing about this app but am excited to see GitHub has done a single thing to move their boring featureless application forward.

</comment><comment><USER31> If only I had a dollar for every time the word "community" appears in the article...

</comment><comment><USER32> So what is the next Step for Microsoft? Circle CI? or some other CI tools?

<comment><USER33> Microsoft already has Azure Pipelines

</comment></comment><comment><USER34> That _has_ to be a trademark violation in the UK. Would be very surprised if the trademarks for Clive Sinclair's ZX Spectrum weren't in the same category as this. And thanks to the "Next", they're still in use.

<comment><USER35> spectrum is also the brand name used by charter telecommunications for their ISP and news business, so they obviously do not have much concern about trademark infringement.

</comment></comment><comment><USER36> I tried using spectrum for something the other day and I found it impossible to find what I had already posted (to see if someone answered my question). UI is garbage.

<comment><USER37> Gitter is already owned by GitLab.

</comment></comment><comment><USER38> *joining Microsoft

<comment><USER39> Why is everything I read from Microsoft something I have to translate into what actually is reality. It's exhausting.

<comment><USER40> Unless you're viewing it from a purely financial lens (e.g. you're closely following the MSFT stock), it seems like "joining GitHub" is probably closer to reality than "joining Microsoft" for most purposes. I don't have any more information than the post has, but it sounds like:

* The Spectrum product will be merging with the GitHub product in some sense, maybe integrating completely, maybe re-branded with GitHub branding, maybe separate branding but tighter integrations. It certainly doesn't seem like it'll be a separate Microsoft-branded product.

* The Spectrum team (three people) will join the GitHub team, which of course has its own office, culture, vision, etc. Maybe they'll keep working on Spectrum, maybe they'll work on other parts of GitHub, maybe current GitHub folks will join them, but point is, the people they'll work with are the people who work on GitHub, not Microsoft as a whole. It certainly seems unlikely that they're moving to Redmond to work at Microsoft HQ.

</comment></comment></comment><comment><USER41> Apparently this has nothing to do with the cable company ...?

<comment><USER42> I had the same thought. For the sake of clarity, Spectrum is not a cable company unto itself. It is a brand owned by Time Warner Cable, a thin facade to escape their reputation for costumer dissatisfaction.

<comment><USER43> Somehow they managed to escape into even more dissatisfaction. At least Time Warner had different plans and didn't spam me several times a week with letters. Now they only have one $70 plan and are sending me a ton of mail with "deals" that aren't deals.

<comment><USER44> I must've lucked out, then, as I only pay $15 a month for an Internet-only plan through Spectrum. Granted, the speeds aren't anything to write home about (30 Mb/s download), but it's more than serviceable.

<comment><USER43> Where's that? I have an old $15 plan for 3 mbit grandfathered in but I would like a little more speed. The only plan they are offering to me is $49 for 12 months which then goes up 70.

<comment><USER44> In Los Angeles. Oddly enough, I went to see if I could find that plan again and it's nowhere to be found. The cheapest it's showing for me is a $50 a month plan for 100 Mb/s speeds.

<comment><USER43> I am in LA too. You are lucky. Keep that plan for as long as you can!

</comment></comment></comment></comment></comment></comment></comment><comment><USER45> Oh great, Microsoft bought the cable company!

<comment><USER46> I read the title and thought to myself "alright, now I <i>really</i> need to switch to Gitlab."

</comment></comment><comment><USER47> I am curious how it is not a trademark infringement?

Can someone please explain?

Skype was sued in UK for using letters "S,K,Y" by brand "Sky" and lost [1]

[1] - [https://www.bbc.com/news/technology-32593735](https://www.bbc.com/news/technology-32593735)

<comment><USER48> In the US, similar trademarks are fine as long as they're in different industries. See [https://www.estesrockets.com/](https://www.estesrockets.com/) and [https://www.estes-express.com/](https://www.estes-express.com/) for example.

<comment><USER49> Unfortunately there's [https://spectrum.im/](https://spectrum.im/) which is a bit close for comfort; compare:

        https://spectrum.chat/
        https://spectrum.im/</comment></comment></comment>


Numpy in pypy – update - <AUTHOR> http://morepypy.blogspot.com/2014/03/numpy-status-update-february.html

<comment><AUTHOR> Numpy on pypy's dot operation is now only 1.5 times slower than cpython's c version (not blas optimized)</comment>


Broadcom Sues Netflix - <AUTHOR> https://www.theregister.co.uk/2020/03/17/broadcom_sues_netflix/ <comment><AUTHOR> Broadcom sues Netflix for its success: You're stopping us making a fortune from set-top boxes, moans chip designer

</comment><comment><USER2> when broadcom is finished playing with stone knives and bear skins, then they can assume a modern distribution model

and for what its worth i cut my cable a long time ago due to poor channel selection and content as well as all the graffitti that is plastered all over something that is supposed to be entertaining but becomes annoying like a child standing infront of the screen on purpose.

if broadcom can address those issues im sure they can do well.

</comment><comment><USER3> This article is terrible. Somewhere in the middle they claim the actual claim is about patent infringement, not loss of income due to changing consumer preferences.

(Yes, Patent trolling needs to be stopped)

<comment><USER4> Crying over revenue is what this lawsuit is really about, though, even if patent infringement is the cudgel.

I don't really understand how Broadcom believes they can get anything out of this. Look at the cited patents: several of these were filed and/or granted before Netflix ever streamed a byte, and one of them expired last year. I'm not a patent lawyer, but I thought you had to defend your patents quickly and vigorously. Won't Broadcom have to explain why they sat on this for roughly a decade while Netflix evidently destroyed their market?

<comment><USER5> Also not a lawyer, but I think that's trademark which must be vigorously defended. I believe patents have a six-year limit from infringement: [https://www.law.cornell.edu/uscode/text/35/286](https://www.law.cornell.edu/uscode/text/35/286)

<comment><USER6> There is a six-year statute of limitations on patent infringement claims. But there is a separate doctrine called "laches" that says that, notwithstanding any statute of limitations, if a plaintiff sits around on their rights, their lawsuit can be barred.

But the Supreme Court recently held that laches was not a defense in statute of limitations cases. So, that wouldn't be an issue here.</comment></comment></comment></comment>