Linux 4.14 Has Been Released

https://linux.slashdot.org/story/17/11/12/219238/linux-414-has-been-released?utm_source=feedly1.0mainlinkanon&utm_medium=feed

Linux 4.11 has been released. This release adds support for bigger memory limits in x86 hardware (128PiB of virtual address space, 4PiB of physical address space); support for AMD Secure Memory Encryption; a new unwinder that provides better kernel traces and a smaller kernel size; support for the zstd compression algorithm has been added to Btrfs and Squashfs; support for zero-copy of data from user memory to sockets; support for Heterogeneous Memory Management that will be needed in future GPUs; better cpufreq behaviour in some corner cases; faster TBL flushing by using the PCID instruction; asynchronous non-blocking buffered reads; and many new drivers and other improvements.

Windows wins the desktop, but Linux takes the world By Steve Ranger

http://www.zdnet.com/article/windows-wins-the-desktop-but-linux-takes-the-world/

The city with the highest-profile Linux desktop projects is turning back to Windows, but the fate of Linux isn't tied to the PC anymore.

After a nearly decade-long project to move away from Windows onto Linux, Munich has all but decided on a dramatic u-turn. It's likely that, by 2021, the city council will start to replace PCs running LiMux (its custom version of Ubuntu) with Windows 10.

Going back maybe 15 or 20 years, it was seriously debated as to when Linux would overtake Windows on the desktop. When Ubuntu was created in 2004, for example, it was with the specific intention of replacing Windows as the standard desktop operating system.

Spoiler: it didn't happen.

Linux on the desktop has about a two percent market share today and is viewed by many as complicated and obscure. Meanwhile, Windows sails on serenely, currently running on 90 percent of PCs in use. There will likely always be a few Linux desktops around in business -- particularly for developers or data scientists.

But it's never going to be mainstream.

There has been lots of interest in Munich's Linux project because it's one of the biggest around. Few large organizations have switched from Windows to Linux, although there are some others, like the French Gendarmerie and the city of Turin. But Munich was the poster child: losing it as a case study will undoubtedly be a blow to those still championing Linux on the desktop.

But the reality is that most companies are happy to go with the dominant desktop OS, given all of the advantages around integration and familiarity that come with it.

It's not entirely clear how much of the problems that some staff have complained about are down to the LiMux software and how much the operating system is being blamed for unrelated issues. But whatever Munich finally decides to do, Linux's fate is not going to be decided on the desktop -- Linux lost the desktop war years ago.

That's probably OK because Linux won the smartphone war and is doing pretty well on the cloud and Internet of Things battlefields too.

There's a four-in-five chance that there's a Linux-powered smartphone in your pocket (Android is based on the Linux kernel) and plenty of IoT devices are Linux-powered too, even if you don't necessarily notice it.

Devices like the Raspberry Pi, running a vast array of different flavours of Linux, are creating an enthusiastic community of makers and giving startups a low-cost way to power new types of devices.

Much of the public cloud is running on Linux in one form or another, too; even Microsoft has warmed up to open-source software. Regardless of your views about one software platform or another, having a rich set of options for developers and users is good for choice and good for innovation.

The dominance of the desktop is not what it once was: it's now just one computing platform among many. Indeed, the software on the PC becomes less and less relevant as more apps become device- and OS-independent, residing in the cloud instead.

The twists and turns of the Munich saga and the adventures of Linux on the desktop are fascinating, but they don't tell the full story.

http://www.zdnet.com/article/windows-wins-the-desktop-but-linux-takes-the-world/

Man 'deletes his whole company' after typing wrong bit of code by Chris Graham

http://www.independent.ie/business/technology/man-deletes-his-whole-company-after-typing-wrong-bit-of-code-34629615.html

Hosting provider Marco Marsala accidentally deleted his company after typing in a line of bad code.

15/04/2016

If ever there was a time you wish you could click 'undo', this would be it.

But while most people are often rescued by the quick 'control+z' command - seeing their entire document return to the screen after inadvertently deleting it all - there was no such saving grace for Marco Marsala.

The hosting provider wrote on help forum Server Fault that he had accidentally entered a code that seemed to have wiped his computers, including the websites of his customers. 

The command, "rm -rf", deletes everything it is told to and blocks the helpful warnings that usually inform the user that something is being deleted. In this case, because he hadn't specified what he wanted deleted, it erased everything.

“I run a small hosting provider with more or less 1,535 customers and I use Ansible to automate some operations to be run on all servers,” wrote Marco Marsala.

