Tag Archives: LTS

Linux

Akademy 2013 Day 3 in Photos – Kubuntu Developer Summit

Leave a comment
DSCF8048

KDE Project:

  • At the Kubuntu Developer Summit we discussed various topics. The guys on the left are from a 15,000 seat Kubuntu rollout in Munich, we worked out a plan to supply LTS backport packages they need.


    Dani the Akademy organiser loved Kubuntu so much they gave us a bucket of free beer 🙂

    DSCF8056
    In parallel to the Kubuntu Developer Summit was Qt Contributor Summit, here setting up the keynote room before a talk.

    DSCF8053
    Venue change so lunch not as classy but instead more filling tortilla baguettes.

    13070037
    The blue infiltration

    13070038
    The most classy Akademy ever, now we fill a whole arena with our parties.

    13070042
    You’ve not heard the Beatles until you’ve heard them in the original Basque. The police came to break up the party, another first for Akademy.

…read more

Source: FULL ARTICLE at Planet KDE

Computers

Three Ubuntu Linux versions will reach end of life in May

Leave a comment

Hard on the heels of Canonical’s decision last month to halve the support life for non-LTS releases of Ubuntu Linux, the company late last week announced that three versions of its popular Linux distribution will reach end of life in May.

Support for the server version of Ubuntu 8.04 Long Term Support (LTS) “Hardy Heron,” the desktop version of Ubuntu 10.04 LTS “Lucid Lynx,” and both desktop and server versions of Ubuntu 11.10 “Oneiric Ocelot” will end on May 9, Canonical announced in a blog post on Friday.

Anyone still using these packages should be making plans to upgrade to a newer version.

Ubuntu 8.04 Server

To read this article in full or to leave a comment, please click here

…read more
Source: FULL ARTICLE at PCWorld

Computers

Linux distro update: Ubuntu slashes support, Debian 7.0 draws near

Leave a comment

It wasn’t all that long ago that Canonical extended the support period for Long Term Support (LTS) releases of its Ubuntu Linux from three years to five, but last week it made a move in the opposite direction for its non-LTS software.

Specifically, beginning with Ubuntu 13.04 “Raring Ringtail,” which is due in April, Canonical will reduce the support period for interim versions of its popular Linux distribution  from 18 months to just nine.

New Ubuntu releases come out every six months, with LTS versions every two years.

‘Prepare for a wider role’

To read this article in full or to leave a comment, please click here

…read more
Source: FULL ARTICLE at PCWorld

Linux

Mark Shuttleworth: Let’s go faster while preserving what works best

Leave a comment
;-)

It’s been two weeks since Rick Spencer made the case for a rolling release approach in Ubuntu. Having a rolling release is one of the very top suggestions from the hardcore Ubuntu user community, and after years of it being mooted by all and sundry I thought it deserved the deep consideration that Rick and his team, who represent most of Canonical’s direct contributions to Ubuntu, brought to the analysis.

It’s obviously not helpful to have mass hysteria break out when ideas like this get floated, so I would like to thank everyone who calmly provided feedback on the proposal, and blow a fat raspberry at those of you who felt obliged to mount soapboxes and opine on The End Of the World As We Know It. Sensible people the world over will appreciate the dilemma at being asked to take user feedback seriously, and being accused of unilateralism when exploring options.

Change is warranted. If we want to deliver on our mission, we have to be willing to stare controversy in the face and do the right thing anyway, recognising that we won’t know if it’s the right thing until much later, and for most of the intervening time, friends and enemies alike will go various degrees of apoplectic. Our best defense against getting it wrong is to have a strong meritocracy, which I think we do. That means letting people like Rick, who have earned their leadership roles, explore controversial territory.

So, where do we stand? And where do I stand? What’s the next step?

What makes this conversation hard is the sheer scale of the Ubuntu ecosystem, all of which is profoundly affected by any change. Here are the things I think we need to optimise for, and the observations that I think we should structure our thinking around:

Releases are good discipline, cadence is valuable.

Releases, even interim releases, create value for parts of the Ubuntu ecosystem that are important. They allow us to get more widespread feedback on decisions made in that cycle – what’s working, what’s not working. Interestingly, in the analysis that played into Rick’s proposal, we found that very few institutional users depend on extended support of the interim releases. Those who care about support tend to use the LTS releases and LTS point releases.

