Welcome to Planet openSUSE

This is a feed aggregator that collects what openSUSE contributors are writing in their respective blogs.

To have your blog added to this aggregator, please read the instructions.

Actions:

Sunday
25 June, 2017

Nathan Wolf: KDE Plasma 5 Regional Settings Format Makes Me Happy Again

@ 16:54 UTCmember

face

Since my move from Windows to Linux, KDE has been my preferred desktop environment. I remember switching between Gnome and KDE for a while until I determined that KDE was for me (what I really wanted was Amiga Workbench). KDE's strength has always been its flexibility and ease of customization. I value options which is why I value KDE.

The transition from KDE 3.x to KDE 4.x was somewhat painful for me as for a while, many of the options that I became used to disappeared but later returned. Through the change, I never lost my ability to adjust how I wanted information displayed to me.

With KDE 5.x I was no longer able to properly customize the date format as you could in KDE 4.x and previously with KDE 3.x. I was rather frustrated. I played around with some of the configuration files but thought this was the pits. Why remove what gives KDE it's strength? Why take away entering the date format exactly how I want it for a series of drop downs that I have to search through to find what it is that I want?

I don't like the typical US format of MM/DD/YYYY I think it is all backwards and rather silly. Also, the whole AM / PM thing is dreadful as well. The 24 hour clock is far superior and eliminates confusion.







Although not an option here, I do like ISO format YYYY-MM-DD as that makes perfect sense. I use it very often when naming files to make for easy sorting using the file system but without the dashes: YYYYMMDD. 

The typical European format is less terrible with DD/MM/YYYY but I do get the 24 hour clock. The reason I find the date format undesirable is that it is too close to the backward US method of which I am more used to so at a glance, I get confused.
I have been using the European method for quite some time due to my inability to tolerate the typical US format, but now, by accident, I see that there is this "Default (C)" format available. If I select Detailed Setting and under "Time:" I select the "Default (C)" format. The time is expressed exactly how I like it. DD MMM YYYY along with the 24 hour clock. 

The best readable format that I appreciate the most is the DD MMM YYYY format. It is the clearest short format and very readable. 
My desktop date is readable again! This is very important to me in Kontact, the Personal information Management suite in KDE where I spend a lot of my time each day.

The desktop world is perfect, once again, for me.

Final Thoughts

I first became aware and addicted to the DD MMM YYYY format in 1992 when I bought my first Amiga, the A600. I thought it was such a great format and worked so well with my somewhat OCD personality. Since …
read more

Friday
23 June, 2017

Dominique Leuenberger: Review of the week 2017/25

@ 13:16 UTCmember

face

Dear Tumbleweed users and hackers,

With the pace of Tumbleweed having resumed to ‘almost daily snapshots’ I will to the review again weekly instead of bi-weekly. It’s just easier to remember what big updates came in like this. This week I will cover the 6 snapshots 0616,0617,0618,0619,0620 and 0622 (again, 0622 just passed openQA and you will get it shortly on the mirror). There was also a 0621 tested, but discarded by openQA.

What did those 6 snapshots bring you (or will bring you, in the case of 0622):

  • KDE Plasma 5.10.2
  • A newer version of plymouth
  • Linux Kernel 4.11.5 & 4.11.6
  • Mesa 17.1.2 & 17.1.3 (in 0622), helping with chromium leaking memory
  • GStreamer 1.12.0 – with the MP3 module finally enabled. No more need for extra repos to play your favorite MP3 collection
  • GNOME fixes for Wayland sessions
  • Mozilla Firefox & Thunderbird 52.2
  • LibreOffice 5.4 (beta2!) – Considered stable by the maintainer, but please look out for errors and report them as you see them appear
  • Systemd 233
  • More system user related packaging changes: even ‘root’ comes now from a specific package (system-user-root), no longer ‘hidden’ as part of something else (0622)

You were thinking that this could not all have happened in one week, right? Was my thought too, yet it is true.

And as usual, Tumbleweed can’t be stopped and it keeps rolling. With those things currently being prepared in Stagings:

  • TexLive 2017
  • KDE Frameworks 5.35.0
  • openSSL 1.1 as default
  • GStreamer 1.12.1

