Welcome to ashmew2.me
GUIs : Are they really what we want?
My Adventures with the official NVIDIA Drivers
Keeping the KolibriOS Community Together

Keeping the KolibriOS Community Together [ Programmatically ]

As KolibriOS has a small community of developers and users and
potentially new developers keep showing up from time to time,
it is highly important that the community be reactive to such
changes and welcome users and developers alike.

The scenario:
There are two points of contact for "Chat", one being the
official #kolibrios channel on Freenode, and the other being a
PHP + JS based web chat available via the official forums.

The Problem:
Some developers and users only use IRC, while some only use
Forum Chat. This creates a divide as some ideas that are
discussed on IRC or the forum chat stay in only one location.
Also, some times new users that come by on the IRC or Forum
Chat do not get responses as people might not be active at
the time.

The Solution:
Connect both the IRC and Forum Chat, so that messages sent
to the IRC Channel are relayed to the Forum Chat. This should
work in the reverse direction as well. This will let the users and
developers use the Chat platform that they want while still being
updated with what's happening on the other side. This will keep
the community together, active, as one.

The architecture:
The solution has two major components:
- IRC Watcher :
  - Watch the IRC channel #kolibrios
  - Queue all messages received on the channel for ForumChat Watcher.
  - Send messages to the channel which come from Forum Chat.

- ForumChat Watcher
  - Watch the Forum Chat and queue all received messages.
  - Queue them so that IRC-Watcher can transmit it.
  - Send messages to forum chat which arrived through IRC.

Both components are in Python, Forum Chat Watcher uses Selenium[1]
while the IRC Watcher uses Sopel[2]. They communicate via local
storage to keep the overall architecture simplified.

You can find the sources on github[3].

This is a small step in the direction of achieveing a growing
and sustainable community around KolibriOS. To infinity and beyond!

[1] http://selenium-python.readthedocs.org/
[2] https://sopel.chat/
[3] https://github.com/ashmew2/IRCBot

Date - April 12, 2016, Tuesday

My Adventures with the official NVIDIA Drivers

2011 - Windows 7 - Works fine
2012 - ... - Windows 7 - Driver upgrade breaks driver and now only BSODs occur

Since steam was ported to linux, it was time to bid farewell to Windows.

2016 - Boot into Gentoo,

mount /dev/sda2 /media/Windows
cd /media/Windows
rm -rf WINDOWS
#Only remove WINDOWS to kill Windows installation but keep data alive.

