Alien Pastures

My thoughts on Slackware, life and everything

Category: Rant (Page 5 of 10)

Terror does not kill freedom

January 7, 2015 / / 27 Comments

jesuischarlie

Bear with me – I need to make this statement.

The terror attack on a  french satirical magazine, killing 10 of its cartoonists and journalists, is an attack on Freedom of Speech. Only morons are afraid of words and images. Who in his right mind kills journalists unless he is afraid of the truth?

Wars are fought to gain power, for money, for religion. But religious wars are also just a fight for power. The Crusaders in the Western past, and the Jihadists in the Eastern present, there is no difference. Totally convinced of their own beliefs, the beliefs of other people must be repressed at any cost. What else is this but madness?

Terror goes beyond war. Warring factions are both defending their beliefs, however twisted their beliefs are. Terror on the other hand is waged on innocent people. It is meant to put fear in the hearts of the citizen with a long-term goal of establishing some form or repressive regime – even in democratic countries, repression can be achieved. People can be herded like sheep if you keep the truth from them. In Western (Christian) civilization, it was the period of Enlightenment that rid us of the repression of religion. In some islamic countries, this step still needs to be made. The Crusaders are no more (despite the statements of islamic fanatics) – and now Muslims need to raise their voice and fight these people who justify their actions by calling upon Allah but are in fact without faith. Terror does not need a God.

What is the best weapon against terror and false beliefs? The truth! You can live in freedom only if you have access to the truth, and are able to fight falsehoods with proof to the contrary. Do not let yourself be scared away by terror. The terrorist has already lost if you stand up for your freedom and for the truth.

Eric

(Wine-) Pipelight update – careful upgrade

December 23, 2014 / / 7 Comments

pipelight-logo After a long time of silence (but ongoing development as shown in their git repository) the Pipelight developers released a new stable pipelight a few weeks ago. I created Slackware packages for this (Slackware 14.0 and newer) but before you upgrade, please read the words of caution at the end of this post, they will save you some frustration.

The new pipelight is a bugfix release: after Google deprecated NPAPI plugins, the focus for Pipelight team has been better support for Firefox. As stated in the release notes, most of the remaining bugs should now be in Wine, not in pipelight. That has also lead to more focus on what used to be called “wine-compholio”. the team’s patch-set for wine that implements the Windows browser plugin support. The name “wine-compholio” has changed to “Wine Staging” which is now even used as the default wine version on Fedora. I am not willing to go that far, so there is still a separate wine-pipelight package that you have to install on Slackware in order to use my pipelight package.

Remember that you can always get the latest Windows plugin releases (an important feature in case of security fixes) without having to wait for me creating a new package. Just run the command “pipelight-plugin –update” as root. After doing that, the next time your browser loads the pipelight plugin, it will automatically download the newest version of your installed Windows plugin(s).

I know that some people are grumbling whenever someone develops a program for Linux that enables the use of Windows software (emulated or otherwise), such as wine or pipelight. The fact is, if you want to watch Netflix on your Slackware computer, and you do not want to install Google Chrome, then Mozilla Firefox combined with pipelight and MS SilverLight is still the only way to achieve this. Chromium does not support NPAPI either and the Widevine CDM can not be made to work as it does in Chrome. Also, software using Silverlight is still widespread in school systems. I will welcome the future implementation of EME in Firefox that will allow separate download and use of Content Decryption Modules (CDM) like Widevine which is used by Chrome for streaming Netflix. Then, Google Chrome nor pipelight/silverlight will be necessary any longer. Accepting that DRM is here to stay and can still be made compatible to Open Source and Free Choice is the start and I am glad that Mozilla thought hard and long about the apparent clash and came up with a sane solution.

Anyway, enough of the ranting.

In my original post about pipelight, you will find full installation and configuration instructions, as well as a troubleshooting section. That blog article is also referred to on the pipelight.net support page. Let me remind you that you need to go multilib if you want to use pipelight on 64-bit Slackware.

Package location (uploads expected later today, I thought it was more important to have this blog page up first):