With all these nice things: have a great weekend, have a lot of fun using your up-to-date Tumbleweed system

Thursday
22 June, 2017

Nathan Wolf: Dell Latitude D630 Tumbleweed Refresh

@ 18:16 UTCmember

face

I am not quick to buy new things, though I did replace my Dell Latitude D630 about three months ago with a newer Dell latitude E6440. My plan was to deprecate the machine and put it on a "reserve only" status. In my process of setting up the E6440, I found that I used my D630 still but quite differently, it became my home station machine and my E6440 would be my mobile machine that would return back to "base" where I would have it connect as a client to the D630 for keyboard and mouse. It was a rather nice arrangement. 

Unfortunately, the hard drive died on the D630 and I needed to install openSUSE once again on it in order to continue to use my workspace as I have been. What is $50 on a new hard drive to restore my SuperCubicle, right? 

This time I decided to go for Tumbleweed instead of the usual Leap install. I was concerned about the need for the Nvidia drivers and a year ago when I tried Tumbleweed on it, it didn't go so well. The machine would have lock ups, shut down and occasionally get the flashing lights that indicated video failure from the open source Nouveau drivers. The proprietary drivers were at times problematic, even in Leap, but at least stable enough to get work done. 

I run KDE Plasma for my desktop. I've tried others but the customization options in KDE Plasma just  fits my personal tastes best. I have also been real happy with the speed improvements of KDE Plasma in the last couple years and especially those of KDE Plasma 5.10 on Tumbleweed as of late.

Thankfully this is a Latitude series so the actual process of changing out a hard drive took all of four minutes. The installation of Tumbleweed was also super simple, as expected. I added my Base Application Set to the machine for my multimedia goodies and Smart Card software.

Specification wise, it is nothing impressive, it is quite old. Good at the time this D630 has an Intel Core 2 Duo CPU T9500 @ 2.60GHz, 8GB of RAM, 1 TB SSHD, Nvidia Quadro NVS 135M graphics card (known for burning out early in life) with the highest resolution screen available at the time of 1440x900. 

I have been using Syncthing to synchronize the files back to this machine. Although it has been slow it has been a problem free experience.

Suspend is seemingly working perfectly. Granted, I haven't put it through the paces of being a mobile machine but I have tested it enough to say that this feature is reliable enough.

The D630 has been operational for about a week now and it has yet to glitch out. It has had several rounds of updates come thru and they have all be problem free. My experience with the latest Nouveau drivers with Kernel 4.11.5 is that they are smoother and more responsive than …
read more

openSUSE News: Tumbleweed Gets Qt 5.9, mp3 Out-Of-The Box

@ 11:44 UTC

face

A total of seven openSUSE Tumbleweed snapshots featuring new software were released this week along with an upgrade to GStreamer that allows for mp3 decoding to work out-of-the box.

The newest stable Linux Kernel 4.11.6 is also available in the latest Tumbleweed snapshot 20170620.

Updates in the repositories from the 20170620 snapshot brought both the 52.2 versions of Mozilla Firefox and Thunderbird, which fixed some critical vulnerabilities. Systemd 233 provided a package for a new systemd-umount binary and, with the update of dracut 044.1, supports the new compatibility rule. Fontconfig’s 2.12.3 version fixed the build issues with gperf 3.1 and on GNU Hurd. The Beta 2 version of LibreOffice 5.4 cleaned up the license string and got rid of the Oxygen theme. A removal of support for old, non-systemd distros was made available in the snapshot with libvirt 3.4.0.

Snapshot 20170619  updated translations in both libgnome-games-support 1.2.2 and gnome-tweak-tool 3.24.1, which also added a way for handling a program interrupt signal.

GStreamer 1.12.0 fixed several bugs in the 20170618 snapshot and enabled mpg123, which provides the out-of-the box functionality for mp3 decoding. Some fixes for integer overflows were made with the upstream release of ffmpeg 3.3.2. Libbluray 1.0.1 fixed some resilience and stability issues in the snapshot and libgusb 0.2.10 fixed a memory leak when using control transfers.

