posted 3 months ago on OSNews
iOS developer house Pixite decided to give full access to the entire company to Casey Newton. This past December, Kaneko emailed me out of the blue. He didn't know it then, but I'm a fan of the company's apps: Fragment, which applies prismatic effects to photos, is one of my favorite artistic tools. "As an independent bootstrapped app company, we are struggling," Kaneko wrote. "If things don't turn around, we'll need to lay off half of our staff in the next few months." He invited me to come to San Diego and observe the struggle up close. Kaneko would open up Pixite's books and share every piece of data that I requested while, over the course of two days, his team locked itself in a room and attempted to chart a path forward. Pixite would either figure it out or die. For years now, I've been skeptical here on OSNews about the sustainability of the application store model. After the initial gold rush, Apple (or Google, for that matter) clearly had absolutely no clue what to do with the application store model to keep it sustainable after the gold rush ran out. Even today, after the languishing application store model utterly gutted the independent developer field and has caused tremendous harm to small developers, the two mobile heavyweights still seem utterly oblivious as to what to do going forward. And now that both Apple and Google are trying to scale their mobile operating systems up from Facebook and Candy Crush to actual, serious work, everyone is finally starting to realise what a small number of skeptics warned about so many years ago: there's no more money, incentive, or trust in the application store model for developers to create the kind of applications a scaled-up iOS and Android running on laptops or laptop-like devices would need. This year is going to be incredibly fascinating. I have no doubt that Apple and Google will be able to scale iOS and Android up for work. The real question, though, is if they'll be able to convince weary developers to invest in the application store model again. I think it's too late. Either there's going to be deep, sweeping changes to how we distribute and sell applications on these platforms, or they will be forever confined to consumption.

Read More...
posted 3 months ago on OSNews
What follows is an unordered list of things I'd like to see from Apple over the next few years, starting with the easy & obvious things upfront. Most of these have Radars filed against them, but since they're more often than not dupes of existing Radars I won't post the numbers here. Most of this is about iOS, but not all - I'll say upfront that I don't think OS X has a future with the way it's going currently, and has been running on fumes for most of iOS' lifetime. A great wishlist by Steven Troughton-Smith. Mind you, Steven is someone firmly in the camp that sees iOS as the only way forward for Apple - suffice it to say, I have my reservations about that - so it should be no surprise that many things on this list are focused on making iOS more powerful and versatile.

Read More...
posted 3 months ago on OSNews
With version 16.02, the Genode OS Framework moves beyond x86 and ARM CPUs and embraces the emerging open-source RISC-V hardware architecture. Furthermore, the release comes with the new ability to securely assign USB devices to virtual machines, and updates the Muen separation kernel and the seL4 microkernel. Today's x86 and ARM-based commodity platforms have become increasingly opaque and infested with proprietary firmware. With new platforms becoming ever more complex and being equipped with mandatory companion processors like Intel's Management Engine, the trustworthiness of mainstream hardware becomes more and more uncertain. If those parts of the system become compromised, even a perfectly secure OS cannot protect the user's privacy and security. It goes without saying that this development is a strong concern of privacy advocates. The article Intel x86 considered harmful by Joanna Rutkowska substantiates those concerns extremely well. RISC-V is a possible answer to the call for trustworthy hardware. In contrast to the CPUs of current-generation hardware, RISC-V is an open-source CPU architecture. The idea of open-source CPUs is not new. There exist numerous softcore CPUs like LatticeMico32 or OpenRISC. But in contrast to those projects, which are primarily targeted at FPGA platforms, RISC-V is designed to scale from deeply embedded systems to 64-bit general-purpose platforms. The prospect of a scalable and trustworthy hardware architecture motivated the Genode project to take a closer look. In the just-released version 16.02, RISC-V has been added as a supported architecture to Genode's custom base-hw kernel. Since the hardware is still in flux, the scope of the support is still somewhat limited. But Genode is already able to run on the official Spike simulator as well as on RISC-V as a synthesized FPGA softcore. Besides the added RISC-V support, the second highlight of the current release is the new ability to securely assign USB devices to VirtualBox instances running on top of the NOVA kernel. With this feature, Genode becomes able to accommodate many typical desktop-OS work flows like transferring data via USB sticks, or obtaining pictures from a digital camera. Under the hood, the implementation is quite interesting as it successfully transplants the xHCI device model of Qemu to VirtualBox. The third focus of version 16.02 is the update of the Muen and seL4 kernels. The Muen separation kernel has been updated to version 0.7, which greatly improves the interoperability with Genode's tooling. In fact, Muen can now be targeted with the same work flows as employed for all the other kernels. Genode's support for the seL4 kernel is still a rather experimental line of work. In this respect, the update to the kernel version 2.1 posed a number of interesting challenges with respect to the kernel-resource management. This discussion along with details about the many more improvements of the current release is covered in the official release documentation.

