What is OpenSUSE Tumbleweed?

OpenSUSE Tumbleweed is a cutting-edge Linux distribution from the OpenSUSE team. It uses the latest versions of software applications and the Linux kernel for those who want to see what will be coming up in other Linux distributions in 6-months to a year or more from the time that they appear in Tumbleweed. This means that there are bugs; lots of them. Things break, This is the price that you pay for having the very cutting edge or software technology.

What did Bryan Lunduke actually say?

Let’s break down his complaints. There are only two.

• SUSE Studio
• YaST (ugly, cumbersome, hard to use, stupid, bloated)

The first complaint is an application stack that doesn’t actually have anything directly to do with Tumbleweed. I never used it. It was going by the wayside when I started using OpenSUSE as my daily OS of choice. The source code is still out there and maybe it should be forked and brought back to life. I don’t know. I can’t argue with this point because it is a red herring and has nothing to do the OpenSUSE Tumbleweed distribution.

The second list of complaints is pretty vague, but his complaint is basically that YaST has issues that are causing it to bring does the entire distribution as a whole.

What is YaST?

YaST (Yet Another Setup Tool) is a set of system management tools that are grouped together in a single management application called YaST though they can be installed and run separately as needed.

The modules allow the user to easily control most administrative functions that might be needed. Not all of the modules are the same though. Some such as the printer and scanner modules suck. Other modules like the Software Management module are great. I consider this to be on par with Debian’s Synaptic package management tool which is freaking amazing. If unevenness in the quality of the modules is the reason why he dislikes it so much, then it’s not a completely wrong reason but it’s not a really good one either.

I say that it’s a given that some of the modules are out of date or need a fresh new rewrite, but that’s not specifically what he is saying. He keeps his complaints vague and oddly personal. I’m not privy to much of the inner-workings of the OpenSUSE distribution but I’ve seen from social media that there is some bad blood there between him and folks in OpenSUSE and I really hope this isn’t just a rant against them instead of really against the distribution.

With that aside, let’s talk about the real issue with YaST and any GUI based configuration tool. It is yet another level of abstraction away from actually working with the operating system. For example, YaST has an module called HTTP Server. If you run it, it will set up Apache and any modules like PHP for you and will give you some basic options for tuning it without actually needing to work with the command line or configuration files directly. If someone told me that they had been a system administrator for 5 years but they had only ever used YaST, I wouldn’t hire them because many times things break and they can’t be fixed with YaST. Tools like YaST should mainly be a time saver not a replacement for good configuration and I think that’s what it is currently.

Even with my own genuine complaints above, they don’t really co-inside with Bryan Lunduke’s complains (it’s ugly, cumbersome, hard to use, stupid, and bloated) because I can’t see all of that. It’s no more ugly than any other tool (besides real nerds care about function over form). Granted, some of the modules are cumbersome and hard to use, but not all of them. It’s “stupid, stupid and it’s stupid” what the heck is that supposed to mean? Use your words Lunduke! Don’t just emote. “It’s bloated.” There are currently 183 total YaST modules. Many will never be used by an end user because they are only used during installation. However if you were to install them all, it would take up 176MiB which would average out to .96MiB per module. There are some required Ruby libraries that I’m not taking into account here, but this really isn’t what I would call bloat. You can even uninstall the modules that you don’t want without causing a huge fuss.

Let’s Wrap Up

Bryan Lunduke is wrong when he says that OpenSUSE Tumbleweed is one of the worst distros out right now. He is wrong when he says that YaST is dragging down the entire distro. YaST has problems, but they aren’t what he says they are.

Usually, in my workshop I am listening to the great radio station Bayern 2 (Yeah for public law media). But sometimes you just need to listen to nice classic english punk music, speed folk or (the one and only) Lemmy and friends.

For that I was looking for a so called boom box to stream to from my mobile, simple, dirty and loud. Good that I was a proud awardee at the HiFiBerry Maker Contest 2017 with my TeakEar build, where I won a nice set of a RaspberryPi Zero with a little HiFiBerry MiniAmp, coming with all what is needed to make that working. That should be enough to get proper punk sound in the workshop - and escape the boring normal commercial boom boxes all around.

At a flee market I found a great case for that - exactly one of these that were in the classrooms of my school giving the unbanning gong at the end of each lesson. Nicely with the original non-color textile hiding the speaker and nicely done bended and veneered wood for the elegance.

A great fit for my usecase.

Two 3.3 inch Visaton fullrange speaker are mounted in simple closed chassis. The Raspi with the Amp is mounted between them. All is mounted on a back plate that fits the school speaker chassis. Boombox ready.

From a software perspective, it is there is just a Raspbian running that is configured to act as a bluetooth audio device for my mobile.

