Games + Slackware

Yes, something frivolous... And NO - NO STEAM games here, never.
But about installing free natural-linux games in Slackware 14.1 (64bit).
SBO = slackbuilds.org (buildscripts+source=compile)
SF = slakfinder.org (ready binaries=install)

# Battle of Wesnoth - can be easily installed from SF, Salix. There is also option to compile it from SBO, and tuning the build specifically.
deps: It might need lua (according to SBO, but not according to SF). I had lua installed previously, so I don't know.
- Wesnoth is 'turn-based tactical strategy game'. See here for more in-depth info.
Nothing more to say - I haven't played it yet.

# Tales of Maj'Eyal - Not so easy install at all. Has to be compiled from SBO, and has a bunch of deps: premake - SBO (deps: lua), OpenAL - SF binary, SDL2 + SDL2_ttf + SDL2_image - all three from SBO.
SDL2_ttf gave me error about missing/wrong libGL. Fixed it in usr/lib64/libGL.la - changed obviously wrong libdir='/usr/lib' to libdir='/usr/lib64', and compile finished without further problems. ... I have no idea why it had such a wrong address in libdir...
- Maj'Eyal is 'roguelike RPG, featuring tactical turn-based combat and advanced character building' - see here.
The game is quite enthralling, 'just one turn more' type. It's also not easy, and has various ways to die stupidly. For example: walking in sand-tunnels without digging worm ahead; lack of attention with bosses is often strightly fatal...

# Freeciv - Install is compile from SBO. No deps. Easy-peasy.
- Freeciv is 'a free turn-based multiplayer strategy game'. Has big and quite well-stocked site.
The game has several diffrent modes and mods, including civ1 and civ2. Default mode is not especially easy - certainly for those whos experience runs only in wimpy and feebleminded civ 4 and 5.
Anyway, confs are easily hackable - for example: nations' files reside in /usr/share/freeciv/nation; and in /usr/share/freeciv/default one can find all general conf files. And they all are plain txt.
At the same time, creating a new nation - by tutorial - gave somehow buggy result...
The games' gui is not especially good and easily-usable, but as a civ-game - it's very OK.

# FreeDoom - SBO, and what you get are wads only, engine has to be get separately. And it would be mightily good, if there are old Dooms', or Heretics', or Hexens' original wads available - those are also playable with zdoom or gzdoom engines.
So, pick one of them...
gzdoom seems to be newer: SBO, deps - fmodapi.
zdoom - SBO, and has more deps - TiMidity++, fmodapi, p7zip.
- Doom is a shooter - or should I say The Shooter, at least for me it was first ever game played overnights with sysadmin and some developers (right, over 20 years ago).
Take a look here.

# Lips of Suna - Well, that installation took me some 5 hours of silly wandering around. The game has to be compiled as is, no slackbuild scripts here. For guidelines see here.
Basically, by default it installs to /home/xxx/ :
cd lipsofsuna-X-X-X
./waf configure
./waf install
./lipsofsuna
Here are deps. All are available in SBO, thank god. Ogre compile, though, is long as shit.
Most entertaining was that 'lips...' didn't compile - with nicy orange-bold error. Let's cut it short and reveal my winning configure line:
LDFLAGS=-lboost_system ./waf configure --ogre-plugindir=/usr/lib64/OGRE
Part before 'configure' ensures compile, part after, that ./lipsofsuna also starts.
It bloody compiled, with one orange part (but not bold)... jeez. I am sure it wasn't worth of it. But I won the struggle! :)
- No idea what the game is about, but the word 'naked' in description got me.

# Summoning wars 5.6! - SBO. Pile of deps, for me it was - after previous games: freealut SF Slacky (deps: OpenAL), physfs SBO, CEGUI SBO, poco (deps: mysql-connector-c++, unixODBC, both SBO).
Tried to compile games' new ver.058... and no luck - cegui-084 compile crapped out with windowsy (irrelevant) message ... As this games' description hasn't any word 'naked' in it - I didn't see reason to spend more than an hour with this particular problem ... And stayed with old version - 056 - and readymade SlackBuild. CEGUI compile was slow like dead AND decomposed snail, almost like shitpile firefox ... poco was as bad - like bloody half an hour... physfs compile was short and nice. What a ... letdown..., for example ginormous gcc compiled only an hour in the same box...
a..n..d..I am already compiling sumwars! Lotsa green text! It even moves! err... slowly...! OHHHHH, it erred out, unbelievably, and for your convenience, last lines were:
collect2: error: ld returned 1 exit status
make[2]: *** [sumwars] Error 1
make[1]: *** [CMakeFiles/sumwars.dir/all] Error 2
make: *** [all] Error 2
doh!
| add next day| Fix was like that, in sumwars.SlackBuild:
-DCMAKE_CXX_FLAGS="-lboost_system -ldl" \   # added here '-ldl'.
That was that, compile finished and game started...
- 'Summoning Wars is an role-playing game'.
As all time went for compile, not for play... Only thing I can say just now - games' graphics is horrible, as expected.

| ADD |
# Naev - SBO (deps: OpenAL), two source files, naev and ndata are needed. It compiled/started with no whining...
- Naev is a 2D space trading and combat game. 
Take a look, see...

# Dink Smallwood. (Flare, Baldur's Gate)
Those three are vague future plans. If they, or something else, materialize , I ADD.

All-in-all: Native Linux games mentioned here
- look like shit of various degree,
- play good IF they are out of pre-alpha (infrequent miracle!),
- and install mostly ... like shit.
I am sure that next year is Linux-Desktop Year. :)

URxvt, Slackware, Crux = problems