Release management detracts from development time, and should be balanced against the amount of use that release gets.

While reaffirming our interest in releases, I think we established that the amount of time spend developing in a cycle versus spent doing release management is currently out of whack with the amount to which people actually DEPEND on that release management, for interim releases, on the desktop. On the server, we found that the interim releases are quite heavily used in the cloud, less so on physical metal.

Daily quality has raised the game dramatically for tip / trunk / devel users, and addresses the Rolling Release need.

There’s widespread support for the statement that ‘developers can and should use the daily development release’. …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Serge Hallyn: Qemu updates in raring

Leave a comment

The raring feature freeze took effect last week. What’s been happening with qemu in the meantime?

A lot! I’ll touch on the following main changes in this post: package reorg, spice support, hugepages, uefi, and rbd support.

* package reorg

Perhaps best to begin with a bit of Ubuntu qemu packaging history. In hardy (before my time) Ubuntu shipped with separate qemu and kvm packages. This reflected the separate upstream qemu and kvm source trees. In August of 2009, upstream was already talking about merging the two trees, and Dustin Kirkland started a new qemu-kvm Ubuntu package which provided both qemu and kvm.

In 2010, a new ‘qemu-linaro’ source package was created in universe, to provide qemu with more bleeding-edge arm support from linaro. Eventually the qemu-kvm package provided the i386 and amd64 qemu-system binaries, qemu-common, and qemu-utils. All other target architecture system binaries, plus all qemu-user binaries, plus qemu-kvm-spice, came from qemu-linaro. This is clearly non-ideal from many viewpoints, and especially QA testing and bug duplication. But any reorganization would have to make sure that upgrades work seamlessly for raring-raring, quantal-raring, and future LTS-to-LTS upgrades, for the many commonly used packages (qemu-kvm, qemu on various packages, and qemu-user).

In the traditional 6-month-plus-LTS Ubuntu cycle, raring was a good time (not too close to next LTS) to try to straighten that out. It was also a good time in that upstream qemu and kvm were now very close together, and especially in that the wonderfully helpful debian qemu team which was also starting to merge debian’s qemu and qemu-kvm sources into a new qemu source tree in debian experimental.

And so, it’s done! The qemu-linaro and qemu-kvm source packages have been merged into qemu. Most arm patches from linaro are in our package, but you can still run linaro’s qemu from ppa at https://launchpad.net/~linaro-maintainers/+archive/tools/. The Ubuntu and Debian teams are working together, which should mean more stable packages in both, and combined resources in addressing bugs. Thanks especially to Michael Tokarev for helping to review the Ubuntu delta, and to infinity for more than once helping to figure out packaging issues I couldn’t have figured out on my own.

* Spice support. Spice has finally made it into main! The qemu package in main therefore finally supports spice, without having to install a separate qemu-kvm-spice package. As a simple example, if you used to do:

kvm -vga vmware -vnc :1

then you can use spice by doing:

kvm -vga qxl -spice port=5900,disable-ticketing

then connect with spicec or spicy:

spicec -h hostname -p 5900