A note of caution when upgrading to my pipelight-0.2.8 package:

This only applies to 64-bit Slackware!!!

I have made one important change to the file locations of the 64-bit pipelight package. The file “libpipelight.so” is a 64-bit shared library, but the previous 64-bit pipelight packages would install this file into “/usr/lib/pipelight/libpipelight.so”. That is not the correct location for 64-bit libraries, so the new package installs this file as “/usr/lib64/pipelight/libpipelight.so”.

This has the side effect that your pipelight stops working. The error message(if you start firefox in a terminal) will be something like “pluginInitOkay(): incompatible version of pluginloader.exe“. Don’t worry, you can remedy this.

These are the steps you have to take in order to fix this (it’s a one-time action):

As root user: remove all old copies of the library created by earlier pipelight versions:

# rm -r /usr/lib/pipelight

As your own user account, list all plugins you have currently enabled (copy that command’s output because you have to re-enable them in a later step):

$ pipelight-plugin --list-enabled

That command basically checks your “~/.mozilla/plugins/” directory for symlinks named “libpipelight*.so”. If you look inside that directory, you will notice that all these symlinks are pointing to the no longer existing location “/usr/lib/pipelight”. So, you first remove those symlinks:

$ pipelight-plugin --disable-all

And re-create them properly (still as your own user account):

$ pipelight-plugin --enable <your previously enabled plugin(s)>

That’s all. Have fun! Eric

 

Handbrake – lost for Slackware

November 25, 2014 / / 66 Comments

handbrake_logo Yesterday, I read about the newest release of Handbrake, the powerful video transcoder. I have handbrake in my Slackware repository, so I decided to dissect the source tarball for the 0.10.0 release and see what was needed to compile it into a package.

Boo hoo.

Handbrake 0.10.0 switched from a GTK+2 to a GTK+3 graphical user interface. Not only that, but it requires a version of GTK+3 that is not even contained in Slackware-current. We have 3.8.2 while handbrake uses functionality which was introduced with 3.10. We’re out in the cold, folks!

You might debate whether Slackware’s GTK+3 is not too old anyway, but then again, GTK releases are notorious for breaking all kinds of stuff thanks to ABI incompabilities. Slackware does not contain GNOME, so there is little reason to stay uptodate on the GTK+3 front when running the risk to break dependent packages.

Anyway, it means that you will not be getting a new handbrake package from me anymore. Perhaps when Slackware-current adopts a newer GTK+3 stack, I can reconsider. But even in that case, Slackware 14.1 and older will have to stick with handbrake 0.9.9 as the last release which will compile.

If time permits I will investigate the possibility of statically compiling GTK+3 plus several of other GTK+3 dependendants into the handbrake package. But that needs time which I do not have. You might already have guessed that – this blog has been pretty silent during the past month. Work related frustrations augmented by family issues, resulting in shifting priorities. To me, Slackware essentially is a hobby, it does not have to make me any money (even though some of you donated, for which my eternal gratefulness) and real life sometimes takes over.

If all you wanted to know was about handbrake then you can leave now.

So I’ll rant on if you cared to stay. Handbrake – big disappointment yesterday I must confess. I really liked that program. There’s also this general feeling of depression I have over the state of GNU/Linux, the Open Source community. my work on Slackware, and whether I can still make a difference. The effort I have put into Slackware, promoting the distro and Open Source in general, I’ve always enjoyed doing that. But the fun is eroding away, and there is this sense of stagnation. Things are moving perpendicular to the direction I want to go in. I am going to need some time for reflection around the end of 2014 and find a way to get invigorated again. Suggestions on a direction to take are welcome. There is not so much action around the distro currently. KDE 4 is about frozen, and KDE 5 is not mature. No joy there. LXQt seems to have jumped from Qt4 to Qt5, another step i do not like. Chromium dropped support for compiling NaCL support into 32-bit package – precisely the reason why I hate it that I need to depend on binary toolchains that are impossible to compile on Slackware. And what to do with my ARM port – I am looking at the mountain of work required to revive it. The list of recent frustrations is much longer than that, but you get the point… it all feels so pointless.

