Sharding and IDs at Instagram - <AUTHOR> http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram <comment><USER2> Cool technology, good explanation. Legitimate questions below.

What you're describing (uploading photos + storing metadata) sounds like something which Facebook has tech talked at length about at multiple venues. Their solution was to use distributed FS for images (such as HDFS, though FB uses their internal "Haystack") and then use HBase for the metadata. To be honest, your solution while it works now, looks like a weak home-grown HBase, but leveraging PL/PGSQL for unique IDs. Why not go the snowflake+hbase route? While it may add Ops complexity, it is a fairly battle-proven stack, and JVM ops is pretty well documented.

Or, if you insist on using an RDBMS for metadata, why not just throw money (and not that much) at the problem and buy an SSD for your DB? Increase your iops from 100 or 200 up to 30,000 or 40,000 with a cheap drive, and call it a day. Surely this would be less expensive than the engineering effort that went into (and will continue to go into) this project. This has the added benefit of having no impact on Ops complexity and should scale to quite a staggering number of QPS.

Thanks!

<comment><USER3> Valid questions!

We're on EC2, which has its set of limitations but means we can run a 10 million + user system with two-and-a-half engineers (and no ops team / overhead). So while we hear about more and more folks using SSDs in their DBs, it's not an option in our near-term future.

For SQL vs HBase/Haystack, we don't really have to worry about the photo storage itself, since S3 handles all of it. The data we shard out is more suited to an RDBMS, and since we're way more familiar with that world than with HBase and similar, it was the choice that let us make the most progress in a short time with a small team. Hope that's a helpful description of how we thought about it.

<comment><USER4> From what I am understanding from the post is that you are actually sharding other tables like photos, likes, comments but not the main users table, right?

So, if one day you want to shard the users table, it will render all current sharding useless, right?

</comment></comment></comment><comment><USER5> I work at Flickr and I see they mentioned Flickr's ticket server idea, (ab)using MySQL's autoincrement and "REPLACE INTO" trick and mentioned that a con was the write bottleneck.

We're generating more GUIDs than ever with this system and those boxes are more or less idle on every metric. They're right in that we don't meet their time-ordered requirement, but I just wanted to say that writing (or reading) is not a bottleneck.

<comment><USER3> Thanks for the info, I updated the post to mention that the write bottleneck isn't an issue at Flickr.

<comment><USER5> Thanks!

I like that you guys are using your database's stock features to accomplish this. Most of the time you don't need complicated systems to get things done. Reducing that mental overload of YET another system is huge.

</comment></comment></comment><comment><USER6> I think it's a mistake to tie the shard id into the object id. Shard id should be derived from the object id dynamically based on the placement of the object among the shards. If the shards grow or shrink or object migrated, a different shard id is generated, but the object id doesn't have to change.

Edit: I like how constructive criticism got downvoted. Thanks for discouraging technical discussion.

<comment><USER7> If you do that then you need to keep a mapping of object IDs to shards. You can't store it on the application servers because of race conditions and memory constraints, so each object lookup will require two network trips.

They've defined 2^13 virtual shards, which is fine-grained enough that they can move entire shards between physical servers to eliminate hot spots.

<comment><USER8> I hear what you are saying, but what they have done is derived the their IDs based partially on their current choice of architecture. If, for any reason, they would like to change their architecture later, suddenly they have a real problem.

That feels flaky to me. Its a nice techy solution, and the write up was interesting, but there are definitely a few weak points in their implementation. Their computers have to be absolutely in sync for time, their ID space is entirely guessable once you know the algorithm and they have effectively hard coded their current architecture into their software.

</comment></comment></comment><comment><USER9> Back in 2003 I was a developer on a team at Microsoft that was responsible for building a new storage backend for all the MSN Messenger and Hotmail contact lists. This store had to hold data for close to 300 million user accounts, which we sharded out to a few hundred SQL server databases. Our sharding system consisted of a database with a single table with a row for each user that mapped their 128 bit guid user ID to the ID of their assigned shard. New user creation involved generating a new guid and inserting into this table. Each read operation involved a select from this table.

The database ran on a machine with enough RAM to let SQL Server do its thing and cache almost the whole table in memory. At the time I left the team in 2005, it was executing over 25,000 requests per second, with an average latency of under 3ms. Pretty sure that on modern hardware it would handle much, much more.

<comment><USER10> Can you share some more details? How many shards did you have? Did it all run on a single machine? How much RAM did it have?

</comment></comment><comment><USER11> I've used the "snowflake" like approach in the past with great success. It's really not all that complicated. The reliance on time in the Instagram approach is a bit scary. A few ms off here and there could really hurt this scheme. How do you handle seamlessly transitioning these across machines when your shards move?

<comment><USER12> Not really. Like MongoDB, the first four bytes of an ObjectId are a timestamp. That the timestamp is synced with other instances isn't paramount because the actual value of the timestamp does not matter. What does matter is that the timestamp is new and increasing every second. This is to retain sorting capabilities. With the 13 bits that represent the logical shard ID from this article, Instagram will guarantee uniqueness of an ID within the granularity of a second.

<comment><USER11> "What does matter is that the timestamp is new and increasing every second."

Right. I'm just sayin' that you have to be careful when you move data with a caveat like that. Moving the shard keyspace (the 13 bits) to a new machine that started generating ID's even one second behind (the first 4 bytes) would be troublesome, no?

<comment><USER3> Yep--definitely something to watch out for. At worst, though, you'd have a duplicate key when trying to insert, and can re-try without the risk of having a duplicate ID floating around your system.

</comment></comment></comment></comment><comment><USER13> Interesting article. It seems like a pretty good solution the problem, especially when judged on the ease of maintenance.

One thing that bothered me was, "Let's walk through an example: let's say it's September 9th, 2011, at 5:00pm and our 'epoch' begins on January 1st, 2011. There have been 1387263000 milliseconds since the beginning of our epoch..."

The number of seconds between 5pm one day and midnight another obviously doesn't end in 3, so I looked into it. It looks like that number is taken from the epoch that is used later in the SQL which starts on Aug 24th.

</comment><comment><USER14> I'm sure I missed something, but this doesn't guarantee unique keys across the database does it?

What if you have two tables with the same autoincrement value being updated at the same millisecond by two users with the same UserID%NumShards?

Or is there some relationship between physical and logical shards that makes this impossible?

<comment><USER3> Hey Ken, (author here)

There's a 1:1 mapping between the user's hash modulo the number of shards, and the table they're writing to. So, if we had 1000 logical shards, we have 1000 schema/tablespaces, with the same tables in each. And the database's own 'nextval()' feature makes sure never have the same ID twice. Hope that clarified things.

<comment><USER15> I understand 1000 logical shards is probably a good number to use with PostgreSQL. I'm currently looking at doing something like this myself but I was thinking that it would be so much more elegant if each user could live in his own shard.

