The Case for Abolishing Patents (Yes, All of Them)  - <AUTHOR> http://m.theatlantic.com/business/archive/2012/09/the-case-for-abolishing-patents-yes-all-of-them/262913/ <comment><USER2> Frequently overlooked -- American companies are _huge_ net-exporters of IP, IP licenses, and IP-protected stuff.

Take the recent Apple/Samsung fiasco, for instance. That's a net cash transfer of over $1B from the South Korean economy to the American economy. Maybe $2B to $3B total when accounting for all the factors.

Is that good? No, it's disgraceful, actually. But good luck convincing American legislators of some abstract far-future benefits to a less regulated world when the short-term result would be a worsening of the trade-deficit, a lowering of American exports, and a lowering of American income and tax yields.

It's a _huge_ factor that's usually overlooked in these discussions -- the United States isn't a closed system.

<comment><USER3> Remember theres a difference between getting rid of patents and getting rid of intellectual property.

I don't think anyone is serious about suggesting we get rid of intellectual property; if you're create something, there should be protections to stop people ripping off your stuff and selling it without paying you for it.

It's _patents_ that are the problem.

Patents let you capture an idea and prevent people from creating new things.

That's not protecting something you've created; it's stifling the creative will of others, because you don't want anyone to compete with you. It's the legislative antithesis of the open market.

Notch wrote about this before too, thoughtfully: <http://notch.tumblr.com/post/27751395263/on-patents>

The US could happily continue to have an major IP 'exports' (however that is appropriately referred to) without patents.

<comment><USER4> I disagree that there should be protections to stop people from "ripping off your stuff" and selling it without paying you for it. Instead, there should be protections to stop people from copying your idea without you getting credit for it. But there don't need to be legal protections. All you need to do is make your idea public to prevent anyone else from claiming they were first.

I'm serious about getting rid of all patents and all copyrights.

<comment><USER5> I don't understand.

Say I pay a Valve employee a million dollars for the current working source- code of Half-Life 3. I then compile it and release the first couple working levels for $10 a pop... I should easily be able to make 50 million out of that exercise.

What protections would Valve have in your no-copyright, no-ip scenario?

<comment><USER4> I'm not anti-trade secrets. In your scenario, the source code to Half-Life 3 is a trade secret that the Valve employee is obligated to keep. However, if the code is ever made publicly available to read, it's no longer a secret and no money should be made from selling or licensing it. And even if the source is never public, once binaries are made public, it should be perfectly legal to reverse engineer those binaries.

In a no-copyright world, Valve's business model would certainly have to change, but your particular example would work mostly the same as it does now. The major difference is that you wouldn't be able to make 50 million dollars. Once those levels were released, people would be able to share them freely among themselves. Only the first person has to pay the $10, which means if you're willing to pay a million dollars for illegal access to secret source code, you should probably have a better plan for what to do with it. =P

<comment><USER5> > Once those levels were released, people would be able to share them freely > among themselves

> In a no-copyright world, Valve's business model would certainly have to > change

Yes it would have to change. Honestly I don't think you've thought this all the way through.

You need to show how companies like Apple, Microsoft, Valve and the thousands of smaller software makers (Adobe, Autodesk, Bethesda, Roxio, Zynga, IBM, Oracle, Blizzard, Symantec, Norton, SalesForce.com, Konami, Blackboard...) can still make as much money as they do today and have the same protections they have today.

If you can't well, then we may as well sit around discussing what the world would be like if there was no war, or what kind of tidal waves two moons would generate.

</comment></comment></comment></comment></comment></comment><comment><USER6> > The poster child for strong patent protection is usually the pharmaceutical > industry, as drugs are easily copied and can cost upwards of a billion > dollars to develop. Here, Boldrin and Levine admit that the government would > likely need to step in. But rather than giving companies a legal monopoly > over their formulas, the authors suggest we should modify the drug approval > process to let makers start recouping their costs faster. They would also > set up a prize system to reward companies that invent the new medicines we > need.

This strikes me as a really fantastic idea. Actually, I wonder if insurance companies shouldn't offer these prizes regardless of the patent situation. They know intimately well which disorders cost them the most money. They could form a consortium and offer a prize for x amount of money for reducing the cost of treating some disorder by y dollars per patient, where x is guaranteed to be less than the amount of money they will save.

<comment><USER7> I'm always astonished by the idea that, were it not for patents and the profits they promise, "no motivation to develop drugs would exist".

At one point I worked with a group that raised money to finance medical research for patients with lupus. These were folks who were seen as too few, and suffering from something too complex, to be profitable. For the most part they were relying on some pretty toxic treatments that hadn't progressed since the 1950's - the pharmaceutical equivalent of pre-anastasia surgery.

Believe me, the people suffering from this were HIGHLY motivated to find a cure, and given an organization capable of focusing that interest, they've raised millions upon millions of dollars* to do exactly that. This was an early form of crowd-funding and it just obliterates the argument that "without patents, there's no motivation to cure stuff."

I'm sorry, but that is absolutely, categorically, and demonstrably false. If people are sick and dying, they have bottomless motivation. Indeed, the extraordinarily high prices people people put on their own lives ("my kingdom for a horse!") represents a profound reservoir of motivation.

The patent and approval system diffuses this deep and natural drive, replacing it with the more limited motivation offered by monopolistic rent-seeking (which aims not to cure disease, but to make it 'manageable').

The thing about an awful disease is that it develops a sense of community. I cannot imagine, for instance, someone who has raised a lot of money to find a cure saying, "yeah, but fuck the next generation that comes along and gets hit with the same affliction - those guys are on their own. WE paid for this, and the cure is OURS. They can reinvent their own damn wheel if they want to live."

Just...no, that's not how people think. What they _really_ think is that in devoting themselves to finding a cure, they are finding a valuable role for themselves in a society that tends to see them as victims. It's how they recover a sense of self-worth and dignity. They are PROUD to pay it forward. Indeed, one of the top sentiments I heard from people I interviewed was "I want to find a cure so that no one else anywhere in the world ever has to suffer what I've gone through because NOBODY deserves this."

THAT's what real decency sounds like. And it's what our patent system frustrates in a very profound way. I know the pharmaceutical industry is always brought up as the tough case against patent reform - the exception that "must" be made in any discussions tending towards to liberalization. I'd argue the opposite. I'd say that this is one of the easiest cases to make. Maybe not a decade ago, but as the organizing power of the internet comes into focus, I can see a world where direct and massively distributed research finance is the norm, with the results made openly available to the entire world.

People who are sick used to feel terribly isolated. Thanks to the internet, that's changing. They're finding they discover others going through the same thing, and that they can use the same channels to pool their resources. Were they given tax credits, their resources would increase substantially. And they don't want to "manage" their diseases. They want to cure them. Researchers working on behalf of people trying to solve their own problem pursue tacks different from those who are working from companies looking to exploit that problem most profitably. And when people finding their own cures succede, their natural impulse is to share their triumph with all mankind, the world over, not start trade wars over IP that use the pain and death of millions already in - or facing - poverty as leverage.

*People who say research costs billions, not millions have been suckered by the most pernicious line of bullshit imaginable. The "billions" figure does not represent actual R&D costs, which, in a shocking number of cases, represent single-digit percentages of pharmaceutical company budgets. Instead, they represent the fully loaded costs of maintain legal departments to protect patents and marketing departments to push drugs in cases where they have marginal or negative value. Inflating the reported development costs into the billions is simply propaganda designed to make any system that doesn't involve patents seem like a financial impossibility.