Or - more precisely: Those mentioned in headline WITH Nvidia binary driver AND Compton compositor (and xorgs' version is also a player here).

So the following is obviously about the same thing as in this post - Compton and Nvidia not getting along. But - it's also a slight overview of urxvt.

I installed rxvt-unicode (exec: urxvt) as fun and games and novelty to my new Crux 3.1 (Crux home, my Crux install blah: 3.0 -1, 2, 3 and 3.1) and Slackware 14.1 (and my blah). The outcome was somewhat different in those distros.

But first, what it is this urxvt?
In essence, a terminal born from xrvt, with unicode support. And do a simple search 'rxvt+unicode'. At least two pagefuls give extremely relevant tutorials and stuff. Go.
But, just to mention:
- its' conf is in .Xdefaults (or in .Xresources if going more modern)
- it has transparency in two ways. And colors up to 256.
- it's UTF-8, of course,
- tabs and perl-extensions are configurable, among other things.

- It had lag at bottom of terminal (new-line) in both Crux and Slackware. It didn't wrap lines at all in Slackware.
- Doh.

# CRUX
Only problem: new line at the edge of terminal bottom - a lag of 1-2 seconds.
What I have: Nvidia binary driver 331.xx and compiled compton-master 20140729.
Problem was solved with remade compton start-line in Openbox autostart:
compton --backend glx --vsync opengl-swc --glx-no-rebind --glx-no-stencil --glx-swap-method 3 --unredir-if-possible --paint-on-overlay --shadow-exclude "! name~=''" --config ~/.compton.conf &
Magical part here is '--glx-swap-method 3'. Other is fluff what I think makes my screen look better. There is also option '--backend xr_glx_hybrid' - BUT, that gave me horrible desktop flickering.

# Slackware (and Salix), Nvidia 319.xx and the same Compton as in Crux
Additionally to lag, there was no line-wrap at all (commmand doesn't brake to next line, but acguires '>' and continues from last char...And then also kinda copies whole text to line above of last command. Very bloody confusing and obviously very wrong.
- Compton conf didn't do a thing,
- Compiling everything with Crux defs - no result,
- Copying other terminal-related confs from Crux - no result.
- Means, nothing I tried worked.

So, in Slackware, I ended up installing xfce4-terminal (deps: libxfcegui4, libxfce4util), and - lag disappeared just like that.

# Ah, yes - when digging in confs - as a bonus, I cracked the mystery of 'different looking man-pages for different users' in Crux. Has to have: export PAGER="most" in all .bashrc files. :)

# General notes about urxvt:
If dealing with .Xdefaults (.Xresources)
- might stick in Xft.dpi: 96 there too, it probably makes the console look a little less hairy.
And those -
Xft.hinting:1
Xft.hintstyle:hintfull

- OB autostart - urxvt in daemon mode goes like that: urxvtd -q -o -f &

- browse all possible settings:
urxvt --help 2>&1| sed -n '/:  /s/^ */! URxvt*/gp'

- Transparencies:
# True:
URxvt.depth: 32
URxvt.background: [90]#000000
# native transpency
URxvt*.transparent: true
! URxvt*.shading: 0 to 99 darkens, 101 to 200 lightens
URxvt*.shading: 110

- Scrollbar. Have to define it, have to place it etc:
# scrollbar style - rxvt (default), plain (most compact), next, or xterm
URxvt.scrollstyle: rxvt
# and so on, look it up.

- what icon you want to see in window corner:
URxvt*iconFile: /home/myname/.icons/mytheme/apps/terminal.png

- tabs. Perl-extension thing. Has to be compiled in.
URxvt.perl-ext-common: default,tabbed
URxvt.tabbed.tabbar-fg: 2
URxvt.tabbed.tabbar-bg: 0
URxvt.tabbed.tab-fg: 3
URxvt.tabbed.tab-bg: 0
URxvt.tabbed.new-button: true

# rxvt-unicode is not bad terminal. BUT, if using real Nvidia driver  + Compton + too-new-xorg, it might not be worth the hassle. There are other terminals available - with no config-wrestling.

# PS! Compton + more new Nvidia driver = more likely there are lag-problems... I just downgraded newest 340 to 331 in Crux - as 340 bloody lagged with everything.

Icon cache refresh

Sometimes I play with icons - change them or create new ones. And most excitedly, the folder they are in gets broken/unknown icon pics into it after that.
That means - icon-cache needs to be refreshed. Many distros have a script for that which runs on startup. Or something similar - on one way or another, depends on distro and desktop environment.
But if not, one needs to update cache manually.
Basic and primitive way to do this is gtk-update-icon-cache command. That same app is used also by a lot of nice frontends. The command, in terminal, looks like that, in foolproof way:
gtk-update-icon-cache -f -t /path to your icondir - dir where index.theme is
'-f' means force overwrite old cache despite of it state, '-t' means don't worry if there is no index.theme  file.
Dandy. Yeah, but quite frequently not so - and what you get is:
gtk-update-icon-cache: The generated cache was invalid.
You also see that miscreated file starts with '.' - and it's useless as cache.
I happened to have exactly that sad outcome when trying to refresh my icon-theme cache. After exceptionally frustrating googling, I found that - in my case:
- Only thing that mattered (of multiple web-hints), was spaces in icon names. Not existence of icon-size folders, or of index.theme... or something else...
That means, of course, only that I didn't have other possible problems ... if there are more.

Anyway, I got my very big collected icon-theme validated after I removed all spaces from filenames, and nothing else (well, I also checked if my index.theme was correct. It was).

The script below (Thanks to Michael, stackoverflow) looks also to subdirs so, in idea you can run it from /icons or ~/.icons and get every spacy filename switched.
I did it in slow way - as I wanted to know where problems were. I created test-folder and copy/pasted iconfolders to there one by one, and tried to make cache again. Of course, it's easier to change the script to have 'echo' to show which files were changed... in case you are fluent in bash. I'm not, I am outright moron in it. So I did it mechanically, and found that 3 of 12 folders had 'space-problems'.
And here is the script that fixed it:

#! /bin/sh
# Script what finds spaces in filenames and replaces them with _
# to get gtk-update-icon-cache to validate.

# Change this folder according to needs
cd /home/homeros/.icons/test/mimetypes

find . -depth -name '* *' \
| while IFS= read -r f ; \
do mv -i "$f" "$(dirname "$f")/$(basename "$f"|tr ' ' _)" ; \
done

That was that.

Announcement

As it's obvious, my posting has been somewhat lacking after May.
There are quite simple reasons for that: I seem have reached the last strech of my Linux adventures.
-- I have found two Linux distros I like and keep - Slackware and Crux,
- and so I have lost motivation for more digging around.
-- Also, I do not like at all how modern Linux development turns more and more toward way-of-Windows - sensless bloat, binary blobs, forced unification, idiotic GUI-changes... etc,
- and that means: I am going to try some Bsd's in future (if some of them happen to install this time), but probably not any new Linux distros.

... Might write about some interesting problem (related to those two 'keeper' distros), though.

Crux 3.1, install and so on

# Install is mostly the same as 3.0
- There were slight differences in installable apps - some of them important, see release notes. Also, see Handbook - surprisingly enough, it is corrected for new release (simply, such kind of care is not so common).
So, let's note here some diffrences from 3.0 install:
- fstab (but you still have to fill it out, mostly)
- kernel pre-made conf is more complite/generally-usable.
- network has been split to lo and net scripts, AND those files are already functional.

# Later stuff. See this and this of Crux 3.0 - a lot went the same way.
What differs:
- prt-get sysup. One update was xorg-server. Dependency 'libepoxy' was not noted and compile failed (but I think it's already fixed). Also, after update xorg-server needs drivers reinstalled (I picked libevdev, evdev, vesa, libva and got X started ok).
- Kernel, as a cautionary tale: Despite I was very eagle-eyed when in kernels' make menuconfig, I still missed my sound driver somehow... doh.
So I thought that I create it as a module. Downloaded alsa-driver (and alsa firmware) packages for make&kmod ... and spent an hour with googling/fixing 'configure' (version.h in wrong folder). And then - it still erred (some ioctl stuff) when 'making'. Fuck. So I went and recompiled the kernel. Took me less than 5 minutes... One reboot, alsactl init and sound appeared. What a waste of time - but superbly educational. Maybe.
- dbus is not installed out of box. Now, I didn't have that problem in 3.0 - which might simply mean that I got it at early stages as dependency... Whatever - it needs to be installed now.
- xdotool. Used Pkgfile this time... and got libxdo also installed.
- man: This time, it worked for root OK, BUT, still not for user (error was different of 3.0). prt-get depinst most - and man started up, colors and all ... for a user, BUT not for root. Strange. | Missing export PAGER="most" in root .bashrc, nothing else :) |
- jdk - version in Pkgfile is wrong, fix it.
- gegl (for gimp), footprint mismatch = delete footprint. And Gimp installed without whining despite threatening text in readme. Check URL in Gimps' Pkgfile - at some point of time it is/was incorrect.
- qpdfview, qbittorrent. Neither could make package (bsdtar: *: Cannot stat: No such file or directory). I couldn't find any reasonable lead for fixing that... As I didn't have such a message with any other (NOT-QT) apps, I tend to guess that it had something to do with QT. But finally, I went for simple 'make' and they installed with no fuss.
- fbreader. Missing libpng15.so.15 , ln -s from ver 16 helped.
About libpng - this new one craps pointless wrong-srgb warning messages to everywhere. Very bloody annoying.
- smplayer not recognising mplayer version-and-stuff. It started but didn't play a thing, no video, no audio. I reinstalled mplayer, installed docutils... did something ... and smplayer started to function. Oh good - but, I really don't know what that was about.

That's it for now. I'm sure there will be more. I haven't finished with apps, and I also have some unresolved errors... like 'cannot ioremap fb base' (nvidiafb) at startup...

All-in-all, I am a bit dissappointed - not sure if more in myself or in nature of Crux. Means, I hoped it goes easier second time around. It didn't.
Summary: My level of Linux plus Crux means that it will remain as my second distro after Slackware. I simply don't have multitude of hours to spade-work in google-piles. The perspective of continuous fixing of results of updates makes me ...depressed.
But - as I really like Cruxs' ideas and choices - it's a keeper without question.

Crux 3.0 - 3: later problems

Crux, part 1 and 2.

So, after happyness of 'it's installed, yee' comes usual 'oh shitty, and this doesn't work too'. Means - there appeared more quirks, and some of them still unsolved.
The following is not only 'how to fix Crux', but also 'how to fix certain things in quite general way'.

Advice - good places to track deps and script-configs: http://slackbuilds.org and http://slakfinder.org; BUT, do visit also LFS - as there you get not only deps lists but also explanations and advices. And lastly - apps' home. Last because a lot of those are without any sensible info, or filled with irrelevant drivel.

# GUI su or sudo (as it's annoying to have multitude of terminals hanging around for menu-started sudo apps).
-- First, I tried ktsuss. Made it from different sources, with different configs etc. But - if it wasn't stright segfault, then the thing simply failed with recognizing passwd.
-- Then I tried xdg-su. That worked alright from OB menus, sprouting xterm (after checking for all possible 'friendly' alternatives like kdesu, gksu ...). Xterm for that can be confed as small and in corner of screen. That is - if you have other terminal for normal work. But! - Spacefm doesn't start xdg-su. It looks like it has wrong '-c' parameter in source... As of now - I simply do not know what is good replacement parameter to recompile with. So, no satisfactory gui-sudo-solution yet.

# startup blah: couldn't mount (ext2,3) because of unsupported optional features - Put 'rootfstype=ext4' into your boot command and this message goes away.
# startup blah: Drivel about lvm. If you don't use it, uninstall lvm. I think it comes as dep for something... ie - I definitely didn't pick it...

# SHUTDOWN. I do not have PAM and *kits installed. My usual exit-py-script simply hung ... So I changed script to do shutdown in old way:
groupadd shutdown
In /etc/group , add user to shutdown group, in /etc/sudoers:
%shutdown ALL=(ALL) NOPASSWD: /sbin/reboot  # and the same for /halt
-- if using bash script, make tiny file like this (and another for /halt):
    #! /bin/sh
    sudo /sbin/reboot $*
-- OR - If having some py-script:
Define: os.system("sudo /sbin/reboot") , and the same for /halt
It works alright - and looks especially nice after you add some colored 'echos' to rc.shutdown (and/or rc.multi). Which needs some 'shell-colors' resource-file in /etc ... 

# Windows partitions (ntfs-3g) - no write access:
Add your-user to group 'disk',
ln -sv ../bin/ntfs-3g /sbin/mount.ntfs
chmod -v 4755 /sbin/mount.ntfs
reboot (or logout/login) - and you can write.

# No man-pages displayed at all, but error: sh: most: command not found. Error executing formatting or display command...
-- First, (installed) man port-folder had no packages downloaded or made. At the same time, 'isinst' claimed it IS installed ...
I reinstalled man (-d -u) and packages appeared. Man for root started up - almost. Ie, with silly ESC chars hanging everywhere. After adding 'R' to 'man.conf' line:  
PAGER /usr/bin/less -isR
ROOT started to get clear and readable man-pages. But, for USER man remained with an 'error'.
Then, I installed libslang2 , and after that, 'most'...
Halleluya!! Suddenly I had sillily colorful man for a user working.
... What's odd - there is no colors for root. Seriously perplexed, me. How comes that the app behaves so cardinally differently for different users?
| edit: Well, I certainly had a heavy moment of idiocy - not getting that only problem was missing ' export PAGER="most" ' in roots' .bashrc |

# Spacefm and udevil: Udevil comes 'out-of-repo'. And it has problems with umounting... do for udevil: sudo chmod +s /usr/local/bin/udevil

# I still have startup error for terminus-console-font. No idea why.

# And some solved problems with apps:
-- gcolor2: needs patches (three!). I took them from SBO, patched, and the result compiled ok (no segfault as with vanilla).
-- gimp: problems with deps pkgfiles' URLs. Fixed them. AND there is missing udev machine-id, do:
sudo dbus-uuidgen --ensure
The same id-fix is needed for making qbittorrent!
-- fbreader: also needs a patch, then compiles ok.

Crux 3.1 will be released very soon. That means - I will format my Debian Sid (there will be NO systemd init in my box!) - and install new Crux to this partition. We'll see what gives, compared to 3.0...

Crux 3.0 - 2: Beefing it up

See part 1 - Installation.

So, we have system and xorg installed, network-capable, and bootloader fixed. Time to:
# Get back to Crux and see what gives ... and start adding stuff.

As mentioned before, I complitely missed checking network driver in kernel, and so spent some time seeking non-existing conf-problem ... before discovering that there isn't any driver. After quick re-chroot and re-compile everything was dandy. I system-upgraded and started building desktop:

ports -u  # update/get ports. Downloaded ports go to /usr/ports/
ports -d  # see versions' difference between installed and available
prt-get sysup  # system-upgrade. Take a nap. A loooong nap.

Problems / not-upgraded:
- Perl gave error 404 - version in /usr/ports/core/perl/Pkgfile was old, incorrect. Fix it, and delete md5sum file. Then it compiles.
- atk, gdk-pixbuf, pango, gtk - all missing gobject-introspection. Install it.

Next I got proper video going:
sudo prt-get depinst nvidia
sudo prt-get depinst gl-select
sudo nvidia-xconfig
sudo gl-select use nvidia

I had some strange permissions for and in my /home and X didn't start. Check, fix if needed. Everything there should be 1000:1000 or username:users (if you changed ids to 1000). If things look fishy, do
sudo chown -r 1000:1000 /home/username

Installed apps needed for my Openbox environment (conky, lm_sensors, tint ...)

Exited root and as user:
cat >> /home/username/.xinitrc << EOF
exec openbox-session
EOF

startx

When I was meanwhile in my grub-master Wheezy, I copied most of my various conf files to Crux, and fixed them accordingly. So I got new Openbox with menus and shit up at once (as opposed to normal black nothing).
- First observation - not Openbox nor Conky got image support. Recompiled them with --enable-imlib2 option added to Pkgfile.
- Sensors (in Conky) were not working. I probably left them out in kernel (?). Anyway, they can be added as external module: Did 'sensors-detect', and got names of module(s). For me it was coretemp. I downloaded coretemp.c and its Makefile, did 'make' and then insmod coretemp.ko
Stuck it also to /lib/modules/linux-xxx/kernel/drivers/hwmon/coretemp.ko
It worked and temps showed up.

! To stress trivial: All personal conf -  like .bashrc, .bash_aliases, .profile, .dircolors etc - has to be created or copied from somewhere. Well, of course you personalize as you want ... Crux is not some silly we-know-better-Ubuntu.

# Package management. Yes, see Handbook and see wiki and see prt-get manual, I am not going to quote commands here.
Time to install all those still-missing packages ... after making sure that at least /contrib - besides 3 main ones - is also enabled.

To mention some essentials here (from those 3 main repo-folders):
alsa-utils, alsa-plugins; bash-completion; gdk-pixbuf; gobject-introspection; imlib2; pango; lsof; startup-notification; rxvt-unicode; xorg-font* ... etc etc. After that, and also in between come things from /contrib. I didn't enable any other repos yet - but used separate rsync in some cases.
Crux' packages are really just bash install-scripts, with source URL. Dependencies are mostly listed (and consequently downloaded && installed). That's if you do 'prt-get depinst packagename'. But, dep-listing is not a requirement. Expect surprises once and a while.
When taking Pkgfiles from peoples' repos, always check Pkgfiles - those might be outdated and/or not with conf you expect. Well, there are few errors even in base 3 repos.
Package availability is quite good - for my tastes. And - everything missing can be cooked from source - with Pkgfile && pkgmk -d -i for easier maintenance, or - if Pkgfile-making seems too difficult - with simple ./configure && make && make install (or whatever source wants).

Some notes on installed packages:
- Installed Firefox esr. Unpacked it to /opt  && ln -s binary to /usr/local/bin. This folder has to be created and 'path'ed. Repo has this new nasty chrome-puke version 29 for taking - if one likes such stuff.
- There is spacefm package (Yee!) ... but no udevil. Ignorantgurus' installer works alright, though.
- tint2 is available in antique form only. No surprise here, as tint seems to be quite comatose. I did my usual, and didn't bother with Pkgfile.
- There is wmctrl package, but no xdotool (they both fit in with my openbox setup - not that they are relatives). Xdotool was the last simple 'make' for me (after that I started to create Pkgfiles). Xdotool compiled alright but, didn't copy its' libxdo library. So I did that with cp and then ldconfig to update libs.
- compton+libconfig compiled OK, so did lxappearance.
- With volumeicon there was more hassle - I didn't want to install gtk3 (ver 0.5.0 dep), so I went with 0.4.6. And this one has glib bug (= no compile). At the end, I found the patch, unpacked the source and patched it manually, repacked and compiled successfully.
- I briefly considered installing gksu - but the bloody crap has as many dependencies as a street-dog has fleas... No deal.

All-in-all, I have Crux nicely running, without *kits, gtk3 and display-manager.
Only serious problem still remaining - 'man' is not working. Only thing i get is error about 'display and formatting'. Still no idea what it wants.

# Conclusion.
My home-distro presently is Slackware-current - and I tend to put Crux to nearly same level of pleasantness. Crux is kinda more flexible... dealing with Slackware takes a bit less time. Slackwares' slackpkg (with +) seems to me, maybe, a bit more convenient than prt-get system. But it might be habit talking.
Anyway, I am going to keep Crux, and when 3.1 comes out (with eudev, ie - no systemd perversions), it will rule my linux-roost together with Slack.
Crux is recommended to anyone who wants play with Linux without all bloaty crapware... And doesn't mind messing with compile.
Part 1: Crux install, Part 3: Later problems

Crux 3.0 - 1: Install

Visiting fringes chapter 3. See 1 and 2
http://crux.nu

Now - including Crux to fringes is a lot misleading, especially after pitiable three in 'Fringes 2'. Crux is totally OK source-based distro, pleasantly conservative, works eminently... but, it's definitely out of distros' top 20. Only reason for such a situation - I think, is - Crux is time-consuming to install and renew... seeing gcc compile flicker epileptically for an hour, for example, induces some negative thoughts. Oh, well, Crux also doesn't have anything preinstalled, you have to sweat to get your satisfaction.
But, let's:

# I wrote ISO with dd to USB and booted with no problem.
And landed as auto-loginned root in console. Not being especial fan of fdisk, I had sda8 previously created - and that was the only new partition. I see no reason for swap (with 8GB of RAM), and I don't use separate /home in traditional way. Now:
mount /dev/sda8 /mnt
setup 
I picked /sda8 as my root partition, and next came choosing packages.
Mind! Those packages you see here in repo, in /core, /opt, and /xorg - are NOT all in your puny 250-meg ISO. ISO contains minimal selection for you to get system up and running, and kernel compiled.
It's wise to do a walkthrough in repo-folders, and make clear what is what, what those packages do, and what you really need.

# Package selection.
-- CORE. I left out only btrfs-progs, exim, reiserfsprogs, vim, xfsprogs - as unneeded.
-- Take most of XORG. That, if you are not planning to stay with console.
-- Pick from OPT. Now, picks here depend very much on what you plan to install ... well, as in 'optional' :)
Anyway, here are my picks, according to 'I am going to use X with Openbox and some apps':
atk, cairo, cmake, dialog, expat, fakeroot, fontconfig, freetype, gdk-pixbuf, glib, gperf, gtk, harfbuzz, hicolor-icon-theme, intltool, keyutils, lib*, mdadm, mtools, nano, nfs-utils, openbox, pango, python, rp-pppoe.
After selection, some packages got added as dependencies.
-- As already said, most of packages needs to be compiled/installed afterwards. Whole run takes hours. So, be smart and pick maximum of compiled ones here.

# 'OK' and it copies your selections to disk. Done, no errors on last line?
Ok then, let's chroot, fix some confs and compile our virgin kernel. See here for manual. Next comes, very concisely, what I did:

setup-chroot  # script, puts you stright into fresh Crux system.

passwd  # create your admin passwd

nano /etc/fstab  # fix it, add missing parts. something like that:
/dev/sda8   /          ext4      defaults         1   1
devpts      /dev/pts   devpts    gid=5,mode=620   0   0
proc        /proc      proc      defaults         0   0
sysfs       /sys       sysfs     defaults         0   0
tmpfs       /dev/shm   tmpfs     defaults         0   0

nano /etc/rc.conf  # See here for guidelines. Services I put there were only crond and net. Later I added more - like alsa and gpm...

localedef -i en_US -f UTF-8 en_US.UTF-8

useradd -m -s /bin/bash -G audio,lp,video,wheel -U yourusername
passwd yourusername
nano /etc/sudoers  # enable wheel for sudo.
! Mind! Crux creates ids as 100:101. Which means, when you start to meddle with your other installed Linuxes, you get 'permission denied' shit - as at least Debian, Slackware and even Alpine all go 1000:1000. I fixed that like this:
usermod -u 1000 yourusername
groupmod -g 1000 users
usermod -g 1000 yourusername

Network. See here. I went for dhcp and used example script, and it worked (well, after I got missing driver added and kernel recompiled).
Don't forget to create /etc/udev/rules.d/70-persistent-net.rules
Some silly-looking stuff in there - better copy it from your other Linux.

cd /etc/ports
mv contrib.rsync.inactive contrib.rsync
/etc/prt-get.conf - uncomment - prtdir /usr/ports/contrib
For other repos you have to create rsync files (and add entries in prt-get.conf), like:
cat >> /etc/ports/xfce.rsync << EOF
host=crux.nu
collection=ports/crux-3.0/xfce/
destination=/usr/ports/xfce
EOF
! Good thing: you can also use your local make-dir (where you collect your sources and create packages) as 'prtdir' - and prt-get can see it and operate with your packages.
! Mind! When you do prt-get sysup afterwards, the bloody shit overwrites your freshly-fixed prt-get.conf. So, make a copy before...
For confing pkg and ports, see here.

# Kernel compiling. I went with provided oldish 3.6. That's because Crux 3.1 seems to be coming soon (fingers crossed) - with newer stuff and so on. Also, as my linux-life has shown me several times: Do not go with newest, it might not work!

In 'make menuconfig', take your time and pick all needed... I compiled twice as I missed my network driver at first run. Whole process of kernel creation:

cd /usr/src/linux-3.6.x
make menuconfig
make all
make modules_install
cp arch/x86/boot/bzImage /boot/vmlinuz
cp System.map /boot

Fix/install your bootloader.
Done. exit. umount. reboot. If multibooting, fix your master-bootloader.

! By the way - quite a lot of this command-line conf can be done on other Linux' desktop, in more relaxed way than nano.
! Just to mention: runlevel 1 = single-user, 2 = multiuser, 3,4,5 = not used.

End of part 1. Part 2 - Beefing it up, Part 3 - Later problems

Minix, OpenIndiana, Haiku

Visiting fringes, chapter 2. See chapter 1

Going to extremes now... Fortunately for me, what comes here is more like educational overview, a total hearsay - otherways, I am afraid - I would be now complite drooling and gibbering wreck. I mean - not just slightly nuts as now ... errr ... This longish sentence meant that I didn't install any one of those three, but simply tried to get A Picture by reading various bits and pieces.
The goal of that: Are those three usable as desktop systems?

# Minix
A review, and another.
Minix is independent operating system, not a variation of linux at all. Though it uses Clang as a compiler and some Gnu utilities. There is closer connection with Netbsd nowadays - Minix3 uses their userland stuff. Which is probably very good thing - so they have at least something to use... Package management uses Netbsds' pkgsrc with 'pkgin' frontend.
It's development team has always been marginal - and that's sure way NOT to get WHOLE operational system properly done. Which is, it seems, recognized by Minix project - as focus lately tend to be on embedded ARM.
Some info-bits:
- tutorials and help in Minix3 page are .... kinda like afterthought, semi-finished, raising questions like 'what?', 'and?', 'eh?'.
- installation is non-trivial and by some comments - can be frequently unsuccessful.
- hardware support can be considered ... errr.. hugely lacking.
- There are three window managers available. I myself quite like JWM - but choice of only three here simply means - Minix is not for desktops.
- Quoting: 'Currently, only text-mode browsers are supported under MINIX 3'.
- From 'Goals' of project it's also quite clear that Minix is NOT trying to be usable desktop.
So don't bother to try Minix as desktop system. For embedded systems with arm processor - it seems to be OK. Google Minix Neo X5 and X7, for example.

# Haiku
There are some reviews from 2012-13, this for example.
Quoting: 'The key highlights that distinguish Haiku from other operating systems include: specific focus on personal computing ... blah-blah' - so it's for desktops.
- First - it looks childish and outdated. So, one has to have certain dispositions to like and use it at all...
- Haiku has graphical installer, nothing overly complicated here. That is - if you reach that point - Haikus' hardware-support is (of course) rather limited.
- It uses its own BFS file system - do not expect any other op-system to read Haikus' partition.
- Whole desktop+apps complex is incomplete. There seems not to be any seriously taken and/or flawless app in existence.
Taking to account how difficult and time-consuming it is to create and maintain an operational system WITH usable whole-range bunch of apps, then - Haiku never will be complite. Not ever. No.
According to Haiku looks and (not)functioning - is there any point to try it? No, not really - a) If looking for simplicity, take some flavour of linux-for-simpletons and you get what is not so bloody win31-looking and it even works and has thousands of apps. b) Or if you want reasonably functional retro-look, why not to install Trinity on Ubuntu?
Conclusion:
Last Haiku alphas make colorful desktop-like picture alright, but ... You can't use it really for anything remotely serious.
Oh, well, I can say it, alright: But its obviously interesting for devs which is so good. See?

