They put Java into some standard for Blu-Ray. A lot of places and things were using it thanks to the big, marketing push back in the day. Then, to use that or part of it you need to run Java. As usual with Java, using it is a security risk. This kind of thing happening in tech or standards designed by big companies for reasons other than security is so common that it doesn’t even alarm me anymore. I just assume some shit will happen if it involved codecs or interactive applications.

Old, best practice is to run the Internet apps and untrustworthy apps on dedicated box. Netbooks got pretty good. Substitute VM if trading for cost/convenience. Mandatory access control next with low assurance. You’re totally toast next.

Like @nickpsecurity said, it is used in lot of places so not including it is same as raising middlefinger to your users (they cannot watch their expensive discs) and they go and use some other application, which probably is even less secured. We really cannot make ordinary users stop wanting to use their goods because now we know that they are insecure. Having secure system does not matter if no one uses it.

I share most of his frustrations, both about the fundamental design issues and the incidental issues the plague users. However, I think most build systems are pretty dreadful. The only one I’ve used that I’ve been really enthusiastic about is Nix, but it still has many incidental issues that should be addressed.

In general, I think any build tool that thinks of things in terms of a mutable directory full of files that need to be poked and prodded with tools in the correct order is not the way, fundamentally, we should be thinking about things. Thinking of things in terms of a chain of pure functions could make these things conceptually simpler, faster, and more reliable.

Quasar implements continuations by rewriting JVM bytecode. The goal here appears to be to implement similar functionality at a lower level and let existing JVM bytecode transparently access it. It’s not entirely clear from this proposal how different the implementation will be, however.

Idris looks really well designed, and I think these improvements are actually quite significant. Strictness by default is a game-changer for me; apparently the records and monads are more convenient to use (and there are effects, too? Not sure how experimental they are). If Idris was self-hosted, produced good static binaries with performance comparable to OCaml, and had a package manager I would definitely give it a serious try.

Idris also has a quite buggy implementation at the moment, but like everything else you mentioned, it is a solvable problem. I think it’s a contender for a widely used industrial language in the future. Though at the moment it’s mainly used by people with pretty sophisticated FP knowledge, I think its dependent types and effect system may ultimately become something that’s easier for newcomers to understand than a lot of Haskell is.

They are pretty unapologetic about 1.0 not being industry-grade, and it is not quite the goal of the language:

Will version 1.0 be “Production Ready”?

Idris remains primarily a research tool, with the goals of exploring the possibilities of software development with dependent types, and particularly aiming to make theorem proving and verification techniques accessible to software developers in general. We’re not an Apple or a Google or [insert large software company here] so we can’t commit to supporting the language in the long term, or make any guarantees about the quality of the implementation. There’s certainly still plenty of things we’d like to do to make it better.

All that said, if you’re willing to get your hands dirty, or have any resources which you think can help us, please do get in touch!

They do give guarantees for 1.0:

Mostly, what we mean by calling a release “1.0” is that there are large parts of the language and libraries that we now consider stable, and we promise not to change them without also changing the version number appropriately. In particular, if you have a program which compiles with Idris 1.0 and its Prelude and Base libraries, you should also expect it to compile with any version 1.x. (Assuming you aren’t relying on the behaviour of a bug, at least :))

Don’t get me wrong, I believe Idris is a great language precisely because of that: they want to be primarily a research language, but provide a solid base for research happening on top of their core. They have a small team and use those resources well for one aspect of the language usage. I would highly recommend having a look at it and working with it, this is just something to be aware of.

Haskell is great because it’s where a lot of these ideas were tested and figured out. But it also has the cruft of legacy mistakes. Haskell can’t get rid of them now, but other languages can certainly learn from them.

Example 2 will not compile with the options -Xlint -Xfatal-warnings, which I recommend everyone use. We have a quite large codebase, and it hasn’t been arduous to keep these settings on. Failed exhaustiveness checks are sadly only usually a warning, so I highly recommend people keep this setting turned on.

