Language Selection

English French German Italian Portuguese Spanish

Debian

Ubuntu/Debian Leftovers

Filed under
Debian
Ubuntu

Tails 3.14.2 is out

Filed under
Security
Debian

This release is an emergency release to fix a critical security vulnerability in Tor Browser.

You should upgrade as soon as possible.

Read more

Debian vs. Ubuntu: Best Linux Distro for Laptops, Desktops, and Servers

Filed under
Debian
Ubuntu

There is a seemingly endless list of distributions to choose from if you’re interested in Linux. That said, one of the most popular distributions is Ubuntu. If you’ve heard of Linux, chances are you’ve heard of Ubuntu.

You may have heard that Ubuntu is based on another distribution, Debian. Which one should you choose? Is it a matter of preference, or is easy distribution better suited to different use cases?

Read more

Tails 3.14.1 is out

Filed under
GNU
Linux
Security
Web
Debian

This release is an emergency release to fix a critical security vulnerability in Tor Browser.

It also fixes other security vulnerabilities. You should upgrade as soon as possible.

Read more

Also: It's Time to Switch to a Privacy Browser

MX GNU/Linux, A Desktop Mix of Mepis and Antix without Systemd

Filed under
GNU
Linux
Debian

MX is an interesting desktop GNU/Linux based on Debian but without Systemd. It's powered with simple and user friendly interface thanks to XFCE Desktop. It's actually very lightweight, shipped with a lot of MX own tools (including remastering and tweaking ones), available in 32-bit and 64-bit architectures. The latest version, MX-18 "Continuum", equipped with ability to search and install Flatpak applications. Last but not least, MX exists as collaboration between two big communities, Mepis and antiX, hence the name MX since 2008 up to today. I hope you enjoy my overview below introducing several good points of MX.

Read more

Funding for GNU and Debian

Filed under
GNU
Debian
  • Paying (some) Debian developers

    In an offshoot of the Debian discussion we looked at last week, the Debian project has been discussing the idea of paying developers to work on the distribution. There is some history behind the idea, going back to the controversial Dunc-Tank initiative in 2006, but some think attitudes toward funding developers may have changed—or that a new approach might be better accepted. While it is playing out with regard to Debian right now, it is a topic that other projects have struggled with along the way—and surely will again.

    The discussion on the debian-devel mailing list about possibly recommending dh for building packages that we covered headed into a bit of a tangent on "difficult packaging practices" that might be preventing new people from contributing. From there, Andreas Tille brought up the longstanding idea of creating some kind of Debian equivalent to the Ubuntu personal package archives (PPAs). Raphaël Hertzog suggested that it might be worth using some of the money in the Debian bank account to fund the development of such a feature.

  • Double the movement: Inspire someone to explore free software

    Thank you for being part of our exceptionally generous community. Your interest in our mission is what got us where we are, in position to succeed if we keep at it. While it's incredible to have hundreds of thousands of subscribers around the world, we need to connect with millions if we're to realize a world free of proprietary software. This spring, we have set ourselves goals to reach 200 new members and 400 donations before July 15th, and to achieve them, we need your help. Please take this moment to publicly share your passion for free software. If each free software supporter inspires just one other, we can double our strength.

    We tasked free software designer Raghavendra Kamath with creating some inspiring visual images to help us spread our message further. You can find these banners and profile images, including their embed codes, here. Sharing these images online might inspire someone to explore free software, and may give reasons for you to educate your friends and family about why free software matters. Use the hashtag #ISupportFreeSoftware when you share the images online or on your social media.

Debian: Cross-Version Benchmarks, Debian LTS and HubLinked Meeting in Dublin

Filed under
Debian
  • A Quick Look At The Debian 10.0 Buster vs. Debian 9.9 Performance

    With Debian 10 "Buster" due to be releasing in early July, I've begun testing the near-final Buster images on various systems. Here is a look at a common Intel Core i7 system comparing the current performance of Debian 10.0 to the current stable 9.9 release.

    On the Core i7 8700K system, Debian 9.9 vs. 10.0 were benchmarked with the same hardware under test and each Debian release being cleanly installed and kept to its default settings.

  • Freexian’s report about Debian Long Term Support, May 2019

    Like each month, here comes a report about the work of paid contributors to Debian LTS.

  • Virtual Labs presentation at the HubLinked meeting in Dublin

    We have participated to the HubLinked workshop in Dublin this week, where I delivered a presentation on some of our efforts on Virtual Labs, in the hope that this could be useful to the partners designing the “Global Labs” where students will experiment together for Software Engineering projects.

