Category: Technology

Categories
Technology

Tumbleweed Updated to GCC 5

openSUSE

Today’s Tumbleweed snapshot upgraded the rolling distro from GCC 4.8 to GCC 5!

It has been very quiet on the openSUSE Tumbleweed front for the past few weeks as efforts were put into recompiling the entire distribution against the newer version of GCC. This surfaced many errors and bugs that have been squashed by the community and today the greater openSUSE community is able to benefit from that effort.

Moving to GCC 5 is just another huge push from the Tumbleweed developers in a string of big changes for the distro. GNOME 3.16, KDE Plasma 5.3, and Linux Kernel 4.0 have all been pushed out in recent snapshots as well. This is a huge amount of effort from the developers in the community.

Thanks everyone!

Categories
Technology

openSUSE 42 Work Announced

openSUSE 42The work around the SLE-sources-based openSUSE release has been announced this morning. Douglas DeMaio posted Work begins on totally new openSUSE release this morning which outlines what the release team is thinking of at the moment for the next release of openSUSE.

You can find more information on the openSUSE Wiki on the openSUSE:42 page. That gives you a good outline of what the thinking is at this time along with some background information.

There is still a lot of work to be done, but the future is pretty exciting!

Categories
Business Education Technology

An Internal Tech Summit Retrospective

MLC Old Main

The 2015 MLC Internal Technology Summit took place on May 26, 2015 and, I think I can safely say, was a success. However, just because something was a success does not mean there isn’t room for improvement.

However, I’ll start by just giving an overview of how the day was run.

  • We had half-hour long time slots for topic areas.
  • Every faculty and staff member was invited to attend any of the topic sessions.
  • Individual invitation emails were sent out to individuals noted as being key stakeholders within a certain topic area.
  • All members of our Technology Advisory Committee were recommended to attend all of the sessions and take any notes they wanted.
  • Groups were recommended to come with projects or ideas they would like to see take place over the next 6 months (or more), no matter how crazy it might sound.
  • The information taken from those sessions was to be used for strategic planning purposes.

One additional item was added the day before.

  • Lunch would be provided by the college for the members of the Technology Advisory Committee to eat together as a group.

Overall the entire day ran smoothly. We had nine sessions during the day (the ninth, Classroom Tech, was added late at the recommendation of two of our professors).

I am currently working through the notes from five individuals to see if I can distill them down to general themes from the day that we can “hang our hats on” for improvement in the future. That is a secondary outcome of the day along with the strategic planning implications.

However, looking at the day, here are some improvements I am currently planning on bringing to the tech summit itself in the future:

  1. Longer sessions. I sent out a form requesting feedback from individuals (anonymous), and a request for more time to talk was #1 overall. The shortness of the sessions was, in part, due to the want to have a single track for everyone to attend. This is one thing I do want to address in the future.
  2. Dig into specific projects. The explicit purpose of this tech summit was to get high-level project ideas. For the future people are asking to dig into more specific projects and topics to really brainstorm how to work on those areas.
  3. More faculty-centered topics. This was totally a blind-spot on my part, but the sessions were very staff-heavy to start, with the additional session providing the only faculty-centric outlet. I’ll be aware of the fact that I need to get some faculty members involved in the planning process.
  4. Larger venue. We used a single classroom this time around and a few of the sessions were filled beyond capacity. A larger venue will be required for the next summit, especially on those campus-spanning sessions.
  5. Get the date out there sooner. Due to the planning starting so late in the school year, there was not a lot of time for people to move their schedules around. Just getting the dates chosen and out there as soon as possible will be very important.

That is the what the future might look like for the tech summit at Martin Luther College.

Here are some general things I’m going to look into but might not make it in the near future.

  • Expand to two days. This would make some things easier, but also many things harder. It might burn out those individuals wanting to make it to all of the sessions but it would allow for a lot of in-depth discussion.
  • Incorporate into larger event. There is a year-end faculty week to close out the traditional year on the campus, and maybe there is room for the staff to be included in this and the tech summit to be a part of this as well.
  • Release a feedback tool. This is a longer-term goal for our department. We’d love to have a site where people can toss project ideas online, have discussion happen around it, and then we can “promote” those projects to planned, working on, or released statuses as things are done. This would help us to move some of the brainstorming to an asynchronous system while the actual in-depth discussion can happen during the summit.

Those are a few more ideas for the future.

Overall the entire day went really well, but there is room for improvement. That is sometimes the fun part.

Categories
Technology

Why openSUSE Next?

SUSE on SUSE

This dovetails off of my last post on what I would love to see from a SLE-based openSUSE.

