Many Linux users will guiltily admit to multi-booting, where they have partitioned their hard-drive, so that as well as having Linux installed in one partition, they have the Windows system their laptop came with installed on another.

The usual reason for this is software that will not run on Linux. This is usually computer games, as most software has a simple enough function that its use-cases can be broken down, and a linux compatible alternative written; or its system requirements aren't sufficiently demanding to prevent either the system libraries being emulated with Wine, or the whole machine being emulated with a Virtual Machine.

This is however, becoming increasingly unnecessary.

Playing games for Windows with Wine and PlayOnLinux

Playing games with Wine is usually just a case of running wine on the installer, then wine on the program launcher binary.

However, you may need to track down missing libraries, or perhaps there's bugs which mean you need a very specific version of Wine for it to work.

PlayOnLinux attempts to solve this problem with a wineprefix, which is somewhat like a chroot for an emulated Windows environment, per game.

It also includes instructions to try and make installing games easier.

Optimal graphics performance for laptops with Optimus chipsets

Laptops need to make some sacrifices for power efficiency. One attempt to supply both battery life and performance on some laptops is to have a hybrid graphics card, with a lower power Intel graphics card and a higher power Nvidia card. The Nvidia Optimus chipset is such a beast, and is commonly available on laptops.

Because computer programmers are clever sods who like their puns, the way to handle this on Linux is program called bumblebee. To run a program with the Nvidia graphics card instead of the default, power-saving graphics card, prefix the command with the optirun command.

Native Steam client

Steam, the content delivery platform, has a wide range of games for Linux, and while they only natively support Ubuntu and SteamOS, you can find instructions on how to make it work on a wide variety of distributions.

You can enable Optimus support in steam games by following instructions from Steam's knowledgebase, though you may choose to use optirun rather than primusrun.

Open Source games

There's also games that were previously proprietary, but the game engine has been released, or games written entirely from scratch to be open.

Some which I have enjoyed in the past are: Battle for Wesnoth, The Freespace 2 Source Code Project, the venerable Quake, Warzone 2100 and Xonotic.

While a significant portion of development on FOSS projects is undertaken by volunteers hacking on their free time, the majority, at least on high profile projects like the Linux Kernel is undertaken by organisations to further their own agendas.

Why do organisations contribute to FOSS projects?

Any organisation may make use of a FOSS project, provided they comply with the licence terms. This is appealing for organisations as there is often a FOSS project that does approximately, if not completely, what is required.

Organisations may make changes to make the software suit their purposes better, and they do so freely, providing that they comply with the licence terms.

No FOSS licence requires that organisations contribute their changes directly back to the upstream project, and if an organisation is only making a one-off product and there are no ongoing updates required, then there is no compelling need to contribute the changes upstream.

However, this is an unlikely situation; the success of one product can imply a future product line, and all our gadgets are increasingly connected, so security updates are an essential feature.

Both the case of new products and the case of updating existing products for security or functionality reasons imply the need to use a newer version of any FOSS project used in the product. Since projects change over time to adapt to the needs of their users, and it is a relatively safe assumption that there's an overlap between the needs of the users of the FOSS project, and the users of any given product.

If an organisation chooses to use a new version of a FOSS project than previously used, they will need to port any locally held changes to the new version. This becomes harder the more that the 'upstream' FOSS project has changed relative to the last time the organisation updated. So it becomes more sensible, both from a cost and an efficiency point of view, to 'upstream' any changes so that they are included in the FOSS project, so that there is no need to port the changes or make equivalent changes all over again.

As an added benefit, working as early as possible with the 'upstream' on a change ensures that those responsible for the FOSS project can say whether it is a reasonable approach, as they likely have expert knowledge of the domain.

We spoke in an earlier article about why organisations that use FOSS projects might choose to contribute any changes they make back upstream.

If you become involved in such a situation, there are a few things to consider. The requirements vary between projects, but there are a few general things to keep in mind.

Your code is not a gift, it is a burden.

Unless both you and the maintainer of the FOSS project happen to want a feature that the maintainer of the FOSS project simply hasn't gotten around to implementing yet, your code is an unwelcome increase to their maintenance burden.