Debian GNU/Linux riscv64 port in mid 2019

Filed under
Debian

As it can be seen in the first graph, perhaps with some difficulty, is that the percent of arch-dependent packages built for riscv64 (grey line) has been around or higher than 80% since mid 2018, just a few months after the port was added to the infrastructure.

Given than the arch-dependent packages are about half of the Debian['s main, unstable] archive and that (in simple terms) arch-independent packages can be used by all ports (provided that the software that they rely on is present, e.g. a programming language interpreter), this means that around 90% of packages of the whole archive has been available for this architecture from early on.

Read more

Move to pay Debian devs for project work rears its head again

Filed under
GNU
Linux
Debian

The idea of paying developers to work on Debian GNU/Linux packages has reared its head again, with senior developer Raphael Hertzog proposing that project funds be used for the purpose.

Hertzog made the suggestion in a reply to a post on one of the project's mailing lists which was part of a thread on the subject "Why do we take so long to realise good ideas?"

"Use the $300,000 on our bank accounts?", he wrote, adding that he had heard of another US$300,000 donation made by Google to the project though he was unable to find any publicly accessible reference to it.

The idea of paying developers for their work on what is a community project was raised 13 years ago by former project leader Anthony Towns, with the reason being the speeding up of development so that releases could take place sooner. The idea did not prove very popular as it was meant to be run outside the project proper and was meant to pay core members for their work.

Read more

Debian: Outreachy, Patches and LTS Work by Raphaël Hertzog

Filed under
Debian
Syndicate content

More in Tux Machines

Five Linux Server Administration Mistakes And How To Avoid Them

In 2017, an employee at GitLab, the version control hosting platform, was asked to replicate a database of production data. Because of a configuration error, the replication did not work as expected, so the employee decided to remove the data that had been transferred and try again. He ran a command to delete the unwanted data, only to realize with mounting horror that he had entered the command into an SSH session connected to a production server, deleting hundreds of gigabytes of user data. Every seasoned system administrator can tell you a similar story. The Linux command line gives server admins control of their servers and the data stored on them, but it does little to stop them running destructive commands with consequences that can’t be undone. Accidental data deletion is just one type of mistake that new server administrators make. Read more

Fedora 31 Looking At No Longer Building i686 Linux Kernel Packages

Not to be confused with Ubuntu's varying stance on dropping 32-bit packages beginning with their next release later this year, Fedora 31 now has a proposal pending to discontinue their i686 kernel builds but they will still be keeping with their 32-bit packaging. This Fedora 31 change proposal by Justin Forbes, one of Fedora's kernel hackers, is just about ending i686 kernel builds beginning with this Fedora release due out in October. The i686 kernel-headers package would still be offered in order to satisfy necessary dependencies for 32-bit programs needing those headers. Of course, users will have to be running off a 64-bit kernel. All 32-bit programs should continue to work on Fedora 31. Read more Also: Fedora Workstation 31 Is Looking Great With Many Original Features Being Worked On Fedora booth at Red Hat Summit Fedora Update Week 23–24

Deprecating a.out Binaries

Remember a.out binaries? They were the file format of the Linux kernel till around 1995 when ELF took over. ELF is better. It allows you to load shared libraries anywhere in memory, while a.out binaries need you to register shared library locations. That's fine at small scales, but it gets to be more and more of a headache as you have more and more shared libraries to deal with. But a.out is still supported in the Linux source tree, 25 years after ELF became the standard default format. Recently, Borislav Petkov recommended deprecating it in the source tree, with the idea of removing it if it turned out there were no remaining users. He posted a patch to implement the deprecation. Alan Cox also remarked that "in the unlikely event that someone actually has an a.out binary they can't live with, they can also just write an a.out loader as an ELF program entirely in userspace." Read more

An easier way to test Plasma

Having the Plasma and Usability & Productivity sprints held at the same time and place had an unexpected benefit: we were able to come up with a way to make it easier to test a custom-compiled version of Plasma! Previously, we had some documentation that asked people to create a shell script on their computers, copy files to various locations, and perform a few other steps. Unfortunately, many of the details were out of date, and the whole process was quite error-prone. It turned out that almost none of the Plasma developers at the sprint were actually using this method, and each had cobbled together something for themselves. Some (including myself) had given up on it and were doing Plasma development in a virtual machine. So we put some time into easing this pain by making Plasma itself produce all the right pieces automatically when compiled from source. Then, we created a simple script to install everything properly. Read more