# OpenIndiana
A review here, quite nice by the way.
Quoting: 'OpenIndiana is a robust enterprise operating system, based on the illumos kernel. Blah-blah ..., and suitable for servers and desktops.'
OI is the only one of three which seems to me usable as desktop op-system. Quite simple to install, though somewhat buggy, and unfortunately in semi-zombie state.
Anyway, brave people who tried, say: it makes (gnome2) desktop and has some (great) apps.
It's based on SunOS and/or OpenSolaris... whatever. Commandline is allegedly close to bsd.
- tutorials, support and helps are quite pitifully lacking,
- It only has x86-version. At the same time - looks like zfs is only installable file system - which some people drool over, but which I consider serious overkill for average desktop-user (and there are compatibility issues with linux),
- when installing, Grub (legacy) has NO where-to choice. Beware.
- there are several good server-apps,
- desktop looks antique. OI has quite a lot of apps ... that is - compared to Haiku. But it lacks others, and really, repos are not big at all. It has several conf-utilities, it has nifty backup-utility...
XFCE and KDE are also installable, but allegedly very buggy.

Despite boasting (on their homepage) enterprise-quality, heritage, and more-big-words; it's one of those op-systems severely lacking dev-resources - and probably will be put to sleep after some more futile struggle.
As I noticed somewhere - a user opined that OI should stick with server-side and stop with desktop... I agree, but I think that it's too late for that. I would be very (pleasantly) surprised if OI survives and prospers.
OI really is a functioning system - as opposed to some which simply pretend. Good.
But there isn't any reason to pick it as your desktop platform. If one doesn't like linuxlands' late antics with systemd, gnome3 and tendencies to blindly fuck-up as much as possible - then PC-BSD is your unix-like desktop system.

