Novell has been acquired by The Attachmate Group (http://attachmategroup.com/) and is now privately owned and the original Novell businesses now form most of what The Attachmate Group is.
TAG is now operating four businesses: Attachmate - their original business, NetIQ - the systems/network/identity/compliance/security-management company, where the Novell Managewise, Zenworks, identity manager, platespin, orchestrator, etc, etc, products are a significant part of the portfolio, then Novell - with the "true" Novell products like NetWare and GroupWise, and finally SUSE, with the Linux products.
And TAG is doing rather well overall.
Regarding the IP, you could've seen in the news that this was abould the old Novell patent warchest. Patents that Novell owned for defense purposes, sort of an atomic stockpile for mutual assured destruction. They've been purchased by a consortium created by Microsoft, Apple, Oracle and EMC and safely stored in an equivalent of a nuclear waste storage facility until their danger to the members of the consortium expires.
And nothing of value to Novell was lost - TAG retained the IP relevant to Novell's, NetIQ's and SUSE's present products. You may argue that with a reduction of the number of warheads TAG is more vulnerable. Novell/SUSE/TAG are still a (contributing) member of the OIN and thus believes it doesn't need to own such a huge stockpile itself.
However, the more important question (also answered in the article and the video) is:
Why do people eat more than they need? Why, when the human body can detect when it has enough nutrients and signal satiety to the brain?
The answer being: Because we've developed foods (by using high fructose amounts in them, through sugar) that block those signal paths. We've perfected foods that we want to crave and that don't make us feel we've had enough, so that we can consume more.
Yes, one possible answer to the caloric equation is: Have a strong will, be hungry and you'll be lean. The other is: Eat right, and you'll feel satiated after eating exactly the amount that's needed for your health.
And, btw, the equation assumes that all you eat and is digestible gets digested. That obviously isn't true, when overeating a lot of the food just goes through without the nutrients getting extracted. If that wasn't the case, many people would weigh thousands of pounds today.
Inside the IBIS there is two full SATA drive boards, with SandForce SATA controllers, connected to a standard PCIe/SATA RAID controller on the base board.
The only difference to a SATA RAID controller and two regular SSDs is that the cable is in a different place.
It just means the clone will have to be a bit more expensive.
Cloned tags aren't using the same cheap chips that the common passive tags do. An attacker can afford to carry batteries with him and make the tag completely locally powered. Then he has much more powerful electronics at his disposal and can simulate whatever frequency response the original tag had due to its cheap (few cents per tag) design.
This fingerprinting will do no more than to force the attacker to pay a few bucks more to create a clone.
The article assumes that when within a RAID5 array a drive encounters a single sector failure (the most common failure scenario), an entire disk has to go offline, be replaced and rebuilt.
That is utter nonsense, of course. All that's needed is to rebuild a single affected stripe of the array to a spare disk. (You do have spares in your RAID setups, right?)
As soon as the single stripe is rebuilt, the whole array is again in a fully redundant state again - although the redundancy is spread across the drive with a bad sector and the spare.
Even better, modern drives have internal sector remapping tables and when a bad sector occurs, all the array has to do is to read the other disks, calculate the sector, and WRITE it back to the FAILED drive.
The drive will remap the sector, replace it with a good one, and tada, we have a well working array again. In fact, this is exactly what Linux's MD RAID5 driver does, so it's not just a theory.
Catastrophic whole-drive failures (head crash, etc) do happen, too. And there the article would have a point - you need to rebuild the whole array. But then - these are by a couple orders of magnitude less frequent than simple data errors. So no reason to worry again.