So why might I be excited about a future openSUSE release built on top of a SUSE Linux Enterprise core?

Quite simply, it gives me a base to work from in two cases:

  1. A great, solid openSUSE to deploy in education/family situations where I want to have multiple years of support to work with without needing to pull everything out and redo it.
  2. A great, solid openSUSE to deploy as a server platform both at work and at home with the idea of putting it in place and being able to keep it running (with updates) for multiple years.

Totally selfish motives, I’ll admit. I like a lot of the tooling around openSUSE and it provides a nice continuum for people to move down: openSUSE Tumbleweed => openSUSE Next => SUSE Linux Enterprise. Free => Free => Paid (and up to 13 years of support on a single major release).

That’s really it.

Categories
Technology

Using SLE for openSUSE

openSUSE Next Timeline

There is a very interesting set of conversations happening within the openSUSE Project and openSUSE Factory mailing lists. The focus is on what, if anything, to do with the newly released SUSE Linux Enterprise sources on the Open Build Service.

I’d recommend that you head over to the mailing lists in order to read up on the entire discussion if you have any interest at all. I’m going to use this time to give my thoughts on where the openSUSE project might want to do for the future.

I’ll preface this by stating there are only my opinions and really serve to make my work easier. Whether the openSUSE community feels this way is a question I cannot answer.

I tend to think it is foolhardy to try to please everyone even some of the time. What makes a good project and/or product is making hard decisions about direction and focus.

Tumbleweed

Tumbleweed should stay Tumbleweed and keep doing what they are doing. There is no use trying to slow it down, you just need to keep pushing ahead. Get some additional resources behinds it, start to try to find some ways around the problems binary drivers can cause, and keep plugging again.

Overall, I’ve found Tumbleweed to be really fun and stable enough to use on a day-to-day basis, even for work. It is not going to please everyone (as the kerfuffle over making KDE 5 the default is causing for some at the moment), so don’t even try.

It is a rolling distribution for developers and contributors using some amazing tooling (like openQA and Open Build Service (OBS) to name a couple). Let it continue to be just that.

openSUSE Next

Here is the fun part. I am using the name “openSUSE Next” for this blog post. I might change it to openSUSE X in the future … just because it really doesn’t have a name.

  • Base the release off of the recently-released SUSE Enterprise Linux sources. I’m not sure what is all in there, but build on the work SUSE is already doing and providing.
  • Take full advantage of openQA and OBS to supply a MUCH LARGER selection of packages than SUSE can (or wants to) for SLE.
  • Refocus efforts on “filling in the gaps” from SLE. Release newer desktop environments sooner than SUSE can or should. Update user-facing packages before SUSE can or should. Focus on the things that will set openSUSE apart from SUSE Enterprise Linux.
  • Make openSUSE Next a great platform to build on top of.

The last bullet is the one that hits closest for me. Make openSUSE the premier Linux distribution for building “things” on top of. I think part of this is accomplished through having consistent support.

  • Schedule releases around SLE releases. For example, openSUSE Next 1.1 could ship close to when SLE 12 SP1 ships. Then when SLE 12 SP2 is getting ready, openSUSE Next 1.2 is next up.
  • Normal support for each release is 18 months (or the next release plus six months).
  • “Evergreen” support (it doesn’t have to be, but I’ll stick with the name) happens at the end of each main release. For example, if SLE 12 SP3 is the last service pack before SLE 13, then openSUSE Next 1.3 would receive “Evergreen” support of another 18 months (grand total of 3 years of support for openSUSE Next 1.3).
  • The process starts over again with SLE 13 coinciding with openSUSE Next 2 being released. When openSUSE Next 2.1 is release, openSUSE Next 2 has six months of support left. Then it keeps going.

In the oddball case of openSUSE Next 1, that release line would receive up to 3.5 years of support or 4.5 years if you include “Evergreen” in that number. It doesn’t mean a single release does, but if you follow the interim releases, you can stick with openSUSE Next 1 for up to 4.5 years.

For openSUSE 2, it would be even better (since you get the SLE 13, SLE 13 SP1, SLE 13 SP2, and SLE 13 SP3 releases to work with): 4.5 years of updates and 5.5 years if you go with “Evergreen” support at the end.

Here’s a clearer look at what I am thinking:

openSUSE Next Timeline

Because you are building on top of the work of SUSE, you get that stable base to build on top of that will get patches, and security updates, and fixes for ever longer.

This is a unique opportunity to not just rehash what is already there (like CentOS, a great option), but to build something a little bit different, a little bit broader, a little more ambitious.

I’m going to continue to watch and chime in when I feel it is needed, but this is just a single idea on where the community could go.