For those who prefer shorter forms of information. Usable as a desktop:
Minix - No;
Haiku - hell, No;
OpenIndiana - Yes, maybe, but why?

Slackware, Sid, lags + Nvidia 334.21

To make this shortish story a bit longer, let's start with that I clean-installed Slackware-current over my 14.1 ... because after last patches etc it had developed various quirks which annoyed me a bit. And when the choice is between spending x-hours hunting mysterious faults or spending some 3 hours with new and virginal install/rebuild - I'll pick the last one, period.
Install and rebuild were quite uneventful - nothing to whine over ... Maybe of the contrary - some 2-3 bugs with apps in 14.1 had resolved themselves meanwhile. And it helps to have previous install-list of apps, deps and shit.

But when attempting to install (previously used in 14.1 ) binary Nvidia driver 331.49, I had sudden 'unknown libEGL.so' problem, and no install. So I went for the latest beta - 334.21, which installed with no problems.
... Well, week before or so also smxi in my Debian Sid had got the same driver installed (after Xorg update, as the 'current nvidia'). And I had started to experience some lagging with mouse and keyboard. Sorta, occasional 1-2 seconds before slider moved, or mouse click registered or typed letter appeared. Bloody annoying, that! But, frankly, I thought that the culprit is some other critter of myriad of Sids' upgrades - and that it goes away with next bunch.
Now, after I installed the same driver to Slackware - and at once started to experience lags, I sure reconsidered. As an afterthought - it was most probably some kind of not-syncing between this Nvidia driver and Compton compositor.
Anyway, I didn't want to part with Compton, so I downgraded the Nvidia driver - and successfully, despite:

1. Slackware - previous installers' libEGL crap and no install.
I went to runlevel 3, did separate
sh NVIDIA-Linux-x86_64-334.21.run --uninstall
without letting Nvidia to restore previous xorg.conf (no idea if that matters), then slackpkg search mesa && slackpkg reinstall mesa-9.1.7-x86_64-1 to be sure I don't have leftovers from Nvidia (as I heard, Nvidia overwrites some of mesas' files). Then:
sh NVIDIA-Linux-x86_64-319.49.run
with 32bit support and 'yes' to overwrite xorg.conf.
Success, no whining from installer, AND - no more lags!

2. Sid. Not with smxi help this time, but manually:
telinit 1
sh NVIDIA-Linux-x86_64-334.21.run --uninstall
That finished with installers' ominous whine about leftover symlinks. Whatever... I decided also not to bother with mesa and press on and see what happens:
sh NVIDIA-Linux-x86_64-331.49.run
'Yes, do install' - to installers' worry about 'maybe runlevel 1 is not good...'
With 32bit support, 'Yes' to overwrite conf.
Success, and no more lags!

