WARNING: The method showed here could not prevent the actual execution of "rm -rf" if the "UNIX vandal" is clever enough. Proceed at your own risk, and make backups!
</strong>
<p>
I like Rick Astley late 80's songs, and you can see them here in my Spotify:
<span class="nb">alias sudo</span><span class="o">=</span><span class="s1">'sudo '</span><span class="c"># this enables aliases in sudo, see http://askubuntu.com/questions/22037/aliases-not-available-when-using-sudo</span></code></pre></figure>
Since <code>alias</code> is not able to control the flags of the aliases (see
<a href="http://apple.stackexchange.com/questions/50963/how-do-i-add-a-flag-to-an-alias">here</a>, we are going to redirect each call of <code>rm</code> to
<code>/bin/rmAlias</code>, that would run the command if it is safe. I did
not use a function because it is a bit tricky to make that work with
<code>sudo</code>. So, let's see the code I put in <code>rmAlias</code>:
<span class="nv">ROLLVIDEO</span><span class="o">=</span>/opt/anti-rm/serious-video.mkv <span class="c"># it's just Never Gonna Give You Up on my system, but be free to customize this!</span>
Restart your shell, and enjoy. If you want to test safely, I suggest trying
to run <code>rm -rf</code> with no folders or a nonexistant one, since this
script stops even these commands.
</p>
<p>
If you want even more security, you can rename this script to
<code>/bin/rm</code> and move the original one in some other place, getting rid of all the aliases. I prefer the solution above because it's tidier: you haven't to move anything. In fact, this could be just an AUR package...
<title>Installing Gentoo on a Lenovo ThinkPad X60s</title>
<description><p>My only laptop is a <a href="http://www.thinkwiki.org/wiki/Category:X60s">IBM/Lenovo ThinkPad X60s</a>, a top line “ultrabook” from 2006 that features:</p>
<ul>
<li>An Intel Core Duo L2400 dual core 32 bit CPU, clocked at 1.66 Ghz;</li>
<li>2GB of RAM;</li>
<li>60GB of SATA1 hard drive;</li>
<li>Wifi, Bluetooth, trackpoint mouse only, 56k modem, and a decent set of I/0 ports (including a CardBus slot!).</li>
<p>This machine had an installation on Arch Linux, and I was using it for school stuff. It runned smoothly KDE5, Atom (great editor, I’m using it to write this article), and it was usable even with Phpstorm. Pretty impressive for such an old thing, right?</p>
<p>Since now I don’t need this laptop every day I decided to give a try at Gentoo, another rolling relase, DIY install distro. This was both a test of my skills, my patience and the performances of the machine. For those of you that don’t know, Gentoo hasn’t binary packages: imagine using Arch with just a developer mantained AUR.</p>
<p>I followed the <a href="https://wiki.gentoo.org/wiki/Handbook:Main_Page">installation guide</a> without any problem until I had to emerge and install 309 packets from my <code class="highlighter-rouge">@world</code> set: it took 15 hours! The compilation of <code class="highlighter-rouge">cmake</code> crashed because of memory starvation, and so I had to use a spare USB stick as swap (the root file system wasn’t resizable as it was JFS). After some research and a couple of seconds in <code class="highlighter-rouge">top</code> I discovered that <a href="https://en.wikipedia.org/wiki/Physical_Address_Extension">PAE</a> was not implemented in the install disk kernel. TIP: if you want to use a nicer install enviroment, use the Arch ISO. With gentoo, the initialisation of the file system is made with a <a href="https://wiki.gentoo.org/wiki/Stage_tarball#Stage_3">stage 3 tarball</a> and not by tools like <a href="https://wiki.archlinux.org/index.php/beginners'_guide#Install_the_base_packages">pacstrap</a>.</p>
<p>I had another problem with <code class="highlighter-rouge">make menuconfig</code>, the tool used to specify what features add or remove in your compiled from source Linux kernel. The ncurses menu showed me 64bit options, even if the install disk and the CPU were both 32 bit. If you have this issue too, you can set the <code class="highlighter-rouge">ARCH</code> variable by your own:</p>
<figure class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="c"># make ARCH=i386 menuconfig</span>
<span class="c"># make ARCH=i386</span>
<span class="c"># make ARCH=i386 install</span></code></pre></figure>
<p>At the end, I made it! I only have a base install, but i can show you <code class="highlighter-rouge">screenfetch</code>:</p>
<p>I’ve not installed Gentoo in dual boot because I didn’t figured out how to switch my bluetooth dongle in HID mode yet, so I can’t select the OS with <code class="highlighter-rouge">rEFInd</code>. Hope this rambling was, if not useful, at least entertaining!</p>
I've recently got a Rapoo E6100. This is a minimal and space saving Bluetooth 3.0 keyboard. If you pair it with Windows 10, it will remain paired after reboot, giving the possibility to use it since the login screen. After installing the Bluetooth stack on my Arch via the <code>bluez</code> and <code>bluez-utils</code> packages I thought the pairing process would be as simple as Windows if I used the KDE GUI menus for Bluetooth management. That's not true. The keyboard, once paired, will reconnect automatically just after <code>plasmashell</code> loaded, leaving me without keyboard during the SDDM login screen and, of course, during a non-graphical session.
As usual, i've searched help in the ArchWiki, founding <a href="https://wiki.archlinux.org/index.php/Bluetooth_keyboard">this</a> article. With that, i've succesfully reconnected my Bluetooth keyboard using the <code>bluetoothctl</code> utility. The next step was configuring the service for auto connection during boot. I've created the <code>btkbd.conf</code> and the <code>btkbd.service</code> files, enabling the last one with systemd. Let's give a look to the service file:
<span class="nv">Description</span><span class="o">=</span>systemd Unit to automatically start a Bluetooth keyboard
Line 13 enables the Bluetooth dongle, and line 16 connects it to the keyboard we gave the mac address in <code>/etc/btkbd.conf</code>. This should work flawlessly, right? Of course it doesn't. The service starts before the <code>dbus-org.bluez.service</code> is loaded and fails. However, if the service is started manually after login the Bluetooth keyboard works. After hours of trying figuring out what was wrong I've almost asked for a return on Amazon! The last attempt I made was with sddm disabled and involved built from scratch service:
<span class="nv">Description</span><span class="o">=</span>systemd Unit to automatically start a Bluetooth keyboard
This incredibly worked. I think the problem was that <code>multi-user.target</code> that needs to be reached earlier than <code>bluetooth.target</code>. I got rid of all the tidiness of the ArchWiki solution just to be sure that was not the problem, but I think you can use all of that just correcting <code>WantedBy=</code>. Currently I haven't an ArchWiki account nor a forum one, but as soon as I'll register I'll correct the article.
Last thing: I discovered that my Bluetooth dongle is CSR 8510 A10 based so expect some ramblings about <a href="http://www.0xf8.org/2014/02/the-crux-of-finding-a-hid-proxy-capable-usb-bluetooth-adapter/">hid proxy</a>.