3. Transparent hugepages. The 1.4.0 qemu release includes support for transparent hugepages. This means that when hugepages are available, qemu instances migrate some memory pages from regular to huge pages. Hugepages offer performance improvements due to (1) requiring fewer TLB entries for the same amount of memory, (2) requiring fewer lookups per page, and (3) requiring fewer page faults for nearby memory references (since each memory page …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Thoughts and worries about the proposed new Ubuntu processes

Leave a comment

Today began in a virtual UDS session (Google Hangout) with the Xubuntu team. The video can be seen here: http://summit.ubuntu.com/uds-1303/meeting/21666/community-xubuntu-contingencies/ . Xubuntu devels stopped by #kubuntu-devel and asked us to bring our list of concerns to share. The list we developed:

  • The new system will do away with releases for each upstream KDE release, which is a prominent feature of Kubuntu. One idea is to do releases of LTS+PPA with latest KDE but that’s against policy and needs technical changes to make happen. Or will there be a way to create ISOs from PPAs?

  • Mir is a worry since KWin will clash with it (a compositing manager inside a compositing manager). How good will continued Wayland and X support be?

  • Where to put Beta releases of software? Testing is a huge part of quality. So while a PPA seems the obvious suggestion, but they’ll get less testing there. Now we use a beta ppa only for backports. Consistent quality would require staging major changes somewhere else.

  • How will library transitions be handled outside of cadence?

  • Launchpad breakdowns. We are trying to automate more of our building tasks, but often the scripts must be run repeatedly because of Launchpad timeouts.

  • Weakness of unit & hardware testing. This is crucial for a successful rolling release.

  • Security updates – who gets them? When, and how often? (LTS will get them as usual, but for rolling it seems the monthly snapshots don’t get any? you need to use rolling)

<span style="background-color: transparent;color: black;font-family: Arial;font-size: 15px;font-style: normal;font-variant: normal;font-weight: normal;text-decoration: none;vertical-align: …read more
Source: FULL ARTICLE at Planet KDE

Linux

Ben Collins: Ubuntu Rolling Releases Vs. Hardware Companies

Leave a comment

So I have to speak out on this whole issue. I work for Servergy, and for almost two years I’ve been working on Ubuntu’s PowerPC port in order for our new hardware platform, the CTS-1000, to have an out-of-the-box solution for our customers. We’ve been hedging on Ubuntu, since it was able to provide us a known quantity for release dates and an open community that we could participate in (especially being able to take advantage of my core-developer status).

Now, after so much work, so much planning, we are worried about 13.04 never being properly released. This would leave us with no stable Linux distribution for our hardware, basically yanking the rug out from under all of our work. Having a stable release every two years also enlarges the support gap for our followup platforms. Now I realize most hardware vendors are x86-based, and their issues are likely limited to supporting peripherals, so this affects us more than most. The issue we face is supporting entirely new hardware platforms and SoCs with a completely new kernel (likely requiring lots of supporting patches). This is the type of thing that, historically, isn’t allowed to be added to an LTS release.

So I have to wonder, if Ubuntu does adopt this rolling release schedule, how viable is it for us? I would still be happy if Ubuntu had one release per year, with every other release becoming an LTS. However, the two year window is just entirely too large to depend on for quick moving hardware bring up and release.

…read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Howard Chan: Some thoughts about Canonical and the community

Leave a comment

Yesterday I had a chat with Jono Bacon and Michael Hall from the Canonical Ubuntu Community Team. I first asked them why aren’t they doing at least one physical UDS per year, and they clearly seemed opposing my argument. Then I asked how about per post-LTS and such, and they still don’t see the need for it. Then I saw Pasi Lallinaho’s post about UDS and Canonical away from community, and I agreed.

The problem we have here is this:

Community finds it difficult to adopt

For example, we are now just near Ubuntu 13.04 (Raring Ringtail) Feature Freeze, and now suddenly Canonical’s Technical Lead Rick Spencer wants to step in and say “let’s cancel it for good”. It clearly destroys all the original plans for 13.04, especially for flavours. For example, Ubuntu Studio originally has some plans made for 13.04. Now it’s even unsure would these not be released to the public on April this year.

Update: Jonathan Riddell saved it for good, but fhe future of 13.10 and 14.10 is unknown.

UDS destroys comunity friendship

Canonical is happy that they don’t need to sponsor anyone now, but then this really breaks the Ubuntu community, especially teams of flavours, which now doesn’t have much chance to meet each other

..

People are leaving

From Planet Ubuntu + Google+ at least 4 community members have left the Ubuntu community because of Canonical’s decisions. Most of them even gave up Ubuntu membership. Is this what we want? Canonical being “Big Brother” in the Ubuntu community?

Summary

Canonical has been annoucing decisions that threatens the Ubuntu community. I really hope that the relations can be repaired.

Leave comments if you wish:-)

…read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Joel Pickett: UDS-1303, Day One

Leave a comment

Now UDS-1303 Tuesday is through, I’d like to recap on a couple of the sessions I watched on Google+ Hangouts.

Rolling Release discussion (+1 maintenance beyond April)

Interesting discussion which included some of the System76 folks that basically said that the Ubuntu release schedule works fine for their clients. They ship the latest LTS, 12.04, and the current stable release, 12.10. They pointed out that each release of Ubuntu has been a clear improvement over the previous release (phew!), and were looking forward to the upcoming Raring Ringtail. Very compelling to hear straight from the OEM vendors – they have been shipping Ubuntu for the past fifteen (yes, that’s 15!) releases.