Simpleminded conclusion: If you experience lags (especially after pointless upgrade to latest/greatest Nvidia driver), try downgrading a bit. Beta really was Beta, in my case.

Debian Sid 64bit and adb push

Took me only couple of days after rooting and already I was craving for a mod. Decided to start restrainedly though, and downloaded Cyanogenmod (rather lean, no bloat, good tutorials, and a lot of phones supported).
... And bricked my S3 when trying to flash Cyanogen from ext-sdcard. Means, I suddenly had a phone without system (which I wiped as per instructions) AND not-functioning update zips and also, a restore nandroid with 'error - failed'.

/ Participants: Debian Sid, Galaxy S3 I9300, rooted with: Clockworkmod Recovery, Clockworks' superuser/
## What gives?
The symptoms and happenings:
I had (when I rooted) copied superuser and some jpg-s to sdcard with ordinary file manager. And I had no perceivable problems... So I did the same again - copied cm-10.2.0-i9300.zip and gapps-jb-20130813-signed.zip to sdcard via file manager.

1. Copying went super-fast, like - poof! ... err, what ... let's see:
-- From CWM-recovery - 'install from zip' - and error, and failed.
I tried (after copying whole sdcard to PC) formatting the sdcard in various ways and copying then stuff back to sdcard:
1,5 Gigs in 5 seconds! Bloody hell, quantum computing! Checked md5-s - and incredibly, they were correct...?... But the usage showed approx 300 Megs of written data in sdacrd... shit this quantum.

Let's go for correct/adviced adb route, then:
2. I installed android-tools-adb from Debian REPO. After playing around with sudo and no-sudo, and after adding file /etc/udev/rules.d/51-android.rules with content:
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666"
-- idVendor number comes when you 'lsusb' and pick your probable sdcard device from output - and it's the first half of ID-number.
I got 'pushing' working ... errr, NO - it took time alright, and gave happy stats - BUT, there appeared NOTHING onto sdcard. Shit and hell...

3. So I thought that maybe Debians' adb is a bit oldish for a newish Android 4.3.1
Downloaded adt-pack - 64bit ! - from dev page, unpacked and tried to run nice new exec 'adb'. What I got was 'No such file or directory'. No error messages. Googled and googled and...:

4. Installed missing 32bit libraries. Yes, 32bit! (Shit and hell and MS!)
sudo apt-get install libc6-i386
sudo apt-get install libncurses5:i386
sudo apt-get install libstdc++6:i386

sudo adb start-server  # and for stop 'sudo adb kill-server'
(sudo) adb devices  # because I am already paranoid with all adb, and add sudo to adb-farting too...
sudo adb remount  # IF you have suspicion that sdcard is NOT -rw mounted.
sudo adb shell  # navigate to your sdcard, keep an eye on it with 'ls -la', to be sure.

Then - holy moment - I did it like that (command as long and precise as possible. Paranoid, I said)
sudo adb push filename.zip /storage/sdcard1/filename.zip
I got 'failed' and 'no permission'... fortunately I had shelled before - 'ls' showed - yes, there is a file! I decided to proceed and see what happens - I copied all files and:

## Phone-side,
(Check that /system and /sdcard are still mounted),
'install from zip'
AND, incredibly, it installed both - Cyanogenmod and GApps.
Unplug cable, unmount /system and /sdcard, reboot.
2 min wait looking at spinning Cyanogen-critter (high stroke-risk!)
and welcome to Cyanogen...
:)
The conclusion: 64bit (adb) + 64bit (debian) should equal 64bit (whatever), and IF there is some third player to take to account, then bloody, this 32bit dependency should be THE required dependency. *&^^&%$%$#%#$.

Rooting guide for Samsung Galaxy S3

... and now, something complitely different...
The point of the following - I did spend much time to find the correct way to root my Galaxy S3 (GT-I9300). So I think that one more guide is proper.

Some useful educational links:
S3 in xda,  how to root S3, how to root with Clockwork, Clockwork-recovery guide.
A bit more blah: It's my first smartphone, and no - I did not feel like more 'socializing' but I was thinking about 'little thingy with database and text editing capabilities I can carry with me'. I started thinking about tablet but dropped the idea as impractical - reaching conclusion that only thing  'always carryable' is a phone. After some reasearch into rooting I bought S3 - as certainly rootable and also currently very cheap.
And - some very basic info about rooting:
- Why? For removing bloatware and to use some apps which are unavailable/un-installable for unrooted devices.
- You loose your warranty.
- You might brick your phone.

What I did:
Installed heimdall in Sid, flashed my phone with Clockwork-recovery and installed Clockworks' superuser.

!- With a new phone, it's probably good to wait for first big system-upgrade of your phone - as after rooting you don't get them anymore.

# Meanwhile, download:
- heimdall files (has readymade debs),
- Clockwork recovery,
- superuser.zip (of Clockwork... and, I lost the link),
- and some wallpapers - which you can test-copy from your PC to phones' SD-card when first time in recovery-mode.

# Install heimdall (two debs, cli and gui frontend) to your debian (sid). I did that with simple dpkg -i. Also, heimdall is in Debians' repo too - but, naturally, those are older versions.
And do get readme from here.

# Open up heimdall: sudo heimdall-frontend. 'Sudo' is a must!

!- Do not proceed until your phone is 100% charged. That's a standard warning. Now, it's not very probable that your phone runs out of juice during those couple of seconds when replacing /RECOVERY - BUT, if it does, you get at least soft-brick. So, do charge this bloody battery.

# Insert usb cables' PC end.
- boot the phone to download-mode : Power+Voldown+Home : accept disclaimer.
- connect usb cables' phone-end.

# In heimdall:
- check 'no reboot' because afterwards you want to go to recovery-mode, not to standard reboot. DO NOT check repartition - as this formats your whole phone.
- in 'utilities' tab - 'detect' to be sure your device is detected.
- save the PIT from your phone. In the Download PIT section of the 'Utilities' tab, click the Save As button, navigate to ~/your-correct-folder-for-that-file and enter a file name such as GT-I9300.pit.
Save.
Also, maybe it's wise to check 'verbose' in 'Advanced'-menu.
- Go to 'flash' tab, browse for .pit you saved. When .pit is found, 'add' button gets activated. Press 'Add' and pick your folder to flash and file to flash with.
Correct folder is /RECOVERY and file is recovery-clockwork-6.0.4.6-i9300.img - at this moment anyway.
Click START button (I did that process twice - as the first attempt didn't do a thing). The second one was a success.

# When/if you get success-message, unplug usb and go to recovery-mode: VolUp+Home+Power
Have this super-guide open in your PC.
- Do system backup to SD-card.
- install superuser.zip (which you already copied from your PC to SD-card together with those wallpapers.
- And do whatever you want... errrr... - Don't wipe your system, but you can wipe cache - which is good thing to do, occasionally.

# Reboot normally. Install terminal emulator and do 'su' there to verify successful rooting. Then install no-bloat and clean out all shit. After that clean out 'no-bloat' too...
And then you can re-bloat your phone with all those very-important-special-apps-you-always-wanted.
I suppose that most of Samsungs' devices (phones, tablets) can be rooted with the same general procedure - if there are proper images to be found.

AlpineLinux install etc

Visiting fringes (chapter 1) or,
to put it diplomatically - trying out distros outside of top twenty.
The point - looking for a new pet when Debian goes systemd, or - God forbid - the same happens to my home - beloved Slackware. Also, seeking some cheap thrill.

Somewhere I noticed that AlpineLinux is a distro with busybox and open-rc. It also has its' own package manager - apk, which has dependency-check. And the distro was mentioned as lean alternative desktop (despite it being officially oriented "for x86 Routers, Firewalls, VPNs, VoIP and servers"). Desktops are: XFCE, Gnome, Openbox, Fluxbox - at least. Slim and lxdm are display managers.
What follows here is: a) A short description of various installs up to desktop; b) At the end there is also short list of apps that are not available in this distro - for pre-consideration, because install certainly takes some time.

# Install (to sda7, without grub)
I dd-d ISO to usb-stick and booted without any problems.
It lands to console, where you login as root (enter). Then:
mount -t ext4 /dev/sda7 /mnt
setup-timezone
setup-alpine -q
setup-sshd
setup-ntp
setup-disk -m sys /mnt
And it should be installed (it was mind-bogglingly fast procedure).
umount && reboot

Then I went and fixed my master-grub in wheezy, added into
/boot/grub/grub.cfg:
menuentry "Alpine Linux, sda7" {
 set root=(hd0,7)
 linux /boot/vmlinuz-grsec root=UUID=ba5767878-4a8c-40ed-b710-c4e2b42d6b7a modules=sd-mod,usb-storage,ext4 quiet
 initrd /boot/initramfs-grsec
}
Rebooted to Alpine.

# Post-install. There is a lot to do - nothing got installed but pure system.
Comment first line  - /media/usb/apks - in your /etc/apk/repositories
or apk will whine warnings all the time.
setup-apkcache  # enable local cache, store packs locally. I am not sure it's needed witk hdd-install, but I did it anyway.
apk update  # update package-list.
apk upgrade  # upgrade what's installed.