Snapshot 20170617 delivered Mesa 17.1.2 providing fixes for a build failure in GNOME Continuous and a Chromium memory leak. Ethtool 4.11 added new features to support configurable RSS hash functionality and configurable text editor vim 8.0.627 provided a lengthy list of fixes with its newest version. The snapshot also brought Tumbleweed users three-days of the 4.11.5 Kernel before updating to the 4.11.6 kernel in  the 20170620 snapshot.

KDE desktop users received Plasma 5.10.2 in snapshot 20170616; the bugfix update made the PackageKit backend more resistant to crashes in PackageKit and the Plasma Networkmanager Openconnect made sure the User Interface fits into the password dialog. Build process manager cmake 3.8.2 fix debugging of C++ executables if CSharp is enabled.

Snapshot 20170615 updated the rest of KDE Applications 17.04.2 and snapshot 20170613 updated everything Qt to version 5.9, which added several new features including the addition of an OpenVG backend for Qt Quick.

Wednesday
21 June, 2017

Michael Meeks: 2017-06-21 Wednesday.

@ 11:51 UTCmember

face
  • Mail chew; massaged priorities. Thrilled to see the great work from the team ship in Collabora Online 2.1.2 with avatars, and various other UI features; well worth an upgrade.

Tuesday
20 June, 2017

Michael Meeks: 2017-06-20 Tuesday.

@ 21:00 UTCmember

face
  • Consultancy call, mail chew, built ESC agenda. Lunch. Commercial call; super hot - and 3x active building sites two next-door, and one across the road: wow.
  • Worked lateish and got my hash to wire-id conversion working nicely in online; more efficient and more readable.

Monday
19 June, 2017

Michael Meeks: 2017-06-19 Monday.

@ 21:00 UTCmember

face
  • Mail chew, aborted team meeting; patch review, prodded leads. Lunch. Dug through older E-mail looking for gems. Partner call. Finally got around to de-bonging the online / slideshow unit test. Poked at a particularly fun unit test deadlock for good measure. Tried to unwind what is the same DNS lookup issue as this with unpleasant BT Home Hub. TDF board call.

openSUSE News: Website About People of openSUSE Ends Hiatus

@ 12:08 UTC

face

Interviews with people involved in the openSUSE Project have returned and new pages will be added in the future highlighting individuals involved in the community project.

The first interview to be posted after a five-year hiatus was posted in November of 2016 and highlights Dominique Leuenberger, who is at VLC contributor and release manager for openSUSE Tumbleweed.

Sarah Julia Kriesch, who is a Working Student at ownCloud and member of the Heroes team at openSUSE, discusses in an interview in published in March how she got started with Linux and openSUSE.

The most recent interview published is from Leap release manager Ludwig Nussel, who is a volunteer for a fire brigade in Germany.

The website has interviews dating back at 2007; when many people involved in the project had less grey hair;-). Current interviews focus on newer project members. Interviews include many people involved in the project who participate and contribute to many other open-source projects like Linux kernel developer and Tumbleweed originator Greg Kroah-Hartman, former openSUSE Release Manager and KDE Release Coordinator Stephan Kulow and more.

Michal Čihař: Call for Weblate translations

@ 04:00 UTC

face

Weblate 2.15 is almost ready (I expect no further code changes), so it's really great time to contribute to it's translations! Weblate 2.15 should be released early next week.

As you might expect, Weblate is translated using Weblate, so the contributions should be really easy. In case there is something unclear, you can look into Weblate documentation.

I'd especially like to see improvements in the Italian translation which was one of the first in Weblate beginnings, but hasn't received much love in past years.

Filed under: Debian English SUSE Weblate

Sunday
18 June, 2017

Michael Meeks: 2017-06-18 Sunday.

@ 21:00 UTCmember

face
  • Birthday - 40th' today; a fine clutch of presents over a continental breakfast to enjoy with the family - they're such a blessing.
  • Out to Louth Evangelical Church, good talk on Jesus' teaching's power to amaze & convict people from Mark 1:21-27 from Mark Plumb visiting from Huntingdon. Home for pizza lunch & more Spa'ing.
  • Drove home; un-packed, stories for babes; movie, sleep.

Christian Boltz: Packaging MediaWiki extensions

@ 20:46 UTCmember

face

As part of the work for the openSUSE wiki upgrade and move, I had to package a bunch of MediaWiki extensions. We'll use the MediaWiki 1.27.x LTS release, which means the extensions need to work with this version.

