Language Selection

English French German Italian Portuguese Spanish

Ubuntu: Needs more QA

Filed under

I have been using Ubuntu extensively since 5.10. There are a lot of things I like about it, however here I will spend a few words about one thing that can definitively be improved: Quality Assurance. There are plenty of example of applications that are generally working but shows some bugs that are long since waiting to be fixed. Some are present in all releases, other in only the latests. I am not talking about minor bugs either. Here some:

  • ACPI (resume, suspend) is half-broken in many Centrino based laptops, which resume/suspend only at rare times. Very well documented bug, present in Edgy. People trying out Ubuntu on their new laptop are upsettly turned off by this.
  • System freeze when using ATI radeon 7000. It affects both Dapper and Edgy. A fix for Edgy is available, no sign for one in Dapper. Considering that Dapper offers Long Time Support, I would expect this bug to be fixed by now (it's been around since early 2005). Instead if you need a long time supported release and you use this graphic card (like my Poweredge server), Dapper just doesn't work. Nice.
  • VNC server 4 does not work in edgy. It is waiting for a trivial patch to be made upstream. While it works in Dapper, because of the change in fonts location in Edgy, it is badly broken in Edgy. For people using this tool to control remote machines we have to rely on older and slower versions of VNC.

You may say that those are really minor bugs, and I may agree. However they show not a great deal of care in quality assurance. Lots of resources are spent in improving the user interface, which is a good thing. However I often have the feeling that Canonical is going after new features, without spending too much time producing a really solid
release. I am not talking about exotic hardware, but pretty strightforward mainstream machines.
Am I wrong?

More in Tux Machines

today's howtos

Why Everyone should know vim

Vim is an improved version of Vi, a known text editor available by default in UNIX distributions. Another alternative for modal editors is Emacs but they’re so different that I kind of feel they serve different purposes. Both are great, regardless. I don’t feel vim is necessarily a geeky kind of taste or not. Vim introduced modal editing to me and that has changed my life, really. If you have ever tried vim, you may have noticed you have to press “I” or “A” (lower case) to start writing (note: I’m aware there are more ways to start editing but the purpose is not to cover Vim’s functionalities.). The fun part starts once you realize you can associate Insert and Append commands to something. And then editing text is like thinking of what you want the computer to show on the computer instead of struggling where you at before writing. The same goes for other commands which are easily converted to mnemonics and this is what helped getting comfortable with Vim. Note that Emacs does not have this kind of keybindings but they do have a Vim-like mode - Evil (Extensive Vi Layer). More often than not, I just need to think of what I want to accomplish and type the first letters. Like Replace, Visual, Delete, and so on. It is a modal editor after all, meaning it has modes for everything. This is also what increases my productivity when writing files. I just think of my intentions and Vim does the things for me. Read more

Graphics: Intel and Mesa 18.1 RC1 Released

  • Intel 2018Q1 Graphics Stack Recipe
    Last week Intel's Open-Source Technology Center released their latest quarterly "graphics stack recipe" for the Linux desktop. The Intel Graphics Stack Recipe is the company's recommended configuration for an optimal and supported open-source graphics driver experience for their Intel HD/UHD/Iris Graphics found on Intel processors.
  • Mesa 18.1-RC1 Released With The Latest Open-Source 3D Driver Features
    Seemingly flying under our radar is that Mesa 18.1 has already been branched and the first release candidate issued. While the Mesa website hasn't yet been updated for the 18.1 details, Dylan Baker appears to be the release manager for the 18.1 series -- the second quarter of 2018 release stream.

Exploring Contributors Centrality Over Time

At the end of my previous post we concluded with yet another question. Indeed, on the 2017 KDEPIM contributor network we found out that Christian Mollekopf while being a very consistent committer didn't appear as centrality as we would expect. Yet from the topology he seemed to act as a bridge between the core contributors and contributors with a very low centrality. This time we'll try to look into this and figure out what might be going on. My first attempt at this was to try to look into the contributor network on a different time period and see how it goes. If we take two snapshots of the network for the two semesters of 2017, how would it look? Well, easy to do with my current scripts so let's see! Read more