Read More...
posted 3 months ago on OSNews
Ubuntu's announcement about inclusion of ZFS support in upcoming 16.04 LTS started an important discussion in opensource community: the license incompatibility between GPL and CDDL licenses may be an issue. Being a copyleft license, GPL requires that all works that are derived from GPL-licensed work are also distributed under terms of GPL. CDDL, the license of ZFS code, is also a copyleft license, and as such requires CDDL-licensed work be distributed "only under the terms of [CDDL]." Although Ubuntu's ZFS code comes from OpenZFS project, Oracle is still one of the major copyright holders of the code base, and it does not seem likely to relicense its assets under GPL any time soon. Dustin Kirkland of Ubuntu, the author of the announcement, explained Canonical's position, albeit light on details: The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module -- the kernel itself is quite obviously not a derivative work of this new file system. And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules. Software Freedom Conservancy (SFC), a non-profit with self-assigned mission of carrying on a crusade against GPL violations, quickly pointed out that the "obvious" conclusions of Canonical are not really all that obvious: [I]f ZFS were statically linked with Linux and shipped as a single work, few would argue it was not a "work based on the Program" under GPLv2. And, if we believe there is no legal difference when we change that linking from static to dynamic, we conclude easily that binary distribution of ZFS plus Linux - even with ZFS in a .ko file - constitutes distribution of a combined work. Another non-profit organization - Software Freedom Law Center (SFLC) - provides yet another opinion on the matter. Eben Moglen points out that CDDL permits distribution of binaries under other licenses, so in case of Linux module GPL's requirements in case of binary module may be fullfilled by distributing it under GPL. Admittedly, this does not solve the issue of the license incompatibility of the code bases. The proposed solution is basically to ignore the wording of GPL's viral clause: In this specific sense, then, the conduct which falls outside the words of GPLv2 falls within the "equity of the license," or its "spirit." As all Western legal systems have known since Aristotle, literal interpretation of any legal material will sometimes produce unintended unjust results, which can and should be corrected by the invocation of "equity." This present issue is evidently an example in which the tension between literal and equitable interpretation is raised, and it is the consensus of the kernel copyright holders' intention which determines which mode of interpretation is to be employed. The issue of GPL compatibility and kernel modules' licensing arised before. For example, Linus Torvalds already noted that kernel modules are in "gray area" when it comes to the issue of derived worked. Using an example of Andrew filesystem he stated that external code base that was designed on different system and only required minimal porting effort due to interface similarities, in his opinion, was not a derived work of Linux. Even more appropriate example is Nvidia's infamous proprietary Linux driver, which interfaces the kernel via specially-crafted module that abstracts away Linux kernel implementation details, so that Nvidia's binary blob may still considered to be a self-contained work targetting module's interface, not the interfaces of Linux. This driver is widely used and generally tolerated by distributions. The differences in these two positions reveal the two conflicting opinions on Linux copyright situation. SFLC is more concerned about the ability of opensource ecosystem to survive in face of fanatic GPL enforcement: their statements goes into painful details about difficulties that projects with permissive licenses are facing when they need to maintain the ports of their code in GPLed projects. If stictly enforced, GPL could hinder such projects to the point when whole ecosystem comes to net loss. Such situation could be particularly painful in cases like this, when the goals of GPL are met, but the legal mechanism that was chosen by opensource Foundation prevents both Linux and OpenZFS from cross-polination. But on the other hand, making such excuses would open gates for projects that don't really contribute to the opensource, but only use it to their own benefit. While proponents of permissive licenses (myself included) don't find anything wrong with such outcome, GPL was specifically designed to prevent it, and that is why it is one of the most popular opensource licenses out there. Obviously, every concession weakens the position of those seeking GPL enforcement, including SFC, whose mission right now is endangered by both SFLC's and Canonical's views on ZFS integration into Linux. Being a self-styled GPL crusader with several battles already fought, SFC knows that the ZFS inclusion in Ubuntu may come at a price of legal actions lost, and potentially tolanted hackers driven out of opensource by frustration and disappointment. There is another interesting angle to this situation: by now it is common knowledge that Sun Microsystems specifically designed CDDL to be incompatible with GPL, so that ZFS, while being opensource, could not be included with Linux. Shipping ZFS with Ubuntu would defeat this tactics and potentially remove motivation for such unfortunate choice of license for companies like Sun or Oracle, to benefit of all involved sides. And yet another thing to consider: some (most?) jurisdictions explicitly require sticking with literal meanings of laws and contracts. This means that even if SFLC's position is defendable in United States, it might be dismissed in other parts of the world, giving Linux copyright holders ability to sue Canonical over copyright infringement. Given that Oracle holds copyright in both Linux and OpenZFS, and that it already demonstrated willingness to take legal actions against opensource projects, Canonical might still be under significant risk. At any rate, the outcome of this discussion, if any, have potential to settle a long-standing issue in opensource community, and to make legal implications of using GPL more transparent and clear.

Read More...
posted 3 months ago on OSNews
HoloLens is fully untethered and self-contained. It's the only device that enables holographic computing natively with no markers, no external cameras, no wires, no phone required, and no connection to a PC needed. And it's a Windows 10 device - the interface is familiar, and connected by the power of a unified ecosystem of Windows devices. The device consists of multiple environment understanding sensors and it's powered by a custom-built Microsoft Holographic Processing Unit (HPU) and an Intel 32-bit architecture. The HPU is custom silicon that allows HoloLens to understand gestures and gaze while mapping the world all around you, all in real time. Microsoft today announced that the Microsoft HoloLens Development Edition will start shipping on 30 March, at $3000 a piece. They also offer a look at the hardware powering HoloLens.

Read More...
posted 3 months ago on OSNews
The Raspberry Pi is turning four today, and in celebration of this, they've now released the Raspberry Pi 3 - which packs a serious performance punch, at the same low price point. In celebration of our fourth birthday, we thought it would be fun to release something new. Accordingly, Raspberry Pi 3 is now on sale for $35 (the same price as the existing Raspberry Pi 2), featuring: A 1.2GHz 64-bit quad-core ARM Cortex-A53 CPU (~10x the performance of Raspberry Pi 1) Integrated 802.11n wireless LAN and Bluetooth 4.1 Complete compatibility with Raspberry Pi 1 and 2 All the previous Raspberry Pi boards will remain available, as long as the demand for them remains. In addition, over the course of the coming months, the userland of Raspbian will be moved to 64 bit.

Read More...