Depressed, you say? You bet! It must be an autumn feeling. Where’s the exit? Going to grab me a beer.

Eric

KDE update: 4.14.2. No KDE5 updates yet – devs need to get their act together

October 14, 2014 / / 28 Comments

qt-kde-620x350Remember when everybody was so excited that the KDE developers abandoned their “monolithic” release schedule where all the software was stamped with the same version number and released as a “Software Compilation”…

There have been a number of releases for the KDE Frameworks 5 and Plasma 5 (which depend on the Frameworks) in decoupled release schedules. To me it is clear  that the developers are not (yet) ready for this. Their workflows appear to be such that they write code which depends on other modules’ code which only exists in a Git repository. With the old “Software Compilation” that was never an issue since all these sources would be released simultaneously. Nowadays we are facing independent release schedules and what is the (expected) result? Software starts breaking down because not all of the git code is being released at the time when the dependent code gets released.

Therefore I refuse to build and release Slackware packages for the latest/pending “KDE 5” software set, consisting of Frameworks 5.3.0 (in part 5.3.1 now, apparently) and Plasma 5.1.0. It is a freaking mess with updates, reverts and apologies all abound on the mailinglists. Get your act together! In emergency and disaster responce training, you’ll learn that it’s all about communication. IT is no different in software development. In the “bazaar” model, it is still required of people to coordinate the joint effort or else you’ll end up with a pile of loose sand instead of something solid and useful. Coordination is communication during, not after the events.

Knowing the KDE community, the future releases of the KDE 5 components will gradually reach mature levels again.

And hey! There still is the good old KDE4. A set of Slackware packages for KDE 4.14.2 is ready for you to download and install as of now. The source release was made public  earlier today. As expected from KDE4, it is all about bugfixes and stability enhancements.

None of the dependencies I maintain for KDE 4 had to be upgraded in comparison with my previous release of KDE 4.14.1 packages. KDE 4.14.2 bundles the sources of kactivities-4.13.3 (taken from the KDE 4.13 major release) because no new tarball is being made available. For kde-workspace, an update to 4.11.13 was provided by the developers. I promise that I will have gstreamer-1 packages done for the KDE 4.14.3 release and build artikulate (fingers crossed)!

How to upgrade to KDE 4.14.2 ?

You will find all the installation/upgrade instructions that you need in the accompanying README file. That README also contains basic information for KDE recompilation using the provided SlackBuild script.

You are strongly advised to read and follow these installation/upgrade instructions! Note that this is only useful for you if you are running slackware-current, i.e. our development version. If you are running SLackware 14.1 then there’s still a fairly recent KDE 4.13.3 for you.

Where to find Slackware packages for KDE ?

Download locations are listed below.

You will find the KDE 4.14.2 sources in ./source/4.14.2/ and packages in /current/4.14.2/ subdirectories.

Note that I have symlinks in place (useful for users of a package manager and running slackware-current) so that ./current/latest/ will always point to the latest stable KDE release, and ./current/testing/ will always point to the most recent testing release (currently that’s Frameworks 5 and Plasma 5). Let’s hope there will be something fresh in that “testing” area soon.

Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Have fun! Eric

Fighting spam

September 20, 2014 / / 11 Comments

In an attempt to fight the ever-growing amounts of spam on this blog (nearly hundred a week that I have to manually delete), I have made a change to the comments section.

I already have a conditional CAPTCHA appearing if a comment seems to be a spam message, and Akismet is checking my posts against their spam database, but the spam texts are increasingly “well-written” so that they are harder to distinguish from bona-fide comments. The actual spam URL is mostly no longer in the text body but in the commenter’s address field.

As of now, everyone who does not yet have an approved comment on one of my articles will end up in the moderation queue where I have to approve or reject the comment manually.

That will stop the spam messages from appearing on the blog and RSS feed, and once you have an approved post on my blog, your next posts will not have to be moderated.

My apologies if you want to comment here for the first time and your text does not appear immediately after hitting “Submit”. I think this is the best for the blog as well as its readers!

Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