When it comes to packaging, there are three categories of extensions:

The Good

These extensions are hosted on phabricator.wikimedia.org, and you can easily download a tarball matching your MediaWiki version using the "Download snapshot" link on the extension page.

Packaging these extensions is easy - just unpack the tarball and copy/package everything to the extension directory.

These extensions are standardized enough to use a spec file template - usually I only had to adjust the extension name, tarball name and version. Speaking of the version - most extensions don't have explicit version numbers, so I decided to use the tarball date instead.

An example for this category is Auth_remoteuser (extension page, package) which we use to keep the "nice" wiki login form.

The Bad

These extensions are hosted on GitHub and typically only have a "master" branch. They usually still work with MediaWiki 1.27.x, but there's a small risk that they require features added in newer MediaWiki versions, and this risk will grow over time.

On the packaging side, they are as easy as the "good" extensions.

An example is the ParamProcessor extension (extension page, package) which is needed by the Maps extension

The Ugly

These extensions can be hosted on phabricator.mediawiki.org or GitHub, so there are "god ugly" and "bad ugly" extensions ;-) The thing that makes packaging really ugly is that they don't include all the code they need. Instead, you have to download the missing parts with composer.

composer works fine in a "real" system, but makes packaging hard. Running it from the spec will obviously fail because OBS doesn't allow network connections while building a package (and even if it's annoying in this case, not having network access during build is a good thing[tm]).

My solution is a little script that unpacks the extension tarball and runs "composer install --no-dev" inside the extension directory. The most important part is the "--no-dev" parameter because that avoids lots of superfluous things. Afterwards, I build a tarball from the "vendor" directory and add it to the package.

Yeah, I know that's not nice - guess why I named this section "The Ugly" ;-)

One of the packages that need a "composer install" run is the GitHub extension (extension page, package including script to run composer).

Luckily, "ugly" only applies to packaging. The extensions and their maintainers are for sure not ugly - for example, the maintainer of the GitHub extension was very fast in fixing a bug :-)

Michal Čihař: New projects on Hosted Weblate

@ 09:00 UTC

face

Hosted Weblate provides also free hosting for free software projects. The hosting requests queue was over one month long, so it's time to process it and include new project.

This time, the newly hosted projects include:

We now also host few new Minetest mods:

If you want to support this effort, please donate to Weblate, especially recurring donations are welcome to make this service alive. You can do them on Liberapay or Bountysource.

Filed under: Debian English SUSE Weblate

Saturday
17 June, 2017

Michael Meeks: 2017-06-17 Saturday.

@ 21:00 UTCmember

face
  • Up earlyish, out for a walk through the countryside around Louth; with the family - lovely; picnic lunch in a field. Back for a long swim together at the lodge Spa; lovely. Fine steak dinner, bed.

Friday
16 June, 2017

Michael Meeks: Link

@ 21:00 UTCmember

face

2017-06-16 Friday.

  • Out for a run with J. mail chew, mail chew; calls with Miklos & Kendy; lunch. Set off to the Lincolnshire Wolds in the early afternoon with the babes; picked up H. and N. on the way, worked in the car. Arrived, meal, watched some Black-Mirror, bed.

YaST Team: Highlights of YaST development sprint 36

@ 12:50 UTC

face

We are still digesting all the great content and conversations from openSUSE Conference 2017, but the development machine never stops, so here we are with the report of our post-conference sprint.

Storage reimplementation: expert partitioner

You have been reading for months about the new stack for managing storage devices and the new features and improvements it will bring to the installation. But so far there was no way to view and fine-tune the details of those devices. During this sprint we have implemented a first prototype of the new version of the YaST2 Expert Partitioner, that awesome tool you can invoke with yast2 storage.

To make the transition easier and to be able to submit it to Tumbleweed as soon as possible (hopefully in a couple of months, together with the rest of the new stack) we decided to postpone any UI redesign. So this first incarnation of the new expert partitioner looks and behaves exactly like the one available in current versions of (open)SUSE.

To try it out (on a scratch machine!), add a repository and remove the current storage library, as described in yast-storage-ng: Trying on Running System and then run zypper install yast2-partitioner. As you may have noticed, we split the partitioner in a separate package, unlike the current version that was part of the basic yast2-storage.