Installing the NVIDIA driver afterwards was quite a bit of pain, especially owing to the kernel modules that needed to be enabled on my 3.3x kernel (to support hybrid graphics on my XPS l502x machine). But after a long time figuring out that the Intel modesetting needed to be enabled by default, I could finally emerge the nvidia-drivers on Gentoo
(following this guide: https://wiki.gentoo.org/wiki/NVIDIA/Optimus)

The NVIDIA Driver would not install, and keep spitting some compile errors related to slab allocator.
I asked on the IRC channels, but apparently no one knew and I got no response on how to fix this.
I disabled the pax USE_FLAG in my GLOBAL USE_FLAGS variable for portage, and it worked.

Sadly enough, just after a few minutes of setting up xrandr offloading bridge between the Intel and NVIDIA GPUs, I got a freeze. I thought only X crashed, but nothing would work. I rebooted thinking maybe it will go away (1 in a billion chance), but unsurprisingly it happened again. But this time i was prepared with another system SSH'd into this machine.

dmesg revealed a kernel crash due to the NVIDIA Driver.

OK, so maybe my card is really fried..
Some discussion on #archlinux and #gentoo gave me hope that the official drivers are a mess..so maybe the card isn't broken after all.

After looking around for some time trying to fix the crash, i finally decided that I will use nouveau. Now there are a lot of tutorials and boards out there advising you to use Official NVIDIA + Intel drivers mixed in with Bumblebee, but that wasn't an option for me. So I enabled the nouveau modules, blacklisted nvidia module , removed nvidia-drivers and installed xf86-video-nouveau.

How do you run Hybrid graphics with nouveau?
Tried bumblebee, It wouldn't function with optirun.
Installing primus as a bridge to bumblebee did'nt work either as it kept trying to pull in nvidia-drivers and I was too restless to fix the code right then.

Enter nouveau documentation.

(The DRI2 section)

So I could use DRI_PRIME to get my card going with nouveau and Intel. Sounds like a good way out of this mess.


After a few minutes of running X, the same crash happened, although this time nouveau revealed a lot more about the crash compared to NVIDIA's proprietary blob.

dmesg showed:
NULL Pointer dereference in the kernel.

There seemed to be a few bugs floating around the same issue but no real solutions. So it was finally time to go onto #nouveau, and they suggested I should consider moving to DRI3, the latest kernel, the latest intel drivers, the latest mesa, the latest xorg-server and the latest nouveau drivers.

In order to move to DRI3,

I enabled ~amd64 to install upstream testing packages from gentoo.org to grab the latest packages.

Hacked the ebuild for media-libs/mesa to remove the --disable-dri3 part and add --enable-dri3 instead of that.
Make sure you do not have the bindist USE_FLAG set as this prevented installation of OpenGL Version > 2 on my machine.
After changing to "!bindist", I could get a more recent version of OpenGL reported by glxinfo.

After installation of DRI3 enabled X packages, I had to create a simple file for X configuration at /etc/X11/xorg.conf.d/intel.conf with these contents:


Section "Device"
Identifier "intel"
Driver "intel"
Option "DRI" "3"

#End of file

This was done in order to force the intel driver to use DRI-3 instead of DRI-2.

Making sure that DRI3 was indeed enabled, this command came in handy:

LIBGL_DEBUG=verbose glxgears

After making sure everything was set up for DRI3, I didn't need to set up the xrandr offload anymore.

And finally I can run stuff without crashing using:

DRI_PRIME=1 steam

No crashes, more FPS and no stuttering.
Thanks to nouveau and FOSS, I don't have to throw away my NVIDIA graphics card which the official driver forced me to think is broken and useless.

A part of this and some other details I gathered from my experiences with messing around with these drivers are posted on the Gentoo Wiki,
Here: https://wiki.gentoo.org/wiki/Hybrid_graphics


GUIs : Are they really what we want?
The GUI invented for systems in general on Linux (From X windowing managers
to full blown Desktop Environments like Gnome/KDE/Unity) seem adamant on
destroying the reason for their creation : Simplicity. Given a terminal
and a fancy GUI environment, which would you prefer? I would definitely
prefer a CLI compared to contemporary graphical environments because of the
sole reason that I want to find stuff without thinking where in the
menus would it be hidden.

A usual point that is raised in discussions of CLI v/s a GUI is that GUIs
are far better for someone who's new to the whole scene of computers. But that's
the catch, you can't advocate that using Windows is easier than using the
Linux shell because it would be an unfair comparison. If someone has never
been exposed to the Shell and it's wonderful set of tools, he/she would
obviously find it intriguing. Consider someone who has never used Windows,
and has only typed away at a UNIX shell all his/her life. Would they still
find Windows easier? I don't think so.

The aim of computers and smartphones was to help people achieve what they
wanted in a simplified manner, which seems to be going away. Personally,
I cannot even stand using Windows 8 because it's too complicated. I remember
trying to find the shutdown button for about 10 minutes because for some reason
the Alt+F4 key combo wouldn't cut it.

It's upto the reader to consider this as a pointless rant or something that
raises a deeper question, are we headed the right way? As far as usability
of our own machines is concerned. Why would anyone want their machine to be
full of bloat when the simplistic option is available? Agreed that we have
super fast beasts (Quad Core, and so on..) but still, why waste resources?

Date May 5 2015, Tuesday.