Language Selection

English French German Italian Portuguese Spanish

Slack

New Packages in Slackware

Filed under
Slack
  • LibreOffice updates for Slackware 14.2 and -current

    This month, I am building different versions for LibreOffice, for our stable Slackware 14.2 and for the -current testing ground. During my holiday, new versions became available and last week I built packages from those sources.

    The 6.2.6 release which was announced by the Document Foundation two weeks ago brings some security fixes to the 6.2 series. Therefore it was important to get rid of the old 6.2.5 packages. I built 6.2.6 for Slackware 14.2 and those packages have been available for download now since early last week. Go get them!

  • VLC 3.0.8 packages

    The Release Notes state that this releases provides fixes for several security issues among wich 11 which are CVE-worthy. Meaning that it’s prudent to upgrade your VLC to 3.0.8 soonest.

    I have the new packages available (for Slackware 14.2 and -current) in my repository since a couple of days. I used the opportunity to update the following internal libraries as well: bluray, dav1d, ebml, and matroska.

    You will also probably note that there is no “npapi-vlc” package. I decided to retire this VLC based NPAPI webbrowser plugin from my repository. Modern browsers are all moving away from NPAPI plugin support, and relying on HTML5 instead. Chrome/Chromium always only supported PPAPI based plugins anyway.

  • Chromium package updates

    There was a new Chromium source release last week, but there were other software releases that had priority to get packages out the door. Therefore I could only chromium packages this weekend.
    Chromium 76.0.3809.132 fixes 3 security holes. Note that the version before that (76.0.3809.100) also fixed 4 critical holes but I never packaged that as I went on holiday. So, upgrading now would be a good idea.

Slackware, the Longest Active Linux Distro, Finally Has a Patreon Page

Filed under
Slack