The new expert partitioner will only give you a read-only view of things similar to the following screenshots, not being able to modify anything yet.

New expert partitioner - hard disks list

As you can see in your own system or in the screenshots, the following items are already functional

  • Hard disks and their partitions
  • Volume Groups, Logical Volumes, and Physical Volumes of the Logical Volume Manager (LVM)

The other kinds of devices that you can see in the navigation tree are so far only stubs.

New Expert Partitioner - logical volume overview

You may feel a bit underwhelmed by this, and that’s OK, because most of the effort that we spent on this is actually hidden in a set of nice UI classes which we use to reconstruct the legacy procedural UI code. So the new expert partitioner not only relies on the revamped storage stack, but also on a powerful and reusable set of shiny UI components. If you ever need to code a user interface for YaST, the next section is for you.

New Expert Partitioner - list of physical volumes

New CWM Widgets

This section may be a little bit too developer-oriented, so feel free to skip it if you don’t care about the YaST implementation details. If, to the contrary, you want to have a glance at the new YaST widgets, go ahead.

Before diving into the new widgets, let us introduce what CWM is. It stands for Common Widget Manipulation and it is an old procedural YaST module which puts together a widget, its help and its callbacks. These callbacks are used to initialize, validate and store the content of the widget. This organization allows easier re-usability of widgets, which are then put together into a dialog. We also made an object-oriented version …

read more

Dominique Leuenberger: Review of the weeks 2017/23 & 24

@ 12:00 UTCmember

face

Dear Tumbleweed users and hackers,

It’s said that time flies when one is busy – so what does that mean in the context of Tumbleweed? We must be skipping entire periods. The last two weeks have seen 10 snapshots being published, which is a clear indication that our community IS busy bringing you all the nice updates you wish for. I will cover the snapshots 0602, 0604, 0605, 0607, 0608, 0609, 0610, 0612, 0613 and 0615. 0615 passed openQA and is currently in progress of syncing out, mirrors should deliver it shortly.

What did those snapshots all bring you?

  • QEmu 2.9.0
  • KDE Plasma 5.10.1
  • KDE Applications 17.04.2
  • Linux Kernel 4.11.4
  • Qt 5.9.0
  • GO 1.8 is available, in parallel to version 1.7

And some more things are coming your way – larger and smaller changes, some keeping developers busy for long nights:

  • systemd 233
  • KDE Frameworks 5.35.0
  • GStreamer 1.12.0 – expect this soon now!
  • OpenSSL 1.1 as default
  • LibreOffice 5.4
  • Linux Kernel 4.11.5

If there are any areas you wish to work with the community, don’t be shy, speak up and help you get started. Besides the feeling of helping the community, it can also be a great learning experience.

Thursday
15 June, 2017

Michael Meeks: 2017-06-15 Thursday.

@ 21:00 UTCmember

face
  • Mail chew; disappointed to see Tim Farron stand down from the Lib-Dems: "... we are kidding ourselves if we think we yet live in a tolerant, liberal society." Shame on those lazy interviewers who attack the man not the policies.
  • Back to poking at calc formula iteration; Tor fixed the problem; nice.

Wednesday
14 June, 2017

Michael Meeks: 2017-06-14 Wednesday.

@ 21:00 UTCmember

face
  • E's birthday - present opening at breakfast, so lovely. Mail chew, re-built master, admin - lots of it. Plugged away at Calc, and at online in the evening.

openSUSE News: KDE Applications 17.04.2 Arrives in Tumbleweed

@ 12:29 UTC

face

KDE Applications 17.04.2 is now available to openSUSE Tumbleweed users after arriving in the most recent snapshot of the five snapshots delivered this week.

Snapshot 20170612 is the largest snapshot of the week and centers mostly on fixing bugs and adding patches. GNOME’s Bijiben upgraded to version 3.24.0 and fixed a memory leak as well as cleaned-up some code. The library used mainly by GTK and GNOME Application, glibmm2_4 moved to version 2.50.1 and also fixed a memory leak. Other libraries updated in the snapshot were the portable renderer for Advanced Substation Alpha/Substation Alpha libass 0.13.7, emulation/playback library for video games and music libgme 0.6.1, and the machine learning software library opencv 3.2.0. The update to Linux Kernel 4.11.4 deleted several patches, including one for IPv6 and X11 package xlockmore 5.54, which fixed the xmb fonts and xjack mode. Yast2-trans removed obsolete Portable Object Template files and enhanced translations through the use of Weblate.