Does anybody know of a database product / solution that will handle hundred thousands of shards? I don't have a need for joins across shards, each user account only uses it's own data. And data and access within a shard would be very small, a SQLlite instance for every user would be a theoretical solution. The idea would be to have one (in memory) table to connect the app to the correct shard for the user and then get "perfect" horizontal scaling. Is anybody doing this?

</comment></comment></comment><comment><USER16> Did you evaluate using something like Redis for this? It's got an atomic increment command that guarantee's unique ID's and the performance is stupid fast.

<comment><USER3> We love Redis at Instagram (it powers a lot of our systems...more write-ups on these soon), and considered it for our ID generation, but it would have introduced a single point of failure, unless we split the load between several Redis instances, at which point it would be hard to make the IDs time- sortable. Also, most of our Redis systems are durable within a minute (we write to disk on a slave every minute), but if we were to lose the master and slave simultaneously (imagine an EC2 network issue or such), then it would be hard to know what the last known 'good' ID was--not an insurmountable problem, but one more moving part to worry about. That said, using Redis with something like the upcoming Redis Cluster could be a good choice, though.

</comment></comment><comment><USER17> I like it. Question, did you consider using composite keys of shard_id and id to make up a single primary key? If so what were the pros/cons you found with that approach?

btw, tambem sou brasileiro vivendo em san francisco (<https://twitter.com/#!/artilheiro>)

<comment><USER3> We considered the composite key, but we often have to store keys in other systems like Redis, where having a single 64-bit integer makes it more portable and stored compactly (Redis, for example, has an optimization when storing integer values vs string values in its lists). Valeu pelo comentário!

</comment></comment><comment><USER18> Hi, very helpful post. Thank you.

Something still puzzles me though. You wrote a sequence is unique to each table in each schema. However, your example seems to use the same sequence name for all tables within a schema.

Also, shouldn't your mod operation have only one %?

Thanks again!

</comment><comment><USER19> One nit about snowflake in your article (i'm the author of snowflake)– the zookeeper integration is optional and only used for sanity checking the configuration (that the worker ids are distinct, etc).

</comment><comment><USER20> We use a solution similar to snowflake at Formspring:

<https://github.com/formspring/flake>

In the 18 months this system has been running, we never experienced any issue.

</comment><comment><USER21> Neat.

You could avoid having to create a per-schema id function by passing the shard id and the sequence oid as params to the function, so you'd have default public.next_id(5,'insta5.table_id_seq'::regclass)

</comment><comment><USER22> Hi Mike, excellent article! One question about sharding, do you find that it reduces High Availability overall, as your uptime depends on the vagaries of additional database servers??

</comment><comment><USER23> What I'd be more curious to hear about, is how they deal with super nodes and if they're storing a map (or any kind of routing table) or simply using generic modulo hashing on a key.

<comment><USER3> Right now, it's a lookup dict in our Django app--which involves brief downtime just to update the shard map when moving the data (more on this in another post). We hash on user ID (in most cases) and then look the shard # in the dict, then look up the shard # in a logical-to-physical dict.

By the way we use & love Sentry!

<comment><USER23> Ah so you don't actually have 1000 (or whatever) schemas set up right off the bat?

Or I might be misunderstanding, and you're saying that you're just mapping which physical server has the schemas

<comment><USER3> We set-up the schemas ahead of time, and then each lookup is (with, say, 1000 schemas):

      user_id % 1000 -> schema ID
      schema ID -> database ID

then select FROM schemaID.tablename etc on that particular database.

<comment><USER23> Ah ok that's what I figured. We do a lot of the same things right now with various DBs (we just describe it as pre-sharding so we can avoid the actual re-sharding dilemma). We've had to do this with both PostgreSQL and Redis now.

The schemas are definitely a neat way to handle this though so you dont have to worry about table names.

</comment></comment></comment></comment></comment><comment><USER24> Holy god. The post mentions "We evaluated a few different NoSQL solutions, but (...)".

I couldn't even imagine having to _think_ about this sort of thing; CouchDB makes this an absolute no-brainer. I mean, the act of creating a document assigns it a UUID in the database _by_ _default_.

Or, do you want to fetch a UUID before assigning it to any data? localhost:5984/_uuids Want to fetch 10? localhost:5984/_uuids?count=10 Want to fetch a million? localhost:5984/_uuids?count=1000000

Instagram seems like the absolutely perfect candidate for CouchDB -- unstructured data, speed, HTTP querying, big data, attachments...

<comment><USER25> Requirement number one was that IDs be sortable by time. CouchDB UUIDs are random.

<comment><USER26> The call to default _uuids API call generates random UUIds, however you could override the call in the _config to have a different algorithm field, one that potentially could call "utc_random" still while appending a timestamp in the string to sort by later. Was this thought about when CouchDB was potentially considered?

</comment></comment></comment><comment><USER27> This seems fairly neat. Is it possible to do something like this with MySQL?

<comment><USER3> (author here) I think this should also be possible with MySQL's stored functions, but one huge benefit to PostgreSQL is the schema/tablespace feature, since it means all our logical shards all live inside one database (you could do something similar with MySQL, but it would mean multiple databases or prefixing table names with the shard ID).

<comment><USER28> PostgreSQL schemas are very similar to MySQL databases in functionality. In fact, in MySQL you can use SCHEMA in all places you can use the term database, ie. CREATE SCHEMA foo; instead of CREATE DATABASE foo;

</comment></comment></comment><comment><USER29> I just love how startups keep reinventing the wheel to solve problems that haven't been problems for decades.

Come on, 25 pics + 90 likes per second... that almost like... [wait for it]... nothing.

I'm pretty sure you got your number wrong.

<comment><USER29> Almost forgot: Sharding 101 "Always shard via directory..."

</comment></comment><comment><USER30> How to do sharding:

1\. Define your keyspace in bits.

2\. Shard your keyspace in CIDR notation

3\. Resharding always splits a keyspace in half

      eg. 0.0.0.0/0 becomes 0.0.0.0/1 and 126.96.36.199/1

4\. Store your shard keyspace in DNS with SRV/TXT records

5\. Assign IDs randomly

This gives a couple interesting properties, for replication odds are very high that your corresponding server has a shard of similar size and if not its generally only split over two servers. Servers also only need to speak directly to their one or two replicas in the other data center. The other really nice property if you're using spindle disks is that you can copy the entire HD and just delete the half of the keyspace not used after the split.

It's all written up here if you want to dig into with a full description of all the pieces: <http://bit.ly/FredPatent>

<comment><USER31> It takes some nerve to actually be proud of that patent.

Luckily for the rest of us, there is not just one way to do sharding (which in the original version of your post you assertively referred to as "how to do sharding _right_ ").

It depends on the individual architecture and the tradeoffs people consider important. That means you don't get to have an undeserved but legal monopoly holding the entire scalable web hostage, just a part of it. Nevertheless: you should be ashamed of yourself.</comment></comment>


A graphical breakdown of the death of newspapers - <AUTHOR> http://www.mint.com/blog/trends/the-death-of-the-newspaper/?display=wide

<comment><USER2> The gray background is a little hard to read against. White would have been much better.

I don't know if I trust stock prices as a measure of the "death of the newspaper". I mean pretty much every company's stock prices went down recently.

I think it would, however, be interesting to see how the fall in stock prices for the newspaper companies compares with the fall in stock prices for other companies in different fields, say online news services or TV news.

<comment><USER3> compare with the dow:

[http://finance.yahoo.com/echarts?s=^DJI#chart1:symbol=^dji;r...](http://finance.yahoo.com/echarts?s=^DJI#chart1:symbol=^dji;range=my;indicator=volume;charttype=line;crosshair=on;ohlcvalues=0;logscale=on;source=undefined)

</comment></comment><comment><USER4> I would really like to see some statistics about online press because it is not clear for me at the moment if people are moving online or just simply stopping to read. If it is the latter, we have a huge problem.

I've got this question after reading Amusing Ourselves to Death by Neil Postman.

<comment><USER3> Looking at the people around me my guess would be moving online at the expense of periodicals and TV.

That's a very limited sample though. I used to be an avid newspaper and periodicals reader, 3 subscriptions to monthlies (nature, Scientific American and the Lancet) and a newspaper were paid for, then reading every other publication I could get my hands on.

Now it's all internet.

My other friends and family are much the same. In a shopping center a while ago I was offered something like 6 months free on a newspaper subscription. I said no thanks and the person was like 'what do you want, what does it make to get you to accept' and I said I don't think it can be done.

Even if its free I still have to get rid of the things every couple of weeks, and they harm the environment. I do buy books on paper though, there's something about curling up in a corner with a book that a computer can't give me (yet).

<comment><USER4> I was talking more about general audience. I understand that people who read SciAm won't magically switch to the Twitter and YouTube videos as their main media for public discourse.

P.S. Not related to the main topic, but you might find it interesting. For the past few months I was reading books exclusively on Kindle but recently I had to buy a paper book (Coders At Work) and the experience is awful so far. I can't highlight and save quotes I like, I can't make notes, I can't quickly look up a word definition. But the worst part is that with Kindle I forgot how difficult and almost impossible it is to read while standing in the train or laying in bed. So, although Coders At Work is a very interesting book I can't wait to finish it and return to my ebook reader.

<comment><USER3> That's as good an ad for the kindle as I've seen to date :)

Not sure how well they work in Europe though, I'll have to look in to that.

<comment><USER4> AFAIK they are pretty much useless outside the United States. Check out other readers (from Sony, etc.). They are pretty much the same but not tied up to the Amazon.com.

<comment><USER3> Ok, I will do that. Thanks for the tip!

</comment></comment></comment></comment></comment></comment><comment><USER5> There were zero weekend newspapers in 1989? That first graph is pretty confusing.

<comment><USER6> No, there were 60-odd million. The graph does not seem hard to read to me at all. There is a darker color graph overlain by a partially transparent lighter color graph.

<comment><USER7> Its not that hard to read, but a simple line graph would probably have been clearer.

</comment></comment></comment><comment><USER6> Newspapers have grown decreasingly diverse over time as they have concentrated more and more on regurgitating wire stories, with human interest non-news, opeds, and fill-in-the-blank local reportage as padding. Very little of the content in papers is legitimately new reporting or investigative journalism. As wire reports etc. have become available cheaper, faster, and more conveniently through the internet and TV the dubious nature of the "value add" of news papers has become more and more apparent.

That news papers have become utterly dependent on advertising in an age when print advertising is dying is a separate phenomenon which has effectively sealed the fate of most papers. Few papers are willing to accept the notion that they cannot survive without dramatic, fundamental changes. They would rather live with the fantasy that it's just not possible or that profitability is just a few little insubstantial tweaks away.

If papers dumped their standing armies of news regurgitators, got lean, and concentrated solely on local news and investigations, they might have a chance of surviving in the modern, ultra-connected world. But few are willing to make such dramatic changes, so we will see a lot of papers die before this all gets sorted out.</comment>


How Safe Do LGBTQ+ Individuals Feel in Tech? - <AUTHOR> https://insights.dice.com/2020/06/29/how-safe-do-lgbtq-individuals-feel-tech/ <comment><USER2> I wonder if there are LGBTQ people working at Brave and what do they think about Eich. Ie him contributing money to block same sex marriage in California.</comment>


The British Government Takes on the British Civil Service - <AUTHOR> https://www.economist.com/britain/2020/07/04/the-government-takes-on-the-civil-service <comment><USER2> The article says this is led by Dominic Cummings, whose blog is [https://dominiccummings.com/](https://dominiccummings.com/) if you want to know more about him. He advocates for a tech/quantitative approach to policy, e.g.

[https://dominiccummings.com/2020/01/02/two-hands-are-a- lot-w...](https://dominiccummings.com/2020/01/02/two-hands-are-a-lot-were- hiring-data-scientists-project-managers-policy-experts-assorted-weirdos/) on who he wants to hire.

[https://dominiccummings.com/2019/06/26/on-the- referendum-33-...](https://dominiccummings.com/2019/06/26/on-the- referendum-33-high-performance-government-cognitive-technologies-michael- nielsen-bret-victor-seeing-rooms/) on tech to assist decision making in government.

[https://dominiccummings.com/2014/08/19/standin-by-the- window...](https://dominiccummings.com/2014/08/19/standin-by-the-window-where- the-light-is-strong-de-extinction-machine-intelligence-the-search-for-extra- solar-life-neural-networks-autonomous-drone-swarms-bombing-parliament- genetics-amp/) on his trip to SciFoo, and being a policy person amongst tech people.

He's not very popular in the UK, which is tangential to the article, so this thread is at risk of becoming a smear comment section.

</comment><comment><USER3> "This government has a better chance of building a more effective British state than any government in decades".

They saved the biggest joke for the end, this Government makes Theresa may look "strong and stable".

<comment><USER4> I read this as being to do with a crisis (Brexit / Covid-19) being an opportunity, particularly with an 80-seat majority. But I share your deep cynicism about their ability to actually make any productive use of that, and in fact expect the opposite - a deeper crisis.

</comment></comment><comment><USER5> Not sure what this has to do with tech or HackerNews in general.

<comment><USER2> The leader of this, Dominic Cummings, advocates for a quantitative/tech approach to policy, e.g.

[https://dominiccummings.com/2020/01/02/two-hands-are-a- lot-w...](https://dominiccummings.com/2020/01/02/two-hands-are-a-lot-were- hiring-data-scientists-project-managers-policy-experts-assorted-weirdos/) on who he wants to hire.

[https://dominiccummings.com/2019/06/26/on-the- referendum-33-...](https://dominiccummings.com/2019/06/26/on-the- referendum-33-high-performance-government-cognitive-technologies-michael- nielsen-bret-victor-seeing-rooms/) on tech to assist decision making in government.

[https://dominiccummings.com/2014/08/19/standin-by-the- window...](https://dominiccummings.com/2014/08/19/standin-by-the-window-where- the-light-is-strong-de-extinction-machine-intelligence-the-search-for-extra- solar-life-neural-networks-autonomous-drone-swarms-bombing-parliament- genetics-amp/) on his trip to SciFoo, and being a policy person amongst tech people.

<comment><USER6> His goals are rather dystopian though, despite the sophisticated tools.

There is no scientific view under which Brexit, which he helped achieve, is a good idea.

<comment><USER2> > His goals are rather dystopian though, despite the sophisticated tools.

Oh?

> There is no scientific view under which Brexit, which he helped achieve, is > a good idea.

Brexit involved many factors including the value attributed to greater democratic control and greater control over immigration. How have you quantified that in your (allegedly) exhaustive evaluation of all scientific views?

</comment></comment></comment></comment><comment><USER7> I worry it's the overconfidence of an Oxbridge education that leads to picking the most complicated of possible solutions. Rail privatisations or farm subsidies implemented in such a Byzantine way that no normal mortal can ever understand them, let alone implement them. Though ultimately we will get better government when the electorate votes for better people. Despite their good intentions so many of our MP's are way out of their depth.

</comment><comment><USER8> Paywalled article. Without a link to the full article I am not sure this is right for HN.

In summary for international readers, the situation in the UK is that the British government changed with Brexit. There is the Prime Minister who was elected to get Brexit done, his unelected special adviser and fellow Brexiteer Michael Gove.

With the election the ruling party only have pro Brexit MPs, the pro-Europe supporting members of the party were replaced.

As a consequence government is not by cabinet, there is the clique of the Prime Minister, the special adviser and Michael Gove. Michael Gove has a proper job title but few Brits know it.

With the current lineup of the cabinet the special advisers for each cabinet member now have to work for the prime minister's special adviser. These civil service jobs are now political appointments.

There have been other changes that this article is about, essentially civil servants from the top down are being replaced with Brexit supporters. Normally civil service jobs go to those with experience and skills, not Brexit ideology.

In the process the trio running the country have picked a fight with the whole civil service.

<comment><USER4> Turn off JavaScript (e.g. using uBlock Origin) and you can read it in full.

<comment><USER7> Or feed the URL into outline.com or archive.org

</comment></comment></comment><comment><USER9> HN really needs tagged filters on submissions so i can ignore all 'general' news stories. So many non-tech, non-startup or non-'intellectual' stories hitting front page.</comment>


Evidence for superconductivity above 260 K at megabar pressures (2018) - <AUTHOR> https://arxiv.org/abs/1808.07695 <comment><USER2> I've seen this research cited a few times (perhaps even here on HN) and every time the conversation is centered on whether this is practical or the naysayers moaning how this isn't practical.

The research isn't intended for commercial, practical use. There is no point in discussing it in such terms.

The interesting thing is that this behavior was predicted by models, and the experiment confirms the model. That is it. Perhaps with increased confidence in the models it will lead to improvements in practical superconductors in time, but not now.

<comment><USER3> As you seem to understand this topic a bit more: can you explain the model?

What is the current theory how superconductors work?

<comment><USER4> _> What is the current theory how superconductors work?_

The best general model of superconductivity I'm aware of is still the BCS model:

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

This model basically says a superconductor is a Bose-Einstein condensate, where the Bose "particles" are pairs of electrons in the material that are entangled via an interaction involving low-energy vibration states of the material as a whole. The problem is that this general model doesn't tell us what the critical temperature for the Bose-Einstein condensation is. We have to find that out by a combination of experimentation with different materials, and more detailed extensions of the model that test various hypotheses about what kinds of material properties should affect the critical temperature. This paper is just a recent development in that line of research.

</comment></comment></comment><comment><USER5> The necessary pressure isn't that important. Obviously using this material under those conditions in the real world won't be realistic.

However, what this shows is that superconductivity is possible at those temperatures, and that pressure is a factor to further investigate when experimenting with other candidate materials.

<comment><USER6> > _pressure is a factor to further investigate when experimenting with other > candidate materials_

There are crystals which retain their internal strain after release. This is valuable research.

<comment><USER7> Isnt growing crystal under high pressure in presses also not well understood? Like how are you going to make long traces or intricate structure in a high pressure environment that dont fully know growth and forming process of such crystals?

</comment></comment></comment><comment><USER8> This occurs at 2 million bar (pressure).

From an engineering perspective, what does it take to contain such pressures, and would it be possible to make 'wire' consisting of a pressure-maintaining jacket surrounding the conductor?

Anyone want to do the maths? How much Kevlar are we talking...?

<comment> semi-extrinsic What you need is a material with very high ultimate tensile strength. Carbon nanotubes _might_ do it. Let's check.

To compute the burst pressure of a pipe, we can use Barlow's formula:

P_max = S * T /R

where T is wall thickness, R is radius of the outside of the pipe, and S is ultimate tensile strength. Here T=R is the limit where the inside radius is zero. So the best case is

P_max = S/1.0000001

Carbon nanotubes are the highest strength material, with a theoretical S=100 megabar. So not possible, sadly.

<comment><USER9> This is far outside my wheel house, but... Surely it's the pressure differential that dictates the burst pressure? So if you had multiple sleeves, each decreasing in pressure as you get closer to the outside, this could be possible?

<comment><USER10> I'd expect that for a pipe under high pressure but small pressure differential compressive strength would matter much more than tensile strength.

</comment></comment></comment></comment><comment><USER11> Stupid question from a non-physicist: what exactly does the high pressure do here? How does it contribute to the superconductivity?

<comment><USER12> I'm guessing it essentially increases the elastic constants of the material; that is, increases the "spring constants" of the bonds between atoms. As a result, the resonant frequency of acoustic vibrations rises. When these acoustic vibrations are quantized into phonons, the minimum energy of each phonon therefore rises, since it is proportional to this resonant frequency. Since conventional cooper pairs are pairs of electrons bound by a phonon, this increases the binding energy of the pair, and makes it more resilient to being broken up by the thermal energy.

</comment></comment><comment><USER13> Putting P-T into context, the conditions involved in synthesizing some forms of lanthanum decahydride are enough to create diamonds.[1]

The cubic phase of LaH10 is synthesized around 170 GPa and 1000 K.[2] The SC properties arise ~10 centigrade below the freezing point of water, but still under enormous pressure (190 GPa).

So if a sample of graphite were cooked aside during the synthesis of cubic LaH10, it would have become a diamond by the end of the experiment.

[1] [https://en.wikipedia.org/wiki/Diamond#Thermodynamics](https://en.wikipedia.org/wiki/Diamond#Thermodynamics)

[2] [https://sci-hub.se/10.1002%2Fanie.201709970](https://sci- hub.se/10.1002%2Fanie.201709970) (This paper shares some authors with the paper to which this post links.)

</comment><comment> phoe-krk That's over one million atmospheres of pressure we are talking about here. Are there any predictions of how this is going to affect modern-day electronics that will be unable to undergo such massive pressure?

</comment><comment> lachlan-sneff Perhaps it would be possible to contain materials at such high pressures inside other materials like carbon nanotubes or diamonoid structures?

</comment><comment><USER14> Maybe we can get to some happy medium where it's a practical level of pressure and cooling, not quite room temperature but still something we can use.

<comment><USER15> Liquid nitrogen is almost that already. It's readily available, reasonably cheap, and you just need Styrofoam for the bulk of the insulation.

The superconducting material itself is expensive, brittle, hard to fabricate, and hard to work with.

<comment><USER16> Standard "high-temperature" superconducting wire (e.g. YBCO) isn't actually all that bad to handle or wind. You buy it extruded in a metal matrix (usually copper), and treat it only a little bit more gently than standard copper wire.

</comment></comment></comment><comment><USER17> let's all move to megabar!</comment>


Neuralink's plans for brain-reading 'threads' and a robot to insert them - <AUTHOR> https://www.theverge.com/2019/7/16/20697123/elon-musk-neuralink-brain-reading-thread-robot <comment><USER2> Elon Musk has gone full Elizabeth Holmes.

</comment><comment><USER3> Ready or not, here comes the future...</comment>


Ask HN: Site feedback requested - OnsideKick.com - <AUTHOR>

After about 9 months of development with my co-founder, we launched OnsideKick.com today.  We plan to ramp up additional features and functionality over the summer and switch to a subscription service in August.  Would appreciate any and all feedback from the HN audience!<p>http://www.onsidekick.com <comment><USER2> Curator idea is a cool one -- would def get me to visit, but prob not subscribe. I second gabaix´s comment about refining the core value prop a bit more.

For example: As an Alabama fan, I subscribe to TiderInsider because there´s a perception that the guys that post on that forum are really "in the know" -- so I pay to get access to that early intel, tips, credible (and not-so- credible) rumors, etc. from insiders with the program. Site doesnt look like much, but you can get info there days/weeks before it hits mainstream outlets like ESPN/SI.

</comment><comment><USER3> Clickable: <http://www.onsidekick.com/>

2 Things I noticed right away:

1\. The pictures in the slider are ugly. Over-compressed, full of artifacts, and in some cases distorted (resized incorrectly). If you're going to feature pictures, use pretty pictures.

2\. The logo - you need a better one.

Cool idea. Not trying to be harsh, btw - just being blunt.

</comment><comment><USER4> Looks promising. Just think the site needs a UI look soon. It seems kind of cluttered, but since I'm a football fan, I don't mind for now. :)

</comment><comment><USER5> a couple of questions: \- what is the essential feature of this site? how can you emphasize it more? \- could you describe your site in one-liner? "football news curator" \- have you tested to football fans? would they urgently need it compared to other football news sites?</comment>


Britain's Productivity Decline Is the Worst in 250 Years - <AUTHOR> https://www.bloomberg.com/news/articles/2020-02-03/u-k-s-productivity-depression-is-unparalleled-in-250-years <comment><USER3> What a load of nonsense. Britain created many low wage jobs and decreased unemployment, of course the average "output" per hour will stagnate. The productivity of the country has increased dramatically though if formerly unemployed people now have jobs.

<comment><USER4> Unemployment is very low (45 year low if I recall correctly). However the productivity of the nation as a whole hasn't increased dramatically, GDP growth has been anaemic in recent years.

Having said that I'd rather we had low productivity than the problems some of the Southern European countries have had with high youth unemployment.

<comment><USER5> Unemployment isn't low. The figures are massaged with Orwellian precision to give that impression. But they're dishonest and frankly manipulative to an almost Soviet level.

The official ONS definition - which anyone can check on the ONS site - <USER2> anyone who works _one hour a week_ as employed.

The figures also include anyone who is self-employed for tax purposes, whether or not they have any income from work.

If we used 1970s metrics, where employment was defined as having a full-time job that comfortably covered basic living expenses, unemployment would be running at absolutely terrifying levels.

<comment><USER4> _counts anyone who works one hour a week as employed_

As I said elsewhere underemployment has been falling as well.

<comment><USER6> If that's how they measure employment, how do they measure underemployment?!

</comment></comment></comment></comment></comment><comment><USER7> It boggles the mind why they went through with Brexit! Seriously.

<comment><USER8> Because it's easier to blame Others for not being the centre of the universe any more, than to man up and do something about it. Lazy, nihilistic, CBF, post-Empire shitehole. What a sick, sad waste of potential.

<comment><USER9> Yeah, completely crazy to want your own self-determination.

<comment><USER10> I never really understand the special status given to national sovereignty. We all give up some control in a democratic system, from the local level upwards. Why is there some special status for the national level? What is it that's so bad about giving up some control at that level as part of a greater system?

<comment><USER11> When you no longer really believe (or never did believe) in one of the fundamental pillars of the EU e.g. ever closer union.

If you don't believe in that then it's your duty to leave and let those that do continue forwards with an ever closer union.

The UK joined really hoping to push the EU more towards a confederation which it would've felt comfortable in, the whole "working from the inside" thing that people are always saying is the best way to influence the EU. But ultimately a majority of the rest of the EU wants much closer integration than the UK would've ever been comfortable with... so here we are.</comment></comment></comment></comment></comment>


Custora (YC W11) Helps Businesses Battle Churn - <AUTHOR> http://www.readwriteweb.com/biz/2011/03/yc-startup-custora-helps-busin.php

<comment><USER2> interesting idea, definitely a lot of value. I've seen many of the big telcos and large companies spend a lot of resources and $$ on this problem.

<comment><USER3> Thanks! We're working hard to build the product based on the latest research in the field.

<comment><USER2> got links to what models you're using? I used to analyze such data.

</comment></comment></comment><comment><USER4> I've taken the tour, but I still don't understand what you do. Can you explain how it works?

</comment><comment><USER5> _in order to better offer better targeting and messaging_

How about "making something people want" as a strategy for retaining customers?

<comment><USER6> How do you work out what people want?

Then how to you change to make sure that your product is targeting the wants of the largest addressable market?

<comment><USER7> To add to that: how do you get what people want to the people who want it? Without hunting them down, they're unlikely to know you've solved their problem(s).</comment></comment></comment>


Rewriting Fortran Software in Rust - <AUTHOR> https://mckeogh.tech/post/shallow-water/ <comment><USER2> I used to maintain a large FORTRAN codebase - it seemed like every time new grad students showed up, everyone got a wise idea to re-build everything in a modern language.

This question is revisited a lot, but the general consensus has been that FORTRAN is fast, simple, easy to understand and code, and the compilers used are super optimized (Intel's FORTRAN compiler was really a gem - it managed to do a ton of automatic parallelization on modern hardware)

I'll see if I can find it, but I remember attending a conference talk at AGU in ~'08-10 called "Do-over or make-do" [1] that analyzed how many people-hours it would take to update all the climate modeling software (earth and space sciences are really huge on legacy FORTRAN code), and the conclusion of that talk was: use modern code/tools for glue, keep your climate models in FORTRAN.

There's a ton relating to precision - we had a huge ordeal converting our 32-bit space weather model to 64-bit because the change in precision changed our results, so we couldn't publish (in good conscious) without making sure the results weren't within a good margin of error. Anyhow.

This is always a fun thing to revisit now that I'm really far away from having to maintain any FORTRAN code any more :)

edit found it! [1]: [https://www.easterbrook.ca/steve/2010/12/agu-session-on- soft...](https://www.easterbrook.ca/steve/2010/12/agu-session-on-software- engineering-for-climate-modeling/) [2]: slides [http://www.cs.toronto.edu/~sme/presentations/Easterbrook- AGU...](http://www.cs.toronto.edu/~sme/presentations/Easterbrook-AGU- fall2010.pdf) Also randomly found this: [http://www.moreisdifferent.com/2015/07/16/why-physicsts- stil...](http://www.moreisdifferent.com/2015/07/16/why-physicsts-still-use- fortran/)

<comment><USER3> Although Fortran compilers may produce fast code (they have to - there's no chance to play with SIMD intrinsics or templates unless you want to use C++), I don't find them very good. I've personally hit several bugs in gfortran. The code I maintain now has some extremely ugly hacks to work around unfixed compiler bugs. I recently tried compiling it with Intel Fortran and got a compiler crash on one input file. Maybe they work well with Fortran 77 level code, but the Fortran 2003 level support seemed rather buggy. I suppose this is the problem with a minority language.

I won't recommend Fortran unless the code has to be written by scientists who know nothing else. It has horrible string support, no data structure or algorithm library (like STL), no templates, few non-numeric libraries (e.g. http, json...) and (as above) buggy compilers. Furthermore, C++ gives you much more control over numerical speed when you need it.

<comment><USER4> "It has horrible string support", this is untrue. Learn Fortran 2003, 2008, 2018.

<comment><USER3> What? Where is this good string support in Fortran 2003, 2008 and 2018? I must have missed it in the manual. Now you can allocate a string of a non fixed size - simply amazing technology! Actually, one of my compiler crashes was trying to use this revolutionary feature.

<comment><USER5> > Now you can allocate a string of a non fixed size - simply amazing > technology!

That's more than what C gives you out of the box ;)

<comment><USER6> Many languages forbid mutable strings. They aren't really a very good idea, imo. Even less of a good idea are extensible strings. More complex data structures are required for efficient extensible strings, and this complexity shouldn't be hidden in a simple interface. Better to have a Buffer type or something that is distinct from the String type so programmers are made aware of the performance/allocation characteristics.

Though, this is kind of ridiculous to even talk about, since the CPU and compiler itself are responsible for the greatest sins of hiding something unimaginably complex behind a simple interface.

Ah, the joys of the 6502 and the Commodore 64!

<comment><USER7> Delphi had mutable xor aliased strings. That is really great. Each function can change the string as fast as a mutable string, but once it shared with other functions, they can be certain that it will not be changed randomly

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> It's nice to see an article that makes assumptions and then realizing that they didn't really work out and walking back on them. It's often good to try rewriting things, but often the thing you think is old and crusty (FORTRAN) is actually quite good, perhaps in ways you weren't aware of. So it's important to be able to say, "yes I tried some nice new thing, it didn't really work out how I had expected, also some of my assumptions I started off with were not really correct either and I might not have made a fair comparison".

</comment><comment><USER9> I find it remarkable that one person with just over a year of Rust experience can successfully rewrite ~6000 lines of well-tested, highly tuned Fortran in Rust and end up with similar performance on benchmarks without having in-depth expertise in the domain (simulation of fluid dynamics). The benchmarks ([https://mckeogh.tech/post/shallow- water/84896735-54a97580-b0...](https://mckeogh.tech/post/shallow- water/84896735-54a97580-b09c-11ea-9e61-6b3fcd37a3cd.jpg)) show similar performance across all input sizes for both the old Fortran and the new Rust code, with Fortran outperforming in some cases and Rust outperforming in others.

<comment><USER10> Actually closer to 4 years of experience:

> As for my Rust experience, I've been using it for personal projects since > ~2016 and I worked as a Rust software engineer at a startup in Berlin for a > year after leaving high school.

Publish date on this blog post: July 14th, 2020

</comment></comment><comment><USER11> This is an interesting article. I have often wondered if there would be benefits to porting scientific simulation codes to more modern languages. In the end I've always reluctantly stayed in C or Fortran for scientific simulations. The article touched on the some of the issues (and the ever present issue of "If it isn't broke, don't fix it"). But I do think that the article ignored what I think is the biggest issue.

To me the biggest issue is that some simulations just need to run on 1000s or hundreds of 1000s of cores, and the primary technology that lets this happen is MPI (Message Passing Interface). I've been writing new Fortran code only because I want the simulation to be able to scale to this kind of size. The issue is that MPI only has official bindings for C and Fortran, so the only real choice I have is to keep programing in C or Fortran if I want to use MPI.

Any thoughts on this? Personally I would love to move towards more modern languages but without the proper libraries it is still a tough decision.

<comment><USER12> Rust can bind to C libraries, as can many other languages.

<comment><USER11> I have looked into this a bit, but the issue appears to be that MPI is not a library per se but a standard interface to more underlying function calls. Different implementations of MPI are in effect different libraries using the same API, and because of that it is difficult to write general bindings rather than just bindings to a particular version of an MPI library that is implemented on a particular supercomputer. In short, it's too site specific and fragile, unfortunately. If you change the system, the program might no longer compile. I appreciate the comment and feedback, though.

This Stack Overflow page comments more on this issue:

[https://stackoverflow.com/questions/22949462/rust-on-grid- co...](https://stackoverflow.com/questions/22949462/rust-on-grid- computing/24913447)

<comment><USER4> MPI officially supports only C and Fortran. Anything else for any other language can be only considered as adventures of some open-source developers, that may not last forever. Take a look at the fate of the C++ bindings for MPI.

</comment></comment></comment></comment><comment><USER13> This is a really cool post, but I wish the author had profiled his code. He makes several statements like "I think the performance issue is XYZ" but never bothers to check if his guess is correct. As Walter Bright liked to say, Use the profiler, Luke!

</comment><comment><USER14> Nice article. I'm curious which Fortran compiler did you use? One key difference that I see in the context of this article is that Fortran is natively parallel (both shared and distributed memory) via coarrays, teams, and events, whereas Rust (and Rayon), as far as I can tell, is shared-memory only. For applications that need to run on 100s or 1000s of cores, Rust needs to bind with C MPI. Is there any other approach to distributed-memory parallelism in Rust?

Good points on the lack of certain features and ergonomic libraries. We're working hard on making this much better for Fortran [1] by developing a community-driven stdlib, package manager, and similar tools.

In fact, we'll have our monthly community call tomorrow [2] where we'll discuss the best way forward for a nice strings API in Fortran stdlib. I welcome everybody interested to join the call.

[1]: [https://fortran-lang.org](https://fortran-lang.org) [2]: [https://fortran-lang.discourse.group/t/fortran-monthly- call-...](https://fortran-lang.discourse.group/t/fortran-monthly-call- july-2020/195)

</comment><comment><USER15> This is interesting, I did write BLAS in Rust [https://github.com/schultzer/libblas](https://github.com/schultzer/libblas) it's only single threaded at the moment.

I feel people forget to ask a more important question before they start a full rewrite and that is: Where is the hardware trends going and, is dedicated GPU, CUDA etc. even the future.

I feel it would be wasteful to spend a lot of time writing GPU specific code, Its not really maintainable on these scientific project (where only a select few people contribute, usually people that do the research).

</comment><comment><USER16> The author says he's happy with the performance improvements he made, but-- even at the size where the Rust version performs best--he gets much less than a 2x speedup. After a couple months of effort, that's not a whole lot to show. This reads like a case study in why it's probably a bad idea to rewrite even when you think you have compelling reason for it.

<comment><USER17> Also the author has not used state of the art compilers like XL, Intel and PGI.

<comment><USER14> Indeed, and this depends between applications. For the WRF (Weather Research and Forecasting) model, I get 3-4x speed up with Intel Fortran compiler over gfortran. I don't see where the Author mentions the Fortran compiler used, though.

<comment><USER18> > I get 3-4x speed up with Intel Fortran compiler over gfortran

Wow, even at similar optimization levels? -O3 for each?

<comment><USER14> Not quite, but at optimization levels set by default WRF configuration for each compiler (definitely not a fair comparison):

gfortran: -O2 -ftree-vectorize -funroll-loops ifort: -O3

I don't have the timing results anymore. This was in 2018 on Xeon Platinum 8168.

I recently tried replacing -O2 with -Ofast -ffast-math to gfortran settings, which gives about 18% speed up. So still far from Intel. I recently proposed it here [1].

[1] [https://github.com/wrf-model/WRF/issues/1254](https://github.com/wrf- model/WRF/issues/1254)

<comment><USER19> Have you posted about this on the gfortran mailing lists? They are generally interested in examples that show where the compiler could be improved.

<comment><USER20> I doubt they are short on inspiration for further improvements. A big part of the speed advantage of ifort is the aggressive loop unrolling, pipelining, splitting and multiversioning.

Coming up with these transformations is not the difficult part. That would be actually implementing these transformations correctly and keep the whole compiler optimization framework maintainable.

And of course there is certainly a cost for the improved runtime. Primarily in compile time and code size. For the Intel compiler it generally makes sense to sacrifice these in favor of runtime performance, because it is used on these kind of scientific codes a lot, but for gfortran the balance might different.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Already mentioned on the Reddit thread, the author apparently isn't aware of modern Fortran capabilities, IDE tooling support, NVidia and Intel offerings for GPGPU programming or HPC.

</comment><comment><USER21> PGI's Fortran compiler, bought by NVidia a few years ago, has excellent GPU extensions. You set an attribute on an array, move stuff on there, do your computation, move stuff back. It was the easiest GPU coding experience I've had.

</comment><comment><USER22> Nice post!

I have written several versions of a scientific simulation program in python, first using MPI (single machine) and then native multiprocessing. Using numpy and Pandas for all the heavy data operations. I really valued the ergonomics of python and native multiprocessing and found the MPI code to be not very human friendly. However, I ran into some very strange bugs relating to MKL and multiprocessing that just hung the program on large input sizes with MKL_NUM_THREADS above 1. I also had to bounce the input data to the worker processes to files due to mp not being able to pickle data when it got too large.

As soon as Apache arrow support in rust gets more feature complete I'll probably try to redo it there.

</comment><comment><USER23> TL;DR: wanted to leverage GPUs for computation (but couldn't), the ergonomics of arrays in Rust for scientific computing without the use of ndarray are not good, had memory bandwidth issues to keep cache lines fed, performance of the two implementations is comparable

One of the things I find interesting is how the Fortran version is faster both with small and huge inputs, while the Rust version is faster for input sizes in the middle.

</comment><comment><USER24> In my experience... Reinventing (or rewriting) the wheel is a fun exercise. It's even more fun to write it in rust (biased). Occasionally, the new wheel is better. Mostly, I learn how some of my assumptions were wrong and/or how I didn't even account for "this, that, and the other."

That said, I enjoyed reading through and finding "Edit: I was wrong about X." Learning experiences all around!

Also, might have been mentioned but is this a typo?

> I'm guessing that FORTRAN is faster on small inputs due to the threading > overheads, but faster on large inputs

Anyways, thanks! Enjoyed the article!

</comment><comment><USER25> > Having written parallel software in both C and Rust, the memory safety > guarantees and easy parallelisation with Rayon offered by Rust contrasts > quite sharply with my poor experience using OpenMP

While I appreciate the strive for safety, and the effort being put into the rewrite, I believe in that particular case it would be more beneficial to rewrite it in ATS with safe formally-proved C rewrites/known to be safe inlined C calls.

<comment><USER26> It seemed like this one area was a definite plus for the rewrite in Rust. I recently added some OpenMP goodness to some C++ code. Making the loops run parallel was almost trivial. The challenge was going over a couple thousand lines of code checking for safety. There were data structures being created and shared in various was but the code was written in a very functional style so it worked in the end. With Rust, all that analysis is done by the compiler. So for that code migrating to Rust is probably a good idea.

</comment></comment><comment><USER27> " I'm guessing that FORTRAN is faster on small inputs due to the threading overheads, but faster on large inputs because of contention between threads for cache lines and memory bandwidth"

I think the author meant FORTRAN was slower on small inputs?

<comment><USER23> Look at the graph (or the chart on the left, I had to to understand it): the green and blue lines cross _twice_ , first the FORTRAN version is faster, then the Rust one, then the FORTRAN version again.

</comment></comment><comment><USER28> New engineer thinking, want to do everything themself

</comment><comment><USER4> why? Why would you do so? Did you gain any significant improvement in your final results compared to the original software? Why would rewrite a software that already works fine, other than not having the will to learn a bit of a new language? Why???

<comment><USER29> All your questions are addressed in the article. It does turn out that some of the author's beliefs were incorrect (e.g., the state of Fortran GPU compute libraries), though, so it's possible that they would have come to a different conclusion had they known that.</comment></comment>


Google's new phones will be called the Pixel and the Pixel XL - <AUTHOR> http://www.androidpolice.com/2016/09/01/exclusive-googles-new-phones-will-be-called-the-pixel-and-pixel-xl/ <comment><USER2> So Google discontinues Pixel laptop ([http://arstechnica.com/gadgets/2016/08/google- discontinues-t...](http://arstechnica.com/gadgets/2016/08/google-discontinues- the-chromebook-pixel-2-without-replacing-it/)) which is very disappointing by the way (I have 2015 Pixel LS running Ubuntu - best laptop ever had) and then renames well known Nexus phones as Pixels? This cannot get more confusing and I just don't understand their reasoning.

<comment><USER3> They already released a Pixel tablet that ran Android so this latest move actually reduces confusion (on the assumption that ChromeOS is getting absorbed into Android going forward).

</comment></comment><comment><USER4> This seems like such an odd move to me seeing as Google has made a much greater effort over the last year in marketing the Nexus line of phones. Sure, the Nexus line still isn't exactly a household name, but I'm sure it's more well known than the Pixel line.

I've had the pleasure of using my friend's Pixel C and 2015 Chromebook Pixel and was thoroughly impressed with both from an industrial design perspective. I personally find the Chromebook Pixel even better looking than the MacBook Pro I'm currently using. The Pixel design team really seems to know what they're doing, which makes me disappointed that this year's Nexus(now Pixel) phones look to be heavily derivative of HTC's hardware rather than having a more original design as employed by the rest of the Pixel line.

I can see why Google wants to make a Pixel phone, and after seeing the other Pixel products I want them to make one too, but it seems strange that they would choose to rename this year's upcoming phones when they are following the usual Nexus blueprint of being heavily based on a partner's design rather than purely Google's own. This is of course assuming the leaks I've seen regarding the new Nexus/Pixel phones prove to be accurate.</comment>


The Complete Guide to Mobile App Development Timelines - <AUTHOR> https://da-14.com/blog/complete-guide-mobile-app-development-timelines <comment><USER2> [http://www.onlinecourses.store/the-complete- ios-10-developer...](http://www.onlinecourses.store/the-complete- ios-10-developer-course-build-21-apps) is an excellent course, it is very complete.</comment>


Verizon Will Charge $2 To Pay Bill Online Or By Phone - <AUTHOR> http://www.npr.org/blogs/thetwo-way/2011/12/29/144444008/verizon-will-charge-2-to-pay-bill-online-or-by-phone?ft=1&f=1001

<comment><USER2> I cannot imagine why a one-time credit card payment would be more costly than processing a payment mailed in an envelope.</comment>


Ubuntu Is Planning to Make the ZFS File-System a "Standard" Offering - <AUTHOR> http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-ZFS-Standard-Plans <comment><USER2> This is simply awesome. ZFS is a killer file system.

I so wish Oracle would change the license on ZFS.</comment>


The Girls Next Door  - <AUTHOR> http://www.5280.com/girlsnextdoor/?src=longreads&mc_cid=54948c4afe&mc_eid=99af5e345c <comment><USER2> Took me a while to realize: you have to scroll down to see the content.

<comment><USER3> In Chrome, it doesn't scroll. It appears to be only the image and the headline. (Edit: nope, nor Firefox either, for me)

<comment><USER4> It does scroll in Chrome. However, you have to scroll for a bit before anything beyond the scrollbar changes.

</comment></comment></comment><comment><USER5> Slavery in America is something that really needs to be discussed openly and in free society. People believing that slavery doesn't/can't exist in their modern world really need to be exposed to the truth: there is more slavery now than there ever was.

<comment><USER6> When you say there's more slavery now than there ever was I can't tell whether you're exaggerating or know something that I don't. As far as America goes, it seems like a stark difference between now and 150 years ago when 13% of the population consisted of slaves [0]. If you're referring to third world countries that's more understandable due to the number of young workers building products for wealthier countries.

[0] [http://en.wikipedia.org/wiki/1860_United_States_Census](http://en.wikipedia.org/wiki/1860_United_States_Census)

<comment><USER5> [http://www.globalslaveryindex.org/report/](http://www.globalslaveryindex.org/report/)

It is estimated that the US has 60,000 slaves _today_ , per definition. So no, its not over yet in the US.

However, world-wide: approximately 30 million people fit the definition of enslaved humans.

One thing, though: the US Prison System is considered by some to be industrialized slavery. If this is included in the statistics, the US enslavement index goes way, way up.</comment></comment></comment>


The America Invents Act's Patent Reform Might Strengthen Patent Trolls - <AUTHOR> http://www.litigationandtrial.com/2011/07/articles/attorney/patent-infringement/the-america-invents-act-and-patent-trolls/

<comment><USER2> His argument makes no sense. The argument is that the Act might make it more expensive to get a patent (because it makes it easier for third parties to make the patent go through extra review). Small entities might not be able to afford that, so might not get as many patents, whereas large or well funded entities will be able to afford to go through the process. He gives Intellectual Ventures as an example of a large entity that will be largely unaffected by this.

First, he's wrong that IV will be unaffected. True, they can afford the cost of extra review, and so if all the extra review did was raise costs then they would be unaffected as far as their ability to get patents goes. However, that's not all the extra review does. The extra review will also cause some patents to be rejected that otherwise would have been issued. That will affect everyone who tries to get patents that are not novel or non-obvious to one skilled in the art, regardless of their size and ability to pay for the more costly procedures.

Second, even if the Act merely weakens small trolls, and leaves larger trolls untouched, that still has overall weakened trolls. No patent troll is strengthened by the Act.

Third, most troll patents come from small entities. The large trolls buy most of their patents from small entities or individual inventors. IV does do a significant amount of original research and gets patents on it, but those only comprise a few percent of their portfolio.

<comment><USER3> Bear in mind that Congress hasn't done anything to change the types of things that can be patented; under the Act, the patent for thermal refreshing of bread would still be appropriate. Software patents are still all the same.

The critical part there is how, as you noted, "most troll patents come from small entities." Raising the cost and time of obtaining a patent will have only a modest effect in stopping people from attempting to file for these weak patents, but will have a major effect in compelling them to assign the patents to larger, better-capitalized entities with greater capabilities in pushing the patents through the process, like IV.

It is counterintuitive. I wouldn't have thought this would be the result had I not seen the same thing happen in securities litigation: Congress attacked the nuisance suits and ended up making the biggest securities law firms far stronger and more profitable. Counterintuitive, but demonstrated empirically in another field.

</comment></comment><comment><USER4> There is a recent article by PIA: <http://truereform.piausa.org/> where they claim mostly the same.</comment>