Both wartremover [https://github.com/wartremover/wartremover] and scapegoat [https://github.com/sksamuel/scapegoat] can prevent example 1, by preventing Serializable (or Product or AnyRef) from being inferred. I understand that “use a third-party linter” isn’t the answer a lot of people want, but it’s quite easy to set up and integrate into an SBT workflow.

As far as the other problems, they are all syntax-related, and I grant Scala has some annoying ambiguities there.

So this is where I get confused. What the license seems to be saying is that if I engage Facebook in litigation over some kind of patent of theirs, the license that they are granting me (to use the software freely, etc.) is revoked. If that happens, then what? Would it then be technically illegal to use React? If so, under what law – copyright law? Is this really enforceable?

What I’m really getting at is, is RMS being a hard-ass and this is actually pretty typical, or is Facebook being sly and hiding restrictions in their software that don’t need to be there?

Yes, the license is enforced under copyright law. It’s the same mechanism the GNU license uses to enforce its restriction that you must distribute source code with your binary. If you don’t fulfill the requirements of the license, then you don’t have a license to use the code any more.

What the “first generation” of open source licenses doesn’t deal with is patent rights. Which means you can end up with a license to copy the code but not a license to use the code. Various attempts have been made to address that, including this FB language.

Whether and how all this enforceable is the eternal question of all open source licenses, and indeed all licenses. :)

No. The patent grant is an additional grant of rights to React users, above and beyond the BSD license. The patent grant may be revoked if you sue (or countersue) Facebook, but the original BSD license cannot be revoked.

IANAL, but consider if FB hadn’t created and distributed the patent grant file. My guess is we would probably be worse off. But creating it draws attention to something normally invisible, because I don’t think any software license automatically protects you from patent litigation.

Also not a lawyer, but Apache 2.0 explicitly mentions patents. As I understand it, it says that you have an automatic grant to all relevant patents owned by all contributors, but if you claim one of your patents is infringed by people using the software, you lose your licence to the software.

Compare to the React licence, which says you lose your licence to the software if you sue Facebook over any patent at all, regardless of whether it’s related to React or not.

The Apache 2.0 licence is a well-regarded Free Software licence, but the React licence, it seems, is not.

This is incorrect. If you sue Facebook over any patent at all, it does not terminate your software license. It does terminate the additional patent grant. So the patent grant plus the BSD license gives you strictly more legal protection than the BSD license alone does. The Apache 2.0 license also revokes the patent grant, but not the entire license, if you initiate patent litigation against the copyright holder.

Apache 2.0 covers you, but the point still stands for other libraries licensed under licenses such as BSD. I’d presume GPL(v2) also protects you against patents, but this is just an assumption. It would be nice to get confirmation for this from a source that is at least somewhat official (regarding US jurisdiction).

A singleton holds a global static variable. The fact that it’s usually (entirely) private is its only slight slaving grace. Making it a little more public introduces issues of thread-safety and referential transparency that didn’t exist before, and wouldn’t exist at all using a saner pattern.

The cost of adding a networked computer to something is now low and getting lower, but the cost of making the software the runs on it secure or reliable has stayed high. With engineer salaries having grown like they have, it may actually be getting more expensive. In the long term, businesses are going to wake up to liability and customer satisfaction concerns and stop selling insecure, unreliable “internet of things” devices. But I think we’re in for a few years of zero-days on refrigerators, big invasions of privacy, and maybe some injuries and deaths before this happens.

Another reason for that shift is that ISPs have started realizing it might be valuable in its own right to own & control a distributed network of access points. For example all newer Comcast routers are dual-SSID routers. One of the SSIDs is configurable by the customer as their usual home wifi network, and the other one is locked to SSID ‘xfinity’, serving as part of Comcast’s national wifi network.

I’d like to see entertainment systems standardized and shared between car manufacturers. Why can’t I just get a double/triple/quad din entertainment drop in replacement at my local electronics shop and have it control exactly the same things the previous one did?