Rick Spencer outlined the idea to keep LTS releases and focus on daily quality with monthly pulses. I think this is an interesting concept in relation where Ubuntu is as a platform. If this idea had been discussed around the days that I started as an Ubuntu user (Intrepid Ibex era), the daily quality was just not there. It was more of a sentiment to encourage users not to use the development build until the later alpha snapshots, or even beta releases.

These days I’ve been using the Quantal and Raring dailies with minimal disruption, essentially my desktop and laptops feel like a normal (release) install. It’s just that updates are much more frequent and I’m using the latest available version of the software.

Loco discussion (LoCo community – what’s next?)

Another interesting discussion was the concept of approved and unapproved LoCo teams. I’m a member of the Australian LoCo, which is currently approved. As Jono stated in the session, I think there’s less of a need for approved LoCo teams now. The main benefit of being an approved LoCo is that, historically, LoCos would be sent CD’s/DVD’s, stickers and other Ubuntu merchandise around releases and conferences. This isn’t particularly sustainable to send a pack to all approved LoCos each release, and arguably more people are using other media like USBs to install Ubuntu.

The other concern was the labelling and divide of LoCo teams. It should be noted that being an unapproved team doesn’t make you any less important than an approved LoCo. At the end of the day, LoCos will be recognised for the work that they do, supported by Planet Ubuntu blog posts, pictures of events (release parties, conference talks, Ubuntu Hours, Ubuntu Global Jam sessions) and team reports.

Thoughts on the first online UDS

On the whole, I think it went quite fine. I think if the LTS release structure is continued, I think a physical week-long UDS would be appropriate at least once through the LTS cycle. It’s also a positive bonus that everything is logged and the sessions are available once the session ends for people that have missed the session. These short UDS place a focus on detailed discussion, though if anything is missed, we’ll be able to revisit it again at the next UDS in a few months or on ubuntu-devel.

It would have been nice for Mark Shuttleworth to comment …read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Kaj Ailomaa: Future Ubuntu Studio changes

Leave a comment

The first UDS (Ubuntu Developer Summit) of the year has just started. It’s now an online event, held every three months, where Ubuntu developers and contributors meet and discuss future development goals.

UDS used to be a physical event, held every 6 months, just after a new release of Ubuntu. Traditionally participants is a mix of Canonical employees, sponsored participants, and volunteers. It’s free and open for anyone to attend. Usually at least the project lead of each of the official Ubuntu flavors would attend. In October I attended when it was held in Copenhagen, and the year before, in US, Scott Lavender, the project lead of Ubuntu Studio attended.

Many things are being discussed during UDS that might radically change how Ubuntu Studio, and other community Ubuntu flavors will be developed and supported in the future.

Moving Towards Rolling Release?

One of the major topics for this UDS is the discussion on whether or not Ubuntu should start using the rolling release model. The LTS(Long Term Release) will still continue, as Canonicals clients value that,  while the interim release is proposed to be dropped.

Many ideas are floating around how to make this work. So far, northing’s conclusive, but it seem sto me, reading mail lists and such, that many people want it to happen, even if this does cause quite a bit of disturbance among flavor developers, who have been planning for a release in April for the last six months.

X Window to be replaced by MIR

Many things were announced at the same time, and while the rolling release is still up for discussion, it seems that the move towards replacing the X window system with MIR is already decided. Of course, at this point nothing is for sure, since MIR still needs to be developed, and the change will not come instantly. The goal is for a full change by the release of 14.04 LTS.

This will be a huge change for the community, as it means either all of the desktop systems on Ubuntu will need to support MIR, or the current X window system will need to be fully supported by the community developerst, since Unity – the Ubuntu desktop system will not be using X, and thus, they will not be supporting it.

What will this mean for Ubuntu Studio?

Right now, we don’t really know. In many ways, Ubuntu Studio itself is quite flexible, as we do not actually depend on any specific windowing or desktop system (as long as our applications are able to run on it, though we prefer to stay with XFCE), and our main concern about the rolling release is really just will it be stable enough for users? Some of our users don’t need anything but a LTS, but that is a minority of our users. A potential rolling release will be our main release, and it needs to be good and usable.

…read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Ubuntu Server blog: Ubuntu Server Team Meeting Minutes 20130226

Leave a comment

It was decided not to send an alpha-2 call for testing, but to wait for beta instead. Daviey mentioned that matsurba has kindly offered to help with dep-8 tests.

BLUEPRINTS