And here we go with adding shit and all:
apk add nano  # trying to avoid vim :)
apk add bash bash-doc  # default shell is ash. In /etc/passwd , changed shell to /bin/bash
adduser myusername
nano /etc/group and I added my fresh user to groups: lp, audio, video, cdrom, plugdev, netdev, power, wheel (and whatever).
nano /etc/sudoers and uncommented 'allow wheel members whatever sudo thingy' at near files' end.

Back to adding things:
apk add perl automake cmake build-base qt sudo
setup-xorg-base  # this one is script
apk add xorg-server
Evdev, mouse and keyboard came automatically. But not video:
apk search xf86-video   # to find what drivers there are. For me it was
apk add xf86-video-nouveau
NB! It seems that it's impossible to install Nvidia binary, so, nouveau it has to be.
I did not 'Xorg -configure' - it started without that.

apk add udev  # Manual says that you should do the following below. I forgot, and then I discovered that it was already automagically done ... but whatever:
/etc/init.d/udev start && /etc/init.d/udev-postmount start
rc-update add udev sysinit
rc-update add udev-postmount default

apk add xfce4-terminal xarchiver
First one brought a pile of good things (cairo, pango, hicolor...)
apk add openbox
touch ~/.xinitrc && echo "exec openbox-session" >> ~/.xinitrc

# startx
Now, I suppose that whomever installs Alpine, already has a bunch of confs hoarded - and now it's time to copy-and-fix them for Alpine. From .config/openbox/* to .bashrc and gtk.
After that I installed fonts (search 'font' in alpinelinux.org 'Packages' for suitable ones), gtk+2.0, gtkmm, gtkmm-dev (and with gtk's there will be enormous pile of nice addons), gtk-engines, coreutils, py-gtk, firefox, pcmanfm, geany, feh, conky, alsa.
Alsa wants also something like that:
alsactl init
rc-update add alsa
rc-service alsa start

# What is not there, of my favourite basics:
obconf, lxappearance, spacefm, medit, nitrogen, tint2, compton, smplayer, volumeicon, wmctrl, xdotool...
Wmctrl I made from from source, it needs libxmu-dev.
It's not possible to make spacefm and udevil (in reasonable way) - and that is quite a showstopper for me.
Volumeicon - it compiled, through some wrestling, but didn't work anyway.
That is the point I reached currently.
To mention more not-there-apps-and-shit: LXDE, Mate, lxpanel, leafpad, gedit, libreoffice, meld, gcolor2, qeeqie, chromium ... etc.

# Conclusion
Desktop on AlpineLinux is definitely possible. IF available stuff is of your taste. I am missing some 80% of what I prefere... Compiling in Alpine is ...errr ... hit and miss.
So, despite that I kinda like Alpine - and it's fast alright - it looks, I am on the road again.
Also see - the second round of Alpines' install - Lenovo laptop.

Removing kits, in Sid

I am not exactly sure why I write this... but there might be two main reasons - I wasted enormous amount of time (80% of this googling crap) and need to get at least some kind of visible outcome. And secondly - it might be of help to someone as of 'how not to get results'.

The idea was to see if I can get rid of *kits in my Debian Sid. And possibly of PAM too. This last one I left aside pretty fast - too many unavoidable deps.
What consolekit and policykit do and why they are also shitty and unneeded part in single-user desktop, that can everyone google themselves.

In my Debian Sid I got such deps for kits: they and their libraries, and Lightdm. That was all, and life seemed rosy.

1. I removed lightdm and replaced it with slim (has optional consolekit dependency) from Debian repo.
As a by-thought - Slims' login-screen looks, frankly, like shit... But slim is real light-weight and easy to configure: /etc/slim.conf and themes reside in /usr/share/slim/themes. Graphical part of themes are quite extensive - and not so trivial to change. If pointed to correct folder, slim lists all your sessions automatically.
But never mind that - of course the debian slim had been compiled with consolekit support.

2. Recompiling slim with -DUSE_CONSOLEKIT=no. My installation needed additionally libpam0g-dev for that.
After playing around with original source - I even got it 'made' (after endless tries and some conf and parameter changes) - I decided for making proper debian package.
So I played several evenings with pbuilder and cowbuilder (there are tons of material to read, some heavy packages to install and not very simple conf to conf). I managed to create quite an impressive mess - and finally went for simpler way and used dpkg-buildpackage.
In very concise way, whole thing was like that:
apt-get source slim   # downloads source packages to current folder and unpacks tars in correct way.
-DUSE_CONSOLEKIT=no  - change it in /slim-unpacked-source/debian/rules
change conf in /debian/patches/slim-conf.patch to reflect your situation (less to do afterwards)
dpkg-buildpackage -rfakeroot -uc -b  # in source folder
and there should be new slim.x.x.deb in sources root.

3. Removing vanilla slim and *kits.
Went to console, killed slim and X, then removed slim, policykit, consolekit and deps. Installed:
dpkg -i slim...new-one.deb
Rebooted.
X did not start and dbus did not start (despite I had the second one in .xinitrc).
Manual dbus-launch worked but then X claimed to have a segmentation fault. Bugger!
I reinstalled consolekit - and X started without any problems... Double bugger!
To cut it short, after trying several things - to (unsuccessfully) root out consolekits' leftovers, I threw a towel.
Shame-facedly, I reinstalled both kits. That's that - a defeat.

At the same time - there are cases of successful removals. So, it can be done. I suspect that without display manager (but I wanted to keep it), linux-with-no-kits is possible.

PC-BSD, take 2

I have been feeling restless and somehow unsatisfied lately, kinda missing some thrill in my Linux adventures. Also, some part of it is my disappointment that Debian chose the future of systemd. Means that there will not be next stable Debian install for me. All in all - I decided to start with some slightly radical projects, one of which is new visit to BSD-land.
See the previous one here.

I dowloaded PC-BSD DVD-USB-version of iso, dd-d it to usb-stick:
dd if=PCBSD10.0-RELEASE-x64-DVD-USB-latest.iso of=/dev/sdd bs=1M
and booted it without problems. With my new and better box it didn't take very long for language-menu to appear. Whole installation looks roughly identical to ver 9.2.
Only filesystem available is zfs.
The new installing option is 'grub-slice' for planting grub2 to bsd root. What a joy - at last an option to escape fucked-up MBR, and get grub-generated correct boot-code!
... Well, it wasn't. Joy, I mean.
What I got was grub 'exiterror', indicating something like 'I can't understand so many partitions or labels or whatever'. And installation ended with 'Failed'.
I found quite a lot of the same when googling about it. What I didn't find was the solution.

I mused a bit over it - mind, quite relaxedly this time - as my expectations of successful installation wasn't especially high anyway.
Conclusion:
1. I really do not need zfs for my desktop. It's an overkill.
2. There seems to be quite a lot of difficulties to get zfs pool mounted in Linux - as BSD version of system tends to be newer than Linux-provided zfs-fuse. Means, one has to do various tricks for that, or - to get some common r/w partition for those op-systems (and no, freebsd does not recognize ext4).
3. And - I am not going to repair my MBR because some silly shit wants to overwrite it. One thing I expect from op-system is that it installs as I want it to be installed. PC-BSD still doesn't do it for me.
Formatted this special primary partition I had kept for BSD to ext4, and I might try Gentoo there ...

Because my previous BSD-post had a little part about Ghostbsd, then - I took a look. As is seen there, ver 4 alpha is out (and is based on Freebsd 10). Consequently - no install-attempts just now. But I will try when 4 gets released.

Alsa problem on new Wheezy

I just did Wheezy netinstall to really old box. Athlon64, sound through nforce chipset. Wheezy called the working sound (mostly) 'Nvidia CK804'.
Alsa was installed as per usual:
alsa-base, alsa-utils, alsa-tools, libsound, alsamixer, (and dependencies) and lastly volumeicon (started from Openbox autostart file).

alsactl init did the trick and everything seemed dandy.
Unfortunately, the sound worked alright only to first reboot. Then it didn't anymore, and volumeicon also disappeared (and refused to start from terminal with quite a lengthy fail-message).

I tried various stuff to diagnose and fix:
The simple alsactl init again, and heavier alsa force-reload.
Pried from terminal with:
lspci | grep audio
aplay -l
aplay -L 
and even with hwinfo (install from repo)...
Visited alsas' home for information and for possible source download.
Peeked into files:
cat /proc/asound/cards
cat /proc/asound/modules
cat ~.config/volumeicon/volumeicon
cat /etc/modprobe.d/alsa-base.conf

Conclusion:
1. Nvidia or no, the drivers are:
snd-hda-intel => card0 (default), and not working for me,
snd-intel8x0 => card1, and working when manually chosen.
2. Solution is that the second one should be the first, default choice. And then there wouldn't be also need to change the last block in volumeicon file:
[Alsa]
card=default

sudo nano /etc/modprobe.d/alsa-base.conf
After lines of 'install' and before 'options' I added two lines:
options snd-intel8x0 index=0
options snd-hda-intel index=1

sudo alsa force-reload
And there was sound! And it still is - also after reboot.
That's it.

New hardware, old Linuxes

I swapped out my 5 years old machine to a bit more contemporary one.
Everything except video card (gtx 560) and one irrelevant hdd got swapped out.
Relevant changes were - ahci/ehci mode for hdd-s, new sound chip, new network chip.

Practical philosophy for hardwaring:
Decide what you really need - for example, in my case:
- inverted-layout box, as I keep it against wall and wanted to turn back panel to front (which would have caused blocked cooling for classic box). AND - it's very, very inconvinient to have big video card and hdd-s kissing each other.
- bigger hdd bay, for not cramming several hdd-s on top of each other.
- modular psu, as miditowers are bloody tight really.
- and if you do not need raid or full-ATX or simply-mucho-expencive MB, then really, you don't.
Why back panel in front, you ask? Because it irritates me to have usb-s divided between ends of box. So I cannibalized the front and planted usb-s, switches and leds to back panel, closed holes in front panel and - done.
- There are two things one have to read - as RTFM - MB manual and Bios. Don't skip!

Software, fixing it:
I packed (and backed) up all my current 5 linuxes with fsarchiver. Then I connected the new system-hdd to the old machine and unpacked distros to their new partitions.
When the new box was ready - bios checked etc, it got it's hdd-s installed. First boot was from usb stick (which happened to be PartedMagic).
Usb because, with such a total overhaul there are some things to be done before you can have any hope to see your dear display manager again.

# Did the distros end up on different partitions (of originals)? Open up all etc/fstab-s and correct them. There is no such problem if fstab uses UUIDs (sudo blkid to get whole list) as fsarchiver restores systems with original UUID.

# Chroot.
For that procedure it's better to google and find your own recipe - I am not sure that mine is the very right one.
What you have to do is, basically: mount and bind targets' /sys, /proc and /dev (for debian, better to mount also sysfs) to /mnt, then
sudo chroot /mnt. And fun begins.
Patients: Slackware, Salix, Vsido and my own netinstalled Wheezy and Sid. All need new initrd files (changed drivers!)
- Slackware and Salix have most nice mkinitrd script, currently ran like that:
/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 3.10.17
which works no problems. Run lilo afterwards. In my case, lilo is in root part (not MBR), and has to be run with partition-number: lilo -b /dev/sda2 -c
- Debians: dpkg-reconfigure linux-image-3.x.x... (number is uname -r). Which is dandy, except that uname -r in chroot shows number for host kernel. So I checked up how old initrds look and - seems that everything between kernels' number-start and .gz IS the right thing. Example:
dpkg-reconfigure linux-image-3.11-10.dmz.1-liquorix-amd64
The good thing with previous command is - it also renews your grub.
Done with chroot. 'exit' and 'umount' everything you mounted.

- And that was all that Slackware needed for reaching the desktop.
- Not so with Debians - error: no screens, and no xorg. To cut it short, the solution was  simple: delete /etc/X11/xorg.conf and recreate it. Mind! I am talking of Nvidia binary driver. It installs itself and also makes new xorg.conf. I do not know what happens with other video drivers.

# Network: new chip, new interface = no network.
The important file is
/etc/udev/rules.d/70-persistent-net.rules
Only Wheezy - somehow - managed to create new entry there (with new mac number!), and named it as eth1. And/but - eth1 does not start automatically - still no network.
So, I copied this new entry to every other distro, changed NAME="eth0", and that was that. I still do not know where to find mac numbers :)
It is also said that deleting that file and rebooting creates automagically the new (correct) one.