KDE bug fixes in version 5.10.1 took center stage in the 20170610 snapshot. However, photography professionals will find the release of libgphoto2 2.5.14 adding more support for Fuji, Sony, Canon and Nikon cameras. An update in the snapshot to xfsprogs 4.9.0 from 4.5.0 added numerous fixes and support for the administration and debugging tools for the XFS file system.

Snapshot 20170609 updated a just few library functions for date calculations like perl-Date-Manip 6.59, perl-DateTime-Locale 1.160000, and perl-DateTime-TimeZone 2.13.

Software development studio Anjuta added a patch to build with GNU Compiler Collection 7 in snapshot 20170608 and xkeyboard-config 2.21 updated the A Programming Language and extended backslash keyboard layout for Slovak. Spec-cleaner had in update in both the 20170608 and 20170612 snapshots, which fixed a parsing that crashed the app on execution.

Git was updated to version 2.13.1, which provided corrections to documentation and command help output, in snapshot 20170607. There were also several updates for YaST with yast2-storage 3.2.14, yast2-network 3.2.28 and yast2-installation 3.2.44, which fixed the path to the “adddir” command.

Sankar P: golang range Tickers

@ 05:43 UTCmember

face
Update: Please use the playground/gist urls for reading code. Blogger's code formatting is terrible and does not support embedding gists either.

Yesterday Praveen sent me an interesting piece of golang code. Read the following code and tell what the answer will be:

===
type LED struct {
state  bool
ticker *time.Ticker
}

func toggle(led *LED) {
led.state = !led.state
}

func looper(led *LED) {
for range led.ticker.C {
toggle(led)
}
}

func main() {

fmt.Println("Initial number of GoRoutines: ", runtime.NumGoroutine())

led := &LED{state: true, ticker: time.NewTicker(time.Millisecond * 500)}
go looper(led)
fmt.Println("Number of GoRoutines after a call to looper: ", runtime.NumGoroutine())

time.Sleep(2 * time.Second)

led.ticker.Stop()
fmt.Println("Number of GoRoutines after stopping the ticker: ", runtime.NumGoroutine())

runtime.GC()
fmt.Println("Number of GoRoutines after gc: ", runtime.NumGoroutine())

}
===


Golang playground URL: https://play.golang.org/p/1as5QN1r2c
Gist URL: https://gist.github.com/psankar/8af76ba183b0203ec141bca8156f5955

I will explain roughly what the code is doing.

There is a LED struct which has a Ticker and a state variable. While creating an instance of the led struct, we initialise the state and the Ticker.  There is a looper function will toggle the state, whenever the Ticker fires an event.

Now when the program is launched, there will be one goroutine (the initial main thread). After we call looper in a goroutine, the goroutineCount will be 2. Now, comes the tricky part. We stop the Ticker, after a particular amount of time. We even call the gc.

It was observed by Praveen that this piece of code was leaking go routines and the number of go routines was never going down, inspite of the Ticker getting stopped.

The reason why the leakage is happening is because, the "range" loop is never exiting. If the range loop was on a channel, you could "close" it. The ticker.C channel however is a receive only channel and you cannot close it.

How do we fix this, so that none of the goroutines are leaking ? If you have watched the talks, golang concurrency patterns by Rob Pike and Advanced golang concurrency patterns by Sameer Ajmani, then you will realise that it is quite easy to add another parameter to the looper function, which could just exit the loop. So the updated code will be:

===
type LED struct {
state  bool
ticker *time.Ticker
}

func toggle(led *LED) {
led.state = !led.state
}

func looper(led *LED) {
for range led.ticker.C {
toggle(led)
}
}

func looper2(led *LED, q chan bool) {
for {
select {
case <-led.ticker.C:
toggle(led)
case <-q:
fmt.Println("Exiting the goroutine")
return
}
}
}

