Time to replace my four year old mobile printer, here’s my take on the HP Officejet 150
Read more at Enterprise Open Source Toolkit
Pocket’s Prototype for Android Wear Saves Articles Right from your Wrist
Googled unveiled Android Wear this week and encouraged developers to build apps purpose-built for the wrist. Pocket is among the first companies to rise to the challenge, showing off a prototype version of a software development kit for Android Wear today that will let you save links directly from your watch. The prototype allows developers to integrate Pocket into their own apps so that users can save items with a couple of taps. “Up until now, smartwatches have focused solely on delivering short notifications,” Pocket says. “What’s been missing is the ability to quickly act on that information by saving or sharing it.”
Pocket’s SDK works by allowing you to turn those notifications into saved articles and videos. When an alert on…
Read more at The Verge
How to Manage Btrfs Storage Pools, Subvolumes And Snapshots on Linux (part 1)
Before we dive into using Btrfs, how is it pronounced? Lots of ways, like Bee Tree Eff Ess and Bee Tee Arr Eff Ess. That’s too many syllables, so I favor Butter Eff Ess. It sounds nice, and everyone likes butter. In this two-part series we’ll build a three-node Btrfs storage pool and learn all about managing snapshots, rollbacks, and subvolumes. Part 1 covers installing Btrfs, creating a simple test lab, creating a storage volume, and what commands to use to see what’s in it. In Part 2 we’ll create and manage subvolumes, snapshots and rollbacks.
What’s the Big Deal about Btrfs?
Btrfs is the next-generation Linux filesystem all cram-full of advanced features designed for maximum data protection and massive scalability such as copy-on-write, storage pools, checksums, support for 16, count ’em, 16-exabyte filesystems, journaling, online grow and shrink, and space-efficient live snapshots. If you’re accustomed to using LVM and RAID to manage your data storage, Btrfs can replace these.
A snapshot is a copy of a Btrfs subvolume at a particular point in time. It’s many times faster than making a traditional backup, and incurs no downtime. You can make snapshots of a filesystem whenever you want, and then quickly roll back to any of them.
Prerequisites
To use Btrfs you need a recent version of Debian, Arch Linux, Ubuntu, OpenSUSE, SUSE Enterprise Linux, Red Hat Enterprise Linux, or Fedora Linux, and an extra empty hard disk to play with, or ~50GB of free space on a hard disk. Btrfs is already supported in the kernels of these distros (run cat /proc/filesystems to check), so you only need to install the user-space tools btrfs-progs, which is btrfs-tools on Debian/Ubuntu/Mint/etc.
You’ll see a lot of warnings in the Btrfs documentation, and even in the output of some commands, that it is not ready for production systems and to not trust it for anything important. However, the good people at SUSE Enterprise Linux claim the opposite, and have supported it for production systems since SLES 11 SP2. I use it on my OpenSUSE and Ubuntu systems without drama. But, as they say, your mileage may vary and you should do your own testing. Meanwhile, it’s free to test and learn, so let’s get cracking.
Creating a Btrfs Storage Pool
First create three partitions of equal size to create a simple testing environment. GParted is a great graphical app to do this, and it partitions and creates the filesystem at the same time (figure 1). The Btrfs documentation recommends a mininum partition size of one gigabyte. In the examples for this tutorial they are 12 gigabytes each. I’m using a blank 150GB SATA hard disk for this article (/dev/sdd) because it makes me feel a little safer using a separate hard drive for filesystem testing. You can use any hard disk on your PC that has enough free space to play with, and 50GB gives you plenty of room to do mad Btrfs experiments. Do be careful to not destroy stuff you want to keep, like your root filesystem and data.
Now that we have three Btrfs partitions to play with, we will combine them into a Btrfs storage pool with the mkfs.btrfscommand:
# mkfs.btrfs -f -L testbtrfs /dev/sdd1 /dev/sdd2 /dev/sdd3 WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using adding device /dev/sdd2 id 2 adding device /dev/sdd3 id 3 fs created label testbtrfs on /dev/sdd1 nodesize 4096 leafsize 4096 sectorsize 4096 size 35.16GB Btrfs v0.20-rc1
The -f option forces an overwrite of any existing filesystems. -L creates a filesystem label, which is any name you want to give it. With no other options this command creates a three-node RAID array, using RAID0 for data and RAID1 for metadata. The RAID in Btrfs has some differences from the old-fashioned RAID we’re used to. In Btrfs RAID0 stripes your data across all available devices with no redundancy. RAID1 mirrors your data in pairs, round-robin across all available devices, so there are always two copies of your metadata regardless of how many devices are in the storage pool.
Seeing Your Partitions and UUIDs
You can use the familiar old blkid command to see your new Btrfs filesystems (the UUIDs are abbreviated in this example):
# blkid /dev/sdd* /dev/sdd: UUID="e9b11649" UUID_SUB="af7ce22c" TYPE="btrfs" /dev/sdd1: LABEL="testbtrfs" UUID="b6a05243" UUID_SUB="4770cbfb" TYPE="btrfs" /dev/sdd2: LABEL="testbtrfs" UUID="b6a05243" UUID_SUB="b4524e3d" TYPE="btrfs" /dev/sdd3: LABEL="testbtrfs" UUID="b6a05243" UUID_SUB="7e279107" TYPE="btrfs"
Mounting the Btrfs Storage Volume
Notice that the UUIDs on the three partitions in our storage volume are the same, but the UUID_SUBs are unique. If you run the blkid command before creating the storage pool, the UUIDs will also be unique. I like to create a special testing directory– in this example, /btrfs — so I don’t accidently gum up something important. Mounting any single device mounts the whole works, like this:
# mkdir /btrfs # mount /dev/sdd3 /btrfs
You can create an /etc/fstab entry in the same way as for any filesystem. Use your label or the UUID (not the UUID_SUB) like one of these examples:
LABEL=testbtrfs /btrfs btrfs defaults 0 0 UUID=b6a05243 /btrfs btrfs defaults 0 0
What are my RAID Levels?
You can check your RAID levels with the btrfs command:
# btrfs filesystem df /btrfs Data, RAID0: total=3.00GB, used=0.00 Data: total=8.00MB, used=0.00 System, RAID1: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=1.00GB, used=24.00KB Metadata: total=8.00MB, used=0.00
Measuring Available Space
You can’t use our good ole du and df commands to measure used and free space on the mounted Btrfs filesystem, because they don’t understand Btrfs metadata, RAID, and how it manages storage. Measuring available space on a Btrfs volume is tricky because of these factors. I copied 7GB of files into my little test volume, and this is what it looks like with thebtrfs command:
# btrfs filesystem df btrfs/ Data, RAID0: total=9.00GB, used=6.90GB Data: total=8.00MB, used=0.00 System, RAID1: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=1.00GB, used=46.01MB Metadata: total=8.00MB, used=0.00
You could also try it on any raw device in the storage pool:
# btrfs filesystem show /dev/sdd1
failed to open /dev/sr0: No medium found
Label: 'testbtrfs' uuid: b6a05243
Total devices 3 FS bytes used 6.95GB
devid 3 size 11.72GB used 4.01GB path /dev/sdd3
devid 2 size 11.72GB used 3.01GB path /dev/sdd2
devid 1 size 11.72GB used 4.02GB path /dev/sdd1
Allrighty then, we have a nice Btrfs storage pool to play with, and know how to poke around in it. Come back for part 2 to learn how to create, remove, and manage snapshots and subvolumes.
Android-x86 Just Might Make a Good Linux Desktop Alternative
Read more at LinuxInsider
Neela Jacques: Why Collaborative Development is Right for Software-Defined Networking
There are a number of open source software business models that companies employ today. These approaches fall along a spectrum of openness, from companies building their products and services utilizing fully open, raw code to a mostly closed model in which they offer access to their products via a limited API, says OpenDaylight Executive Director Neela Jacques. In between lies what he calls “Open Plus,” or proprietary software built on open source and/or open standards.
“I believe this is where the sweet spot lies,” Jacques wrote recently in his OpenDaylight blog. “In many cases end users here can experience the best of both worlds – the performance from a highly tuned, controlled piece of software, but the ability to migrate to another member of the ecosystem if technical requirements change.”
Vendors are already taking this approach with the OpenDaylight project, and many other open source projects that follow the collaborative development model. Jacques and other collaborative project leaders will go into more detail about this approach in a keynote panel, moderated by Linux Foundation Executive Director Jim Zemlin, next week at Collaboration Summit in Napa, Calif. Here he talks more about collaborative development, its challenges and successes, and its role in revolutionizing software-defined networking.
Linux.com: Is collaborative development the new model for open source success (as Peter Levine recently suggested), why or why not?
Neela Jacques: I see running open source a little bit like air traffic control in the way that it benefits end users (passengers). To do this well you need solid infrastructure and governance – common systems, agreed upon paths, a standard way for planes to communicate, signs for taxiing etc. On the other hand, you want competition for what comes around it – companies utilizing the common infrastructure and governance to innovate on top – (planes), service providers (airlines) and other services (food service, shops etc.).
I do believe we are seeing a major evolution in how software is being developed. It used to be you had two opposing models: Closed Proprietary vs. Fully Open. Today what we’re seeing is something I call open-plus, where players large and small work together to define standards, develop industry wide APIs and protocols, and to create platforms everyone can plug into. In this model you overcome the challenges with each model and get the best of both. You don’t get the waste of everyone constantly reinventing the wheel with undifferentiating technologies just like you don’t want a country with eight separate incompatible phone systems. In fact this frees up resources for people to invest in making solutions that have better UX, that better solve end-user problems. It’s not surprising that so much of the technology that has changed our lives incorporates open source code at its core.
Can you describe the biggest challenge you’ve faced so far and how you overcame it?
Jacques: In general mine has been to bring the skeptics on board. Many correctly identify all the challenges to collaboration in our industry. I find myself often having to invite folks into the community to see for themselves that it’s a meritocracy.
From a technical perspective the biggest challenge has been to determine support for a wide variety of ideas and technologies. OpenDaylight prides itself as being the place where people come to debate their ideas of how networking should be done, but to debate with code. The Service Abstraction Layer (SAL) is the solution we’ve found to enable a multitude of southbound devices and protocols.
Why is an open source, collaborative development model right for software defined networking?
Jacques: The key difference between SDN and traditional networking is that you are centralizing network intelligence at least to some degree, primarily to get greater programmability and agility in your network. Having multiple controllers makes as much sense as having multiple disparate civil air traffic controllers in the same city. SDN begs for a platform into which all network services can plug into and that can talk to the set of hardware devices to its south. One option is to anoint one player to own that platform and let them control the market and the bulk of profits for the next twenty years. The challenge is if that’s the model everyone will spend money trying to be that one dominant player, and therefore we’ll see endless turf wars. Open, collaborative development makes perfect sense for SDN because controllers are the wrong battleground. They all do roughly the same function. The value is in the apps, in the network services, in the orchestration and in the hardware/chipsets. Basically anywhere but the controller.
What other industries or market niches are ripe for collaborative development and why?
Jacques: I think PaaS and orchestration as two areas really needing strong community collaboration. I was very excited to hear Pivotal announce it was creating a foundation for Cloud Foundry. The way that apps are written needs to change, and while AWS has many advantages it still doesn’t provide all the elements of a true PaaS. The Cloud Foundry community has the potential to become Borland, Eclipse, WebSphere and AWS all wrapped into one – a one-stop shop for app developers – but it’s hard for me to see any one company providing all the resources and leadership needed to be able to achieve that.
When I was at VMware I used three words to describe the approach you need to take to get to a software-defined data center. For each type of resource (compute, storage and networking) you need to “abstract, pool, and automate.” The industry has been making great progress on abstract and pool, but we’re still in the early days of “automate.” I would love to see industry collaboration around developing an industry standard orchestration and automation engine. OpenStack Heat is a good start, but I think the potential in the space is huge. I see OpenDaylight plugging right into OpenStack Neutron which will enable a much richer set of networking functions and tasks to be automated.