“Last night I accidentally ran, on all servers, a Bash script with a rm -rf {foo}/{bar} with those variables undefined due to a bug in the code above this line.

“All servers got deleted and the offsite backups too because the remote storage was mounted just before by the same script (that is a backup maintenance script).”

The response from the forum was far from positive.

“If you really don't have any backups I am sorry to say but you just nuked your entire company”

"If you really don't have any backups, I am sorry to say but you just nuked your entire company," wrote Andre Borie.

Another, Michael Hampton, said: "You're going out of business. You don't need technical advice, you need to call your lawyer."

One respondent pointed out - rather unhelpfully - that Mr Marsala should have kept the backup separate from everything else.

"Backups need to be offsite, offline, and incremental," said Tim. "That you could delete them from your main server means they weren't what I would call backups."

UPDATE: Marco Marsala's post on Server Fault:

http://serverfault.com/questions/769357/recovering-from-a-rm-rf

UPDATE: That man who ‘deleted his entire company’ with a line of code? It was a hoax:
http://www.pcworld.com/article/3057235/data-center-cloud/that-man-who-deleted-his-entire-company-with-a-line-of-code-it-was-a-hoax.html

Microsoft brings SQL Server to Linux by Mark Wilson

http://betanews.com/2016/03/07/sql-server-linux/

The new Microsoft has placed an increased importance on the cloud, and with other companies following suit, reliance on server solutions has increased.  Today the company announces that it is bringing SQL Server to Linux.

Both cloud and on-premises versions will be available, and the news has been welcomed by the likes of Red Hat and Canonical. Although the Linux port of SQL Server is not due to make an appearance until the middle of next year, a private preview version is being made available to testers from today.

Microsoft's increasing embrace of Linux sees the company expanding to a wider audience than ever. Al Gillen, group vice president, enterprise infrastructure, at IDC says that it shows Microsoft's "commitment to being a cross platform solution provider".

Writing on the Official Microsoft blog, Executive Vice President of Cloud and Enterprise Group at Microsoft, Scott Guthrie says:

• Today I’m excited to announce our plans to bring SQL Server to Linux as well. This will enable SQL Server to deliver a consistent data platform across Windows Server and Linux, as well as on-premises and cloud. We are bringing the core relational database capabilities to preview today, and are targeting availability in mid-2017.
• SQL Server on Linux will provide customers with even more flexibility in their data solution. One with mission-critical performance, industry-leading TCO, best-in-class security, and hybrid cloud innovations -- like Stretch Database which lets customers access their data on-premises and in the cloud whenever they want at low cost -- all built in.

Microsoft has not yet made clear exactly what other features of SQL Server 2016 will make their way to SQL Server for Linux, but more news is expected over the coming weeks and months.

Paul Cormier, President, Products and Technologies, Red Hat said, "SQL Server's proven enterprise experience and capabilities offer a valuable asset to enterprise Linux customers around the world." He continued:

• We believe our customers will welcome this news and are happy to see Microsoft further increasing its investment in Linux. As we build upon our deep hybrid cloud partnership, spanning not only Linux, but also middleware, and PaaS, we’re excited to now extend that collaboration to SQL Server on Red Hat Enterprise Linux, bringing enterprise customers increased database choice.

While the full launch of SQL Server for Linux is not due until the middle of 2017, SQL Server 2016 is expected to launch later this year.

Privacy-Centric Linux Distro Tails Hits 2.0 Release

http://linux.slashdot.org/story/16/01/29/159219/privacy-centric-linux-distro-tails-hits-20-release?utm_source=feedly1.0mainlinkanon&utm_medium=feed

Privacy-Centric Linux Distro Tails Hits 2.0 Release38

Posted by timothy on Friday January 29, 2016 @10:11AM from the your-eyes-only dept.

A_Mythago writes:The Amnesic Incognito Live System (Tails) has finalized version 2.0, which has several improvements and updates to continue to meet their mission of preserving privacy, anonymity and circumventing censorship without a trace, using a Debian 8.0 custom live distro. More details about Edward Snowden's use of Tails and the distro itself can be found at a previous Slashdot story from 2014.

10 Years of Git: An Interview with Git Creator Linus Torvalds by Jennifer Cloer

http://www.linux.com/news/featured-blogs/185-jennifer-cloer/821541-10-years-of-git-an-interview-with-git-creator-linus-torvalds