I think it is a nice addition to my workshop, with a great ease of use since it auto-connects to my mobile. Does it sound great? Oh no, not ..really. Is it loud? Well, yes, loud enough to not get in trouble with the neighbors. Given it’s size, it is actually impresse.

Surely Lemmy would be fine to play Rock’n Roll through it :)

The only downsize of the whole thing is that it disturbs the radio reception quite a bit, so it is really either or. Any hints how to reduce that?

Weblate 3.6.1 has been released today. It is a bugfix release fixing several issues reported after the 3.6 release.

Full list of changes:

• Improved handling of monolingual Xliff files.
• Fixed digest notifications in some corner cases.
• Fixed addon script error alert.
• Fixed generating MO file for monolingual PO files.
• Fixed display of uninstalled checks.
• Indicate administered projects on project listing.
• Allow update to recover from missing VCS repository.

If you are upgrading from older version, please follow our upgrading instructions.

You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Turris, FreedomBox, Weblate itself and many other projects.

Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English SUSE Weblate

A Gigglescore is a ratio score of price to performance for single-board-computers like the LattePanda or Raspberry Pi. A lower Gigglescore means a better value for the money. A higher one is worse. You can see more here: https://gigglescore.com/

My LattePanda:

sudo ./benchmark.sh 149
   Repository 'openSUSE-Leap-15.0-Non-Oss' is up to date.                                                                                                                                                               
   Repository 'openSUSE-Leap-15.0-Oss' is up to date.                                                                                                                                                                   
   Repository 'openSUSE-Leap-15.0-Update' is up to date.                                                                                                                                                                
   Repository 'openSUSE-Leap-15.0-Update-Non-Oss' is up to date.                                                                                                                                                        
   All repositories have been refreshed.
   Category5.TV SBC Benchmark v1.1
   Powered by sysbench 1.0.11
   Number of threads for this SBC: 4
   Performing CPU Benchmark… WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
   576.760 events per second. Price: Ģ930.02 per unit.
   Performing RAM Benchmark… WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
   3,625,781.466 events per second. Price: Ģ0.15 per unit.
   Performing Mutex Benchmark… WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
   6.873 events per second. Price: Ģ7.80 per unit.

Total Giggle cost of this board: Ģ1,397.58

Giggles (Ģ) are a cost comparison that takes cost and performance into account. While the figure itself is not a direct translation of a dollar value, it works the same way: A board with a lower Giggle value costs less for the performance.
 If a board has a high Giggle value, it means for its performance, it is expensive. Giggles help you determine if a board is better bang-for-the-buck, even if it has a different real-world dollar value. Total Giggle cost does not include I/O since that can be impacted by which SD card you choose. Lower Ģ is better.

Being that the suggested retail price is currently $149, we get a Gigglescore of 1,397.58. This is right between the Raspberry Pi 3 B+ and the ODROID XU4 in terms of value for the dollar.

Weblate 3.6 has been released today. It brings rewritten notifications, user data download and several other improvements. It also sets depreciation timeline for Python 2 installations - after April 2020 Weblate will only support Python 3.

Full list of changes:

• Add support for downloading user data.
• Addons are now automatically triggered upon installation.
• Improved instructions for resolving merge conflicts.
• Cleanup addon is now compatible with app store metadata translations.
• Configurable language code syntax when adding new translations.
• Warn about using Python 2 with planned termination of support in April 2020.
• Extract special chars from the source string for visual keyboard.
• Extended contributor stats to reflect both source and target counts.
• Admins and consistency addons can now add translations even if disabled for users.
• Fixed description of toggle disabling Language-Team header manipulation.
• Notify users mentioned in comments.
• Removed file format autodetection from component setup.
• Fixed generating MO file for monolingual PO files.
• Added digest notifications.
• Added support for muting component notifications.
• Added notifications for new alerts, whiteboard messages or components.
• Notifications for administered projects can now be configured.
• Improved handling of three letter language codes.

If you are upgrading from older version, please follow our upgrading instructions.

You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Turris, FreedomBox, Weblate itself and many other projects.

Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English SUSE Weblate

Traditionally, GObject implementations in C are mutable: you instantiate a GObject and then change its state via method calls. Sometimes this is expected and desired; a GtkCheckButton widget certainly can change its internal state from pressed to not pressed, for example.

Other times, objects are mutable while they are being "assembled" or "configured", and only yield a final immutable result until later. This is the case for RsvgHandle from librsvg.

Please bear with me while I write about the history of the RsvgHandle API and why it ended up with different ways of doing the same thing.

The traditional RsvgHandle API