"Slackware is the longest active Linux distribution project, founded in 1993," writes TheBAFH (Slashdot reader #68,624).

"Today there are many Linux distributions available, but I've remained dedicated to this project as I believe it still holds an important place in the Linux ecosystem," writes Patrick J. Volkerding on a new Patreon page. He adds that Slackware's users "know that Slackware can be trusted not to constantly change the way things work, so that your investment in learning Slackware lasts longer than it would with a system that's a moving target... Your support is greatly appreciated, and will make it possible for me to continue to maintain this project."

Read more

Games in GNOME, New KDE Plasma5 for Slackware and KDE Wiki

Filed under
KDE
GNOME
Slack
  • Andrei Lisita: Getting closer

    Since my last blog post I have been on a short vacation but I have also managed to make some progress on my GSoC project again with guidance from my mentor.

    [...]

    Every savestate also has a creation date which is displayed in the menu, but that’s certainly not as eye-catching as the screenshots.

    There are still many missing features and things that need improving (such as the date formatting) but with every commit I feel that I am getting closer to the finished project.

  • KDE Plasma5 for Slackware, introducing Qt 5.13 in the July’19 update

    Now that all major components of the KDE software stack have fresh new releases, I bundled them for Slackware-current and voila: KDE-5_19.07.

    I have uploaded KDE-5_19.07 to my ‘ktown‘ repository. As always, these packages are meant to be installed on a full installation of Slackware-current which has had its KDE4 removed first. These packages will not work on Slackware 14.2.

  • The new userbase wiki

    When you find a kool feature in KDE software, you can write a small tutorial or just a small paragraph about it and the KDE Userbase Wiki is the right place to publish it. You don’t need to know how to code, have perfect English or know how MediaWiki’s formatting work, to contribute. We also need translators.

Cinnamon 4.2 Early Testing

Filed under
GNOME
Slack

it's been a while since posted a post here, but that's because of my work load which was way so hectic, so i didn't have time to post an update on Slackware or other things related to Slackware, but for today, i will make an exception since it's time to play with Cinnamon 4.2, the latest release of Cinnamon, which is yet to be announced, but the tarballs are already released on their github project page.

There's no news yet on their blog, but i'm guessing they will release it soon after they mark it as stable. It took several minor releases to ensure stability and compatibility in Cinnamon based on past track records. We had some minor issue dealing with cinnamon-settings-daemon for Slackware-Current since they moved to support newer UPower 0.99 API while in Slackware, we still use the old UPower 0.9.23. In the end, upstream patched a bit, but i'm not really sure the power management component works best since i haven't tried it yet on a laptop (desktop is fine).

Read more

Also new: Cinnamon 4.2.0

zenwalk current ISO for 02 06 2019

Filed under
GNU
Linux
Slack

New current ISO is ready !

In addition to the hundreds of packages updates from upstream Slackware Current and Zenwalk native, you'll get the new Firefox 67.0, latest XFCE 4.13, a new desktop theme, and a brand new Whisker applications menu.

For complete changelog see both Slack changelog on slackware.com and Zenwalk changelog on this site.

Read more

Slackware Removal of Lumina Desktop and Additional New Packages/Versions

Filed under
Slack
  • Lumina Desktop will be removed from my -current repository

    The Lumina Desktop is part of the TrueOS project, a FreeBSD variant. I packaged version 1.4.0.p1 for Slackware and it is part of the Plasma5 variant of my Slackware Live Edition.

    I noticed a while ago that Lumina would no longer start but it was low on my priority list to try and fix it.

    Today I found the time to look into this, but a recompilation against the latest Qt5 and other libraries, altough error-free, would not make the Lumina Desktop start successfully: it will start to load, but then you’ll hear a beep and you’re dumped at the command prompt or at the graphical login screen without evidence of what happened.

  • Valentine present for Slackers

    Today is Valentine’s Day. A moment to give some extra attention to people that are dear to you.

    In my case, that’s everyone who loves, uses, supports, advocates or develops Slackware Linux. For all of you, I uploaded “KDE-5_19.02” to the ‘ktown‘ repository. There’s some updates in there that might interest you, see below.
    If you do not (want to) run or install Slackware-current, I will make sure that a new ISO of the Slackware Live Plasma5 Edition will be available around the weekend. That way, you can safely try it out without having to touch your hard drive.

    As always, these packages are meant to be installed on a Slackware-current which has had its KDE4 removed first. These packages will not work on Slackware 14.2.

Uploading 15 GB of new Slackware Live Edition ISO images

Filed under
Slack

The squashfs modules in the XFCE ISOs are compressed with ‘xz’ to keep them as small as possible (so they will fit on a CDROM medium). All of the other ISOs are compressed with ‘zstd’ which gives the Live OS a speed boost of ~20% at the cost of 10% increase in the ISO size.

Read more

KDE4 and Plasma 5 for Slackware

Filed under
KDE
Slack
  • KDE4 and Qt4 deprecation in FreeBSD

    This is a reminder — for those who don’t read all of the FreeBSD mailing lists — that KDE4 is marked deprecated in the official ports tree for FreeBSD, and will be removed at the end of this year (in about 20 days). Then Qt4 will be removed from the official ports tree in mid-march.

    Since both pieces of software are end-of-life and unmaintained upstream already for several years, the kde@ team at FreeBSD no longer can maintain them. Recent time-sinks were dealing with OpenSSL 1.1.1, libressl, C++17, .. the code is old, and there’s newer, nicer, better-maintained code available generally by replacing 4 with 5.

  • KDE Plasma 5 for Slackware – end of the year edition

    I just uploaded a whole new batch of packages containing KDE Plasma5 for Slackware. The previous batch, KDE 5_18.10 is already two months old and has some library compatibility issues. The new KDE 5_18.12 for Slackware consists of KDE Frameworks 5.53.0, Plasma 5.14.4 and Applications 18.08.3. All this on top of Qt 5.11.3.
    Compiled on the latest Slackware -current, it’s running smoothly here on my laptop.
    I decided against upgrading to QT 5.12.0. This is a new LTS release, but I will wait for the other distros to find bugs in this new software. Next week, KDE will release KDE Applications 18.12.0 and that too is something I want to check a bit before releasing Slackware packages. Therefore it’s likely that a new batch of packages containing Qt 5.12 and KDE Applications 18.12 will see the light shortly after the New Year.

Absolute Linux: Testing Snapshot/15.0 Based on Slackware Current

Filed under
Reviews
Slack

Patrick, next Slackware and moving forward with KDE Plasma5

Filed under
Slack

I assume that many of you will have been reading the recent Linux Questions thread “Donating to Slackware” and in particular Patrick Volkerding’s reply where he explains that the Slackware Store (an entity independent of Slackware with which he has a business arrangement involving a percentage of sales profit and medical insurance) has not been paying him any money for the last two years and that most likely all the PayPal donations through the Store have gone into the pockets of the Store owners. Read that thread if you have not done so yet.
Basically Pat is broke. That thread lists a PayPal address which Pat eventually shared and where donations can be sent directly to him, so that he can fix his roof, his airco, his crashing server and his wife’s car. That would be a start.

That LQ thread is also perused to discuss possible ways forward for Pat (setting up a Patreon account, or a business PayPal account, etc) so that he can support his family and continue working on Slackware. To me it looks like the Store will be a thing of the past unless they change their attitude. Switching from a business model where revenue is generated from optical media sales, to a model where supporters set up a recurring payment in exchange for the prolonged existence of their favorite distro, and possibly get Pat to write up some hands-on stories as a reward, may ultimately benefit Pat, and Slackware, more than the way things are handled at the moment. If you are doubting the financial impact of a recurring payment through Patreon or PayPal, look at it this way: if you donate one euro per month, you will probably not even notice that the money is shifted out. But with 2000 people donating one euro per month, Pat would have a basic income (pre-tax) already. Not a lot, but it’s a start. The 2000 people is a rough estimate of the people who ordered a DVD or CD through the store: the owners told Pat that the earnings of the 14.2 release were 100K (and Pat got 15K out of that, go figure!). Divide that through ~50 euro per DVD, results in 2000 people. Then there’s all these people who donated money through the Store or bought shirts, caps and stickers. I think the amounts of money even a small community (like us Slackware users) can contribute should enable Pat to shed his financial worries. The fact that the Slackware Store basically has been ripping off the hand that feeds them is enraging and inexcusable.
This is all about a community standing up to provide support for what (or who) bonds us together.

Read more

Syndicate content

More in Tux Machines

Kernel Articles at LWN (Paywall Just Expired)

  • Filesystem sandboxing with eBPF

    Bijlani is focused on a specific type of sandbox: a filesystem sandbox. The idea is to restrict access to sensitive data when running these untrusted programs. The rules would need to be dynamic as the restrictions might need to change based on the program being run. Some examples he gave were to restrict access to the ~/.ssh/id_rsa* files or to only allow access to files of a specific type (e.g. only *.pdf for a PDF reader). He went through some of the existing solutions to show why they did not solve his problem, comparing them on five attributes: allowing dynamic policies, usable by unprivileged users, providing fine-grained control, meeting the security needs for running untrusted code, and avoiding excessive performance overhead. Unix discretionary access control (DAC)—file permissions, essentially—is available to unprivileged users, but fails most of the other measures. Most importantly, it does not suffice to keep untrusted code from accessing files owned by the user running the code. SELinux mandatory access control (MAC) does check most of the boxes (as can be seen in the talk slides [PDF]), but is not available to unprivileged users. Namespaces (or chroot()) can be used to isolate filesystems and parts of filesystems, but cannot enforce security policies, he said. Using LD_PRELOAD to intercept calls to filesystem operations (e.g. open() or write()) is a way for unprivileged users to enforce dynamic policies, but it can be bypassed fairly easily. System calls can be invoked directly, rather than going through the library calls, or files can be mapped with mmap(), which will allow I/O to the files without making system calls. Similarly, ptrace() can be used, but it suffers from time-of-check-to-time-of-use (TOCTTOU) races, which would allow the security protections to be bypassed.

  • Generalizing address-space isolation

    Linux systems have traditionally run with a single address space that is shared by user and kernel space. That changed with the advent of the Meltdown vulnerability, which forced the merging of kernel page-table isolation (KPTI) at the end of 2017. But, Mike Rapoport said during his 2019 Open Source Summit Europe talk, that may not be the end of the story for address-space isolation. There is a good case to be made for increasing the separation of address spaces, but implementing that may require some fundamental changes in how kernel memory management works. Currently, Linux systems still use a single address space, at least when they are running in kernel mode. It is efficient and convenient to have everything visible, but there are security benefits to be had from splitting the address space apart. Memory that is not actually mapped is a lot harder for an attacker to get at. The first step in that direction was KPTI. It has performance costs, especially around transitions between user and kernel space, but there was no other option that would address the Meltdown problem. For many, that's all the address-space isolation they would like to see, but that hasn't stopped Rapoport from working to expand its use.

  • Identifying buggy patches with machine learning

    The stable kernel releases are meant to contain as many important fixes as possible; to that end, the stable maintainers have been making use of a machine-learning system to identify patches that should be considered for a stable update. This exercise has had some success but, at the 2019 Open Source Summit Europe, Sasha Levin asked whether this process could be improved further. Might it be possible for a machine-learning system to identify patches that create bugs and intercept them, so that the fixes never become necessary? Any kernel patch that fixes a bug, Levin began, should include a tag marking it for the stable updates. Relying on that tag turns out to miss a lot of important fixes, though. About 3-4% of the mainline patch stream was being marked, but the number of patches that should be put into the stable releases is closer to 20% of the total. Rather than try to get developers to mark more patches, he developed his machine-learning system to identify fixes in the mainline patch stream automatically and queue them for manual review. This system uses a number of heuristics, he said. If the changelog contains language like "fixes" or "causes a panic", it's likely to be an important fix. Shorter patches tend to be candidates.

  • Next steps for kernel workflow improvement

    The kernel project's email-based development process is well established and has some strong defenders, but it is also showing its age. At the 2019 Kernel Maintainers Summit, it became clear that the kernel's processes are much in need of updating, and that the maintainers are beginning to understand that. It is one thing, though, to establish goals for an improved process; it is another to actually implement that process and convince developers to use it. At the 2019 Open Source Summit Europe, a group of 20 or so maintainers and developers met in the corner of a noisy exhibition hall to try to work out what some of the first steps in that direction might be. The meeting was organized and led by Konstantin Ryabitsev, who is in charge of kernel.org (among other responsibilities) at the Linux Foundation (LF). Developing the kernel by emailing patches is suboptimal, he said, especially when it comes to dovetailing with continuous-integration (CI) processes, but it still works well for many kernel developers. Any new processes will have to coexist with the old, or they will not be adopted. There are, it seems, some resources at the LF that can be directed toward improving the kernel's development processes, especially if it is clear that this work is something that the community wants.

Server Leftovers

  • Knative at 1: New Changes, New Opportunities

    This summer marked the one-year anniversary of Knative, an open-source project that provides the fundamental building blocks for serverless workloads in Kubernetes. In its relatively short life (so far), Knative is already delivering on its promise to boost organizations’ ability to leverage serverless and FaaS (functions as a service). Knative isn’t the only serverless offering for Kubernetes, but it has become a de-facto standard because it arguably has a richer set of features and can be integrated more smoothly than the competition. And the Knative project continues to evolve to address businesses’ changing needs. In the last year alone, the platform has seen many improvements, giving organizations looking to expand their use of Kubernetes through serverless new choices, new considerations and new opportunities.

  • Redis Labs Leverages Kubernetes to Automate Database Recovery

    Redis Labs today announced it has enhanced the Operator software for deploying its database on Kubernetes clusters to include an automatic cluster recovery that enables customers to manage a stateful service as if it were stateless. Announced at Redis Day, the latest version of Kubernetes Operator for Redis Enterprise makes it possible to spin up a new instance of a Redis database in minutes. Howard Ting, chief marketing officer for Redis Labs, says as Kubernetes has continued to gain traction, it became apparent that IT organizations need tools to provision Redis Enterprise for Kubernetes clusters. That requirement led Redis Labs to embrace Operator software for Kubernetes developed by CoreOS, which has since been acquired by Red Hat. IT teams can either opt to recover databases manually using Kubernetes Operator or configure the tool to recover databases automatically anytime a database goes offline. In either case, he says, all datasets are loaded and balanced across the cluster without any need for manual workflows.

  • Dare to Transform IT with SUSE Global Services

Audiocasts/Shows: FLOSS Weekly and Linux Headlines

  • FLOSS Weekly 555: Emissions API

    Emissions API is easy to access satellite-based emission data for everyone. The project strives to create an application interface that lowers the barrier to use the data for visualization and/or analysis.

  • 2019-11-13 | Linux Headlines

    It’s time to update your kernel again as yet more Intel security issues come to light, good news for container management and self-hosted collaboration, and Brave is finally ready for production.

Bill Wear, Developer Advocate for MAAS: foo.c

I remember my first foo. It was September, 1974, on a PDP-11/40, in the second-floor lab at the local community college. It was an amazing experience for a fourteen-year-old, admitted at 12 to audit night classes because his dad was a part-time instructor and full-time polymath. I should warn you, I’m not the genius in the room. I maintained a B average in math and electrical engineering, but A+ averages in English, languages, programming, and organic chemistry (yeah, about that….). The genius was my Dad, the math wizard, the US Navy CIC Officer. More on him in a later blog — he’s relevant to what MAAS does in a big way. Okay, so I’m more of a language (and logic) guy. But isn’t code where math meets language and logic? Research Unix Fifth edition UNIX had just been licensed to educational institutions at no cost, and since this college was situated squarely in the middle of the military-industrial complex, scoring a Hulking Giant was easy. Finding good code to run it? That was another issue, until Bell Labs offered up a freebie. It was amazing! Getting the computer to do things on its own — via ASM and FORTRAN — was not new to me. What was new was the simplicity of the whole thing. Mathematically, UNIX and C were incredibly complex, incorporating all kinds of network theory and topology and numerical methods that (frankly) haven’t always been my favorite cup of tea. I’m not even sure if Computer Science was a thing yet. But the amazing part? Here was an OS which took all that complexity and translated it to simple logic: everything is a file; small is beautiful; do one thing well. Didn’t matter that it was cranky and buggy and sometimes dumped your perfectly-okay program in the bit bucket. It was a thrill to be able to do something without having to obsess over the math underneath. Read more Also: How to upgrade to Ubuntu 20.04 Daily Builds from Ubuntu 19.10