<comment><USER8> Tens of millions of dollars won't get a drug to market. Will it fund research that could find useful leads that could produce a drug? Of course.

So how do you incentive private organizations to fork over the $100 million(1) or so it takes to get a drug to market? You provide a mechanism to regain your capital plus something more. It's a system that works pretty well.

(1) That's if everything works the first time. Since only 1 out of 10 drugs that are tested on humans get to market, it's closer to $1 billion on average.

<comment><USER7> "it's closer to $1 billion on average."

As mentioned, that's a hugely suspicious "fact". As noted by the National Center for Biotechnology Information.

"In the March 2003 edition of the Journal of Health Economics, a trio of economists from the United States wrote about a number. Soon after, that number began popping up all over the place — in newspapers and political speeches, on television and the Internet. But the figure, despite reaching near-canonical status, drew criticism. Some said it was inflated. Less diplomatic detractors said it was a 9-digit fairy tale.

That number was 802,000,000. It was, according to the 2003 study, the number of US dollars that pharmaceutical companies spent, on average, to bring a new drug to market (J Health Econ 2003;22[2]:151-85). Now there are new numbers. Some health economists peg the current cost of drug development at US$1.3 billion, others at US$1.7 billion."

Full article here.

<http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2630351/>

Key point: the data used to come up with the original number came from an industry financed source and was not made public. And here's a bit more coverage that throws additional cold water on 10 figure costs.

