It isn't. You can take any older release of that module code that was under an open source license and fork from there. Presumably, the code has changed since then, so you'd just be missing any of the more recent developments.
Yeah, fair enough, except since the core is already under an open source license, any attempt to put it under a closed-source license would quickly result in an open source fork maintained by many of the same contributors. This is one of the strengths of open source in general -- it really is hard to put that kind of cat back in the bag.
You're right that the headline is wrong, but not entirely in the way you assume. The license for Redis itself (the core database, including failover and clustering/distribution, etc.) isn't changing. It's still BSD licensed. What they changed was the license for the extensions they've written (RedisSearch, RedisGraph, RedisJSON, RedisML, and RedisBloom). Now, I personally think that's a mistake (and I suspect they'll end up realizing that at some point), but it also doesn't affect how I use Redis today, nor does it affect how the cloud vendors use it in the services they provide.
Java has had non-blocking IO since 1.4, which was released in 2002.
Java has had NIO for a long time. But, the Java world was pretty mature already by the time those APIs were introduced, and a ton of libraries had already been written that used threads and blocking calls, including some that were included in Android. That momentum just made it easier for Android to adopt the blocking call model for a lot of the new stuff they added. There's a bit more to it than that, if you're interested, going back to the creation of OpenBinder at Be, Inc. (& then at Palm), followed by Google hiring one it's key developers (Dianne Hackborn). Binder is how Android makes blocking calls work across processes without incurring a bunch of overhead (gross oversimplification of Binder; read up on it if you're interested in it, though – distributed objects, RPC with thread migration, etc.).
Sure. Blocking APIs are things like "reading this file and wait until the bytes are actually read before moving on to the next line of code". But, even though reading a file doesn't take long, the kernel still has to do something with your thread while it's waiting on the IO. So, it has to put that thread to sleep and find another thread to run. Now, imagine this was a network IO over a cellular network instead of just reading from a file. Those network IO calls are often blocking-style, too. You definitely don't want to stop the UI thread from responding to inputs or updating the screen while you go do that kind of thing. So, you need to put all your IO on a non-UI thread. That means you have to communicate across threads, which means thread-safe data structures with locks, etc. The code ends up a bit more complicated.
Non-blocking APIs look more like "start reading this file and call this other function when you're done, but return immediately". Your code ends up being structured differently, since everything is an event. Once you're used to it, it's pretty nice. Closures and lambdas make everything really simple, so your code even starts to look more like the linear/blocking style. So, if you do need an HTTP server in your app, it just looks like a few IO event handlers that you set up along with all your UI event handlers. Putting it on your UI thread is a judgment call at that point. You can make sure the HTTP event handlers never take enough time to impact usability, and in return you get to avoid having to deal with inter-thread communication, etc. Or, you can go ahead and create a thread and give it its own event loop to run the exact same non-blocking style code. I've done it both ways, and couldn't tell the difference in the UI (this was on an old iPhone 3GS back in the day).
ARM licenses the instruction set and their implementations of it independently. Apple licenses the instruction set, but their A-series chips are custom implementations of that architecture as far as I know. One of the differences is that the recent A-series chips no longer include support for the 32-bit instruction set –only 64-bit (iOS can't run any 32-bit code any more). This is important because the older 32-bit instruction set had some unpleasant aspects when it came to performance (barrel shifter in the data path, conditional execution bits taking up instruction encoding space, 16 architected registers, etc.; that's just from memory). The 64-bit ARM instruction set is pretty clean (I remember thinking it looked more like MIPS or Alpha when I looked at it briefly), and that helps when you're trying to go fast. Meanwhile, Qualcomm has to continue to support the older 32-bit instruction set (and maybe even the ancient "thumb" stuff) on the same die as the newer 64-bit mode. Intel is in the same boat (only with even more –and even older –baggage).
There's another difference between Apple's processors and the ones on Android phones that goes unnoticed by most. Apple's APIs are all non-blocking / event-driven. Want to run an HTTP server on the same thread as your UI? You can, and it's easy, and it even works pretty well. Android APIs are almost entirely blocking, because of the Java legacy. So, on iOS, you see lots of apps with only a few threads doing most of the work, while on Android, you see dozens of threads, and the work is spread across them. This is why Apple focused early on optimizing single-core performance while Qualcomm was busy adding lots of slower cores to their chips. Both companies were doing the right thing for the platforms they were targeting. But, now that Apple has those highly optimized single cores, and a machine like the big iPad Pro that can dissipate more heat, then can put 4 of those fast cores in there and get some impressive numbers.
Most of the freedoms we enjoy have costs. Often, those costs can be measured in human lives. But, as a society, we've already decided that we're willing to pay that price. The right to bear arms has a cost in human lives that's pretty easy to see and measure. Freedom of speech, the right to choose – all have a cost. In this case, it's the right to privacy, and the cost may be that some criminals aren't convicted. Or worse – that some terrorists are able to plan and execute attacks. This is what real freedom looks like. Enjoy it. But, also acknowledge the cost and honor those who are paying it for us.
Slashdot Mirror
It isn't. You can take any older release of that module code that was under an open source license and fork from there. Presumably, the code has changed since then, so you'd just be missing any of the more recent developments.
Yeah, fair enough, except since the core is already under an open source license, any attempt to put it under a closed-source license would quickly result in an open source fork maintained by many of the same contributors. This is one of the strengths of open source in general -- it really is hard to put that kind of cat back in the bag.
You're right that the headline is wrong, but not entirely in the way you assume. The license for Redis itself (the core database, including failover and clustering/distribution, etc.) isn't changing. It's still BSD licensed. What they changed was the license for the extensions they've written (RedisSearch, RedisGraph, RedisJSON, RedisML, and RedisBloom). Now, I personally think that's a mistake (and I suspect they'll end up realizing that at some point), but it also doesn't affect how I use Redis today, nor does it affect how the cloud vendors use it in the services they provide.
Why is that?
Java has had non-blocking IO since 1.4, which was released in 2002.
Java has had NIO for a long time. But, the Java world was pretty mature already by the time those APIs were introduced, and a ton of libraries had already been written that used threads and blocking calls, including some that were included in Android. That momentum just made it easier for Android to adopt the blocking call model for a lot of the new stuff they added. There's a bit more to it than that, if you're interested, going back to the creation of OpenBinder at Be, Inc. (& then at Palm), followed by Google hiring one it's key developers (Dianne Hackborn). Binder is how Android makes blocking calls work across processes without incurring a bunch of overhead (gross oversimplification of Binder; read up on it if you're interested in it, though – distributed objects, RPC with thread migration, etc.).
Non-blocking APIs look more like "start reading this file and call this other function when you're done, but return immediately". Your code ends up being structured differently, since everything is an event. Once you're used to it, it's pretty nice. Closures and lambdas make everything really simple, so your code even starts to look more like the linear/blocking style. So, if you do need an HTTP server in your app, it just looks like a few IO event handlers that you set up along with all your UI event handlers. Putting it on your UI thread is a judgment call at that point. You can make sure the HTTP event handlers never take enough time to impact usability, and in return you get to avoid having to deal with inter-thread communication, etc. Or, you can go ahead and create a thread and give it its own event loop to run the exact same non-blocking style code. I've done it both ways, and couldn't tell the difference in the UI (this was on an old iPhone 3GS back in the day).
ARM licenses the instruction set and their implementations of it independently. Apple licenses the instruction set, but their A-series chips are custom implementations of that architecture as far as I know. One of the differences is that the recent A-series chips no longer include support for the 32-bit instruction set –only 64-bit (iOS can't run any 32-bit code any more). This is important because the older 32-bit instruction set had some unpleasant aspects when it came to performance (barrel shifter in the data path, conditional execution bits taking up instruction encoding space, 16 architected registers, etc.; that's just from memory). The 64-bit ARM instruction set is pretty clean (I remember thinking it looked more like MIPS or Alpha when I looked at it briefly), and that helps when you're trying to go fast. Meanwhile, Qualcomm has to continue to support the older 32-bit instruction set (and maybe even the ancient "thumb" stuff) on the same die as the newer 64-bit mode. Intel is in the same boat (only with even more –and even older –baggage). There's another difference between Apple's processors and the ones on Android phones that goes unnoticed by most. Apple's APIs are all non-blocking / event-driven. Want to run an HTTP server on the same thread as your UI? You can, and it's easy, and it even works pretty well. Android APIs are almost entirely blocking, because of the Java legacy. So, on iOS, you see lots of apps with only a few threads doing most of the work, while on Android, you see dozens of threads, and the work is spread across them. This is why Apple focused early on optimizing single-core performance while Qualcomm was busy adding lots of slower cores to their chips. Both companies were doing the right thing for the platforms they were targeting. But, now that Apple has those highly optimized single cores, and a machine like the big iPad Pro that can dissipate more heat, then can put 4 of those fast cores in there and get some impressive numbers.
Most of the freedoms we enjoy have costs. Often, those costs can be measured in human lives. But, as a society, we've already decided that we're willing to pay that price. The right to bear arms has a cost in human lives that's pretty easy to see and measure. Freedom of speech, the right to choose – all have a cost. In this case, it's the right to privacy, and the cost may be that some criminals aren't convicted. Or worse – that some terrorists are able to plan and execute attacks. This is what real freedom looks like. Enjoy it. But, also acknowledge the cost and honor those who are paying it for us.
then TAMU, SLS, Slackware, Red Hat, and finally Ubuntu
I'll take a guess and say the next article will be about crap.
I suppose that will be a shitty article.
Now, now -- there's no need to get pissy about it.