The final purpose of an RsvgHandle is to represent an SVG document loaded in memory. Once it is loaded, the SVG document does not change, as librsvg does not support animation or creating/removing SVG elements; it is a static renderer.

However, before an RsvgHandle achieves its immutable state, it has to be loaded first. Loading can be done in two ways:

• The historical/deprecated way, using the rsvg_handle_write() and rsvg_handle_close() APIs. Plenty of code in GNOME used this write/close idiom before GLib got a good abstraction for streams; you can see another example in GdkPixbufLoader. The idea is that applications do this:

file = open a file...;
handle = rsvg_handle_new ();

while (file has more data) {
   rsvg_handle_write(handle, a bit of data);
}

rsvg_handle_close (handle);

// now the handle is fully loaded and immutable

rsvg_handle_render (handle, ...);

• The streaming way, with rsvg_handle_read_stream_sync(), which takes a GInputStream, or one of the convenience functions which take a GFile and produce a stream from it.

file = g_file_new_for_path ("/foo/bar.svg");
stream = g_file_read (file, ...);
handle = rsvg_handle_new ();

rsvg_handle_read_stream_sync (handle, stream, ...);

// now the handle is fully loaded and immutable

rsvg_handle_render (handle, ...);

A bit of history

Let's consider a few of RsvgHandle's functions.

Constructors:

• rsvg_handle_new()
• rsvg_handle_new_with_flags()

Configure the handle for loading:

• rsvg_handle_set_base_uri()
• rsvg_handle_set_base_gfile()

Deprecated loading API:

• rsvg_handle_write()
• rsvg_handle_close()

Streaming API:

• rsvg_handle_read_stream_sync()

When librsvg first acquired the concept of an RsvgHandle, it just had rsvg_handle_new() with no arguments. About 9 years later, it got rsvg_handle_new_with_flags() to allow more options, but it took another 2 years to actually add some usable flags — the first one was to configure the parsing limits in the underlying calls to libxml2.

About 3 years after RsvgHandle appeared, it got rsvg_handle_set_base_uri() to configure the "base URI" against which relative references in the SVG document get resolved. For example, if you are reading /foo/bar.svg and it contains an element like <image xlink:ref="smiley.png"/>, then librsvg needs to be able to produce the path /foo/smiley.png and that is done relative to the base URI. (The base URI is implicit when reading from a specific SVG file, but it needs to be provided when reading from an arbitrary stream that may not even come from a file.)

Initially RsvgHandle had the write/close APIs, and 8 years later it got the streaming functions once GIO appeared. Eventually the streaming API would be the preferred one, instead of just being a convenience for those brave new apps that started using GIO.

A summary of librsvg's API may be something like:

• librsvg gets written initially; it doesn't even have an RsvgHandle, and just provides a single function which takes a FILE * and renders it to a GdkPixbuf.

• That gets replaced with RsvgHandle, its single rsvg_handle_new() constructor, and the write/close API to feed it data progressively.

• GIO appears, we get the first widespread streaming APIs in GNOME, and RsvgHandle gets the ability to read from streams.

• RsvgHandle gets rsvg_handle_new_with_flags() because now apps may want to configure extra stuff for libxml2.

• When Cairo appears and librsvg is ported to it, RsvgHandle gets an extra flag so that SVGs rendered to PDF can embed image data efficiently.

It's a convoluted history, but git log -- rsvg.h makes it accessible.

Where is the mutability?

An RsvgHandle gets created, with flags or without. It's empty, and doesn't know if it will be given data with the write/close API or with the streaming API. Also, someone may call set_base_uri() on it. So, the handle must remain mutable while it is being populated with data. After that, it can say, "no more changes, I'm done".

In C, this doesn't even have a name. Everything is mutable by default all the time. This monster was the private data of RsvgHandle before it got ported to Rust:

struct RsvgHandlePrivate {
    // set during construction
    RsvgHandleFlags flags;

    // GObject-ism
    gboolean is_disposed;

    // Extra crap for a deprecated API
    RsvgSizeFunc size_func;
    gpointer user_data;
    GDestroyNotify user_data_destroy;

    // Data only used while parsing an SVG
    RsvgHandleState state;
    RsvgDefs *defs;
    guint nest_level;
    RsvgNode *currentnode;
    RsvgNode *treebase;
    GHashTable *css_props;
    RsvgSaxHandler *handler;
    int handler_nest;
    GHashTable *entities;
    xmlParserCtxtPtr ctxt;
    GError **error;
    GCancellable *cancellable;
    GInputStream *compressed_input_stream;

    // Data only used while rendering
    double dpi_x;
    double dpi_y;

    // The famous base URI, set before loading
    gchar *base_uri;
    GFile *base_gfile;