func main() {

fmt.Println("Initial number of GoRoutines: ", runtime.NumGoroutine())

led := &LED{state: true, ticker: time.NewTicker(time.Millisecond * 500)}
q := make(chan bool)
go looper2(led, q)
// go looper(led)
fmt.Println("Number of GoRoutines after a call to looper: ", runtime.NumGoroutine())

time.Sleep(2 * time.Second)

led.ticker.Stop()
fmt.Println("Number of GoRoutines after stopping the ticker: ", runtime.NumGoroutine())

q <- true …
read more

Nathan Wolf: openSUSE Tumbleweed on Dell Latitude E6440

@ 02:21 UTCmember

face

I needed a new computer and generally don't like getting new things. I'm not a very good consumer (unless I'm buying food, I love food) but I really needed a new laptop to replace my beloved, tried and true yet aging, Dell Latitude D630. It has been a great machine but has been come to the end of its service life. There is only so much you can do to a machine of nearly 10 years to keep it current and some of the surprise battery failures really chapped my hide.

I was very specific about the machine I wanted as my replacement. My minimum, must have requirements for this machine was, dock station capability, built in Smart Card reader, 1080p screen, a removable media bay and in a 14" platform. Certainly, this is not a popular setup for most but it is what I very much require. The machine that fit the bill was the Dell Latitude E6440. I realize, this is not a new machine, I believe they were discontinued in 2016 but it is just the right age for me as there will be no hardware surprises.

Preparing the Installation

I didn't have to do much here. The only task I was interested in doing was to have all the necessary updates, specifically the firmware and the like from Dell completed before I killed Windows 7. Primarily, I wanted to ensure that I wouldn't fiddle around with updates after I switched it to Linux.

After the firmware updates from Dell, I reset the machine and went into the BIOS to deactivate the secure boot and put it in legacy mode. My understanding is that it is no longer a necessary step but I didn't want to fiddle with it.

Installing openSUSE Tumbleweed

For most cases Leap is probably the choice I would make for most people. It is an "enterprise hardened" distribution that is super rock solid. I also have a desire to do more when it comes to testing and development, etc. I really wanted more up to date packages and I really wanted to kick the tires on a rolling release to see how it works for me. I had an expectation of stability issues and some reservation on whether or not this would be good enough for my personal "multi-tool" rig. Leap has been great but it was time to see how this rolling release would work for me.

Specifications (That Matter)

I don't typically stay on the cutting edge of technology as I don't want to bleed to death but I had some very specific requirements based on my experience with my previous primary machine. There were some features lacking that I really wanted and some features that I didn't want to give up.

These were my requirements. 14" chassis, 1920x1080 screen resolution, AMD GPU, Smart Card reader, back-lit keyboard, removable media bay, dock station capability, built in web cam and SD Card slot …
read more

Tuesday
13 June, 2017

Michael Meeks: 2017-06-13 Tuesday.

@ 21:00 UTCmember

face
  • Patch review, built ESC agenda. Plugged away at some calc pieces with Tor, commercial call, partner call & two customer calls. Visited a friend in the evening for some advice.

Frédéric Crozat: Synology PhotoStation password vulnerability

@ 14:36 UTCmember

face

On Synology NAS, synophoto_dsm_user executable, part of PhotoStation package, was leaking NAS user password on the command line.

Using a simple shell loop to run "ps ax | grep synophoto_dsm_user", it was possible to get user and password credentials for user on the NAS who had PhotoStation enabled with their DSM credentials.

Fortunately, by default, shell access on the NAS is not available (by ssh or telnet), it has to be enabled by the admin.

Still, it is a bad practise to pass credentials to process using command line, which can be intercepted.

PhotoStation version 6.7.1-3419 or earlier is vulnerable. I've contacted Synology and they should release a security fix really shortly, as well as a CVE for it.

Update (June 13, 2017): Synology has released a CVE and the vulnerability is fixed in PhotoStation 6.7.2-3429 or later. Remember to update this package on your NAS !

Monday
12 June, 2017

Michael Meeks: 2017-06-12 Monday.

@ 21:00 UTCmember

face
  • Mail chew, a trio of team calls; partner call in the evening.

Joe Shaw: Don’t defer Close() on writable files

@ 12:00 UTC

face

Update: Another approach suggested by the inimitable Ben Johnson has been added to the end of the post.

Update 2: Discussion about fsync() added to the end of the post.

It’s an idiom that quickly becomes rote to Go programmers: whenever you conjure up a value that implements the io.Closer interface, after checking for errors you immediately defer its Close() method. You see this most often when making HTTP requests:

resp, err := http.Get("https://joeshaw.org")
if err != nil {
    return err
}
defer resp.Body.Close()

or opening files:

f, err := os.Open("/home/joeshaw/notes.txt")
if err != nil {
    return err
}
defer f.Close()

But this idiom is actually harmful for writable files because deferring a function call ignores its return value, and the Close() method can return errors. For writable files, Go programmers should avoid the defer idiom or very infrequent, maddening bugs will occur.

Why would you get an error from Close() but not an earlier Write() call? To answer that we need to take a brief, high-level detour into the area of computer architecture.

Generally speaking, as you move outside and away from your CPU, actions get orders of magnitude slower. Writing to a CPU register is very fast. Accessing system RAM is quite slow in comparison. Doing I/O on disks or networks is an eternity.

If every Write() call committed the data to the disk synchronously, the performance of our systems would be unusably slow. While synchronous writes are very important for certain types of software (like databases), most of the time it’s overkill.

The pathological case is writing to a file one byte at a time. Hard drives – brutish, mechanical devices – need to physically move a magnetic head to the position on the platter and possibly wait for a full platter revolution before the data could be persisted. SSDs, which store data in blocks and have a finite number of write cycles for each block, would quickly burn out as blocks are repeatedly written and overwritten.

Fortunately this doesn’t happen because multiple layers within hardware and software implement caching and write buffering. When you call Write(), your data is not immediately being written to media. The operating system, storage controllers and the media itself are all buffering the data in order to batch smaller writes together, organizing the data optimally for storage on the medium, and deciding when best to commit it. This turns our writes from slow, blocking synchronous operations to quick, asynchronous operations that don’t directly touch the much slower I/O device. Writing a byte at a time is never the most efficient thing to do, but at least we are not wearing out our hardware if we do it.

Of course, the bytes do have to be committed to disk at some point. The operating system knows that when we close a file, we are finished with it and no subsequent write operations are going to happen. It also knows that closing the file …

read more

Open Build Service: Highlights of the OBS frontend development sprint 17

@ 00:00 UTC

face

We are back! Since we were preparing for OSC17 we had a little break and suspended our SCRUM sprint for one week. Now we are back! And this is what we have accomplished in sprint 17 (2017-05-29 to 2017-06-09). Deployments It's been a month now, since we started to deploy the rails frontend more frequently. On some days we now deploy multiple times a day. Since this is quite different from what we did before...

Sunday
11 June, 2017

Michael Meeks: 2017-06-11 Sunday.

@ 21:00 UTCmember

face
  • NCC in the morning; some disappointing suggestions. Home for lunch in the garden; tried to get Unreal Editor working nicely with the Vive for H. crimped some ethernet cables, tried to get the editor UI to work at all; eventually managed to find the documentation on how to use it.

Saturday
10 June, 2017

Michael Meeks: 2017-06-10 Saturday.

@ 21:00 UTCmember

face
  • Up early, contract review in the early morning; setup the Vive for E's friend to play with; J. out to funeral parlour to do bereavement counselling. Lunch, out to studlands park green for a family fun-day with M. & E. - lazed in the sun.
  • Home for tea with Kiaran & Amy & Julie-Anne, lovely to catch up with them.

Friday
09 June, 2017

Michael Meeks: 2017-06-09 Friday.

@ 21:00 UTCmember

face
  • Packed H. off for DofE expedition, mail, got used to the idea of weak and unstable Government for a while - and moved on.
  • Chewed through admin quickly, worked on making tile hashes more comprehensible and smaller on the wire. Partner calls. E's birthday party, caught up with Marina, E's friend over for the night.

Older blog entries ->

© 2010 Pascal Bleser and the openSUSE Community.

This site is not an official openSUSE website, and is not in any way affiliated with or endorsed by SUSE Linux GmbH or Novell.

openSUSE and SUSE are trademarks of Novell, Inc. in the United States and other countries.