# alsa gave a looooong list of warnings when starting (but worked). In Slackware, delete
/var/lib/alsa/asound.state
and create new, 'alsactl store', done.
In Debians.... I think it just went away after first boot.

# Sid and sensors. Or, really - no sensors... Run:
sudo sensors-detect, answer questions, let it write modules and run:
sudo /etc/init.d/kmod start
Done.

# Annoyances:
- monitor dimensions changed and some (desktopy) things were not in right places anymore.
- sensors data presentation errors in conky (new cpu, new 'cut's  etc)
- console resos out of whack. None that is possible according to vbeinfo is fitting for 1920x1080. and KMS doesn't work as I use proprietary driver... bugger. Still no solution here.
- some 5-6 irritable hours thrown into googling.
And I am sure there will be more things creeping out.

But all in all - it was quite alright compared to coming reinstall of borked Windows. Always hated that...
'Old Linux in new box' can be summed like that: fstab, initrd, 70-persistent-net.rules. Done.

Tweaking JWM

Joe's page .
But see also Puppy and archwiki.

# JWM, install in Debian Sid, from repo, one file only.
Conf - one file only, copy /etc/jwm/systemjwmrc.conf to your home as ~/.jwmrc

# Tweak.
Jwm is definitely quite simple WM, but - surprisingly tweakable, at the same time.
For refresh - Jwm has nice 'restart' for you, almost only thing in menu that works out of the box. Yes,  menu building is manual. At the same time, Jwm seems quite lenient to syntax errors - just applying defaults, and not crashing (like Openbox).
All essential can be found on Joe's page. Start from this. Mostly, it's troublefree - read and apply. Mind, there are two distinctly separate parts for tweaking (with varying scope) - features and styles. Means some shuttling back and forth.

Some notes:
- Swallow lets you get some apps' (simple) output onto panel...
I inserted my narrow conky there, and it worked... errr.... It ate Jwms' clock (as conkys' positional command seems to overrule Jwms' efforts. AND!
CPU usage in idle went to 6-7%, which is scandalous. Seems that Jwm and swallowed conky are not best friends... So, I made panel shorter and planted my conky outside of it, to right bottom corner. Problem solved - usage dropped to normal 1-2%.
And that after previously startupping compton with:
compton --backend glx --vsync opengl-swc --paint-on-overlay --shadow-exclude "! name~=''" --config ~/.compton.conf
spacefm with '-d' and also feh for background.
Also, pleasant surprise was that my wallpaper-changer script worked under 'Desktop / Background /command'.
- Group: A lot of options here... but... Oh well, there are things like 'constrain', 'layer', 'nolist' - but see yourself (link one). For group classes, do xprop WM_CLASS and click then on window, and info will be in terminal.
- WindowStyle - border and title. Look also here.
Quite a lot is supported. Fonts etc can be regulated in separate cases, colors for fg and bg, the same for 'active / inactive' - good, I like playing with colors.
Tray items change active / inactive color-behaviour according to mouse-over - and that's because default FocusModel is 'sloppy', not 'click'.
- Keybinds - related to window, mostly, and as such, quite unexciting for me - mouse-oriented as I am.
- Mousebinds - nothing much of interest here.
- Menu - for unactive, there is no gradient. But, there is for active...
- Desktops. The usual... different is that a lot of them are there by default. This multitude can be culled by row (width) and column (height) numbers.

- Window start positions - maybe I missed it, but there doesn't seem to be that option. And that's a thing I would like to have.

Conclusion: Again - no, I am not going to convert, but I keep Jwm for futher playing and who knows... Taken as a panel Jwm is somehow more exciting than lxpanel. Made me feel that I can get more. Probably it's subjective - but also, Jwm feels to me graphically nicer and slicker than Fluxbox. It appears that quite a few of options are new with fresh Jwm v2.2. Keep up with the good work, Joe. And thanks, Puppy Slacko, for drawing my attention to Jwm.
A pleasant experience indeed.
Edit| I have to tone down my excitement: Did new netinstall Wheezy for my 4 year old son, and as I considered him a good test subject - installed Jwm.
Result: Jwm got half-transparent when compton came to play, and youtube flash crashed totally in every browser (strange that). So I swapped to Openbox - and everything was alright. I didn't bother to investigate deeply. Anyway - I will be wary next time. |edit

Salix upgrade 14.0 to 14.1

I haven't used my Salix some month... lately because "let's upgrade before...". Or, to put it differently - after Slackware-proper is installed with all custom adds, then there is really no reason to go for 'easy'. Because tuned Slack is easy, and one finds gslapt kinda... strange.
So much of philosophy.

Essential links for how-to-upgrade: salix and slackware.
How I did it, in my Openbox Salix, step by step:

