Labels

Monday, February 23, 2015

Linus Torvalds email on Linux 4

https://lkml.org/lkml/2015/2/22/203\

Date
SubjectLinux 4.0-rc1 out..
From

.. let's see how much, if anything, breaks due to the version number.
Probably less than during the 3.0 timeframe, but I can just imagine
somebody checking for meaningful versions.

Because the people have spoken, and while most of it was complete
gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall
be. Unless somebody can come up with a good argument against it.

So far, the arguments against it seem to have been "major numebr
should go with a major new feature or breaking of compatibility",
which just shows how little people know. We don't break compatibility,
and we haven't done feature-based releases since basically forever.

On the other hand, the strongest argument for some people advocating
4.0 seems to have been a wish to see 4.1.15 - because "that was the
version of Linux skynet used for the T-800 terminator".

So on the whole, I wouldn't read too much into the number.

On an actual technical side, this was a *fairly* small release. By
modern standards, that is. It's certainly noticeably smaller than some
recent kernels have been, although we're talking ~9k non-merge commits
rather than 10-11k, so it's not like it's that huge of a difference.

The live patching infrastructure made some news, but my personal
favorite features are actually some vm cleanups, where this release is
getting rid of the largely unused non-linear remapping code (replaced
with just emulating it with lots of smaller mappings) and unifies the
NUMA and PROTNONE handling for page tables.

But nobody should notice. Because moving to 4.0 does *not* mean that
we somehow changed what people see. It's all just more of the same,
just with smaller numbers so that I can do releases without having to
take off my socks again.

Go test it out. The git trees are already out, the tar-ball and
patches are going out as I write this.  Of course, with the version
change, I suspect that there will be *some* hiccup with kernel.org
mirroring, even if Konstantin thinks that the scripts are all ready to
go.. So if you don't find tar-balls and patches, either I screwed up,
or Konstantin did ;)

                              Linus

Linux 4.0-RC1 Tagged, Linux 4.0 Will Bring Many Notable Improvements by Michael Larabel

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.0-rc1-Kernel-Released



Linus Torvalds has decided to go ahead and rename the Linux 3.20 kernel to Linux 4.0 per his polling last week. Torvalds released Linux 4.0-rc1 on Sunday night and this release comes with many significant updates. 

Linus tagged the Linux 4.0-rc1 kernel just moments ago in Git and codenamed this release the "Hurr durr I'ma sheep." He wrote in the commit message
.. after extensive statistical analysis of my G+ polling, I've come to the inescapable conclusion that internet polls are bad.

Big surprise.

But "Hurr durr I'ma sheep" trounced "I like online polls" by a 62-to-38% margin, in a poll that people weren't even supposed to participate in. Who can argue with solid numbers like that? 5,796 votes from people who can't even follow the most basic directions?

In contrast, "v4.0" beat out "v3.20" by a slimmer margin of 56-to-44%, but with a total of 29,110 votes right now.

Now, arguably, that vote spread is only about 3,200 votes, which is less than the almost six thousand votes that the "please ignore" poll got, so it could be considered noise.

But hey, I asked, so I'll honor the votes.
Linux 4.0 is happening! 

As of writing this article no Linux 4.0-rc1 release announcement has been issued, but in my close monitoring of the code and mailing lists of the past two weeks, here's the changes for the Linux 4.0 kernel exciting me the most: 

DRM / Graphics Drivers: 

- The AMD Radeon driver finally has DisplayPort audio support

- The Radeon driver also has better fan control support and other improvements

- The AMDKFD HSA kernel driver has basic work towards Carrizo/VI APU support

- The Intel DRM driver has many improvements throughout and basic Intel Skylake support should now be working. 

- The Nouveau DRM driver has GK20A re-clocking support and other improvements. 

- Freedreno's MSM driver has Embedded DisplayPort support, YUV support for newer hardware, and various other changes. 

New DRM drivers and other improvements

File-Systems / Disk Drives: 

pNFS block server support and it's currently supported by the XFS file-system. This feature has been a long-time coming for mainline. 

RAID 5/6 improvements for Btrfs

VirtIO 1.0

Fixes to the F2FS file-system

- Handling of multiple read-only layers for the OverlayFS

Processors: 

Intel Quark SoC x86 platform support

Numerous new ARM platforms are now enabled for this next Linux kernel release. 

Various x86 KVM optimizations

A new AMD ACPI driver and Skylake P-State support, among other power management and ACPI improvements. 

Full IBM z13 support

Other Hardware: 

Improved Toshiba laptop support

Bootloader improvements for the Sony PlayStation 3 with Linux

TPM 2.0 support for Trusted Computing. 

Various sound updates

New input drivers

New and improved media drivers

Better Logitech HID++ support

Other: 

Many staging changes along with the demotion of the I2O subsystem. 

Live kernel patching infrastructure work as the joint work between the kGraft and Kpatch initiatives from SUSE and Red Hat, respectively. 

That's hopefully all of it and not missing anything else too exciting... Be sure to share your favorite changes of Linux 4.0 for what you're looking forward to within our forums.

Tuesday, February 3, 2015

"Should developers be forced to build apps for dying operating systems? BlackBerry thinks so" by Paul Sawers