Daviey thinks we look a little further behind than we actually are, and asks that everyone take a look to make sure their blueprints are uptodate. If you’d like to mark some items postponed, please first talk to Daviey, jamespage or smoser.

QA

plars will be taking hggdh’s place representing QA.

plars noted that conffile failures no longer raise individual bugs, but rather are reported at https://jenkins.qa.ubuntu.com/view/Raring/view/Smoke%20Testing/job/raring-upgrade-quantal-server/ARCH=amd64,LTS=non-lts,PROFILE=server-tasks,label=upgrade-test/lastSuccessfulBuild/artifact/results/obsolete_conffiles.log

KERNEL

smb re-advertised http://people.canonical.com/~smb/lucid-ec2-ng/

ACTIONS:

* jamespage to milesone documentation updates [carryover]
* serge to update server meeting docs to reflect palrs representing qa
* serge to consider putting the obsolete_conffiles.log url in weekly triaging knowledgebase section

…read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Jorge Castro: What the LTS Enablement Stack means for sysadmins

Leave a comment

TLDR: 12.04.2 ISOs are NOT just rolled up updates, they’re 12.04 with newer kernels.

I’d like to point out some changes to things that might affect our server users. The last 12.04.2 point release is the first real release where the LTS Enablement Stack is in effect.

There are some things I’d like to highlight for those of you not reading the release notes, as this is different from how we rolled point releases in the past.

  • New installs from the 12.04.2 ISOs will get a newer kernel (3.5) than 12.04 (3.2).
  • Machines currently running 12.04 will NOT receive these kernel upgrades, only new installs from the new ISOs will get the enablement stacks.

Recommendations:

  • The 12.04 and 12.04.1 ISO’s are at http://http://old-releases.ubuntu.com/ – you’ll likely want to keep a set for yourself if you want to roll out with the same exact kernel for your deployments – you’ll probably want to have all three ISO sets on hand depending on your hardware.
  • The original 12.04 stack will continue to be maintained for 5 years, if you don’t need the new kernel, you don’t need to use it.
  • In the past if new hardware rolled out and didn’t work with the LTS you were kind of stuck with either backporting a kernel, or (what I reluctantly did) deploy a non-LTS release until the next LTS came out, at which point you would rebase on the new LTS.)

What this means is that the life of the LTS is now much longer, while also giving you the option of sticking with a stable userspace with newer hardware support (if you need it). The wiki page has a bunch more details, please check it out.

…read more
Source: FULL ARTICLE at Planet Ubuntu

Linux

Milo Casagrande: Fixing Network Errors in VirtualBox

Leave a comment

This is that kind of post that are more necessary to me for remembering than anything else. Lots of digital ink has already been spent on this topic, but, as others I guess, I find that writing down things helps me remembering them (and mind-maps are precious on that front).

VirtualBox Clone Operation

I have a couple of local virtual machines installation for Ubuntu desktop and Ubuntu server, usually the latest LTS ones, and I clone them as I needed: I need to test some scripts, or the installation of a program, like it was being performed on a real installation.

VirtualBox has this nice little feature of creating clones of your virtual machines, and in no time you are up an running with a clean environment (as long as you remembered to take a snapshots at a good point in time).

The Error

When you clone a virtual machine, you are cloning everything of it, configurations included. And that’s where the problem is. The network will not work at all, and ifconfig will tell you that there is no interface configured.

The Solution

The solutions lies in one file:

/etc/udev/rules.d/70-persistent-net.rules

Open that file with your editor, remove the offending line and reboot.

In this case the offending line is an erroneous “eth*” interface, that will results in multiple network entries in that file when just one is needed. Pay attention to the MAC address of the network interface though.

Source: FULL ARTICLE at Planet Ubuntu

Linux

Elizabeth Krumbach: Beautiful Pangolin!

Leave a comment

I know it’s past pangolin season, but we still have plenty of LTS users out there! While at the San Diego Zoo following LISA ’12 we were able to meet their pangolin. I got a few photos with my little digital camera:

IMG_9541 IMG_9489
IMG_9505 IMG_9508

4 photos above licensed CC BY 2.0

But my fiancé was able to get some really great shots:

San Diego Zoo
San Diego Zoo

Above 2 photos licensed CC BY-ND 2.0 by Mike Joseph

Happy Holidays!

Source: Planet Ubuntu