Ten years ago this week, the Linux kernel community faced a daunting challenge: They could no longer use their revision control system BitKeeper and no other Software Configuration Management (SCMs) met their needs for a distributed system. Linus Torvalds, the creator of Linux, took the challenge into his own hands and disappeared over the weekend to emerge the following week with Git. Today Git is used for thousands of projects and has ushered in a new level of social coding among programmers.

To celebrate this milestone, we asked Linus to share the behind-the-scenes story of Git and tell us what he thinks of the project and its impact on software development. You'll find his comments in the story below. We'll follow this Q&A with a week of Git in which we profile a different project each day that is using the revision control system. Look for the stories behind KVM, Qt, Drupal, Puppet and Wine, among others. 

Why did you create Git?

Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM's with a passion. But then BitKeeper came along and really changed the way I viewed source control. BK got most things right and having a local copy of the repository and distributed merging was a big deal. The big thing about distributed source control is that it makes one of the main issues with SCM's go away - the politics around "who can make changes." BK showed that you can avoid that by just giving everybody their own source repository. But BK had its own problems, too; there were a few technical choices that caused problems (renames were painful), but the biggest downside was the fact that since it wasn't open source, there was a lot of people who didn't want to use it. So while we ended up having several core maintainers use BK - it was free to use for open source projects - it never got ubiquitous. So it helped kernel development, but there were still pain points.

That then came to a head when Tridge (Andrew Tridgell) started reverse-engineering the (fairly simply) BK protocol, which was against the usage rules for BK. I spent a few weeks (months? It felt that way) trying to mediate between Tridge and Larry McVoy, but in the end it clearly wasn't working. So at some point I decided that I can't continue using BK, but that I really didn't want to go back to the bad old pre-BK days. Sadly, at the time, while there were some other SCM's that kind of tried to get the whole distributed thing, none of them did it remotely well.  I had performance requirements that were not even remotely satisfied by what was available, and I also worried about integrity of the code and the whole workflow, so I ended up just deciding to write my own.

How did you approach it? Did you stay up all weekend to write it or was it just during regular hours?

Torvalds: Heh. You can actually see how it all took shape in the git source code repository, except for the very first day or so. It took about a day to get to be "self-hosting" so that I could start committing things into git using git itself, so the first day or so is hidden, but everything else is there. The work was clearly mostly during the day, but there's a few midnight entries and a couple of 2 a.m. ones. The most interesting part is how quickly it took shape ; the very first commit in the git tree is not a lot of code, but it already did the basics - enough to commit itself. The trick wasn't really so much the coding but coming up with how it organizes the data.

So I'd like to stress that while it really came together in just about ten days or so (at which point I did my first *kernel* commit using git), it wasn't like it was some kind of mad dash of coding. The actual amount of that early code is actually fairly small, it all depended on getting the basic ideas right. And that I had been mulling over for a while before the whole project started. I'd seen the problems others had. I'd seen what I wanted to avoid doing. 

Has it lived up to your expectations? How is it working today in your estimation? Are there any limitations?

Torvalds: I'm very happy with git. It works remarkably well for the kernel and is still meeting all my expectations. What I find interesting is how it took over so many other projects, too. Surprisingly quickly, in the end. There is a lot of inertia in switching source control systems;  just look at how long CVS and even RCS have stayed around, but at some point git just took over.

Why do you think it's been so widely adopted?

Torvalds: I think that many others had been frustrated by all the same issues that made me hate SCM's, and while there have been many projects that tried to fix one or two small corner cases that drove people wild, there really hadn't been anything like git that really ended up taking on the big problems head on. Even when people don't realize how important that "distributed" part was (and a lot of people were fighting it), once they figure out that it allows those easy and reliable backups, and allows people to make their own private test repositories without having to worry about the politics of having write access to some central repository, they'll never go back.

Does Git last forever, or do you foresee another revision control system in another 10 years? Will you be the one to write it? 

Torvalds: I'm not going to be the one writing it, no. And maybe we'll see something new in ten years, but I guarantee that it will be pretty "git-like." It's not like git got everything right, but it got all the really basic issues right in a way that no other SCM had ever done before.

No false modesty ;)

Why does Git work so well for Linux?

Torvalds: Well, it was obviously designed for our workflow, so that is part of it. I've already mentioned the whole "distributed" part many times, but it bears repeating. But it was also designed to be efficient enough for a biggish project like Linux, and it was designed to do things that people considered "hard" before git - because those are the things *I* do every day.