How does BlackBerry plan to rescue its ailing mobile empire? Well, it’s notjust banking on gold smartphones, it seems. It hopes regulation will help save its bacon.
BlackBerry CEO John Chen has revealed some interesting thoughts on themuch debated subject of net neutrality, touching on what the definition of the term should encapsulate. And interestingly, he reckons developers should be forced to produce applications for all mobile operating systems, not just the big players such as Android and iOS.
This has been a perennial problem for both BlackBerry and Windows Phone, with many big-name apps either taking their time to arrive on the scene, or simply never showing up at all. And this is bad news for them, because apps are seen as being key to success, irrespective of whether the hardware is any good.

Net neutrality

Generally speaking, net neutrality has come to define the principle that Internet service providers (ISPs) and the relevant authorities should treat everything equally — a single tier where no website, application, or demographic is given preferential treatment, particularly for financial gain. It’s all about protecting the free and open Internet.
Chen, however, says that net neutrality should be regulated at the “application and content layer.” In a letter sent to a number of high-ranking U.S. Senate figures, which was later adapted for a blog post, Chen says:
Neutrality must be mandated at the application and content layer if we truly want a free, open and non-discriminatory internet. All wireless broadband customers must have the ability to access any lawful applications and content they choose, and applications/content providers must be prohibited from discriminating based on the customer’s mobile operating system.
Chen goes on to cite Netflix, which has been a strong supporter of net neutrality at a carrier level, as one example of where companies fail to treat all operating systems equally. Indeed, the video-streaming service has hitherto failed to launch an app for BlackBerry, though it does have one for Windows Phone.
The CEO accuses Netflix of “discriminating” against BlackBerry customers, and “many other applications providers similarly offer service only to iPhone and Android users.”
“This dynamic has created a two-tiered wireless broadband ecosystem, in which iPhone and Android users are able to access far more content and applications than customers using devices running other operating systems,” says Chen. “These are precisely the sort of discriminatory practices that neutrality advocates have criticized at the carrier level.”
While some may argue that Chen has a point on a very broad level, it’s important not to confuse the issue of net neutrality here. ISPs charging some companies or consumers more than others to deliver faster Web access goes against the very notion of a “free and open Internet.” Actively forcing private companies to build an app for a specific platform simply isn’t practical on any real level, and would not work.

Impractical

Who would these rules apply to? Just big companies with the resources to splash out on a BlackBerry app that will be used by so few people?
Think about it. There are thousands of indie developers out there, working away in their bedrooms to produce what they hope will be at least a minor smash hit on Google Play or Apple’s App Store. Are these individuals really expected to invest time and resources in learning how to build apps for a whole new operating system, one that will see very little in the way of financial return?
Even Android, which holds the lion’s share of mobile market in most countries, has had a tough time getting developers to adopt a “non-iOS first” mindset when building apps. But at no point has any sane person suggested that iOS developers be forced to code for Android. It would be nice if they did, sure, but it shouldn’t be legislated.
Chen even points to its own proprietary BlackBerry Messenger (BBM) service as one example of how BlackBerry has opened its own services to third-party platforms.
“Unfortunately, not all content and applications providers have embraced openness and neutrality,” he says. “Unlike BlackBerry, which allows iPhone users to download and use our BBM service, Apple does not allow BlackBerry or Android users to download Apple’s iMessage messaging service.”
Indeed, BBM finally launched on Android and iOS in 2013, meaning anyone could now message each other across different platforms. But this wasn’t done in the spirit of openness — BBM was one of the few BlackBerry offerings that still had a degree of traction on a consumer level, and this was its way of ensuring BBM didn’t die off.
Why did BBM take so long to land on Android and iOS? And why, after that, did it take so long to arrive on Windows Phone — almost a year later?
Chen also points to BlackBerry making its security-focused BES12 device management software available to iOS and Android. Again, BlackBerry has had to put a renewed focus on its software, making it available on multiple platforms — because its hardware business is no longer the force it once was.
To suggest that BBM or BES12 was launched on Android and iOS for any reason other than self-preservation would be disingenuous at best.

Innovation

BlackBerry basically rested on its laurels and was blindsided by the emergence of Apple and Google in the smartphone realm — it failed to innovate quickly enough and it’s now paying the price. This has happened to many other companies through the foggy ruins of time — companies that failed to adapt and move with the zeitgeist.
That’s not to say BlackBerry won’t recover — it’s returning a small profit again and is now driving forward into different verticals, though largely with security and software in mind.
BlackBerry has already been pushing hard to open up to Android apps, but this doesn’t cover all apps and doesn’t support things like Google Play’s in-app purchase functionality. So developers still have to re-jig things for BlackBerry.
HTML5 is becoming increasingly used on mobile, bypassing the need for native apps altogether, but native apps still rule the roost on smartphones. What Chen is probably hoping for is a common coding language that spans all mobile operating systems — so that developers can easily tweak their handiwork so that apps work like a charm on all devices. However, this is unlikely to happen any time soon.
Chen’s logic makes sense on a broad level. He argues that net neutrality should extend to content in apps, which is currently siloed by operating systems — and why should access to content be restricted by a lack of interoperability?
But if that’s the argument, then Chen’s target shouldn’t be the content and application providers, because they merely work within the limitations of the operating systems. To suggest for a second that there should be an official mandate that stipulates which platforms a developer should build for is crazy and completely unworkable.