Layoff Underway at IBM - <AUTHOR> http://spectrum.ieee.org/view-from-the-valley/at-work/tech-careers/massive-worldwide-layoff-underway-at-ibm <comment><USER2> Before the IBM apologists start commenting: I was an IBM employee a few years ago and I would never recommend it as a good place to work. You were constantly worried about your job and there were cuts to basic resources all the time. It's not at all surprising to see this happen. IBM only cares about its shareholders and not its employees or customers.

<comment><USER3> It's so ironic to me that some large corporations only focus on shareholders. Focusing on customer satisfaction, and product quality leads to greater sales more than anything else. A byproduct of this is...wait for it...higher value to shareholders!

<comment><USER4> They are, in most cases, legally required to place shareholder value over all else.

<comment><USER5> No they aren't. Time to put that misconception to bed:

[http://www.washingtonpost.com/opinions/harold-meyerson- the-m...](http://www.washingtonpost.com/opinions/harold-meyerson-the-myth-of- maximizing-shareholder- value/2014/02/11/00cdfb14-9336-11e3-84e1-27626c5ef5fb_story.html)

<comment><USER6> True, they aren't obligated. Another thing to note is that most executives get paid with equity more than cash. So it is in their self interest to have the stock stay steady or go up and not take a nose dive.

<comment><USER7> _So it is in their self interest to have the stock stay steady or go up_

Until they are ready to cash out, which might be as soon as a year away. It needs to be redesigned with long-term incentives in mind.

</comment></comment></comment></comment></comment></comment><comment><USER8> > Of course, the appearance of the situation, in the eyes of employees and the > public, is not being helped by the fact amid IBM's actions comes the board's > announcement on Friday of a big raise for CEO Ginni Rometty.

<comment><USER9> The article linked in from that bit is pretty good too: "IBM redefines failure as 'success,' gives underachieving CEO huge raise" \- [http://www.latimes.com/business/hiltzik/la-fi-mh-ibm- redefin...](http://www.latimes.com/business/hiltzik/la-fi-mh-ibm- redefines-20150202-column.html)

 _" The company has posted lower revenue for 11 quarters in a row."_

She gets a raise for successfully shrinking the company?

<comment><USER10> In an alien world a million billion miles away a general marshalling forces after defeat after defeat offers it's sword (or other death dealing device) to the star marshals and is told, "no, not now" but inconsolable the resignation is re-tendered, so now the star marshals give it a medal, and a pay rise and a nice pat on the heat, and it agrees to remain in charge.

If I could reduce and organisation to zarg-jelly by resigning I would extract similar geld I guess..

<comment><USER11> Your analogy is hard to follow.

<comment><USER12> Well, I guess the GP meant that if you could inflict significant harm on the company by resigning, the shareholders won't let you do that, so you can just start extorting them for money.

</comment></comment></comment></comment></comment><comment><USER13> Reminder that Cringeley's original claim from Jan 22nd was:

To fix its business problems and speed up its "transformation," next week about 26 percent of IBM's employees will be getting phone calls from their managers. A few hours later a package will appear on their doorsteps with all the paperwork. Project Chrome will hit many of the worldwide services operations. The USA will be hit hard, but so will other locations. IBM's contractors can expect regular furloughs in 2015. One in four IBMers reading this column will probably start looking for a new job next week. Those employees will all be gone by the end of February.

Now he's trying to spin that he never said "layoffs". Not sure why the IEEE is still trusting him.

<comment><USER14> Wait. I'm confused: was cringeley right or wrong?

<comment><USER15> Well, here's what we know:

Cringely claims 100k people

IBM claims low thousands (at a cost of $0.6B, which seems quite high) [1]

ieee says Alliance@IBM, an ibm union, claims they know of 5k jobs eliminated; they further say they're seeing a flood of backdoor layoffs, ie sudden bad reviews

My guess is in 6 months, Cringely was more right than wrong. Or at least we see an employment reduction of tens of thousands.

[1] [http://mobile.reuters.com/article/idUSKBN0KZ1WF20150126?irpc...](http://mobile.reuters.com/article/idUSKBN0KZ1WF20150126?irpc=932)

<comment><USER13> >IBM claims low thousands (at a cost of $0.6B, which seems quite high)

If you pay 6 months severance, it adds up quickly. A million dollars covers only 20 $100k employees.

<comment><USER16> What is the reason companies pay a severance? Most jobs are hire or fire anytime right?

Is the reason only lawsuits and good will?

<comment><USER17> It's a good time for the company to attach various nondisclosure, noncompete, non disparagement clause(s) and they mark the severance pay as consideration. These agreements typically only hold up if there is commensurate consideration attached to them. This of course varies by state and local laws if they hold up at all.

<comment><USER15> IBM has been repeatedly sued, sometimes successfully, for age discrimination, so you can bet that severance package requires agreeing not to sue for age discrimination.

see, eg, [http://www.cookbrown.com/docuserfiles/file/Spring%20Newslett...](http://www.cookbrown.com/docuserfiles/file/Spring%20Newsletter%20THE%20IMPORTANCE%20OF%20BEING%20EARNEST%E2%80%94WHY%20UNBIASED%20INVESTIGATIONS%20MATTER%20Debra%20Hinshaw%20Vierra%20Article.pdf)

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Nobody ever got fired for choosing IBM.

Except as an employer.

</comment><comment><USER19> IBM didn't take the microcomputer seriously, until it saw how well Apple did and then made an IBM PC to compete with it.

They made a deal with Microsoft for DOS, but didn't make the deal exclusive so Microsoft sold their own version of DOS to the PC Cloners.

IBM made the PS/2 series with Microchannel as Clone Killers. VGA was a better video, and Creative Labs had the Sound Blaster for better audio. IBM's Microchannel flopped because people wanted to still use their ISA cards. IBM had OS/2 and Microsoft had their own version of OS/2 and Windows, and Microsoft took their OS/2 NT 3.0 and made Windows NT 3.1 out of it and stabbed IBM in the back for a second time.

IBM sold their printer line to Lexmark, and their PC X86/X64 line to Lenovo, IBM didn't know how to turn a profit on them.

When IBM couldn't supply the PowerPC chips to Apple for their Macintosh line, because IBM was making PowerPC chips for video game consoles as a priority, Apple switched to Intel chips. Then later video game consoles switched to Intel or AMD chips. IBM open sourced their PowerPC chips eventually.

IBM bought out Lotus and basically ran it into the ground and let Excel replace Lotus 123, and Lotus Smartsuite was never updated to compete with Microsoft Office and for modern Windows systems so it fell away and IBM forked OpenOffice.Org to make Lotus Symphony. That also went nowhere.

IBM still earns money from mainframes and contract support. I think IBM got into Linux and Java contracting as well.

But IBM has changed over the decades and it is not the same company it once was. It fell into a trap of maximizing shareholder values rather than making the customer experience a better one like Apple did. Microsoft also suffers from the same sort of thing that IBM does which explains why Microsoft Surface sales tanked.

IBM needs a big reboot, and to focus on making the customer experience better. Mobile apps is an area they could focus on, make the IBM Cloud and then make IBM Lotus Symphony for iOS and Android and store the documents on the IBM Cloud and offer subscriptions for more storage. They should also make Lotus Domino and Lotus Notes for mobile devices, and make a set of developer tools to make Android and iOS apps easier to program.

</comment><comment><USER20> But nobody will admit that there is a massive ageism problem in technology..? It is nice that some countries have moved to protect against ageism, it is an extremely common problem that few wish to address or take seriously.

<comment><USER21> Do you feel like being old would entitle you to a job? And if so, why?

<comment><USER22> Being old of course does not entitle you to a job. However people being fired _because_ they are old is something that should bother you. One day, you will be old.

Walk into the office of an accounting firm, engineering firm, bank, architects office, whatever. Count the number of employees that you see with gray hair. Now walk around your (software company's) office and do the same. Chances are ( __particularly__ on the west coast in my experience), there is a big discrepancy.

There are several possible explanations. Maybe the old people get fired. Maybe old people get the hell out of the industry on their own terms. Maybe young people are just hired at an absurd rate, which is suppressing the proportions of old people.

Some people suggest that it is because this industry is young, but it isn't _that_ young. Your standard 20-something dev might think he is entering an exciting new industry, but the reality is that the industry is several decades old already; more than enough time to accumulate lots of gray-headed programmers.

<comment><USER23> > Maybe young people are just hired at an absurd rate, which is suppressing > the proportions of old people.

Honestly, I think this accounts for most of the ageism in tech.

Way more people are entering the field now than in the 1970s, so even if there's absolutely no ageism at play you'd still expect the majority of all developers at a company to have graduated in the last decade.

<comment><USER24> If you entered in the 1970's you would likely be at retirement age now.

</comment></comment></comment></comment></comment><comment><USER25> "IBM said there would be thousands of layoffs. We believe there have been 5,000 layoffs. Clearly IBM was lying."

Um.

<comment><USER26> What are you quoting?

<comment><USER27> When Cringely wrote his clickbait 100k, IBM responded saying that the layoffs would be more like 10K.

</comment></comment></comment><comment><USER12> Wait what... does that mean that management at IBM suddenly realized they don't need 1/4 of the company? Since they rather won't be hiring new people in place of all laid off, I wonder what is going on there? Did they recently have an extremely successful merger with a very similar company? Did 1/4 of the company provide zero output? Or did Watson get so good it can actually replace engineers and sales people?

<comment><USER28> From what I understand; They are getting rid of employees in low performing areas and hiring in growth areas like CAMMS (cloud, analytics, mobile, social, and security) and Watson.

<comment><USER29> Why would anyone in the top (let's say, 5%) of tech be interested in working for IBM when it seems this is how it treats its employees?

<comment><USER30> fwiw, they did a great job taking care of me and some other heavy hitters while I was there. Regular bonuses, very very nice salaries, and it was predictable. I worked on products though, not services, and our product made money.

honestly, I don't know what 400,000 IBMers work on. Every company of a certain size and age does layoffs. You could ask the same question of Apple or Microsoft and at some point Google too.

<comment><USER31> How long ago were you there? Things seemed to start to dive 2-3 years ago.

<comment><USER28> I don't think I've seen a bonus since being acquired. This had to be years ago.

</comment></comment></comment></comment></comment></comment><comment><USER32> Ouch. I lived in Columbia, Missouri for a couple years starting in 2012. The IBM office had just opened in 2010 and was a big deal. The city and state gave them large tax incentives to open it there. If IBM really laid of 150 people in it, that's a huge cut.

[http://www.columbiatribune.com/news/local/ibm-layoffs-hit- co...](http://www.columbiatribune.com/news/local/ibm-layoffs-hit-columbia- service-center/)

[http://www.columbiatribune.com/news/local/department-of- econ...](http://www.columbiatribune.com/news/local/department-of-economic- development-to-review-ibm-incentives-after-columbia/)

<comment><USER33> Native Iowan, same goes for Dubuque Iowa.

</comment></comment><comment><USER34> It would be nice to hear from honest IBM managers, who are doing the firing and downgrading of employees, what is really going on. Though I'm pretty sure most people know what the score is.

</comment><comment><USER35> Why is the tone of the comments on this story so different from those of just last week?

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

One hypothesis... some of the IBM managers who were commenting on that story now realize Cringely was at least partly right?

<comment><USER36> This is a tech board where anyone can post anonymously, so sockpuppeting and astroturfing are quite common, especially as employees of these companies post here. In every thread about Apple/Amazon/Google/Facebook/IBM/Microsoft/etc you'll always have to wonder who's behind that post or who clicked the upvote and downvote arrows.

</comment></comment><comment><USER37> Still no real confirmation of figures but I guess there is purposeful obfuscation here.

<comment><USER38> Even so, if IBM loses 100,000 employees in the course of a month it's going to be pretty damn obvious. I'm still betting that the numbers are wildly exaggerated.

<comment><USER39> I'm not. If it were just a couple thousand, they wouldn't be doing all the shenanigans with review numbers.

This is a test to see what they can get away with before class action lawsuits start flying. If they dumped all 100,000 at once, they'd get smashed with lawsuits.

So,they're going to try to pull it off with 10,000 and see how many lawyers appear.

</comment></comment></comment><comment><USER40> So maybe not uncritically accepting IBM's press releases would be a good idea?

</comment><comment><USER41> What a remarkable collapse from the "Big Blue" of the 1960s. Is there really anything sexier then then thought of brand new IBM 360 getting loading into a PanAm jet-powered aircraft.

</comment><comment><USER42> A goodly chunk of the company I work at was recently sold to IBM. Not my chunk, but still - color me deeply un-reassured!

</comment><comment><USER43> Does this impact SoftLayer in any way?

</comment><comment><USER44> Cringly said in his article that a quarter of the IBM workforce would "get their paperwork" to be laid off in the last week of January or so. He was very specific and he's not even close. At some point, the layoffs may total a quarter of the workforce, but that's not what his histrionic diatribe said. If he now gets to backpedal and "restate" what he said and be right in his predictions, then so were the forecasters who said New York was going to be buried in snow and yet only got dusted.

People have been predicting the imminent death of IBM, with detailed litanies of the myriad of ways it's unrecoverable failures, pretty much every day of the 30 years I've been in IT. The thing about predicting the end of the world, is that if you do it long enough and lack the humility to be ashamed of all the times you were wrong, you'll eventually get to be right.

</comment><comment><USER45> IBM seems like it would be a terrifying place to work, Initech level. With the 1,2,3 system there is also probably tons of project protectionism going on, and you probably have to wear a tie.

<comment><USER44> We don't wear ties.

</comment></comment><comment><USER46> Recently, Apple announced highest quarterly income in corporate history and now, IBM is going through biggest layoffs in corporate history. It seems to be the season of superlatives in corporate history.

But what a contrast between Apple and IBM!!!

<comment><USER47> Tech has a very powerful tendency to winner-takes-all dynamics. IBM's had an unbelievably long run (formed in 1911 though through the merger of two existing firms), and has taken on and disposed of other competitors (most recent Sun, though there were the Seven Dwarfs in the 1960s / 1970s).

Which is to say, the shifts are likely not unrelated, though Apple doesn't directly compete significantly in business.</comment></comment>


Ask HN: What are programming jobs that require travel? - <AUTHOR>

<comment><USER2> Developer/consultants for government contractors.

My coworkers and I move to different project sites on time scales ranging from 1-5 years. We do government software and live on-site in the capitols where we're working. Most developers move from one semi-permanent office to another new client after the project transitions to a maintenance mode.

Experienced devs in particular sub systems might go on 1-3 week trips to other locations to bootstrap or assist on large issues.

Devs are also a large part of our marketing department. A few are regularly tasked with putting together demos for clients and delivering them on-site; others help as needed.

Most devs also have the opportunity to attend career fairs to assist the recruiters. I've personally attended 3 in 4 years. It's such a good opportunity to be the face of your company and have the first round recommendation on hires. Sure the management has the final say but they definitely value our input.

My job is defined by travel, some stops are just longer than others.

If any of this sounds interesting to you, shoot me an email, I'd love to talk with you about it.

</comment><comment><USER3> A lot of enterprise system integrators (eg: integrating big software products together or into an enterprise's existing infrastructure) require travelling programming consultants. Also, consultants focused on improving an enterprises development process, and team.

</comment><comment><USER4> I have a small group of friends that work for big companies or consultants. All of them in this group travel at least once a week, usually round-trip (home<\-->work-site). The work-sites can change weekly to once every two years.

This group of friends include HP, Oracle (formerly Siebel) and VMWare employees/contractors. All of them that I talk to regularly dislike the travel because of the big company horseshit that goes along with it. I've turned down this work repeatedly because of the travel and the company crap associated with it. Of the people I've talked to about it, only those with unstable or shitty home-lives like the travel a majority of the time.

AFAIK, my friends that do not work for huge companies do not travel much outside of conferences and the like.

<comment><USER3> > only those with unstable or shitty home-lives like the travel a majority of > the time.

I wouldn't go that far. If you're single, the travel is a hell of a lot of fun. You usually have expense accounts and get to see parts of the world on someone else's dime. I traveled 48 of 52 weeks a year for 6 years and loved it. But my personality loves constant change. I liked being able to change most of the people I worked with every month or so and solve new organizational problems.

<comment><USER5> Yes, it really depends on the person. By and large, though, I've observed that your post's parent is correct - lousy home life, want to cheat, that sort of thing. Living in a hotel is dreadful (IMO, of course), having none of your own resources (I like playing guitar, woodworking, playing with my dogs, and so on, none of which are particularly possible in a hotel) is draining, and I don't really like endless rounds of bars and restaurants. So, a terrible life from my point of view. The pluses - new cities, new people, etc., don't compensate. I have a friend that travels all the time, and I'll get plaintive emails about being in some hotel in some great city, such as Hong Kong, and he has been working 15 hour days and crashing in his hotel room, while his wife and kids and home and dog are half a planet away. I do not envy him.

To answer the OP: any kind of service/support role in the technical side can give you lots of travel. Install this new server, or help clients get up to speed, or debug this thingy onsite. But, be sure to figure out what this entails: are you working 5 hours and then carousing in NYC (the vision), or working 17 hour days in some dingy facility in the middle of Iowa? To make all that plane flight + hotel + expenses + salary pay off, it's likely to lean towards the latter.

I made a joke that is no joke to my gf from my hotel room a few weeks ago: "you know those bar/restaurant/hotel travel scenes in 'House of Lies'? My trip is exactly _not_ like that"

Which is not to dissuade you; plenty of people have great travel for work experiences. It is just a suggestion to figure out exactly what you will be getting, and to look inside yourself to figure out if it appeals to you.

</comment></comment></comment><comment><USER6> Developer evangelist. You travel to developer conferences, hackathons and other events.

</comment><comment><USER7> ERP consulting and development. Think SAP, Oracle, Peoplesoft, Dynamics AX.</comment>


Ask HN: Is functional programming inherently difficult? - <AUTHOR> Functional programming is very popular on HN, but less so in the wider developer community. Many consider functional programming "hard". But is functional programming actually difficult, or is this merely a symptom of developers learning procedural languages first? <comment><USER2> It is more difficult than OOP because of its strong association with mathematics (ie category theory and logic). Without this background knowledge it becomes like a magic black box with monads, monoids, applicatives..etc etc

</comment><comment><USER2> The human brain understands objects more intuitively rather than abstract mathematical objects.</comment>


Think Julia: How to Think Like a Computer Scientist - <AUTHOR> https://benlauwens.github.io/ThinkJulia.jl/latest/book.html#_colophon <comment><USER2> Ubuntu 18.10 version doesnt work with proxy. Couldnt import any of the julia packages, and my git and ENV has my proxy settings that work.</comment>


Tracking down a segfault in grep - <AUTHOR> http://blog.loadzero.com/blog/tracking-down-a-segfault-in-grep/

<comment><AUTHOR> Author here. Part 2 will be coming soon.

If you would like the immersive experience - try this at the mac terminal:

echo i860 | grep --color -e i860 -e i86

<comment><USER2> Yep, and the crash reporter gives:

      Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
      0   libsystem_platform.dylib      	0x00007fffxxxxxxxx _platform_memchr$VARIANT$Haswell + 101
      1   libsystem_c.dylib             	0x00007fffxxxxxxxx __sfvwrite + 268
      2   libsystem_c.dylib             	0x00007fffxxxxxxxx fwrite + 142
      3   grep                          	0x00000001xxxxxxxx 0x10xxxxxxx + 13606
      4   grep                          	0x00000001xxxxxxxx 0x10xxxxxxx + 12465
      5   grep                          	0x00000001xxxxxxxx 0x10xxxxxxx + 8190
      6   libdyld.dylib                 	0x00007fffxxxxxxxx start + 1

A different version from yours though:

      what /usr/bin/grep
        PROGRAM:grep  PROJECT:bsdgrep-17

<comment><USER3> Is it possible that you're using Yosemite and TFA uses Mavericks? I have the same bsdgrep-16 on Mavericks.

<comment><AUTHOR> Yep - I'm on 10.9.5

<comment><USER2> yep, 10.10.2 here

</comment></comment></comment></comment></comment><comment><USER4> Great read.. even prompted me to order "The Linux Programmer's Toolbox" from the author's affiliate link. For me there is no other way to REALLY learn about operating systems or hacking in general without tackling such problems that force you to dig more the further you look . This is the reason I prefer Dtrace as my investigative tool of choice and FreeBSD as my base OS for my side projects. Combined they allow one to see and investigate problems to a much deeper level without the severe overhead of other tools and understand the practical workings of a Unix derived OS without being a kernel hacker.

<comment><AUTHOR> Thanks for the positive feedback and the contribution, I appreciate it. It's a good book :)

</comment></comment><comment><USER5> It's certainly rather surprising to see that _colouring the output_ would cause such different (and buggy) behaviour - the number of matches shouldn't be affected by whether the output should be coloured or not... I would look carefully at how the execution flow diverges between the presence and absence of the --color option.

</comment><comment><USER6> On your Mac the stack trace hints that the bug is due to a bad pointer/offset/size being passed to fwrite() but in the debug builds it looks like it's in the fastcmp() function. Is this the descrepancy you're talking about in the final paragraph?</comment>


Should Your Start Up Go Static or Dynamic? - <AUTHOR> http://www.mahdiyusuf.com/post/16746798643/should-your-start-up-go-static-or-dynamic

<comment><USER2> The definition given for dynamic and static languages is not very good. The main difference is that a statically typed language has type checks preformed at compile time and a dynamically typed language has them preformed at runtime. My intro CS professor had a really good explanation for this: in a statically typed language, the variables have types where in a dynamically typed language, the values have types.

Also, his graph of languages doesn't really make any sense at all. If he just kept it as a division into groups, it would make sense, but it really looks like he's trying to say that C++ has a "weaker" (whatever that means) type system than C or that Haskell has a "weaker" type system than Scala.

Also, static typing is not always for robustness; it can also increase performance. C is a perfect example of this--it is one of the easiest languages to write bugs in but is also really fast.

Overall, I was not terribly impressed with this article--it gave poor definitions and little new insight (as far as I could tell, it just reiterated the same old cliches about static vs dynamic types without any anecdotes, experience or advice).

<comment><USER3> Not impressed either. It also repeats the misconception that statically typed languages make it harder to do exploratory development. But with type inference, not only do I not have to define my variable types up front, the type checking makes it very easy to explore and refactor code, especially when the exploration involves _changing_ the types.

Add in the ability of haskell to let you write your own control structures and do higher-level programming, and I find myself exploring and refactoring my code much more than I do when using a dynamic language.

</comment></comment><comment><USER4> "Now if you are raging to some serious dubstep, its easy enough to miss that small typo, you go screw it and do it live, and deploy to production. Python will simply create the new variable and not a single thing will be said."

Erm... Did the author test this code before making this assertion?

        >>> def get_first_problem(problems):
        ...     for problem in problems:
        ...         return problam
        ...
        >>> get_first_problem([1,2,3])
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
          File "<stdin>", line 3, in get_first_problem
        NameError: global name 'problam' is not defined

<comment><USER5> maybe he updated it? now it shows is an additional line:

        def get_first_problem(problems):
            for problem in problems:
                problam = problem + 1
                return problam

but there's nothing wrong with this, I assume he meant to return problem instead of problam which would produce an unexpected result without having added 1. Nothing a unit test wouldn't catch though :)

Edit: formatting

</comment></comment><comment><USER6> > Dynamic languages are languages that don't necessarily need variables to be > declared before they are used.

Not exactly true. You do need to declare variables in some dynamic languages (var in JavaScript, for example), but you don't need to declare their __type __.

Anyhow, the whole question is a little irrelevant. The language you pick for your startup is among the factors least important to its success. Just pick a reasonable language that you are productive with, that has library support for the stuff you need, and that works well on the operating systems you care about, and that will be fine.

<comment><USER7> _You do need to declare variables in some dynamic languages (var in JavaScript, for example)_

You can declare variables in JavaScript, but you don't need to. JavaScript is bad example here, as the var keyword is not really used for declaring but for scoping the variable.

</comment></comment><comment><USER8> This discussion is missing two key things: Go and Dart. They both combine the best of static and dynamic languages. There is no need to choose, you can have the best of both worlds, without the disadvantages.

I'm using Go right now, it is amazing, blowing both Python and C# out of the water, with speed of development, robustness and maintainability.

</comment><comment><USER9> I am all for strong, static typing, but in fairness I don't see how C++ can be considered weaker than C?

Or alternately how F# is less static than Haskell or weaker than Scala?

Or am I just reading too much into the chart?

<comment><USER10> …Or that Haskell, with arguably the most sophisticated type system in the world is considered less strongly typed than Ruby!

The graph makes no sense to me.

<comment><USER10> "Standard ML, Objective Caml and Haskell have purely static type systems, in which the compiler automatically infers a precise type for all values. These languages (along with most functional languages) are considered to have stronger type systems than Java, as they permit no implicit type conversions"

<http://en.wikipedia.org/wiki/Strong_typing>

</comment></comment></comment><comment><AUTHOR> Good discussion, but I am sure the developer proficiencies will out weight any of the affects of the language choice in early stage.

<comment><USER11> That, and presence of existing frameworks, libraries, support, etc...

</comment></comment><comment><USER12> If you're asking this question this early, you're doing it wrong. Just code in whatever language you like and can pick up quick, build a product, talk to users, and iterate.

</comment><comment><USER13> Your startup should go with "what works." The exact definition of what works varies for each person/company, but here's a list of things that aren't in it:

* Languages that entirely lack the needed libraries to perform a library-intensive task. (e.g. a CRUD web app in C++) * Languages that you do not know * Langauges that you only want to use because they're "hip" right now

</comment><comment><USER14> Nitpicking, perhaps, but I really would like the author to motivate why Haskel (sic!) is more weakly typed than say Ruby, Java or C#? Not sure how Ruby is less dynamic than Python either (besides the fact that his definition doesn't really admit a sliding scale), but that might be my relative inexperience with the languages showing.

<comment><USER15> No, you're exactly right. The author defines "weakness" versus "strongness" as whether you can do something like "int + array" and get a result other than a type error. ECMAScript is very "weak". Haskell is ridiculously "strong" by this definition, since you get a type error for computing "(1 :: Int16) + (1 :: Int32)". As far as stricter languages go, there is perhaps only Ada.

There are two kinds of language comparisons I've seen:

1\. Language comparisons posted by dabblers, which you could scrape together by reading Wikipedia. You see a lot of poor logic and unsatisfying definitions, because if the logic were sound and the definitions useful, a dabbler would never have enough expertise to write the post.

2\. Language comparisons by experts, which restrict the discussion to history, the underlying logic of type theory, or empirical observations about a small set of languages.

</comment></comment><comment><USER16> You're doing it backwards. You didn't get to choose the language, you use whichever language has the best libraries/frameworks for your problem domain.

</comment><comment><USER17> funny, I've been writing haskell for years and don't remember "declaring" any variables even though its static and strict. author needs to check his definitions.

<comment><USER18> If you have to do graphs, here's one with credibility (solid scala/haskeller/

<http://james-iry.blogspot.com/2010/05/types-la-chart.html>

<comment><USER17> +1 for disambiguating haskell98 and GHC haskell

</comment></comment></comment><comment><USER19> I think the trend is definitely for startups to choose Dynamic languages as well as choosing frameworks to go along with these languages often times.

When you are cash strapped, speeding up time to market often becomes the number one priority.

<comment><USER20> If time is important, then language proficiency is more important than the dynamic/static choice. You don't want to learn the in-and-out of a language in the crunch time of delivering a product.</comment></comment>


Show HN: Dashboard – The missing action center for Android TV - <AUTHOR> https://play.google.com/store/apps/details?id=com.samabox.dashboard <comment><AUTHOR> I always wanted to see a control center on Android TV where I can quickly do things like turning WiFi on/off, switching to a recent app, taking a screenshot, opening a sideloaded app, force closing an app ..etc. I didn't find a good app for that so I created Dashboard.

I used a similar design as the native apps drawer to make the app familiar to users, and the same shortcut (hold the home button) is used to quickly open it. So, in a way, it's also a replacement to the native apps drawer.

In addition to showing apps, it also allows the user to access sideloaded apps, recent apps, and many actions.</comment>


Colorado State University Global Campus offers credit for Udacity class - <AUTHOR> http://blog.udacity.com/2012/09/colo-state-university-global-campus.html

<comment><USER2> Giant step forward.

Requires an $89 proctored exam, which is in line with the cost of other exam- based credit (dantes, clep, etc).

Very interested to see where this goes from here.</comment>


UASP makes Raspberry Pi 4 disk IO 50% faster - <AUTHOR> https://www.jeffgeerling.com/blog/2020/uasp-makes-raspberry-pi-4-disk-io-50-faster <comment><USER3> > Without UASP, a drive is mounted as a Mass Storage Device using Bulk Only > Transport (or BOT), a protocol that was designed for transferring files way > back in the USB 'Full speed' days

Wow, holy shit, TIL.. I was always assuming that USB drives were always SCSI — they show up as 'da' (Direct Attach) on FreeBSD after all.

Looking at umass driver source:

* The driver handles 3 Wire Protocols

* - Command/Bulk/Interrupt (CBI)

* - Command/Bulk/Interrupt with Command Completion Interrupt (CBI with CCI)

* - Mass Storage Bulk-Only (BBB) (BBB refers Bulk/Bulk/Bulk for Command/Data/Status phases)

* Over these wire protocols it handles the following command protocols

* - <USER2>

* - UFI (floppy command set)

* - 8070i (ATAPI)

* UFI and 8070i (ATAPI) are transformed versions of the SCSI command set.

Huh, they _are_ pretty much always SCSI, and "bulk only" is (unsurprisingly) only a USB transport level thing that doesn't change the command set.

I guess "UASP" is some sort of marketing term for Command/Bulk/Interrupt then..?

<comment><USER4> FreeBSD doesn't support UASP (protocol id 98). AFAIK neither do the other three BSDs.

<comment><AUTHOR> Apparently as of 30 minutes ago FreeBSD _does_ support it on the Pi 4! [https://twitter.com/FreeBSDHelp/status/1280062935327313920](https://twitter.com/FreeBSDHelp/status/1280062935327313920)

<comment><USER4> This is the PCI express driver for BCM2711. Good to see this but the UAS support would be elsewhere! Either in the umass driver or a new uas driver (just a guess as I am unfamiliar with the USB related kernel code).

<comment><AUTHOR> Gah, you're right. Totally misread that tweet in my state of non-caffeinated stupor this morning. Still a useful improvement!

</comment></comment></comment></comment></comment><comment><USER5> > I used a Satechi USB-C power tester and measured an 8% peak power savings > using UASP. That means you'd get 8% more runtime on a battery if you do a > lot of file transfers.

No no, even better! Peak power consumption is lower, but the same work is completed much more quickly due to increased throughput, so the energy required for the same work is decreased dramatically. Between the performance increase and the lower power usage I wouldn't be surprised if this reduces energy use by 50 %.

<comment><USER6> Yeah. This kind of savings comes up in interesting places elsewhere -- if you make your algorithm run twice as fast but using twice the memory, your time- integrated memory use (measured in gigabyte seconds) remains the same. So _if_ you can make good use of that memory while your algorithm isn't running, you're saving CPU and not really using more RAM.

For something like the Pi this is unlikely, but in data centers with big, latency-insensitive distributed workloads "using memory for less time" can be a real win. (The battery example with the Pi really is the perfect example though, because you're usually interested in the time-integrated value more than the peak draw.)

</comment></comment><comment><USER7> The Pi 4 is a big revolution, fast enough to serve as a desktop computer for most office people, students, and so on. It's pretty impressive and more attention is being paid to it as a first-class computing platform as time goes on.

Our desktop monoculture has led to serious security problems and massive stagnation at least until recently. Even if you don't use a Pi you should be thankful that they exist.

<comment><USER8> It should be and is decent, but when we tried we ran into numerous paper-cuts:

\- Needed to set up NTP to set the clock, it was always wrong.

\- It can't power down through software, so you have to shut down and then hit the power switch like it's 1990.

\- Audio was a mess and had to spend hours researching how to write and edit a bunch of config files to make it predictable.

\- The weird set up program means you need to do a lot of googling on how to fix issues in a non-standard to linux way. It mostly works however.

\- Raspbian feels not quite "finished." Was much happier with Ubuntu Mate, as they fixed 99% of the paper cuts like audio already, but it doesn't support the 4 yet.

In short, it is a bit too cheap. I would have definitely spent another dollar to see these hardware issues fixed. Or dropped the CPU speed a hundred MHZ, whatever it takes.

In the end, a friend gave us a ten-year-old used iMac for free. I installed Ubuntu Mate on it and it had none of the above problems. It's even a touch faster.

<comment><USER9> A touch faster? The slowest 2010 iMac is the 21" with an i3-540 Dual core CPU, Geekbench 4 is 2211 single/4466 multi. The Pi 4 is around 970/2000, less than half the performance.

The Pi 4 has come a long way in speed since the lowly original Pi, but its still not even close to a 10 year old desktop PC (or iMac).

<comment><AUTHOR> More people (even in 2010) used laptops than desktops, and the Pi is in line with the numbers from the cheaper MacBook Airs at the time (I still have one that runs... though it's getting some weird green lines on the display).

But I can say that working on the 2010 MBA is not fun; one of my webcams doesn't even work with it (choppy at 30p), zoom is... slow at best, and web browsing is a bit choppy even with ad blockers. Even then, it is a smoother overall experience with that hardware and macOS than when I was testing 64-bit Pi OS on the 8 GB Pi 4 a few weeks ago: [https://www.jeffgeerling.com/blog/2020/i-replaced-my- macbook...](https://www.jeffgeerling.com/blog/2020/i-replaced-my-macbook-pro- raspberry-pi-4-8gb-day)

</comment></comment></comment></comment><comment><USER10> But does it work reliably?

I have a cheap Inateck dock which does support UASP (the FD2005). Two or three times I had a bunch of errors like these:

        Sep 22 17:26:01 nuc kernel: sd 4:0:0:1: [sdb] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
        Sep 22 17:26:01 nuc kernel: sd 4:0:0:1: [sdb] tag#2 CDB: Write(16) 8a 00 00 00 00 01 4d b4 c4 00 00 00 03 b0 00 00
        ...
        Sep 22 17:26:22 nuc kernel: usb 2-3: stat urb: no pending cmd for uas-tag 2
        ...
        Sep 22 17:26:22 nuc kernel: xhci_hcd 0000:00:14.0: ERROR Unknown event condition 34 for slot 3 ep 3 , HC probably busted

followed by filesystem corruption.

I found other folks complaining about similar problems, eg: [https://unix.stackexchange.com/questions/239782/connection-p...](https://unix.stackexchange.com/questions/239782/connection- problem-with-usb3-external-storage-on-linux-uas-driver-problem)

Then I disabled UAS. Haven't had any corruption since. It's not absolute proof, but I believe the firmware and/or driver support for UAS with this dock is buggy, and the older protocol works fine. I like speed as much as the next person, but not if it means repeated filesystem corruption...

<comment><USER11> I'm all for blaming dodgy chipsets, but the Superspeed and Superspeed+ support in Linux definitely has not had all of its rough edges filed off yet either-- especially the stuff that uses streams and asynchrony.

However, the article comparing to USB 1.1 is silly.

If you are on USB 2.0 (and I haven't bumped into anything mass storage in the last 10 years that isn't), the bulk endpoints are quite happy to take advantage of the USB 2.0 bulk packet size (512 bytes) and microframes (120us turnarounds) with 13 packets per microframe.

That's going to get you in the 400Mbps+(40Megabytes/sec) range without a lot of problem.

<comment><AUTHOR> That's still less than half the speed you get from USB 3.0 even without UASP from a cheap SSD. I drew the 1.1 comparison mostly to illustrate the fact that the general protocol for MSD on USB was created in the late 90s for an interface 400x slower than 3.0.

</comment></comment></comment><comment><USER12> >I found a USB 3.0 SSD was ten times faster than the fastest microSD card I tested

I looked it up because i know enough about hardware that this shouldn't be the case (even with a cheap SD Card). Seems it's a limitation of the Pi's SD Card slot. [https://www.jeffgeerling.com/blog/2018/raspberry-pi- microsd-...](https://www.jeffgeerling.com/blog/2018/raspberry-pi-microsd-card- performance-comparison-2018)

<comment><USER13> This is more up-to-date, and includes more models of Pi's and SD cards. It was linked in your post, but the post is now out-of-date relative to my link below.

[https://pidramble.com/wiki/benchmarks/microsd- cards](https://pidramble.com/wiki/benchmarks/microsd-cards)

<comment><AUTHOR> If you want to bookmark a page, that's the one that I update every year or two (usually after a new Pi model is released). The blog posts fade a little in relevance over time since I don't keep them updated.

<comment><USER13> Thanks for all the work you've put in to this. I hope we see a Pi with NVMe soon.

</comment></comment></comment></comment><comment><USER14> Excellent reading this; My Pi4/8GB cluster uses a 1000bT PoE hub for a backplane, and / is an nfsroot from a node running a Sandisk UASP USB3 SSD. Like the author, I'm blown away by the fun to be had with Docker and Kubernetes on this cluster. Unlike the author, I'm having a great experience with it as a Mac-replacing daily driver (thanks mostly to never running chromium on the same node that runs gnome-session, to spread things out a bit). Love to read about everyone's Pi cluster adventures.

<comment><AUTHOR> I think I could make it work, but the hindrance to my media (library of 65,000+ RAW photos from three different camera bodies and about 8 TB of 1080p video projects (and counting)) workflows was what really killed it for me.

Even basic photo import / adjustments were a pain with any of the applications I tested, and that was partly due to the Pi's slower GPU/CPU, the 64-bit ARM paucity of desktop apps, and the lack of good (read: like Adobe/Apple/pro-tier media apps) UI-based applications on Linux.

Most of the other issues (like window management and resolution problems) I ran into with the 'Pi for a Day' project I could probably resolve with a few more days' work.

</comment></comment><comment><USER15> Friends, I have a question but I don't have a Pi 4 sitting around to test this:

Is it possible to run a Pi 4 using UASP if I set it up to boot from a decent (Sandisk/Samsung/etc) USB 3.1 pen drive?

Also, is this a reliable setup, or will the device be more stable if booted and run from a MicroSD?

<comment><AUTHOR> I'm going to be testing a few different thumb drives in my next post / video. I have a couple SanDisk models and an Arcanite USB 3.1 drive that I'll be testing... but I don't believe they use UASP (haven't had time to confirm that suspicion yet).

<comment><USER16> Thanks Jeff, you're doing a great service to the community here. I've tried to hunt around for a good system drive and fell short so far; support for UASP/TRIM in thumb drives is both rare, and seldom specified by manufacturers even when present. Looks like the only way is to buy a bunch and try.

</comment></comment></comment><comment><USER17> I've been using UASP SSD drives in Linux for ~ 5 years, the main issue I face is not performance related but w.r.t monitoring.

S.M.A.R.T doesn't behave well with UASP, so not all Smartmontools's feature work[1]. Especially, LifeTime of the SSD don't and they are crucial. I had to resort to calculating remaining life of the SSD manually from the reported lifecycles and negating it with the manufacture's MTBF if they're reported.

I've faced this with devices from varying price range [USB 3.0/3.1] - MyDigitalSSD(OTG), Samsung T5, various ORICO USB SSD enclosures with Samsung EVO/Crucial SSDs on host systems of different architectures(x86/ARM).

How are you all monitoring the life of your USB SSD on UASP in Linux?

[1][https://www.smartmontools.org/wiki/USB](https://www.smartmontools.org/wiki/USB)

<comment><USER18> I have a USB 3.0 Orico enclosure with a Pi4 and I had to pass '-d sat' to smartctl for it to work:

smartctl -a -d sat /dev/sda

Newer versions of smartmontools shouldn't need it, only the older one that Raspberry PI OS has.

</comment></comment><comment><USER19> How does a USB 3.x NVMe drive function on the RPi4? I notice those on Amazon as well.

</comment><comment><USER20> What possible "controller feature" would be needed from the controller on the hardware side to support just another USB protocol?

<comment><USER21> I was curious about this as well. The issue appears to be lack of scatter- gather support. See: [https://github.com/raspberrypi/linux/issues/875#issuecomment...](https://github.com/raspberrypi/linux/issues/875#issuecomment-482533041)

<comment><USER20> which is not required to implement any usb protocol. one can easily use normal DMA and still get a speed gain. since the bottleneck is _not_ CPU, making it work a bit harder putting together those DMA descriptors is worth it.

</comment></comment></comment><comment><USER22> Why can't the RPi have at least 1GB or 2GB of flash storage on its board? My 4 year old, 80 euro android has 8GB.

It's not a secret SD cards quickly fail.

I've not bought the RPi for that specific reason. Even if the RPi is 5 times slower, having reliable storage seems seems like a most important feature.

<comment><USER23> Because forcing everyone to pay a chunk more money for on-board storage which not everyone needs is unnecessary. Their decision shows that cost is a more important feature and I don't think that should come as a surprise, there's plenty of stuff out there justifying the various decisions and it all comes down to cost.

<comment><AUTHOR> I'm guessing if the RPi Foundation went that route with the Pi 5, it would be similar to the Compute Module where there would be a cheaper 'Lite' version without eMMC then more expensive ones with eMMC.

</comment></comment></comment><comment><USER24> Just did a "dd if=/dev/zero [etc]" in my Rapberry Pi 4:

4974456832 bytes (5,0 GB, 4,6 GiB) copied, 25,4896 s, 195 MB/s

Using this controller and a Samsung EVO SSD drive, I'm really happy with the results: [https://geekworm.com/collections/raspberry- pi/products/raspb...](https://geekworm.com/collections/raspberry- pi/products/raspberry-pi-4-model-b-x825-2-5-inch-sata-hdd-ssd-expansion-board)

</comment><comment><USER25> Well, looks like I need to ditch the SD cards on my Pi4 based robot! Seems like this would improve reliability over SD cards too.

</comment><comment><USER26> I honestly thought this was common knowledge.</comment>


Ask HN: How do you separate art from the artist? - <AUTHOR> <comment><USER2> My sister-in-law could be lured away from the canvas with a good bottle of red wine but you'd need dynamite to separate my brother from his record deck...

</comment><comment><USER3> Care to elaborate ?

</comment><comment><USER4> try that with Cosby..</comment>


Ask HN: For how much should I sell my side project? - <AUTHOR> Hi HN,
I have a Saas side project that I'd like to sell, but not sure about the price.
It's solo and bootstrapped. I work on it for 2-3 hours per month, answering emails, no other work is required.
It has 70 paying users and 500 total. Profit is around $4000 monthly. What would you say? <comment><USER2> 1x yearly revenue for a business like that would be something people would accept rather easily. SaaS runs a lot of risk that someone will produce a better product. Customers will also generally leave the product over time. 1x annual revenue is a quick sale.

</comment><comment><USER3> I would be interested as a potiential buyer. Please send me an email at waterloodevs@gmail(dot)com

</comment><comment><USER4> Please email more details to martin at pixdeo.com</comment>


Startups should not use React - <AUTHOR> https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2 <comment><USER2> It's worth noting this "you can't sue us for violating your patents if you use our non-free open source software" is working as designed.

Facebook claims that if _every_ company adopted a React-like license, that software patents as we know it would basically die. It's worth noting that both Google and Facebook's patent lawyers are generally of the opinion that software patents are net bad, but differ in their opinions of how to express that intent without exposing their companies to additional risk from patent trolls.

If you want to be acquired, then this is the opposite of what you want. You file patents for every part of the product you can; you audit your dependencies to avoid copyleft (AGPL and GPL) and React-like licenses, so your software can be folded into a 100% closed source product or shut down or whatever your acquirer wants.

If you run a start-up, and you're worried about the React license, you should be speaking to your own legal counsel about the best way forward.

<comment><USER3> If Facebook's approach is so great, by introducing a legal provision in the OSS license, how come it has not been adopted by any other company except for Palantir, despite being introduced in 2014?

I analysed 75+ OSS projects from 35 companies, and Facebook is practically alone.

[https://medium.com/@raulk/list-of-companies-and-popular- proj...](https://medium.com/@raulk/list-of-companies-and-popular-projects-by- the-open-source-licenses-they-use-35a53eaf1c80)

<comment><USER4> I commented elsewhere on this, but how about CDDL? IANAL but it seems to do the same thing, patent poison pill in the event of suit.

<comment><USER3> CDDL includes a "weak patent retaliation" clause [1], meaning you only lose the grant if you initiate a patent infringement claim within the context of the project, i.e. saying that the project you have adopted infringes a patent of yours.

And even if you do, the revocation takes effect in 60 days, which is pretty friendly IMHO.

[1] [http://en.swpat.org/wiki/CDDL_and_patents](http://en.swpat.org/wiki/CDDL_and_patents)

</comment></comment></comment></comment><comment><USER5> Nerds shouldn't write opinion pieces about subject domains they don't understand.

Seriously, stop this. Sometimes you just need to admit you have no idea what you're talking about and shut up.

The author honestly thinks using Preact or Inferno could protect them from patent lawsuits. Oh, wait, maybe "Facebook holds any software patents on the Virtual DOM or the React APIs" so better use Vue and Cycle.

Unless you actually know

1) which patents Facebook holds and

2) which patents are relevant to each framework/library (i.e. React and various its alternatives)

stop giving people legal advice about which library they should be using.

The cosmic irony would be if Facebook didn't hold any patents covering React to begin with but DID hold patents covering parts of Angular, Ember, Vue and Preact, over which they can sue who they like because Facebook never gave them a patent grant for those. Sounds far-fetched? It isn't because we don't know which actual patents these could be and who holds them.

Or for all you know Google might sue you. Or Apple.

This isn't a discussion, this is literally just a bunch of nerds ranting on the Internet about problems they don't sufficiently understand, playing Three Blind Men with the elephant that is Software Patents.

<comment><USER6> _You_ should stop, immediately. Attempting to silence an issue because people are not experts on the issue is beyond immoral.

Please reflect on how you are hurting everyone, not helping.

<comment><USER5> There isn't an issue. The issue is software patents.

What's hurting people is self-proclaimed experts writing authoritative blog posts about what technologies people should chose and presenting it as if it were legal advice.

This entire drama is a 100% repeat of what pops up on almost a monthly basis because some random developer finds out about Facebook's open source patent grant and decides he has an opinion without even understanding the basic underlying concepts.

There are legitimate issues worth discussing, especially around the notion of open source purism (i.e. whether React should migrate to the Apache license to make it more compatible). But instead of having these discussions we get ridiculous unfounded opinion pieces by yet another "dude with an opinion" who didn't even bother validating his basic premises.

</comment></comment></comment><comment><USER7> The author is making assumptions about what Open Source is and what should or shouldn't be. While many developers would like Open Source to be about "creating communities to build better software together" (myself included), open source just means that everyone can read the code.

Different developers and companies might use Open Source for different reason, included but not limited to: reduce Q&A, brand relevance, increase hiring power, strategic positioning, ideals that code should be _libre_, etc. Some companies and devs might even want several of those!

In this line, Facebook is a private corporation who I think we all agree their main reason for releasing React.js or any code at all doesn't seem to be purely idealistic. I would say strategic position (the best tool in the dev world, notably against Angular) and increasing their hiring power are really high within their reasons to release Open Source.

It is patently absurd to tell companies what to do and patronizing to tell developers what to do. Also, something that I don't see anyone arguing for/against is why so many big companies, even ones competing with Facebook, can use React.js freely and without worries? It's a point that anyone arguing against React is conveniently ignoring but I'd love to hear about.

<comment><USER8> I don't disagree with your general point, but I don't think we can ascribe a singular objective to Facebook as an entire organisation.

It was quite clear from the discussion around the recent github issue asking them to consider relicensing that there are many parties internal to Facebook with a say in the decision, and it's unlikely they all agree on everything. The React developer's motives for releasing React as open source are probably more along the lines of "creating communities to build better software together", and there are obviously others within Facebook who are motivated by protecting Facebook from lawsuits. What we see on the outside is the resulting compromise. See Dan Abramov's comments in the issue, particularly [1] & [2]

1: [https://github.com/facebook/react/issues/10191#issuecomment-...](https://github.com/facebook/react/issues/10191#issuecomment-316223034) 2: [https://github.com/facebook/react/issues/10191#issuecomment-...](https://github.com/facebook/react/issues/10191#issuecomment-316739812)

<comment><USER7> Sure, I totally agree. What I tried to express is that there is probably a hiring and brand push as well for keeping React Open Source, not that it is the only one.

</comment></comment></comment><comment><USER9> Trust. Trust. Trust and Trust again. My brain becomes exhausted within seconds of reading a licence. Not just because I'm lazy, but because I know that however closely I think I'm reading it, I probably won't be reading it closely enough to be 100% sure of my conclusions (viz. the differences of opinion here from people that actually have read this thing).

So what do I do? I trust certain organisations and I don't trust others.

No-one in their right mind can trust Facebook. You might as well trust the Ocean.

<comment><USER5> Here's an idea: if you intend to lock people into a technology so you can sue them later, would you

a) build a small library that encourages modular code, has tons of escape hatches to use other libraries and has so few concepts it actually encourages learning the language and solving problems outside the library instead? Or

b) build a large monolith that comes with dozens of idiosyncratic concepts and its own way to solve every problem so you build your entire application inside of it?

If I was a patent troll, I would create Angular, not React.

I don't trust Google, I don't trust Facebook, I don't trust Tilde, I don't trust Evan You. But at least with React I'm not deeply invested in non- transferable knowledge and have easy migration paths if I ever need to move away from it.

<comment><USER9> Probably why I'm still using Backbone - and actively pondering other options!

<comment><USER5> You think there aren't patents covering Backbone?

Or _any_ other part of your applications?

<comment><USER9> My concern isn't with Patents per se. It's mainly with the good faith of the originator of a particular piece of code. I mean yes there could be Patents covering everything and anything I ever do, but how would I assess such a thing. I haven't got much control over that side of things.

However, I can exercise judgement on the source. And my judgement on Facebook is that I never saw them do anything I liked.

</comment></comment></comment></comment></comment><comment><USER10> There was a time when React was Apache v2! [https://github.com/facebook/react/blob/3bbed150ab58a07b0c4fa...](https://github.com/facebook/react/blob/3bbed150ab58a07b0c4faf64126b4c9349eecfea/LICENSE) shows that license.

Has anyone seriously explored forking React from the last Apache v2 version?

<comment><USER11> If they published React under Apache v2 at one point in time, how can they later re-release under a new license and claim patent rights on it then? Since, assuming whatever patents they own covered this version of React as well...wouldn't that be considered prior art?

<comment><USER12> From what I understood, It is not a patent on React. As far as I can tell nothing about React is patented... and that is not the discussion over the past few days has been about.

This whole shebang has nothing to do with React itself, or the "technology" that React uses or anything, but more about the way many FB's open source libraries are licensed, one of which is React.

The license specify that you are free to use React as you would use a BSD licensed software, provided that you never sue FB for a patent. That means, if you use React, and you happen to own a patent for something that FB utilises, you can't sue FB without losing your React license. So, your option is either suck it up and let FB use your patented thing for free, or rewrite your software to take React out of it, and then proceed with the lawsuit.

<comment><USER13> > That means, if you use React, and you happen to own a patent for something > that FB utilises, you can't sue FB without losing your React license.

Correction: Without losing your license to use any _patents_ on React. Which...

> As far as I can tell nothing about React is patented...

I agree. Which means the entire issue is a huge paper tiger; you lose your right to use something that doesn't seem to exist.

<comment><USER12> I wouldn't say it's entirely paper tiger though, given that it also discourage you from exercising any patent you have against Facebook, no matter how legitimate the patent is.

I'm neither a native English speaker nor a lawyer to really understand the wording in the legalese, or if it only cover software patent or patents in general, but I think that clause is pretty broad.

<comment><USER13> Here's the thing:

If you have a potential patent claim against Facebook (or any other large entity) you know that they will, as a matter of course, dig through their enormous stockpile of patents looking for some counter-claims to make the second you file. Given the size of that stockpile, they're probably going to end up with a sizeable stack, so you need to engage in some serious due diligence before filing to evaluate the strength of your claims and the strength of their likely claims.

All the React patent grant means is that, _IF_ this happens, they can add any React-based patents to the pile, if any exist. I rather suspect that there _are_ no React-based patents, but it doesn't really matter if they are, because statistically speaking, it's not going to materially change the size of the stack. (Not using React entirely also won't materially change the size of the stack; any hypothetical React patents probably apply to whatever hypothetical non-React tech you used instead.)

> it also discourage you from exercising any patent you have against Facebook

No, what discourages you from exercising a patent against Facebook is that _they 're Facebook_, and they have vastly more money, lawyers, and patents than you do. The potential React patents are the least of your worries.

</comment></comment></comment></comment></comment></comment><comment><USER14> I really like the idea behind this license.

They want to see a world where software patents no longer exist. So they write a term into their licensing that makes it really difficult for people who _do_ like software patents to use their stuff.

I think I will move my projects over to a similar license. The only thing I would change would be to broaden it to invalidate if your company sued _anybody_ over _any_ patent.

If everybody did that, maybe software patents would finally go away.

<comment><USER15> >Facebook claims that if every company adopted a React-like license, that software patents as we know it would basically die.

If you think patents shouldn't exist then why is the purpose of the license to protect a single company from patent lawsuits. Why isn't the license covering any patent lawsuits of any kind to any party like the ASL does? Why does the license only protect facebook? What if there are patents that apply to react that facebook doesn't own? Patent trolls can't sue facebook but they can still sue users of react and continue to use react.

>If everybody did that, maybe software patents would finally go away. No because facebook can still sue you for other software patents for internal software they didn't release.

Facebook's patent grant is a halfassed solution. They are either outright malicious and merely acting in self interest or blatantly incompetent. But since they are unwilling to change the license and patent grant I'm betting on the former.

<comment><USER16> Facebook's licence is as half assed as the free Internet they wanted to bring into India and some African countries. It only benefits Facebook and comes with strings attached.

</comment></comment></comment><comment><USER17> Does this mean I should primarily use services from startups that use React, so that they won't get acquired and the service shut down?

<comment><USER18> Also keep monitoring them for when they unviel their latest UI change for usability improvements which sublty removes React for some other framework. This change would be the canary in the mine and would probably be accompanied by changes in terms of use / privacy policy with some subtle word changes. One could almost imagine this monitoring being automated... if it could be backed up with data!

</comment></comment><comment><USER19> FUD, FUD, FUD. Pure FUD.

There are, AFAIK, no known patents on React. This means you can go ahead and sue Facebook for patent violations to your heart's content. The license they granted to you to use any of their patents applied to React (of which there are none) is terminated, and you can merrily continue using React.

If this is incorrect, and Facebook actually do hold patents on React, then all of the popular alternatives almost certainly infringe on them as well. So, the worst-case scenario is no different.

<comment><USER20> > AFAIK

Should I tell that to my investors? That AFA matthewmacleod on HN knows, we are good?

> then all of the popular alternatives almost certainly infringe on them as > well.

But the lawsuit would be against those alternatives directly and not my company? I'm not sure about this, but I'm not also sure why we should be taking advice about this issue from non-experts.

<comment><USER21> You could easily use this argument against the writer of the original blog post. "Someone wrote a blog post saying React's license is bad"

<comment><USER20> That's a fair point. We really need some patent and license lawyers to weigh in on this and willing to put some skin in the game. I think Facebook should also be willing to change the license to clarify intent so they can't later use the license to do something other than what they claim they want to do: make software patents useless.

<comment><USER22> An IP lawyer has: [https://firstname.lastname@example.com/react-facebook-and-the- revok...](https://email@example.com/react-facebook-and-the-revokable- patent-license-why-its-a-paper-25c40c50b562)

<comment><USER20> Thanks. I'm already aware of that article. What I meant by some skin in the game is the opposite of what the author included at the end of that article:

"Disclaimer: As with everything in law, I reserve the right to throw every word out like yesterday's newspaper if presented with new information or a recent decision by a non-caffeinated judge. Hubris and the law make for bad bedfellows. If you have information or arguments that I didn't consider, make them below! I will update this blog if any new information changes my opinion."

</comment></comment></comment></comment></comment></comment><comment><USER11> Do most software startups even have patentable technology? I'm rather curious about this. Most consumer and SaaS apps I know of are built on non-patented software so I generally question this advice.

The fridge example was a case in point of how ridiculously low the odds of any company getting into patent litigation with Facebook are. To go to battle with FB you're gonna need millions and it's going to take years. That's not a light decision.

<comment><USER23> It's purely anecdata but I've worked for a dozen different companies in my career. The only companies that are still around today are the companies that had patents.

<comment><USER11> I worked for a $5 billion 25 year old company that had no patents to its name (until this year). What matters is execution and distribution, above and beyond patents, especially in software.

</comment></comment></comment><comment><USER24> Are companies getting asked about React in M&A due diligence or has any lawyer recommended this, because otherwise this post is pure clickbait.

<comment><USER25> code licenses come up in even simple funding rounds. IP happens in due diligence to avoid "oh actually this one freelancer owns all the code"-style situations.

</comment></comment><comment><USER26> > If all giants agreed to open source under the "BSD + patents" scheme, cross- > adoption would grind to a halt. Why? If Google released Project X under "BSD > + Patents", and Amazon really liked it, rather than adopting it and losing > their right to ever sue Google for patents, they would go off and build it > on their own.

This seems like a reasonable argument, but it doesn't seem to have deterred several big name companies from using React. Airbnb, netflix, and dropbox for example.

<comment><USER27> Developers are not lawyers, and developers and lawyers don't talk to each other all the time. I wonder how many of those companies even bothered to check the license, given how fast they have to move? I've been guilty of that as well in the past.

<comment><USER28> > I wonder how many of those companies even bothered to check the license, > given how fast they have to move?

Airbnb, Netflix, and Dropbox? I guarantee you all of those companies have lawyers that reviewed the license.

<comment><USER27> Sure they have lawyers, but I highly doubt they reviewed it and I don't blame them since open source licenses have been pretty vanilla for over a decade now. The only companies that actually even really reviewed open source in terms of legal implications were extremely risk averse ones like the telecoms... in the 90s and early 2000s. Of course I could be wrong especially if any of those companies use a tool that checks licenses (I have my doubts).

</comment></comment></comment></comment><comment><USER5> Aside from the validity of the article's claims about patents (see my other tirades about that) I'm not sure the point even makes sense.

React, the library, is at its core a glorified templating system. It provides plenty of escape hatches that make migration as well as inclusion of foreign UI components and libraries a breeze. It's stupidly simple to migrate away from.

If you are a high valuation startup looking to get acquired for your technology (rather than acquihired) I find it extremely unlikely your valuation hinges on your frontend code. And even if it does I find it extremely unlikely your frontend is tied so closely to React you won't be able to spend, say, 1MM replacing React with Vue or what have you (maybe at the cost of a little pizzazz).

If your frontend is animation-heavy, that likely doesn't live in React land. If your frontend is mostly static, it should be trivial to replace React as well.

If your startup is valuable, being sued over some frontend library is probably the least of your concerns. If the company looking to acquire you has enough cash in the bank to sue Facebook, they have far more than enough cash in the bank to replace React.

<comment><USER29> Just throwing this out there - replacing an entire front-end monolith framework in large part depends on the size/scale of the application, and how well it was implemented to begin with.

<comment><USER5> Okay, so maybe the recommendation should be "build your app around the assumption you may have to swap individual dependencies out in the future".

Amazingly enough, this recommendation is also beneficial if it turns out there are patents covering Angular, Vue or Ember.

</comment></comment></comment><comment><USER30> I'm _not_ using React for _another_ reason. I don't agree with the way they treat their users (i.e., as a product).

</comment><comment><USER31> What happened to the "software patents are ridiculous and should never be granted" argument?

Now it seems that the same sort of people advancing the anti-patent argument are angry about FB's licence. This seems like pretty muddled thinking.

<comment><USER32> It seems like the times have changed in that regard. If you hung around on slashdot in the 2000s, it was commonly accepted that software patents are bad, and that the GPL was more good than bad.

Now, it appears there are many people thinking they will at some point get filthy rich with their patents. And I've frequently seen the GPL being derided as some sort of communist plot.

It's good to see that at least the large companies are still on the side of openness, although I fear what will happen when today's commentators become tomorrow's CEOs. Imagine something like the nodejs ecosystem, except now you'll have to buy a $1000/year subscription to the "node modules starter edition".

</comment></comment><comment><USER33> "So you've sewn up the market eh? Here's your check for $500million."

"But don't you want to know what technology we built it with?"

"No."

</comment><comment><USER34> > If there is no chance of igniting a community, there is no reason to open > source.

I see most of this article as a dangerous way of thinking, but especially the above.

The mentality I get from this quote (especially combined with its context) is basically: I should only open source something I'm working on if I can build a community around it (that I control/influence/benefit from).

Open sourcing your software should be the default. If I make a tool or small library/function, I would more look for a reason NOT to open source it. When I can't think of one, I will open it up, regardless of whether or not there is a "chance of igniting a community".

</comment><comment><USER35> Can someone please share what patents cover react?

Because if they're revoking patents that don't cover react then there should be no problem to continue using react right?

<comment><USER36> If I understand that license correctly, it is not 'patents that cover react', it is 'any facebook patent, present or future'. Also as explained in the article, it is also about my patents if I have any, in case facebook tries violating them. Far wider than 'react patents'.

<comment><USER35> I understand that but here's the scenario I'm talking about:

\- I use React for my startup's dashboard

\- I sue facebook for violating my startup's patent without removing my react dashboard first

Now, what patents can facebook use to counter sue me that they couldn't sue me with anyway had I not used react?

<comment><USER37> Facebook won't counter sue you. They don't have to. You just lose your right to use React, due to its license.

<comment><USER38> That's not true: [https://code.facebook.com/pages/850928938376556](https://code.facebook.com/pages/850928938376556)

Facebook can't take away your rights to use React under the BSD license, no matter what you do.

</comment></comment></comment></comment></comment><comment><USER39> This is a badly written article full of FUD. It's written by an angry backend engineer, not a lawyer, and it shows.

He goes from this:

> _The instant you sue Facebook, your patent rights for React — and any other > Facebook 'open source' technology you happen to use) — are automatically > revoked._

To this:

> _If you use React, you cannot go against Facebook for any patent they hold. > Full period._

"Full period", really? Because the first does not imply the second. This is now how patent law works.

Now, I'm not a lawyer either, but broad assertions like these should tell you that there's emotion at work here, not reason. In his fourth update, he made a list of companies that add something about patents to their open source licenses, implying that somehow that that proves something.

So the thing that people confuse here is patents and copyrights. The BSD license grants you the right to use works copyrighted by Facebook people and contributors. The patents clause, further, promises that should Facebook hold any patents that cover the OSS, they won't use them against you, unless you sue them first.

There is the whole idea floating around the internet that a BSD license somehow ensures that nobody will sue you for patent infringement. I really don't understand where this comes from. Hell, Android is Apache Licensed (which includes a patent grant) and still anyone who makes an Android phone has to pay license fees to all kinds of patent trolls (Microsoft most notably). These things are totally separate.

So first, if you sue Facebook for patents, you lose their patent grant (so they can sue you back, which everybody always does anyway - it's the only defense companies have in patent wars). But you don't lose the BSD license or anything. That's not how it works. All you lose is Facebook's promise not to sue you because you use React.

Secondly, and this is the core point, patents don't cover code, they cover ideas. Any patents that Facebook might have that, right or wrong, cover React, will surely be written broad enough that they also cover Preact, Inferno, Vue.js probably, and I bet also Angular. Not using React but one of these other libraries therefore makes no difference - in both cases, Facebook can use their React-ish patents to sue you.

To my understanding, patent lawsuits rarely get to the nitty gritty details of actual patents in reality. It does not matter whether a Facebook patent written broadly actually covers Vue.js or not - in practice, more often than not, companies will compare the height of the patent stacks they have, and agree on a settlement based on that.

All this patent grant says is that Facebook gets to use their patents that cover OSS to make their stack of paper a bit higher. Like they would if they hadn't made a patent grant at all.

So, repeat after me: using open source does not shield you from patent infringment lawsuits.

</comment><comment><USER40> What makes the PATENTS file legally binding? If I install React via NPM/Yarn, or even as a dependency of another project, I will not see this file.

LICENSE is a pretty common convention and you could argue I should seek out this file in every one of my dependencies' dependencies - but how would I know to look for PATENTS?

Are all statements in the code base legally binding? Could they be hidden in a source file somewhere?

<comment><USER41> Not a lawyer, but I can imagine it can be expected that you do some due diligence before installing it through npm - like checking the website whether their license allows you to use it, and on what terms.

<comment><USER40> If what you say is true then I think our tool chains are failing us.

My React project has 1,015 dependencies (directories in node_modules). If I didn't have locked versions then every minor automatic update could bring in more dependencies without me knowing.

Can anyone honestly say they've done such due diligence?

<comment><USER42> _Can anyone honestly say they 've done such due diligence?_

That seems doubtful.

And that's a real and potentially serious problem, because IP laws typically don't contain any exemptions for code you're using that infringes someone's IP rights just because it was contributed by a third party.

</comment></comment></comment></comment><comment> vladimir-y Can the title be generalized? Like don't use anything from FB?

<comment><USER40> This is true, all of Facebook's projects have the same PATENTS file. The title is the most clickbaity though, which is the intention of the piece.

<comment><USER43> Yarn, RocksDB and ZStandard does not.

</comment></comment></comment><comment><USER44> Even if everything in this article were 100% correct, which is clearly arguable, think about how this would truly play out. Company X would sue Facebook. Facebook would sue them back for using React... and then... lawsuits would ensue. Attorneys would do their things. Cases would be argued out of court. Lots of legal stuff would be going on, and plenty of time would be had for the engineers to select and move to a new framework.

Yes, I think there are problems with the license, and I'm not using React. But do I really think those problems will result in some scenario where you have an overnight show-stopper of your business because of it? Extremely unlikely.

Startups need to stop fearing the law and start understanding it.

</comment><comment><USER45> What is the safe alternative here?

I mean probably FB got patents.

and

Probably they have at least one that covers things React can do.

Almost every framework moved to components and virtual DOM.

So there is a big chance that any framework out there could infringe some of these React patents.

So their either can

revoke your React license when you sue them

or

Sue you over patent infringement if you don't use React

<comment><USER13> You're mostly right, except:

> revoke your React license when you sue them

Incorrect; all they can do is revoke your _patent_ grant and then sue you for patent infringement. They can't "revoke your React license".

So the difference is, if you use React they can only sue you for patent infringement if you sue them first; if you use something else they can sue you no matter what...

...if they have a patent on React. Despite your breezy assertion, patents are public, people have looked, and none have been found.

<comment><USER45> So other libraries can't be sued because there are no patents to be infringed?

And it doesn't matter that FB terminates the patent grant if you sue them, because there were no patents to start with?

</comment></comment></comment><comment><USER46> There were a lot of people in the older thread about the patents stuff saying things like "well, are you ever going to sue Facebook?? You don't need to worry about the patents stuff".

But consider this: Facebook do something disastrous, like leak a bunch of private or financial data and it affects you really badly. There's a class action against Facebook. Now you can't join it, because you don't wanna rewrite your app without React to ensure Facebook can't counter sue over a patent that may or may not exist on React.

<comment><USER47> Except that the patent grant states that the grant only voids if you sue (or are contributing money to such a cause) because of patents. The grant is still valid if you sue Facebook for non-patent related issues.

</comment></comment><comment><USER48> This doesn't convince me. As a consumer patents and patent lawsuits are almost always bad. Patents reduce options in the market, lawsuits between companies waste resources, startups being acquired reduce market options. The only real argument is that it will prevent communities from forming. But I don't buy it. Open source needs competition too, monolythic ecosystems are bad. As an example, Apple didn't want to contribute to gcc so they created LLVM which is a boon to everybody.

<comment><USER49> apple did not create llvm. llvm started as an academic project, and apple took advantage from its ecosystem -- same as many other companies did.

</comment></comment><comment><USER20> I wonder if Facebook's claims that they are doing this in order to make patents useless would have legal standing. In other words, if they become "evil" about this patent clause at some point in the future and try to enforce this in the bad ways that people are imagining _might_ happen, then doesn't Facebook's clearly and publicly stated intentions hurt any claim they would make which goes against those intentions?

</comment><comment><USER50> Facebook is like the Disney in the tech world. They want to be that trove of intellectual property.

They take free-to-use stuff (Disney is cheap ripoff of Hans Christian Anderson's fables), and create "magical" stuff that they protect with their arsenal of lawyers.

If Facebook is able to pull the wool over our eyes this time... OSS is gonna be in a bad place in the next century just like how Disney single-handedly lobbied to change public domain laws in America.

</comment><comment><USER51> Someone with knowledge should bring clarity to all this noise!

My understanding is, if I sue FB for some patents, they can sue me back with any patents they may hold on React. We do not know of any such patents they own. So practically I am no safer if I use preact/vue or even Angular, since they may own some patents that cover those tech.

tldr; Do not sue FB unless you have muscles.

</comment><comment><USER52> It truly seems non-mature businesses should stop relying on open-source with "baggage" and utilize only free software (AGPL3+) that has dual-licensing for commercial use with support as e.g. in Qt, unless you are 100% sure for your product lifecycle you won't get into direct business collision with the "baggage" author.

<comment><USER53> AGPL is too toxic to use. Fortunately, there's not much compelling software using it, so it's easy to avoid.

Businesses should shun AGPL, period.

<comment><USER52> Why is AGPL toxic? I'd advise all developers to do dual AGPL/commercial license for all their open source projects. AGPL would guarantee that their work is not used by others without giving back anything; commercial one to keep them afloat and allow proper business.

</comment></comment></comment><comment><USER33> "Look, we were going to buy you for $500million but our thorough due diligence has turned over a rather nasty stone that you probably wished we didn't look under. You know what I mean don't you? YES - we found out your dirty little secret that you're using ReactJS. Due to this, we have decided to pull the deal in favor of your competitor who uses AngularJS. What you need to understand is that although you've cornered the market with your superb software and business model, we are dead serious about never buying companies that have built on ReactJS. We have a deep, and we think entirely valid, concern that Facebook will, at a point in time, suddenly pull the carpet from under you and Mark Zuckerberg will be laughing at us saying 'suckers... we sure got you with the whole ReactJS ruse didn't we!'"

"We're also not very enthused about you building on Amazon - surprised you'd take a risk like that, it doesn't indicate much business sense."

"Sorry to say, but your business, due to the ReactJS decision, is worth $0."

<comment><USER54> If you're using angular, you're almost certainly using Typescript which contains this less extreme version of the same sort of patent clause:

3\. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non- exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

As I understand it, Angular in general doesn't contain a patent grant at all. Believing that that is superior to a grant that is removed in certain circumstances requires some contentious legal argument that as far as I know has not been demonstrated to stand up in court.

<comment><USER55> But TypeScript compiles to JS right ? How can one prove it's "used" in production ?

</comment></comment></comment><comment><USER56> my reason is that your app doesn't need the whiz bang reactiveness of react of any other frontend framework just yet. it's just extra overhead.

</comment><comment><USER57> I've been saying this for months. Don't use React!

</comment><comment><USER58> Easy workaround: Install Preact. No code changes required, at least not for me last year.

<comment><USER45> even the creator of preact said he doesn't know if he infringed FB patents with the creation of preact, because nobody knows what React covering patents FB holds.

<comment><USER54> And in this, the situation is exactly the same as with any front end library, or even not using one at all. It's almost impossible to know if you're infringing any patents.

</comment></comment></comment><comment><USER59> Yeah because small startups will totally go after Facebook. Make sense. Wow.

<comment><USER60> Google looking to acquire small startup X? Not anymore because they use React. Wow.</comment></comment>