Adding a feature is adding more code that may have bugs hiding in it, more code to compile, more code to test, more code to distribute in releases, more code to change when requirements inevitably change etc.

Nobody likes surprise code.

Make yourself known to upstream.

Let them know what you intend to change, along with your reasoning and your goals where possible. Upstream maintainers can possibly tell you about better ways to make the change; if the relevant part of the code is going to be changed by someone else soon then you would get to know whether you need to throw all your changes away in a week, or even if they won't accept such a change and suggest an alternative.

When the time comes to submit patches it will have been a collaborative effort, so nobody will be surprised, and upstream will be pre-disposed to considering your code for inclusion.

Particularly, it gives some confidence that you will be around, to ask questions of, should bugs be found.

Build up some good will.

Your aim should always be: to have a net positive benefit to the project.

A feature every project wants is simply to be "Not buggy", so if in the process of adding your required feature, you find and fix some bugs, then the rest of your patches are much more welcome.

If a project has a TODO list, then doing a few items on it is also valuable, since it shows an awareness of the needs of the project in line with your own needs.

Continue to participate.

Code needs to change, and it helps if you can continue to test the changes you contributed.

A test suite including test cases greatly helps reduce the maintenance burden, but if the interface changes sufficiently, then the tests may need to change, so it helps if you are around to be asked if it still works for you.

If you are not actively participating in a project's community, then you could find your code removed simply due to a lack of support.

If you are successful in interacting with upstream then you have benefitted by having your code included, and so upstream continues to support your desired feature in all its future versions.

As an added benefit you may have some amount of say in the future direction of the project. Furthermore if you found yourself needing to change the project for one reason, then you may find yourself needing to make further changes for another. After the first hurdle, future changes are easier.

From a personal development point of view, participating properly grants both some job security and an increase in your marketability, since this relationship with a FOSS project has value for an organisation which wishes to make changes.

systemd has a service for managing user sessions called logind(8), this replaces the existing ConsoleKit tool, which was the previous cross-desktop and cross-distribution tool.

This caused some controversy, as logind(8) is not usable without systemd, and the fear was that this would cause distributions to force the use of systemd.

There was some misplaced anger at both the systemd developers and the GNOME developers, when the GNOME package maintainers in Debian decided to build GNOME without ConsoleKit support, as GNOME still supported being built with ConsoleKit, and the systemd developers are not responsible for other developers' decisions to support logind(8) exclusively.

So, controversy aside, what does logind(8) provide to us?

User session management

logind(8) tracks user log-ins and keeps track of which processes are used, by use of a pam_systemd PAM module, so that processes can be cleaned up when a user logs out, or the user is forced to log out, such as when the administrator needs to perform maintainance, or the user is no longer permitted to use the server.

There's little to no configuration needed by users for this aspect of logind(8), but if a user should be allowed to run processes after they log out, such as if they run a screen(1) session, then this can be allowed by using loginctl(1) to run loginctl enable-linger $USER.

Seat assignment

It's common these days for everybody to have their own computer, and the only shared computers are servers, which you interact with via your local comptuer, over a network.

However, back in the day, it was more common for there to be 1 computer shared directly to multiple users, each with their own physical terminal.

Personal computing has made shared machines with multiple terminals mostly unnecessary, but there's still a few uses, such as kiosks, internet cafes, or classrooms, where it would be more cost efficient to have people sharing the computer.

To make this work, systemd supports Multiseat configuration, by assigning multiple physical devices, such as a display, a keyboard and a mouse, to different seats.

Some hardware is automatically configured as a separate seat, but hardware can be explicitly assigned to a seat if these automatic rules are incorrect, by using loginctl attach SEAT DEVICE_PATH.

Hardware sleep

If your computer is battery powered you may want the machine to go to sleep when idle to save power, or you may want to block a system reboot while performing crucial operations, like a system update.

To handle this, logind(8) allows you to take an inhibit lock, which is implemented with file descriptor passing, so a crashing process will automatically release it.

To use an inhibitor lock, either run a command with the systemd-inhibit(1) wrapper command, or request a file descriptor with the logind D-Bus interface.