In my 1999 car I replaced the single din tape player with a 3rd party one, but had to give up volume buttons. It was worth it.
In my 2003 car I replaced the double din stereo with a 3rd party one, but kept all functionality by getting Pioneer -> ISO -> ISO -> Holden.

Newer cars than that seem to have an all in one “iDrive” style system that controls entertainment and gps (Which is fine) but also air conditioning, electric seats, car internetting, performance mode/suspension, lap timing. I can do without some of those things, but not being able to control the air conditioning at a minimum is an absolute deal breaker. If you can live with the lose of the other things it is still going to cripple your resale value. Why do they have to tie everything in together? My friend has a Z4M. The stereo isn’t great, but there is no way he is going to throw out this sort of functionality for a better one.

I just want them to either use standards so a replacement 3rd party unit doesn’t downgrade functionality (I know car companies aren’t going to do this) or at least split up system so that I could just replace the “entertainment system” (Which would basically be the screen + stereo tuner) and the air conditioning could still be controlled through it because the “entertainment system” and the air conditioner talk to each other over a standard interface (USB/ethernet/wifi with a standard open source “car communications” protocol).

Part of the problems with replacements (in the UK at least) is that they’re easy to steal. One of the large drops in the UK crime rate is because car stereos are now integrated and difficult / impossible to casually take.

A nice(?) side effect is that when considering which car to buy next, you’re more likely to go to the same manufacturer so you don’t have to re-learn a new system for changing radio stations.

I always imagined it was because an average $100 3rd party stereo is fine for most people and will only resale for say $30, so it is only worth stealing a $1000+ 3rd party stereo. If you are stealing an original stereo it is only worth stealing it if is actually good, is usable in your car and you have/can crack the code that locks it to the car/ecu.

Depending on how you look at it, a problem on top of this is that technologies keep on removing the ability to control which version of software they run. On my Android phone, if it decides to upgrade a piece of software and I say yes, I cannot downgrade it even if there is a huge security hole in it. I expect to see IoT being even worse about this.

One of the reasons I loved OS X so much was because it had a user friendly interface that was pretty good but I could dive below it and be a power user. The mobile platforms are not catering to this at all. The counter argument is that it is better because a centralized authority is making sure everyone is up to date. IMO, there is no reason to believe that is true.

There are costs with either approach, but for a given problem which is preferable is dependent on all sorts of contingencies. The difficulty of the problem, the existence and usability of a package manager, the expressiveness of the language you’re using, quality of the dependency, and the possibility of forking/maintaining a third-party dependency all should factor into a wise developer’s decision.

Here, I see a lot of complaints about the drawbacks of third-party dependencies (along with a lot of loaded, meaningless language like “trash can full of toxic waste”) but not a very smart breakdown of how frequently these drawbacks occur or how to evaluate or mitigate them.

Further, as another commenter points out, the author takes a very narrow view of what’s a dependency. People claim they have zero- or low-dependency software, but in the big picture it’s hard to characterize a 10kloc program that depends on millions of locs of kernel, compiler, language runtime, standard libraries, and hardware drivers in such a manner.

Broadly, I absolutely agree that any solution to the question is very contingent.

The author’s anecdotes in many ways actually show to me how the challenge of finding the best solution to a simple problem that occurs along the way can distract from finding a workable to the messier tasks that usually are the official job. And, ironically, solving the problem of redundancy vs dependency itself is often in this category of “more interesting than the assigned task”.

The thing is that I think experienced programmers deal with the distraction (that comes from problem like this) through folk-wisdom rules of thumb, rules that don’t need to be at all optimal but which, by getting past and bottling up the small and seductively interesting problems, let one accomplish one’s immediate task.

But ironically, this same “folk effect” tends to make these questions seem uninteresting to consider more deeply beyond the solutions of offered by the obsessed. And think that’s a shame because this kind of problem might open some unexpected doors if examined closely.