Just to pick an example: the concept of "merging" was generally considered to be something really quite painful and hard in most SCM's. You'd plan your merges, because they were big deals. That's not acceptable to me, since I commonly do tens of merges a day when in the merge window, and even then, the biggest overhead shouldn't be the merge itself, it should be testing the result. The "git" part of the merge is just a couple of seconds, it should take me much longer just to write the merge explanation message.

So git was basically designed and written for my requirements, and it shows.

People have said that Git is only for super smart people. Even Andrew Morton said Git is "expressly designed to make you feel less intelligent than you thought you were." What's your response to this?

Torvalds: So I think it used to be true but isn't any more. There is a few reasons people feel that way, but I think only one of them remains. The one that remains is fairly simple: "you can do things so many ways."

You can do a lot of things with git, and many of the rules of what you *should* do are not so much technical limitations but are about what works well when working together with other people. So git is a very powerful set of tools, and that can not only be overwhelming at first, it also means that you can often do the same (or similar) things different ways, and they all "work." Generally, the best way to learn git is probably to first only do very basic things and not even look at some of the things you can do until you are familiar and confident about the basics.

There's a few historical reasons for why git was considered complicated. One of them is that it wascomplicated. The people who started using git very early on in order to work on the kernel really had to learn a very rough set of scripts to make everything work. All the effort had been on making the core technology work and very little on making it easy or obvious. So git (deservedly) had a reputation for requiring you to know exactly what you did early on. But that was mainly true for the first 6 months or a year.

The other big reason people thought git was hard is that git is very different. There are people who used things like CVS for a decade or two, and git is not CVS. Not even close. The concepts are different. The commands are different. Git never even really tried to look like CVS, quite the reverse. And if you've used a CVS-like system for a long time, that makes git appear complicated and needlessly different. People were put off by the odd revision numbers. Why is a git revision not "1.3.1" with nice incrementing numbers like it was in CVS? Why is it that odd scary 40-character HEX number?

But git wasn't "needlessly different." The differences are required. It's just that it made some people really think it was more complicated than it is, because they came from a very different background. The "CVS background" thing is going away. By now there are probably lots of programmers out there who have never used CVS in their lives and would find the CVS way of doing things very confusing, because they learned git first.

Do you think the rate of Linux kernel development would have been able to grow at its current rate without Git? Why or why not?

Torvalds: Well, "without git," sure. But it would have required that somebody else wrote something git-equivalent: a distributed SCM that is as efficient as git is. We definitely needed something *like* git.

What's your latest opinion of GitHub?

Torvalds: Github is an excellent hosting service; I have nothing against it at all. Now, the complaints I've had is that GitHub as a development platform - making commits, pull requests, keeping track of issues etc - doesn't work very well at all. It's not even close, not for something like the kernel. It's much too limited.

That's partly because of how the kernel is developed, but part of it was that the GitHub interfaces were actively encouraging bad behavior. Commits done on GitHub had bad commit messages etc, because the web interfaces at GitHub were actively encouraging bad behavior. They did fix some of that, so it probably works better, but it will never be appropriate for something like the Linux kernel.

What is the most interesting use you've seen for Git and/or GitHub?

Torvalds: I'm just happy that it made it so easy to start a new project. Project hosting used to be painful, and with git and GitHub it's just so trivial to do a random small project. It doesn't matter what the project is; what matters is that you can do it.

Do you have side projects up your sleeve today? Any more brilliant software projects that will dominate software development for years to come?

Torvalds: Nothing planned. But I'll let you know if that changes.

Great Git Interactive Infographic:

https://www.atlassian.com/git/articles/10-years-of-git/

GNOME 3.16 Released

GNOME 3.16 is the latest version of GNOME 3,  GNOME is the primary desktop environment for GNU/Linux operating systems, has been released. It is the result of six months' work by the GNOME project. It includes major new features, as well as a large number of smaller improvements and enhancements. The release incorporates 33525 changes, made by approximately 1043 contributors. New features and improvements being introduced in GNOME 3.16 include:

• Notifications Reimagined
• Files Improvements
• Updated Visuals
• New-Look Scrollbars
• Updated Image Viewer
• New Preview Applications

https://help.gnome.org/misc/release-notes/3.16/

Linus Torvalds email on Linux 4

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

Date Sun, 22 Feb 2015 19:06:40 -0800 Subject Linux 4.0-rc1 out.. From Linus Torvalds

.. 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.