1. New sources: swap 14.0 to 14.1 in /etc/slapt-get/slapt-getrc and slapt-srcrc
2. slapt-get -i xfce4-terminal
The name of the terminal changed, back to proper one. It's sensible to install now, and also change links in your menu.xml and rc.xml (and don't forget tint launcher).
3. ls /var/log/packages/ker*
Get the list of installed kernel packages.
4. slapt-get -i kernel-xxx
Swap out everything (needed part is like 'kernel-headers', and NO numbers). Here is the point to decide: IF writing kernel files over OR installing paralel (can be accomplished with 'installpkg precise-packagename'. I decided to overwrite because I already knew (from Slackware upgrade) that new kernel works in my machine.
5. /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 3.10.17
This gives you proper command for creating initrd, in my case it was:
mkinitrd -c -k 3.10.17 -f ext4 -r /dev/sdb2 -m mbcache:jbd2:ext4 -u -o /boot/initrd-generic-3.10.17.gz
Initrd name I changed, as I wanted it to be more informative.
6. update-grub or lilo -v
To get your boot-manager aware of kernel change.

7. Now I went to console, logged as root and did 'telinit 3', then:

slapt-get -i glibc
slapt-get -i slapt-get
slapt-get --upgrade
slapt-get -i udev

There was a PILE of warnings about symlinks and folders and whatnot... But for me, afterwards, everything came out OK.

8. If using proprietary driver (whitch you downloaded before):
NVIDIDA: sh NVIDIA-Linux-x86_64-319.82.run --kernel-name='3.10.17'
Let it install and create xorg.conf too.

REBOOT.

My desktop came up without any problems.
Then I started to check EVERY installed app:
- compton needed recompile (missing lib).
- clementine did not start, I reinstalled and then it wanted additional libary - chromaprint, I got it from sbo.
- qbittorrent not starting but upgrading to latest available version from Salix repo fixed it.

Everything else seems to work.
Unpleasant surprise for me was that 'custom' repo (my package folder) in slapt-getrc is not working - 'can't find file'. So I did all upgrading from there manually. Whitch deepens my feeling that I really don't need Salix when I have my 'tuned' Slackware.

Otherways... CPU-usage tends to be 3-4% idle - too much.
But all-in-all - very good outcome. Even a bit better, missing-library-wise than real Slack. Congrats, Salix team.
And we'll see if new problems appear or not. If yes - there will be 'edit' here.

Tuning fonts

Not an essential thing - but..., well, better picture looks better.
Now, I did most tweaking in Slackware, and Debian differs.
Mind, very much of fighting with fonts is try-and-test. No 100% recipes here.

'Fontconfig warning: '/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.'
When starting some app from terminal, the previous message is not uncommon.
Essentially, it doesn't mean anything practical - for now. Simply, somewhere in future, fontconfig starts to search for things somewhere else. /etc/fonts/conf.d/50-user.conf specifies those 'future folders'. At least currently Slack doesn't have those folders. But whatever.

Here come some very useful links:
Console and more (Slackware)
Desktop and font substitution - both links are from Ubuntu, but it mostly is universalish... It's always a good idea to look into Archwiki.

# Console, and I am following the text of Slackware-link provided above:
Terminus font is good, do it. Console text gets ... much fuller-looking.
In netinstalled Debian, terminus is not installed by itself. But it is in repo.
I am not sure if Slacks' .bashrc  piece works in Debian... There are two other options: see here, or run following and make your choices:
dpkg-reconfigure console-setup

For checking what's your dpi: xdpyinfo | grep resolution
- I have gdm in Slack, so I added
0=/usr/bin/X11/X -dpi 96
to [server]-part of my /etc/gdm/custom.conf . Better (easier) to reboot for effect. And it worked.
As a comment - I had my Slackware console looking a bit ... chewed - textwise. It was exactly that dpi (somehow) was not proportional. The same (but worse) goes for Debian Sid.
- In Debian /etc/lightdm/lightdm.conf and lightdm-gtk-greeter.conf are the patients:
The first one - outcomment and add to the end
xserver-command=X -dpi 96
The second one - has to have this:
xft-dpi=96

Adding more fonts (into separate folder): good, even super advice - do it like that in Slackware, it works. I haven't tried this in Debian(!).
Webcore-fonts and google-fonts are quite must - if nicer look is what you want.

# I am not vouching for various subpixel rendering stuff in this tutorial - I didn't try it yet. The same with 'Miscellaneous'. But - You try it it and advice me.

# Font substitutions. Following tutorial in Ubuntu forum I swapped Helvetica Neue to Lato (latofonts.com, its free). It worked for me, kinda (means, I am not very happy with this particular swap).
In Debian Sid you can't use ~/.fonts.conf, instead, the same stuff goes to /.config/font-master/local.conf
In Slack it can be in ~/.fonts.conf

# Fonts used on OB 'desktop': Two GUI-options are available, Obconf for menu and window titles, and Lxappearance for what is in those windows'.
After various combinations tried, I have settled with DejaVu , Droid and Arial (except terminal).
This, of course, is individual thing. Feel free to experiment.
It IS possible to get desktops' textwise appearance better.
The same with console - especially vanilla netinstalled Debian looks like shit in this department.

Second Conky for weather

I went even further with my blingish adventures... Somewhere - related to tweaking conky - I stumbled upon weather forecasts. The thing never interested me much - as I don't consider weather-forecast overly trustworthy activity, and also, I didn't feel need to complicate my Linux-wrestling with trifle things.

Well, it suddenly felt alright now.

Here it comes - very simple conky with very simple layout, and launched from Openbox root-menu.

Essential link. The same info can be found in Cruchbang forum. From here (or there) you can get scripts for automatic download of data and conkyrc-s for presenting it.

I didn't change the script (except the URL of weather-data page), but I changed conkyrc quite heavily. I didn't want pics and special fonts and stuff - I wanted it to be functional, period.

Currently it looks like that, but will be tuned a bit more. Screws are for fitting in with my slightly-steam-punkish theme.

No code comes here for conkyrc, but two very helpful links:

Conky config commands and variables for them. 

Essentially: go get script and conkyrc. Tune conkyrc. Almost done.

Almost, because maybe of interest is:

- getting weather-conky working and quitting according to need. I, for example, do not want it sillily hanging on desktop - temperatures doesn't change so fast that it should require permanent watch. 

And here comes code for that. Which is borrowed in very big extent from Ubuntu forum.

/bin/wconky.sh - checks for weatherconkys' pidfile existence in folder where it's created. If it's already there, kills conky, if it's not there, starts conky and writes new pidfile.

#!/bin/bash
# ----------
# Simple script to start/kill weather conky

# folder where script is and data will be
basedir="/home/user/accuweather_conky/"
# pidfile name
pidfile="$basedir/weatherconky.pid"
if [ ! -e "$pidfile" ]
   then
   PROG="conky -c /home/user/.conkyrc_acc_int"
   $PROG &
   PID=$!
   echo $PID > "$pidfile"
else
   pidkill=`cat $pidfile`
   echo $pidkill
   kill -9 $pidkill
   rm $pidfile
fi

exit 0

Why this pidfile stuff? Beacuse I already have one conky started from autostart, with nice minimal sys-info, and I don't want that one killed (with killall). And naturally I am too lazy for pgrep and manual kill -9.

I stuck the script into main OB menu, just before 'exit'. No mysteries here: simple 'sh wconky.sh' as the execute command.

And that's it. Click once - get weather, click second time - no weather.

It was mildly interesting thing to fiddle with. It's usefulness is still in doubt.

Tint2 launcher, screwed

... and Conky screwed too

So I played with wallpapering Openbox, one thing led to another and I decided to amuse myself with panel-decorating, bitmapwise.
Tint2 doesn't support adding image as a panel background and consequently - only option is to stick 'panel' onto wallpaper. Easiest to do it is with layered Gimp file - so you can shuffle your wallpapers under panel and then export them as paneled wallpapers.
Now, what I wanted to do, was very slightly steampunkish appearance. Nothing overwhelmingly fancy like brass pipes, cogwheels, rayguns etc. 'Classic' SPs enormously overstuffed spaces are not my cup of tea.
I am not going to explain my confs' parameters here. Tweaking is reasonably easy thing to do - if using material here (tint2), and here (conky), and here (conky).

It came out like that:

-- wallpaper and 'panel'-ribbon below tint and conky are one jpg.

-- Left side, width 71% - is Tint2. All on-top backgrounds and borders are done by tint and so, easily tunable. Launcher has 5 png-icons.
- Left screw in launcher opens Openbox menu (xdotool key super+q
as exec in obmenu.desktop). Desktop file has to be made. Keybind itself has to be also defined, of course, in rc.xml (for 'root-menu', and here the same key is 'W-q'). Xdotool might not be installed by default (it is in Crunchbang and Vsido). In Slackware it is not installed, but can be made from SBO .
- Right screw is 'show/hide desktop', also through xdotool, key 'super+d'('W-d' in rc.xml).
As both those actions are quite pointless (why not to use keybinds stright...), then other tasks can be put here - exit script, weather conky, or whatever.
When making screws or other tiny icons - make png-s bigger with transparent padding, it gives bigger clickable area. Those here are 16px visible, but 24px with transparency.
Whole tint-tuning is simple playing around with numbers and colors (gcolor2 helps with choosing colors). Though, this play-around takes considerable amount of time...
... Of easy tunability - I haven't yet found error-proof way to restart tint (to see changes). For example:
'killall tint2' and start = corrupted taskbar/tasks (double?)
'kill -9 tint2' and start = no systray items
'killall -SIGUSR1 tint2' and start = corrupted systray (double?)
So, after a while I end up doing logout/login, and then decide that's enough of tint ...


-- Right side, 477px wide - Conky. Conky supports background images. So this dark-brown background-with-screws png-file sits in Conky.
I have to say - it took me some time to get Conkys' conf right. Partly because Conky (also) is not loading everything anew when conf is saved and Conky refreshes. Took me some time to realize that... Better to go for killall-method.
Key thing here is to comment those
#own_window_argb_visual yes
#own_window_argb_value 0
#own_window_colour 534821
and leave the next one working and 'yes'
own_window_transparent yes
Beacuse 'argb' things make your image transparent too...

Tuning conky is a bit trickier than tuning tint2. When pressed to this narrow form, quite many numbers have to be expressly '0', like border_inner_margin 0 for example. And see CPU-usage - it has to have spare space to expand. When numbers get into tens, you don't want your whole conky jumping bigger and hitting volumeicon or whatever.
Oh, and those screws here are just decorations.
What complicated things for me was - I didn't want to add panel to every wallpaper. So it turned to balancing act between tint on relatively light panel and tint on relatively dark wallpapers. It boiled down to playing with colors, and using upper layer (tint, conky) backgrounds without very much of transaparency.

And conclusion: oldish-90s-looking panel can be done with tint and conky. Also, I really like the idea of using screws as launchers. :)
Oh, and - do really use those tint and conky links, and info there - as all possible commands are NOT included in default conf files.
| NB! As it was my first time to include pics, I was quite annoyed when I got persistent error with inserting pics (impossible to insert)... Turned out that Googles' spymasters want popups and all cookies enabled... So I installed separate browser, all security-panties down, just for 'insert pic', and nothing else. But cookies will be deleted afterwards anyway. Quite, quite irritating. |