    // Some internal stuff
    gboolean in_loop;
    gboolean is_testing;
};

"Single responsibility principle"? This is a horror show. That RsvgHandlePrivate struct has all of these:

• Data only settable during construction (flags)
• Data set after construction, but which may only be set before loading (base URI)
• Highly mutable data used only during the loading stage: state machines, XML parsers, a stack of XML elements, CSS properties...
• The DPI (dots per inch) values only used during rendering.
• Assorted fields used at various stages of the handle's life.

It took a lot of refactoring to get the code to a point where it was clear that an RsvgHandle in fact has distinct stages during its lifetime, and that some of that data should only live during a particular stage. Before, everything seemed a jumble of fields, used at various unclear points in the code (for the struct listing above, I've grouped related fields together — they were somewhat shuffled in the original code!).

What would a better separation look like?

In the master branch, now librsvg has this:

/// Contains all the interior mutability for a RsvgHandle to be called
/// from the C API.
pub struct CHandle {
    dpi: Cell<Dpi>,
    load_flags: Cell<LoadFlags>,

    base_url: RefCell<Option<Url>>,
    // needed because the C api returns *const char
    base_url_cstring: RefCell<Option<CString>>,

    size_callback: RefCell<SizeCallback>,
    is_testing: Cell<bool>,
    load_state: RefCell<LoadState>,
}

Internally, that CHandle struct is now the private data of the public RsvgHandle object. Note that all of CHandle's fields are a Cell<> or RefCell<>: in Rust terms, this means that those fields allow for "interior mutability" in the CHandle struct: they can be modified after intialization.

The last field's cell, load_state, contains this type:

enum LoadState {
    Start,

    // Being loaded using the legacy write()/close() API
    Loading { buffer: Vec<u8> },

    // Fully loaded, with a Handle to an SVG document
    ClosedOk { handle: Handle },

    ClosedError,
}

A CHandle starts in the Start state, where it doesn't know if it will be loaded with a stream, or with the legacy write/close API.

If the caller uses the write/close API, the handle moves to the Loading state, which has a buffer where it accumulates the data being fed to it.

But if the caller uses the stream API, the handle tries to parse an SVG document from the stream, and it moves either to the ClosedOk state, or to the ClosedError state if there is a parse error.

Correspondingly, when using the write/close API, when the caller finally calls rsvg_handle_close(), the handle creates a stream for the buffer, parses it, and also gets either into the ClosedOk or ClosedError state.

If you look at the variant ClosedOk { handle: Handle }, it contains a fully loaded Handle inside, which right now is just a wrapper around a reference-counted Svg object:

pub struct Handle {
    svg: Rc<Svg>,
}

The reason why LoadState::ClosedOk does not contain an Rc<Svg> directly, and instead wraps it with a Handle, is that this is just the first pass at refactoring. Also, Handle contains some API-level logic which I'm not completely sure makes sense as a lower-level Svg object. We'll see.

Couldn't you move more of CHandle's fields into LoadState?

Sort of, kind of, but the public API still lets one do things like call rsvg_handle_get_base_uri() after the handle is fully loaded, even though its result will be of little value. So, the fields that hold the base_uri information are kept in the longer-lived CHandle, not in the individual variants of LoadState.

How does this look from the Rust API?

CHandle implements the public C API of librsvg. Internally, Handle implements the basic "load from stream", "get the geometry of an SVG element", and "render to a Cairo context" functionality.

This basic functionality gets exported in a cleaner way through the Rust API, discussed previously. There is no interior mutability in there at all; that API uses a builder pattern to gradually configure an SVG loader, which returns a fully loaded SvgHandle, out of which you can create a CairoRenderer.

In fact, it may be possible to refactor all of this a bit and implement CHandle directly in terms of the new Rust API: in effect, use CHandle as the "holding space" while the SVG loader gets configured, and later turned into a fully loaded SvgHandle internally.

Conclusion

The C version of RsvgHandle's private structure used to have a bunch of fields. Without knowing the code, it was hard to know that they belonged in groups, and each group corresponded roughtly to a stage in the handle's lifetime.

It took plenty of refactoring to get the fields split up cleanly in librsvg's internals. The process of refactoring RsvgHandle's fields, and ensuring that the various states of a handle are consistent, in fact exposed a few bugs where the state was not being checked appropriately. The public C API remains the same as always, but has better internal checks now.

GObject APIs tend to allow for a lot of mutability via methods that change the internal state of objects. For RsvgHandle, it was possible to change this into a single CHandle that maintains the mutable data in a contained fashion, and later translates it internally into an immutable Handle that represents a fully-loaded SVG document. This scheme ties in well with the new Rust API for librsvg, which keeps everything immutable after creation.