[http://www.theglobeandmail.com/life/health-and- fitness/drug-...](http://www.theglobeandmail.com/life/health-and-fitness/drug- rd-costs-are-less-than-estimated---so-why-the-high-prices/article623054/)

While the actual costs remain unknown, it's a safe bet that they're nothing like the inflated figures being circulated by the industry.

<comment><USER8> I agree that the numbers thrown around are often a lot of hand waving. However, let me make a few points few points.

1\. Check out the Tufts Center for the Study of Drug Development. They calculate the cost to create a new drug and their methodology is very transparent.

<http://csdd.tufts.edu/research/research_milestones>

2\. You can do a simple sniff test on these numbers. Simply call up a CRO that runs clinical trials and ask "What will it cost me to run a Phase III clinical trial?" I did this recently for a project I was working on. They will freely give the numbers about since they are all in competition with each other.

This is what a recent survey of CROs found[1]: "As for the average per-patient trial costs across all therapeutic areas, in Phase I, costs rose from $15,023 in 2008 to $21,883 in 2011. In Phase II, the cost rose from $21,009 to $36,070. In Phase IIIa, the cost increased from $25,280 to $47,523 and in Phase IIIb, cost jumped from $25,707 to $47,095. Finally, Phase IV expenses rose from $13,011 to $17.042."

Let's do some simple calculations. 1000 patients, 1 year trial. You need to complete two Phase III trials to keep the FDA happy.

1000 patients * $47,000 * 2 = $94M

And that's only for phase III trials. Add in the cost of discovery, pre- clinical work, formulation, Phase I, Phase II, all the paperwork with the FDA.

OK, great, now you're approved, you still need to actually _make_ the drug which includes scale-up, testing, FDA certification of the manufacturing process, packing and distribution.

When I was working at a big pharma company, I heard about a new manufacturing site they had built in anticipation of a really big drug being approved. The cost? Several hundred million dollars. What happen when the drug got rejected by the FDA? The manufacturing site was written off (couldn't really be used to make anything else).

That's why your drugs cost so much.

[1][http://www.pharmalot.com/2011/07/clinical-trial-costs-for- ea...](http://www.pharmalot.com/2011/07/clinical-trial-costs-for-each-patient- rose-rapidly/)

<comment><AUTHOR> I have heard that drug patents are trivially circumvented by adding some irrelevant part to the active molecule. Instead it is the FDA approval process that prevents ripoffs.

Doesn't that mean pharma is the one industry where patents could be abolished with literally no consequence?

<comment><USER8> It is true that you can get around a patent by creating a slightly different molecule. However, drug companies aren't stupid. When they patent a drug, they are patenting a pretty big space around their molecule of interest. Pretty much every modification you can think of, they will patent. The resulting patents aren't just one molecule but rather an IP "space".

</comment></comment></comment></comment></comment></comment></comment><comment><USER9>
      As long as they still cranked out out new, popular
      products, companies like Apple would continue to profit by
      being the first to market, which often confers a long-term
      advantage.

_Apple_ being first to market? When has Apple ever produced anything novel? Personal computers, MP3 players, smartphones, and tablets; were all invented by other companies. Apple's virtue is superior _execution_ , not being first to market.

<comment><USER10> They didn't invent the tablet, they invented the tablet as we know it. It consider that to be a much harder thing to do. The concept of the tablet hardly needed inventing, just watch Star Trek, it was pretty obvious. The less obvious is the "how" (what you call the execution).

<comment><USER11> I agree; it's a point often overlooked that execution can be innovation in and of itself.

</comment></comment></comment><comment><USER12> So the argument here isn't that a patent system is inherently bad; you _could_ have a patent system that provides a net win for society. But over time, entrenched interests will find ways to twist the system to their advantage, at the expense of society at large.

Let's say this is true; how is this different from any government action in the marketplace? From education to finance to healthcare, we're confronted with problems that have may have good theoretical solutions by government, but the reality is that our solutions will eventually devolve to rent-seeking and regulatory capture by powerful entrenched interests. I have yet to hear a good solution to this problem other than severely limiting the ability of the government to interfere with markets in the first place.

<comment><USER13> Stop electing assholes to public office.

<comment><USER14> The people I've known personally who've tried (and sometimes succeeded, one of them was a member of the European Parliament, my old Irish teacher Sean O'Neachtain) to get into public office have all been pompous assholes. You don't really get much of a choice.

</comment></comment></comment><comment><USER15> It's an interesting thought experiment. If all patents disappeared tomorrow, what would you do differently at your startup? Probably nothing?

<comment><USER16> I would be less afraid.

<comment><USER17> This. One of the biggest risks I would see in a startup these days is that the moment you start to be successful or even just get decent funding there's a decent chance you will be patent trolled out of existence.

<comment><USER18> I assume you've quantified that statistical probability to support your declaration that there's a "decent chance"?

<comment><USER16> The whole point is that its very difficult to quantify. The purpose of government, law, and indeed perhaps civilization itself is to reduce the amount of random, unquantifiable risks in daily life.

That's whats so bad about patent trolling. Its just so _uncivilized_.

<comment><USER18> zm didn't say it was difficult to quantify. He said there was a "decent chance" of being sued. The implication is that he has quantified it and that quantity amounts to a "decent chance."

<comment><USER19> Oh? Well, if "decent" is a quantity then perhaps you can give us the number he's implying.

<comment><USER18> "decent chance" implies you have quantified the probability and concluded it is somewhere between unlikely and likely. It needn't be precise, but it implies a quantity. There is a 0.001% chance of my dying in a car accident this year. If someone said "you shouldn't move to the suburbs because there is a decent chance you'll die commuting" you'd probably shrug that off as hyperbole. There is a 1-3% chance of pregnancy each year despite use of birth control. Would you say "there is a decent chance of knocking up your girlfriend even with condom use?" Possibly, but I think most people consider that probability "remote" rather than "decent." There is a 10% chance of being audited as a small business. Is that "decent"? I think most people would say "keep your books carefully, there is a decent chance of yor being audited."

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> 1\. Software costs next to nothing to produce. Why is it so easy to have startups in this sector? What is the overhead of a software/web company? It is almost all intellectual. Ask Microsoft. Pure profit.

2\. It is difficult for examiners to find prior art because there is no "official" channel for "publishing" software research that they recognise. There is much know-how that is common knowledge among developers but is never published in any paper, textbook, standard, RFC, etc. The "database" for searching all these sources may end being a web search engine. That is not ideal.

1\. Drugs are very expensive to produce. Not only the research, the equipment, the staff, but compliance with the regulatory regime. There are no protections against bad software to protect users (developers operate in a wild west type atmosphere), but we have many rules about medicines. These are designed to protect patients. Can you imagine an unregulated pharma industry? Profits take precedence over safety. It would be very dangerous for patients.

2\. There is a littany of journals that public chemical, biological and medical research and they can all be searched easily in combined databases, to which most all pharmaceutical patent owners subscribe. It is not too difficult for examiners to find prior art and establish publication dates.

These are my thoughts.

<comment><USER21> > 1\. Software costs next to nothing to produce. Why is it so easy to have > startups in this sector? What is the overhead of a software/web company? It > is almost all intellectual. Ask Microsoft. Pure profit.

I'd argue software is extremelty expensive to produce, on the basis that distributing software is so insignificantly expensive that it could be called free. Relative to the costs of distribution, paying developers to write an application is extraordinarily expensive. So is maintaining that code, providing support, and advertising the product. I'd "guess" startups are so abundant in the software sector because distribution is so cheap, not because development is. Entering any other market's distribution channels on an international scale is prohibitively expensive for almost anyone but an already successful mid-sized company.

> 2\. It is difficult for examiners to find prior art because there is no > "official" channel for "publishing" software research that they recognise. > There is much know-how that is common knowledge among developers but is > never published in any paper, textbook, standard, RFC, etc. The "database" > for searching all these sources may end being a web search engine. That is > not ideal.

Even more fundamentally, it is hard to find prior art because software is information / knowledge and traditionally (in the context of math at least) we never had patents on it. If you consider the physical properties of software, it is just the presence of absence of charge over billions of indicants. Does the interface that _exactly_ duplicates the ios home screen but has a binary representation that is nothing like the disassembly of it represent infringement, or the instant messenger whose disassembly looks 95% like the ios home screen? What happens when a music track and an android map are 90% binary identical?

> 1\. Drugs are very expensive to produce. Not only the research, the > equipment, the staff, but compliance with the regulatory regime. There are > no protections against bad software to protect users (developers operate in > a wild west type atmosphere), but we have many rules about medicines. These > are designed to protect patients. Can you imagine an unregulated pharma > industry? Profits take precedence over safety. It would be very dangerous > for patients.

Absolutely you need to regulate the pharma industry somewhat, but I would also argue it is a consumers responsibility to know what they are putting in their bodies. We expect people to be able to judge their own alcohol consumption, how are prescriptions any different? If you make knowledge easily and readily available on what drugs do and their effects, consumers could make informed decisions. A lot of the fears in the phara industry is in how close-boxed knowledge is - you assume your doctor knows best, and don't investigate the effects of drugs you consume. I'd call it foolish to not understand the risks of what you are consuming.

> 2\. There is a littany of journals that public chemical, biological and > medical research and they can all be searched easily in combined databases, > to which most all pharmaceutical patent owners subscribe. It is not too > difficult for examiners to find prior art and establish publication dates.

That doesn't mean that a government granted monopoly on drugs is a good thing. When the expenses of drug research (which end up significantly being the rigorous 3 phase testing drugs need to pass to be allowed to be sold to end users) are so high, and profit motive is involved, drug costs spiral out of control. For Americans like myself without health insurance, we just can't afford to buy any of these drugs even with a prescription because they can cost upwards of $200 or more a bottle. The fact the actual drugs only cost at most a few dollars to produce per bottle, so the rest is profit to recoup research costs, doesn't help the fact that the good is cheap to make and is artificially expensive to recoup tremendous research costs. One (not me, but it is a theoretical) might argue that the R&D of a to-market drug could be just paid in full to whoever developed it, and that the formula itself could be released public domain. Taxes go up, drugs are cheap.

<comment><USER22> The key is that software development is an unavoidable _sunk_ cost. Once it has been paid, it can be ignored in terms of considering per-unit pricing.

The actual marginal cost of each unit of software sold is pretty close to zero. This is what makes it so fantastically profitable compared to almost anything else.

<comment><USER23> The same is true of most drugs. Marginal cost is near zero compared to development cost.

In neither case do you necessarily have fantastic profits although if you can sell at scale at a good price it becomes very likely but if you have a drug for a niche market or software in a crowded market it is quite possible to make a loss.

This is neither an argument for or against the patent abolition proposition which I am torn on. I can definitely imagine with alternative arrangements for Pharma we could be better off than currently but I believe that there must be something possible that is better than both what we have now and better than nothing.

<comment><USER21> I think in half a century we won't have the backwards investment funding model in industries where units are extremely cheap but R&D id expensive. Instead you would have something akin to crowdfunding with guarantees and insurance against failed investments by those that want the end product, so the motive is not profit, but end product. That people who want a _thing_ fund the creation of the thing, instead of people who want _money_ funding an expensive up front thing that is then unnaturally restricted with patents and copyright to try to profit off the unit sales, when in many cases (pharma) they are near free, or in the case of software (past the first copy being distributed) are absolutely free (if those that have the software willingly share it).

</comment></comment></comment></comment></comment><comment><USER24> Yes patents should be abolished. They are not good for the advancement of mankind as a whole.

</comment><comment><USER25> The patent system somehow has morphed from shield to sword.

Protecting inventors is one path toward innovation, but it should be a byproduct of maximizing innovation and not the end state.

If the objective of the patent system is to foster innovation, then it should grant patents only if they are necessary for innovation, i.e., innovation wouldn't reasonably occur otherwise.

Amazon's one-click patent versus drug patents are two good cases. If the patent system didn't exist, is it reasonable to think someone else would come up with a one-click method of shopping? Yes. Drugs, however, often require hundreds of millions of dollars in upfront investment. It is reasonable to think that pharma companies couldn't raise the necessary capital, and therefore invent these drugs, without some protection.

<comment><USER26> I like that idea, and I believe it rings true with most responsible people. However, it's difficult to measure.

As an example, in the recent Apple v/s Samsung, if it weren't for Apple, we would still be dealing with shitty Nokia, Samsung and Sony Ericsson phones with crap OSes, no decent applications, and the phones would be anything but smart - because there was no need to improve. Once Apple made everyone lift their game, their strategy has been to sue all large players aggressively to ensure they can't implement the things that Apple used, no matter how trivial (eg. the green telephone icon). On one hand you can argue that a "slide to unlock" was not done before on a smart-phone and deserves protection. On the other hand, you can argue that it's a very obvious solution for touch screens and someone else would have easily come up with it. You could also argue there's prior art (but that's another story). So ... In this instance, did Apple drive innovation? Yes. Was it necessary for Innovation? Maybe. Would the innovation have happened if Apple hadn't driven it? Not any time soon.

In my view, your definition needs to be tighter to cover scenarios such as these.

In case the Apple fans get their knickers in a knot, Apple aren't the only ones suing others over trivialities. The industry has been locked in a stale- mate for a long time.

<comment><USER27> "Would the innovation have happened if Apple hadn't driven it? Not any time soon."

I am fascinated by this statement. What evidence do you have to support it?

<comment><USER28> The entire mobile industry pre-iPhone?

This is and endless argument, you either acknowledge that they pushed it forward or you don't but there wasn't a significant application platform, touch was nearly nonexistent and even dismissed by RIM, and while many of these things might be dismissed as obvious, Apple made it stick and they beat the entire current crop of competitors to the market.

Everything is easy once you've seen it done...

Take the typical Nokia and Motorola device from 1997 and the typical one from the iPhone launch, biggest improvements? More SMS and the phones got a little bit smaller

<comment><USER27> I agree that apple did bring it all together rather well (over a sustained marketing and development phase) but I just don't see how anyone could think that smart phones similar to those that we have today weren't inevitable with or without apple.

<http://mobile.engadget.com/2006/02/21/review-cingular-8125/> This was released over a year before the first iphone.

I think that apple's contribution was not so much innovation as it was popularisation.

</comment></comment></comment></comment></comment><comment><USER29> At Open Science Summit 2010, there were a few individuals proposing some prize funds and reforming the patent system. The transcripts are a little rough (I was typing), but here goes..

Knowledge Ecology International: [http://diyhpl.us/wiki/transcripts/open- science-summit-2010/j...](http://diyhpl.us/wiki/transcripts/open-science- summit-2010/jamie-love-knowledge-ecology-international/) .. where he talks about an "open source dividend".

Health Impact Fund: [http://diyhpl.us/wiki/transcripts/open-science- summit-2010/a...](http://diyhpl.us/wiki/transcripts/open-science- summit-2010/aiden-hollis-health-impact-fund/)

</comment><comment><USER30> I'm unconvinced by their pharma argument. Some industries need patent protection. My preferred solution would be for the patent office to set different time limits for different industries, depending on the length of the innovation/commercialization cycle in that particular field.

So if it takes 10 years to develop a new drug and have it approved, give them 10 years of patent protection. If it takes a year to invent and perfect some user interface idea, give them a year's worth of patent protection.

Don't set the time limit on a case by case basis or everybody would claim to have thought about it for 30 years before it came to fruition.

</comment><comment><USER31> A good resource: [http://www.stephankinsella.com/category/intellectual- propert...](http://www.stephankinsella.com/category/intellectual-property/)

And innovations that thrive without IP: [http://www.stephankinsella.com/2010/08/innovations-that- thri...](http://www.stephankinsella.com/2010/08/innovations-that-thrive- without-ip/)

Also: [http://mises.org/media/categories/226/Against- Intellectual-P...](http://mises.org/media/categories/226/Against-Intellectual- Property)

and

<http://mises.org/journals/jls/15_2/15_2_1.pdf> [pdf]

</comment><comment><USER32> The pharmaceuticals industry could never have grown so big without patents. That kind of drug research would have had to been done by publicly-funded bodies, such as universities. I kind of feel like this is an argument in favor of this article. It also explains why it will never happen. Now that we have big-pharma how are we doing to disassemble the thing that keeps it alive?

<comment><USER33> Simple, recognize that pharaceuticals are a highly special case and develop a custom set of protections/incentives. There is already a mountain of custom regulation for that industry.

It's absurd to think that the same age-of-steam monopoly grant system that currently sorta benefits the pharmaceutical industry should also apply to software, websites, business methods, and exercising one's cat.

It's completely retarded. In the literal sense, i.e., holding progress back. End the retardedness now!

<comment><USER32> The reason I didn't suggest this is that industry-specific law feels like a byproduct of the lobbyist culture that has lead to many of our current problems and pre-existence doesn't justify its continued creation. But, overall, I think you're right and this is the pragmatic solution.

</comment></comment></comment><comment><USER34> Not all patents are by trolls or big corporates. Patents are crucial to medium size and small size firms. A healthy economy requires to create an environment for these firms to thrive. If you think big corporates are the ones to focus on, check out Germany: <http://www.economist.com/node/18061718>

</comment><comment><USER35> The fashion industry does quite well thank you WITHOUT patents. Check it out. No patents in fashion. The most you can do is copyright a logo and slap that on your product. The rest is open season, and we all are the richer for it. Patents only make lawyers rich at the expense of the rest of us (the 99%).

<comment><USER36> There is no meaningful comparison between the fashion industry and high technology. Keep in mind also that the fashion industry aggressively uses copyright, which last time I checked is also not too popular. That's why a lot of designer goods have a logo plastered all over them. If we abolished patents, there would be a short time span where everyone would prosper, but then eventually it would become clear that nobody is doing basic R&D, because it would be stolen by a competitor immediately. Also, I assure you there is no lawyer conspiracy. 99% of lawyers are in the 99%.

</comment></comment><comment><USER37> Thinking about this, the reverse might also work. Automate the process of granting patents such that patents are granted solely based on algorithms and prior art automated search. That way every one can get every patent immediately.

The work of the patent office then would be to validate the patents when there is a conflict, as a pre-requisite for a lawsuit. The office would have less work to do relatively I would think and hopefully would have more time to review the patents when they come to their desks that way.

</comment><comment><USER38> It's no news that patents and copyright obstruct the progress of science and society (nobody ever listents to Stallman?).

Now, acknowledging that is far from being enough to abolish them. The world revolves around companies making profit, it's naive to think that the government will agree to rule against the huge companies that currently benefit from those restrictions.

</comment><comment><USER39> I don't know how the US patent legislation is implemented but in many countries patents come with a compulsory license. That means that a patent holder cannot restrict others from using his invention. He only has the right to ask for the proper compensation. I think such a clause is imperative to truly have an effective means of promoting innovation.

</comment><comment><USER40> Is there a patent-free economy that is also as innovative as an otherwise comparable one with patents?

Is there another way to encourage innovation?

</comment><comment><USER41> Why take drastic steps like abolishing all patents. A big problem right now are software and design patents. If we're not willing to outright ban them, why not limit their term to 5 years?

</comment><comment><USER42> > Somebody out there actually patented a method for moving information through > the fifth dimension. As in the Bruce Willis movie. As in faster than the > speed of light.

Which movie is that, exactly?

</comment><comment><USER43> Immediately after abolishing patents, let's abolish Federal Reserve (who suggested the patent thing)

</comment><comment><USER44> The article summarizes the alleged benefits of patents as:

a) They improve productivity (I'm assuming this is somehow an Economic encapsulation of the benefit of technological progress, although AFAIK technological progress is essentially a Big Problem for economic analysis, and one of those things that Economists wave off as a pathological one-off event that ruins their assumptions, so I'm guessing it's A-OK for Economists to approximate technological progress -- something they can't really cope with -- as simply output / production cost).

b) They are an alternative to trade secrets, which is dismissed in a single paragraph with the argument that you'll only patent something you can't protect for longer with trade secrets (because, as a typical economic actor you are omniscient and can perfectly predict how long you'll be able to protect something with a patent vs. secrecy).

The follow-up paragraph says this (emphasis mine):

> A more subtle point is that secrecy may bias the type of inventive activity > away from innovations that are not easily kept secret to those that can be, > viceversa for patents. There is historical evidence from Moser [2004, 2005] > in this direction. In 19th Century expositions of inventions, while > countries without patent systems had overall rates of innovation similar to > those with a patent system, they did specialize in innovations which were > more easily kept secret. __How strong this bias would be if no countries had > patent systems – that is, whether it is true that patents encourage > innovations that would not otherwise be made, or if they just shift the > location of innovation from country to country – is not known. __

Oops. So this argument appears to be well-founded, and we don't know how big the effect is. Never mind, moving right along...

> A good case in point is that of the Wright brothers, who made a modest > improvement in existing flight technology which they kept secret until they > could lock it down on patents, then used their patents both to monopolize > the U.S. market and to prevent innovation for nearly 20 years.

Yes, there was no innovation in flight technology between 1903 and 1923.

> The modern and highly successful open source software movement is a more > contemporary example of how collaboration and exchange of ideas thrives > absent intellectual property.

This is where they lose me. OK they lost me a while back. Where is the great open source project which is so awesome everyone is imitating it? Open Source is great at commodifying innovations produced by others. We've got imitation Windows UI, imitation Mac UI, imitation iOS, imitation UNIX, imitation Microsoft Office, imitation Photoshop...

> On the other side of the coin, the rationale for patent systems is weak. In > most industries the first mover advantage and the competitive rents it > induces are substantial without patents. Again: the smart- phone industry – > laden as it is with patent litigation – is a case in point.

So, do they think Apple's first mover advantage would have been worth much if competitors had simply cloned everything it did? It was the delicate dance of ripping off Apple's ideas without crossing the line that created at least of the first mover advantage in this case.

I could go on and on -- the authors certainly do.

> In the case of patents, and particularly pharmaceutical patents, the > situation is even more severe. We have made mention of the loss of human > life due to the pricing of AIDS drugs.

Right, so kudos to the patent system for giving investors a reason to invest money and attention span to creating AIDS drugs, but once they're created they should sell them at break-even? Oh wait, no. No kudos to the patent system for the former -- they were inevitable. People like spending their money making stuff. It happens.

> A simple model helps to focus these thoughts. We suppose that there are two > firms i = 1,2 who must choose between innovating (I) and not innovating (N). > We have in mind here the creation of a new product, so that the choice to > innovate is paramount to entering the market – a firm that does not innovate > is assumed to have no product to sell.

Maybe if we do some pretend math it will make our thinking seem more rigorous. As something of a failed mathematician I like counter-examples. In this universe these guys are basing their entire theory on, the entire market for laundry soap does not exist.

It's just magical thinking.

</comment><comment><USER45> I saw the headline and the source and had one thought: "Finally"</comment>


An interstellar comet that split in two - <AUTHOR> https://www.syfy.com/syfywire/an-alien-comet-dropped-something-off-on-its-way-out-of-the-solar-system <comment><USER2> Kind of an underwhelming read: was this a lifeform dropping off? Most likely not. What was it? Probably ice melting ("calving") and the comment splitting in two. While I'm glad to have learned more, I kind of expected the data to keep going and more theories to build, instead it just goes "Well, we just don't know." I can admire that sometimes but it left me unsatisfied on this occasion.

<comment><USER3> We've taken out the baity bits above.

I bet this is a case where the article would have been more interesting if the title hadn't oversold it.

<comment><USER4> I went to grad school with the author, and I assure you that the title reflects his sense of humor, not over-selling.

<comment><USER3> That's great! Sometimes these things change meaning when they hop contextual boundaries. On HN, a title like that tends to backfire, at least once the story makes the front page.</comment></comment></comment></comment>


Sorry Linux Kubernetes is now the OS that matters - <AUTHOR> https://www.infoworld.com/article/3322120/kubernetes/sorry-linux-kubernetes-is-now-the-os-that-matters.html <comment><USER2> This is a stupid article. You need Linux to run Kubernetes, one (and the way it's configured is even more important given the thinner security barrier between containers and their host), and, two, not every workload will be suitable for containers or Kubernetes.

</comment><comment><USER3> This is really pushing it now. Kubernetes is great for numerous applications, but it is far from necessary in many applications too.

</comment><comment><USER4> Could someone help explain to me how kubernetes is actually an operating system?

I thought it had something to do with containers.

<comment><USER5> Guessing my OS, they mean just like back when the web was taking over and the web was the os, taking over from Windows. In this case, you don't build specifically for Linux, but for Kubernetes and it can be deployed anywhere, including Windows, eventually.</comment></comment>


Show HN: Use React to build G Suite dialogs and add-ons - <AUTHOR> https://github.com/enuchi/React-Google-Apps-Script <comment><AUTHOR> Been working on this side project for a while. Google Apps Script is Google's development platform for writing scripts for Google apps like Sheets, Docs, Slides etc. It also lets you load HTML pages inside window dialogs in these apps, so you can build a simple UI that can interact with, for example, a spreadsheet, or you can use these dialogs to create an add on and publish it in the G Suite marketplace for others to use.

When you load an HTML file, the window dialog environment provides you with a way to call functions you've written in Google Apps Script (basically, Javascript with access to Google APIs).

The drawback with Google's platform is the HTML file has to be a single page, and it can't load other scripts. Google's own documentation recommends using jquery and templates. Bah! Not good!

With the right webpack configuration and plugins you can build a complex React page that is bundled as a single HTML file, and load it into a dialog window. This project is a working demo of how to do that ([https://github.com/enuchi/React-Google-Apps- Script](https://github.com/enuchi/React-Google-Apps-Script)).

The trickiest part here is building a proper local development experience. What I ended up doing is creating a wrapper app that is loaded into the dialog window during development instead of the actual React app. The wrapper loads an iframe pointing at a localhost address, and then I use a modified version of Webpack Dev Server to serve the React app in development at that localhost address. I use a helper utility to call the server-side Google Apps Script functions directly in production, but tells the wrapper component to call the functions in development, so it behaves pretty much the same way in production and development. Okay, a bit hard to explain…

Here's a link to a quick video of using the development mode to actually hot reload the app inside a Google Sheets dialog. Trippy to see a Google Spreadsheet respond to local changes! [https://i.imgur.com/eR1s6FO.mp4](https://i.imgur.com/eR1s6FO.mp4)

<comment><USER2> Wow, not too long ago I tried to get a dev environment setup for working with GAS + Typescript and after a few hours of banging my head on things, I gave up because I couldn't get it working the way I wanted. This is fantastic. Thank you for doing this, I'll definitely try it out!

<comment><AUTHOR> Great! Haven't been a big Typescript user myself but seeing a lot of interest in it for GAS projects so included support for it in this project, and included a sample Typescript demo component.

</comment></comment></comment><comment><USER3> This looks like it was interesting to work on , and you found how to overcome the various challenges.

One question though, if you could use an iFrame to call the same functionality remotely, couldn't this be used as well for production?

<comment><AUTHOR> Thanks. Not sure I understand your question, or if I did a good job explaining the iframe bit. The iframe is needed to load the local development experience, but it is not calling the functionality remotely. It is just passing function calls between the Google Apps Script environment and your app.

</comment></comment><comment><USER4> Thank you for actually showing me a sane workflow for sheet development; we build complex software in sheets (because people understand it) but I never really figured how to make the workflow of JS for sheets more efficient. You did; thanks.

</comment><comment><USER5> Great work and I admire your dedication and work you put into this! How hard do you think it would for someone of average intelligence to fork it to support Vue or Svelte instead?

<comment><AUTHOR> Nice idea -- the main thing needed would be to update the Webpack configuration to support e.g. Vue instead of React, and to make sure to generate a single HTML file for your Vue app that includes all scripts and styles. Might not be so bad!

</comment></comment><comment><USER6> Just wanted to say good job. Loved it.

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER7> tldr; 1MB for dialogs.

<comment><AUTHOR> Mmm, nope. But open an issue and I'll help you out.</comment></comment>


Alibaba Weex Ui - <AUTHOR> https://github.com/alibaba/weex-ui <comment><AUTHOR> A rich interaction, lightweight, high performance UI library based on Weex. Write once and support iOS / Android / Html5 right now!</comment>


My love-hate relationship with LuaJIT (2015) - <AUTHOR> https://blog.separateconcerns.com/2015-06-18-love-hate-luajit.html <comment><USER2> I love commentary on LuaJIT, it's like a discussion of the subtleties of an acient game whose practitioners understand and enjoy, and everyone else ignores.

My experience with LuaJIT has similarly been love, not much hate though. My lack of hate stems from the fact that I don't actually use it in production. I've used it as a learning and teaching tool for the past 4 or 5 years.

What I've learned: Co-routines combined with traditional async IO can make for some very fast IO bound programs.

JIT based FFI for interop is the cats meow

The guts of operating systems can be easily explained using such a simple language.

I went as far as creating a collaborative 3D modeling program (ala OpenSCAD) using LuaJIT.

I've created an entire Windows API wrapper (TINN).

I've explored the guts of Linux (using ljsyscall), and done exploration of various bits and pieces (lj2procfs).

I've been able to explore and play with any manner of API from dozens of OpenSource projects and otherwise, simply because LuaJIT (and specifically the FFI) make it possible to quickly wrap them up in such a way that exploration with script is easy.

I never worry about the death of LuaJIT, just like I very rarely look at the guts of my machine that's been running since 2009. The various parts may no longer be supported, but somehow my machines manages to continue to operate. Eventually I'll build another one and move on.

With recent changes to TypeScript, and the emergence of the Chakra engine, I might be tempted to make JavaScript my new thing, but they lack FFI, which I really love. I wish there were a solution for that.

Go has co/goroutines, which I really like, but I don't think their C interop story is particularly compelling, and not quite a scripty thing, which I find to be fairly useful.

I was originally driven to LuaJIT because PUC Lua had a flaw in their OpenGL binding, and it just wasn't robust enough for my needs. I find no value in their current versions, because FFI seems to be the most valuable thing to me I guess.

So, since it's a play thing for me, I find no other language as compelling or useful, for my needs. Some day, I'll use one of the language tool kits to convert my most interesting Lua code to another language, hopefully one with a good FFI. Until then, I'll keep using it.

And, if you've been around the industry long enough, you realize one language won't do it all for all time. I've long since given up on Objective-C (from NeXT days), I no longer write 6502 assembly (although still very popular apparently). I dove into C++ in the past couple of years, and came out with hives! Rust and Go are on the horizon, and who knows what's after that.

<comment><USER3> Wow! Hard to believe I had never stumbled on your blog until now. [https://williamaadams.wordpress.com/category/luajit/](https://williamaadams.wordpress.com/category/luajit/)

<comment><USER2> heh... I've written a bit about our favorite abandoned language ;-)

</comment></comment></comment><comment><USER4> My perception of LuaJIT is that it's Mike Pall's creation (and what a creation at that!). He stepped down a while ago[1] and since then, at least to me, not much seem to have happened with LuaJIT. CloudFlare was in talks of project governance [2], and Cisco has pushed some MIPS support, but I havn't heard much else. There was a beta release in march this year for 2.1, but that's it.

The fork between PUC Lua and LuaJIT mentioned in the article is a major point of concern. For good and bad, PUC Lua is not known for backward compatibility. PUC Lua is at 5.3 and LuaJIT targets 5.1. There have been some breaking changes since then.

Without a strong community built around LuaJIT, or a corporate backer investing resources in it, I fear that it will die out eventually. I would be hesitant to implement something that uses LuaJIT with the project looking the way it does to me. I would love to be proven wrong though.

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

<comment><USER5> We still would like to hire someone to work on LuaJIT. We've found it very, very hard to find anyone suitable. There are few people who understand LuaJIT internals and few who want to get into it.

If there is someone reading this who wants to work on LuaJIT full time and thinks they have relevant background then please contact me.

<comment><USER3> I am confused about why you guys haven't already hired Peter Cawley, Vyacheslav Egorov, and/or Thomas Fransham.

<comment><USER6> I believe Vyacheslav Egorov already works at Google on LuaJIT.

<comment><USER3> No. He works at Google, and during 2015 he temporarily provided support to internal LuaJIT users there and made many contributions in the process, but working on LuaJIT is not his job. (The world world be a better place if it were!)

Source: [https://github.com/LuaJIT/LuaJIT/issues/45#issuecomment-2340...](https://github.com/LuaJIT/LuaJIT/issues/45#issuecomment-234073487)

<comment><USER7> And for companies not named FaceBook, you probably have about 0 chance of hiring him away from Google where engineers who are really good at building jits are prized ($$$). I am an acquaintance of a very senior, very very good jvm engineer who was offered a ludicrous salary by G.

<comment><AUTHOR> Is Mike Pall independent? I assume many companies have tried to hire him.

<comment><USER7> I was discussing Vyacheslav. I assume Mike Pall can work for msft/goog/fb if he wishes to.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> My love hate relationship is entirely with the language itself. It's incredibly useful as a game scripting language and is extremely easy to bind native functionality to, but man, the language itself rivals JavaScript for quirks.

1-based indexing is just a silly departure from decades of ingrained thinking, dictionaries masquerade as lists but can unintentionally become dictionaries if you mistakenly put a non-numeric key in them, and the only inheritance is prototype-based "classes" that are implemented via gross metatable hacking. Library support is also weak.

I will give it credit though for a robust coroutine implementation.

<comment><USER9> Looks like you got some down votes but I entirely agree. It isn't as bad as JavaScript, but turning typos into nil rather than raising an exception or having a compile time error is also annoying, in addition to the other things you mentioned.

I really wanted to like it for the small and simple implementation, but the language isn't pleasant IMO.

<comment><USER3> > turning typos into nil rather than raising an exception or having a compile > time error is also annoying

So true. However, you can disable this behavior and then just forget about it:

[http://metalua.luaforge.net/src/lib/strict.lua.html](http://metalua.luaforge.net/src/lib/strict.lua.html)

</comment></comment></comment><comment><USER10> I've used luajit. It's unsupported software. If it works, great. If not, you're screwed. The original Lua may be ten times slower than luajit, but anyone can understand and debug it. That's worth something.

It's a shame luajit never created a community beyond its creator. FFI sure was nice.

<comment><USER11> If one heads over to GitHub to check some recently closed issues and recent commits one will discover that there are people who can understand and debug LuaJIT issues.

LuaJIT is not magic, it's a software. Very neat and tightly written but it's still just a bunch of C/assembly/Lua code.

Written by one human, and thus other humans can understand it too.

<comment><USER10> In _theory_ you're right. But it's dense terse code with very little documentation. Some people can fix obvious problems around the edges, but no one would tackle a serious refactoring, porting to more recent version of Lua or adding a new feature.

</comment></comment></comment><comment><USER12> As appealing as LuaJIT was and is, I could never bring myself to write much code for it. Even setting aside the possibility of Mike Pall giving up on the project (which turned out to be correct) the lack of a community around the language meant there would be difficulty getting questions answered and few third party LuaJIT packages. Bugs in particular were a major concern: if Mike Pall didn't find my bug report important, I'd be out of luck.

And as interesting as it is to have a small scripting language be able to run code so quickly, there are new languages that deliver the same benefits. Nothing really stands out about LuaJIT to make me feel it is a language I should use.

<comment><USER13> Which new languages?

<comment><USER12> The benefits I was referring to are being able to write fast, correct code easily. Other languages that allow one to do that include D, Go, Clojure, and Scala. If you want a scripting language, you're stuck with LuaJIT for now, but at least to me that's not an important distinction for anything I'd want to do with LuaJIT.

LuaJIT comes with warnings like "Callbacks are slow" and "The following operations are currently not compiled and may exhibit suboptimal performance, especially when used in inner loops:" which pushes it further down the list for me.

</comment></comment></comment><comment><USER14> The Haxe language targets Lua now [1], and some recent commits I've made enabled 5.1/LuaJIT support. Haxe syntax is significantly different than Lua syntax, but it's closer to ECMAscript, and most likely more familiar to the folks here. If the language syntax quirks are a barrier towards targeting LuaJIT, then check out Haxe.

[1]: [https://haxe.org/blog/hello-lua](https://haxe.org/blog/hello-lua)

</comment><comment><USER15> I love LuaJIT, but what it needs right now is some sort of Lua5.3 compatibility. Despite being an excellent piece of tech I think this current state causes some damage to the Lua community because often developers will write code in a Lua5.1-style so it is compatible with both PUC-Lua and LuaJIT interpreters. This has made the adoption to newer Lua versions more difficult.

</comment><comment><USER16> For me one of the big problems I have with luajit is using it in 64bit applications. luajit internals need to exist within the first 4gb of memory, and in some situations this can be a PITA to properly satisfy. There are solutions, but none I feel too comfortable with using especially cross- platform.

Given luajit development seems to be stalled, I don't have much confidence this will ever be fixed.

<comment><USER17> Try building (the `v2.1` branch of) LuaJIT with `CFLAGS=-DLUAJIT_ENABLE_GC64`. This flag is a relatively recent addition [1], and didn't have JIT support on x64 until really very recently [2], but it should free you from the 4gb limitation.

[1] [https://github.com/LuaJIT/LuaJIT/commit/a92e73023353e59405eb...](https://github.com/LuaJIT/LuaJIT/commit/a92e73023353e59405ebfdb2837b5742d17946a5) [2] [https://github.com/LuaJIT/LuaJIT/commit/2868715d80b6ac497a7f...](https://github.com/LuaJIT/LuaJIT/commit/2868715d80b6ac497a7f08393ec325b60d71df8d)

<comment><USER18> Looking at your PR for it ([https://github.com/LuaJIT/LuaJIT/pull/149](https://github.com/LuaJIT/LuaJIT/pull/149)) it sounds as if there are a few issues remaining, but I'm not enough of an expert to know how problematic they are in practice. Do you think that this feature is stable enough for production use?

</comment></comment></comment><comment><USER19> > _Beyond the purist ideal of understanding the whole stack, this has > practical implications. When you find a bug in LuaJIT, understanding it and > fixing it is terribly complicated._

Well, how often people fix bugs in the compiler they use (and haven't written themselves)? Doesn't seem as much a "practical" consideration as the author says...

> _Another issue is that PUC Lua and LuaJIT are diverging. LuaJIT implements > Lua 5.1. Lua 5.2 code can be made to work as long as it does not use _ENV, > but code that leverages the new features in Lua 5.3 is not supported at all_

Well, not as much diverging as in "going to different directions" as that LuaJIT implements an older version. Isn't it supposed to eventually catch up?

<comment><USER20> Well, I have hit three different bugs in five years using LuaJIT, two of which I was the first to report. You cannot consider it as stable as, say, GCC.

Regarding your second point: Mike Pall had no intention to catch up completely. I don't know how much that has changed under CloudFlare leadership.

<comment><USER19> Thanks, I'd expect it to have some bugs (it's a much newer project than GCC, and even Python or Perl have lots of open bugs), but was missing the second information that Mike gave up on it. Last time I checked (a few years ago) it was still going forward.

</comment></comment></comment><comment><USER21> The problem is that LuaJIT is an engine without a transmission or steering or braking system (this is a tortured analogy). It _makes sense_ for PUC-Lua to have no standard library and focus on embeddability. It _does not make sense_ for LuaJIT to do the same thing. LuaJIT's use case looks more like Torch -- scientific computing where a lot of stuff is written in C but you still need speed for the free-form parts and your target users are in a hurry -- and you need standard libraries for that. LuaJIT can compete with Go and C# on a speed basis, but not a usability basis.

Yeah, the actual compiler could use a maintainer, but who looks at LuaJIT and thinks "clearly, the weak point is the compiler!"?

</comment><comment><USER22> Does anyone know what percentage of LuaJIT bugs are in the interpreter? You can still get a large speedup with it while avoiding the most complex code.

Edit: Also what's this about "a machine that does not support LuaJIT" that's apparently x86-based?

<comment><USER23> Not sure about the machine linked in the article, but sometimes the operating system might prevent you from marking heap allocated pages as executable.

However, in that case you are only prevented from using the JIT compiler and should still be able to take advantage of the high-speed interpreter included.

<comment><USER20> I wrote that article, just found out it was on the front page of HN today.

The machine linked in the article can not even run the unmodified interpreter (or at least it could not at the time) because its CPU does not support the CMOV instruction.

Regarding the bugs: I do think most of them are in the JIT and not the interpreter. Even using a lower optimization level that the default fixes a lot of them.

<comment> david-given What's the processor in the Lima? The website has no technical information on it whatsoever (even under the 'Tech Specs' sections). Genuinely curious; I thought all x86 processors made these days supported CMOV.

<comment><USER20> It is a CPU from RDC (Taiwanese manufacturer). It is 486-compatible but misses some instructions from later Pentium sets.

<comment> david-given I'm thoroughly bemused as to why they picked it --- unless you're aiming at some sort of binary compatibility, and given that it won't run Windows I have no idea what it might be compatible _with_ , surely one of the ARM or MIPS stable would be more appropriate for this kind of device?

...over here, in _this_ cardboard box, I have an old SheevaPlug: a 1.2GHz Marvell ARMv5 in a plug-sized box with some flash, an SD card interface, ethernet, and some USB ports, which appears to be pretty much the same device. (Of course, it's the software that's the interesting bit.)

</comment></comment></comment></comment></comment></comment><comment><USER24> I wonder what programs he was writing with Lua in Minix3 if he even was using them together? He mentions the stuff he wrote for work, and the hobby stuff later in Lua on Linux.

I also used Minix to learn about OSs back in 1991 by installing Minix 1.5 on my Amiga. Sad to say after spending an all-nighter getting it working, I didn't really dive in the way I had intended much after that. Tanenbaum's book was a real eye-opener for me. The source code and a textbook. I haven't seen much like it today. Still, I learned a lot about computers in general doing this, and would recreate the experience in my second dual-boot system, a Mac PowerPC running MkLinux in 1997!

There's something to be said for reading source code, and recompiling small OSs even if you just touch upon it. XV6 was re-written, and the source is < 10K LOC [1]. The course book is about 100 pages and the link also includes the source code in PDF to follow along.

I am also thinking on installing Minix3 on my dedicated linux notebook, but I am afraid I might botch it because my current system is UEFI/SB=off. I think you can only use BIOS/MBR with Minix3, although somebody has posted how to load it from a LiveUSB with Qemu, which you ditch after the install.

[1] [https://pdos.csail.mit.edu/6.828/2016/xv6.html](https://pdos.csail.mit.edu/6.828/2016/xv6.html)

</comment><comment><USER25> "Ravi is a derivative/dialect of Lua 5.3 with limited optional static typing and an LLVM powered JIT compiler."

[https://github.com/dibyendumajumdar/ravi](https://github.com/dibyendumajumdar/ravi)

<comment><USER20> Ravi is interesting and well known in the Lua community, but it is far from the performance of LuaJIT. I don't think a LLVM-based JIT compiler will reach that level of performance anytime soon.

</comment></comment><comment><USER26> For people who like LuaJIT's FFI, there is this library that brings that same style to PUC Lua:

[https://github.com/jmckaskill/luaffi](https://github.com/jmckaskill/luaffi)

It isn't terribly fast though.

<comment><USER27> Its buggy too. Really needs someone to spend some time on it fixing the bugs, but there clearly is not the demand. Actually I am more interested in a maintainable static bindings generator.

</comment></comment><comment><USER28> As someone who doesn't know Lua and after reading this article, can it properly be said that a scripting language is fast if you write most of your time sensitive code in C? Why not just C?

<comment><USER29> I do python where your question applies too.

It is significantly quicker to write code in a higher level language, since the primitives and libraries do more per line of code. The cost is that it doesn't run as fast. But consider these two scenarios:

1 It takes 2 hours to write the code, and 1 hour for it to run.

2 It takes 2 days to write the code, and 1 minute for it to run

Note that "write the code" includes the actual writing, as well as debugging, testing etc. The first scenario is the most immediately productive. But the more you have to run the code, the more the second scenario applies.

Which is why you combine the approaches. Write the parts that aren't performance sensitive quickly in your high level language, and take longer on the performance parts in C. That works better than exclusively approach 1 or 2.

<comment><USER28> Thanks, I think you make a good case for using a language like Lua or Python with an excellent C interface. In some sense, writing everything in C could be a case of premature optimization.

<comment><USER29> Another benefit of Lua/Python is that it is considerably easier to write testing and debugging versus C. They support introspection and similar techniques. A very typical example is something I did a while back.

I wrote the processing in Python first. The core was 10 lines of code and took about 5 minutes to run on a unit of data. It took about an hour to write, and was correct.

It then took two days to rewrite in C and was 400 lines of code, executing in a second or so. Much of the time was finding and fixing minor bugs. But having the "correct" Python code made it very easy to feed the same test data to both implementations and verify the output. Writing test code in C would have taken even longer than just the algorithm!

</comment></comment></comment></comment><comment><USER30> Since someone mentioned it, how slower is PUC Lua in respect to LuaJIT? Compromisingly slower? Are there metrics out there or is it a relatively subjective feeling?

<comment><USER27> PUC lua is probably the fastest traditional scripting language. LuaJIT is much faster, in particular if you are interfacing with C, as the ffi has zero overhead, while the traditional Lua API is relatively slow. Also the performance is noticeable if you are doing a lot of work in the language too, generally as fast as C code for many use cases if you tune the code.

<comment><USER31> > PUC lua is probably the fastest traditional scripting language

That really depends what you are testing for. For string ops is not the fastest. For recursive Fibonacci (inefficient) LuaJIT is faster than D and Lua is faster than Perl.

[http://raid6.com.au/~onlyjob/posts/arena/](http://raid6.com.au/~onlyjob/posts/arena/)</comment></comment></comment>


Challenge: Put all of Shakespeare's works into the smallest HTML file you can - <AUTHOR> https://github.com/xem/miniBook <comment><USER2> I'm guessing whoever manages to implement a subset of [https://en.wikipedia.org/wiki/PAQ](https://en.wikipedia.org/wiki/PAQ) in JS is probably going to win.

Of course, the decompressor itself also needs to be compressed, which I suspect will be where most of the competition will happen.

<comment><USER3> > I'm guessing whoever manages to implement a subset of > [https://en.wikipedia.org/wiki/PAQ](https://en.wikipedia.org/wiki/PAQ) in JS > is probably going to win.

I'm not so sure; PAQ is pretty slow and the challenge has a 30m time limit. Check out the 1GB text compression benchmark in the wiki - it's orders of magnitude slower than the next best algorithm for a 5% improvement, and the benchmark case is basically the same as this challenge.

Edit: I mean, it took 17 hours.

<comment><USER2> According to [http://prize.hutter1.net/#history](http://prize.hutter1.net/#history) the current winner (which has stood since 2009) took 9h on a _2GHz P4_ to decompress its input to 100MB, or roughly 3082 bytes/s.

30 minutes to decompress 5324821B is only slightly less, at 2958 bytes/s. This "on a modern computer", certainly not one from 15 years ago, even after factoring in JS overhead, sounds doable, if not easy. Have CPUs gotten more than an order of magnitude faster since then? Probably (but perhaps not for the type of code that would be encountered in a decompressor --- the biggest boost has been for vector operations, which are neither particularly suitable for high compression algorithms nor easily usable from JS.) Is JS overhead less than 10x native code? Probably for some cases too.

In fact, I just tried paq8hp12 on the file and it compressed it to 1059027 bytes in 208 seconds on a moderately old system (i7 870). Decompression took the same time.

<comment><USER4> 1059027 bytes for the Shakespeare file? that's impressive. I tried something called "PAQ*" compression but it generated a file that was nearly 2MB...

</comment></comment></comment></comment><comment><USER4> Hi! I created that challenge but didn't see this HN page until now :) That's where all this traffic comes from! If you think 30 min is too short for decompression, I can change that rule. Just let me know.

</comment><comment><USER5> another good challenge would to be trying to display them in the most interesting way possible in under x bytes, demoscene style. But I suppose that's a different audience.

<comment><USER4> please develop, I'm actually interested by this kind of challenges too! :) What's your idea? like, asking people to output as much text as they can in 512kb or 1mb?

</comment></comment><comment><USER6> Easy 0 byte compressed solution: just put the entire output in the decompressor and print it. This doesn't seem to be against the stated rules.

<comment><USER7> Just put all of the text in the file names.

<comment><USER4> You can't read neighbour files' names with JS, can you?

<comment><AUTHOR> you can if the server is configured to list directories O_o</comment></comment></comment></comment>