The longer this pandemic drags on, the better the technology decisions companies make. This is entirely due to the lack of executive exposure to enterprise software ads in airports.
— Corey Quinn (@QuinnyPig) April 15, 2020
Making the stupid caps lock into something useful is simple. Bind the COMPOSE function to it and have great time writing special characters.
Edit the file /etc/default/keyboard
Find the line for XKBOPTIONS and edit that to read
Reboot your system and be happy.
I found that my Lenovo laptops did not always get the mousepad right when coming out of sleep or hibernate. After a bit of research I found that a modprobe remove and insert of the psmouse kernel module did the trick.
To automatize this you can insert a file in the systemd control structure to fix the problem yourself (if you are experiencing it). Below is a block of code. Save this to a file in /lib/systemd/system-sleep/touchpad
#!/bin/bash # 2019 Täpp-Anders Sikvall # Reinsert kernel module for mouse pad on lenovo after waking up # from a sleep or a suspend so that things like gestures work # properly # bugs to firstname.lastname@example.org case "$1" in pre) exit 0 # Do nothing just return ;; post) sleep 3 # Wait for system to stabilize modprobe -r psmouse # Remove psmouse from kernel modprobe psmouse # Reinsert psmouse to kernel exit 0 # Return no error ;; *) exit 1 # Normally we should not be here ;; # but if we are, return error esac
Recent update to one of my laptops made the keyboard completely stop working. While rebooting to the previous kernels made it work again.
The kernel that’s the culprit is the generic kernel 4.0.15-29 which does not even work in recovery mode. I have disabled this kernel on my system but could not find information out there about others with similar symptoms so I am writing this here in order to quickly get something out.
Teamviwer relies on a bunch of 32 bit dependencies you need to enable for it to install. This procedure should work:
sudo dpkg --add-architecture i386 sudo apt-get update wget http://download.teamviewer.com/download/teamviewer_i386.deb sudo dpkg -i --force-depends teamviewer_i386.deb sudo apt-get install -f sudo teamviewer --daemon start
I always suggest you take a snapshot before if your file system supports this just in case.
I felt this needed to be shared with a broader audience. It may not be news to everybody but far from enough people understands we are just on the verge of something large happening.
We are building a world sized robot
Bruce Schneier writes in his latest CRYPTO-GRAM about something that has been bothering some people for a while as the implications are yet an undiscovered country. But his words are better than mine, so here goes:
We no longer have things with computers embedded in them. We have computers with things attached to them.
Your modern refrigerator is a computer that keeps things cold. Your oven, similarly, is a computer that makes things hot. An ATM is a computer with money inside. Your car is no longer a mechanical device with some computers inside; it’s a computer with four wheels and an engine. Actually, it’s a distributed system of over 100 computers with four wheels and an engine. And, of course, your phones became full-power general-purpose computers in 2007, when the iPhone was introduced.
We wear computers: fitness trackers and computer-enabled medical devices — and, of course, we carry our smartphones everywhere. Our homes have smart thermostats, smart appliances, smart door locks, even smart light bulbs. At work, many of those same smart devices are networked together with CCTV cameras, sensors that detect customer movements, and everything else. Cities are starting to embed smart sensors in roads, streetlights, and sidewalk squares, also smart energy grids and smart transportation networks. A nuclear power plant is really just a computer that produces electricity, and — like everything else we’ve just listed — it’s on the Internet.
The Internet is no longer a web that we connect to. Instead, it’s a computerized, networked, and interconnected world that we live in. This is the future, and what we’re calling the Internet of Things.
Broadly speaking, the Internet of Things has three parts. There are the sensors that collect data about us and our environment: smart thermostats, street and highway sensors, and those ubiquitous smartphones with their motion sensors and GPS location receivers. Then there are the ”smarts” that figure out what the data means and what to do about it. This includes all the computer processors on these devices and — increasingly — in the cloud, as well as the memory that stores all of this information. And finally, there are the actuators that affect our environment. The point of a smart thermostat isn’t to record the temperature; it’s to control the furnace and the air conditioner. Driverless cars collect data about the road and the environment to steer themselves safely to their destinations.
You can think of the sensors as the eyes and ears of the Internet. You can think of the actuators as the hands and feet of the Internet. And you can think of the stuff in the middle as the brain. We are building an Internet that senses, thinks, and acts.
This is the classic definition of a robot. We’re building a world-size robot, and we don’t even realize it.
To be sure, it’s not a robot in the classical sense. We think of robots as discrete autonomous entities, with sensors, brain, and actuators all together in a metal shell. The world-size robot is distributed. It doesn’t have a singular body, and parts of it are controlled in different ways by different people. It doesn’t have a central brain, and it has nothing even remotely resembling a consciousness. It doesn’t have a single goal or focus. It’s not even something we deliberately designed. It’s something we have inadvertently built out of the everyday objects we live with and take for granted. It is the extension of our computers and networks into the real world.
This world-size robot is actually more than the Internet of Things. It’s a combination of several decades-old computing trends: mobile computing, cloud computing, always-on computing, huge databases of personal information, the Internet of Things — or, more precisely, cyber-physical systems — autonomy, and artificial intelligence. And while it’s still not very smart, it’ll get smarter. It’ll get more powerful and more capable through all the interconnections we’re building.
It’ll also get much more dangerous.
— Bruce Schneier, cryptographer and computer security expert and educator, from his news letter CRYPTO-GRAM of february 15, 2017.
A very useful utility is the Borg Backup system, or just Borg. It’s a deduplicating backup system meaning that is scans the files and when it finds data that is already in the backup the data in the second and all other subsequent files are replaced with a reference to the first instance of that data.
The idea is that the same data is only stored once. All the backups you take after the initial one stores only the differences and the new data that has been accumulated since the last backup. This means that backing up after the initial backup is done is very fast, efficient, saves bandwidth and storage space.
Traditional backups have usually a full backup every month and then they take increments daily or so. If you need to restore a file you need to take the latest full backup, then apply each increment that was taken after. With the borg backup that is not necessary as you can view the file system exactly as it looked upon each and every backup point taken.
In fact you can mount the whole backup as a file system and then traverse it from there. It’s very effective. So let’s get started because face it, you don’t back up as much as you should do!
Borg can be used for multiple platforms but my commands here will be for linux.
The first step is to create a repository, this may sit on a different machine, NAS, attached USB drive or even on the same machine, of course you want multiple backups really so you can take the borg backup locally and then rsync it to as many locations as you feel is necessary.
Take the backup
The first step is to create the dir of the the backup repo and then we need to initialize it for being used with borg. This is quite simply done as:
$ sudo mkdir /bup $ sudo borg init /bup
When the repository has thus been created it is time for the first initial backup. The format should be clear in a bit, it’s not complicated and can look like this:
$ sudo borg create --progress --info --stats /bup::lenovo-170202_163423 /home /root /boot /etc /var
The command above should be a single line. The first thing we give to borg is the command, in this case it is create to create a new backup set for us. Then we have some flags, –progress shows a progress indicator while borg is working that details also the number of bytes being read, backed, compressed and deduplicated. The next –info sets the information level borg presents to us and –stats lets borg summarize the operation with some statistics.
The next part of the command the /bup::lenovo-170202_163423 specifies the backup location and backup name. The name is given after the double colon :: mark. In this case its composed of the date yymmdd and time hhmmss of when the backup is started, doing that makes it easy to find the right set of data later when a restore is needed.
Why did I prefix it with lenovo? Well my main linux laptop is a lenovo and I also have other computers, like an ASUS laptop etc. The beauty with deduplicating backups is that I backup multiple machines to the same repo. By doing that it will deduplicate across the machines and if I have the same files and data in multiple places it will just be replaced by references to the data that is already in the backup.
The final part of the command is just all paths I want to include in this backup. They can vary from time to time. I might backup /home daily but /root only once a week if I want. No problem at all with borg.
Restoring a backup
No system of backup is actually deployed before you have attempted and successfully retrieved data from it so that you know what to do in an emergency as well as being able to extract old data mistakenly erased or restore a full system after a hard drive crash.
Restoring a borg backup works a little different from what you may be used to. First of all you can of course extract the data fully or just single files if you know their paths just like with any other backup system. The restore command is called extract in borg.
$ sudo borg extract /bup::lenovo-170202_163423
This will extract the entire archive and then you can move the files into their respective locations. You can also extract for example only the etc folder from the archive:
$ sudo borg extract /bup::lenovo-170202_163423 etc
Extraction always writes in the current working directory. Therefore you should first extract then move the files into their correct location in your file system or if all the backups are taken from the root of the file system / then you can cd there before extracting but I recommend extracting on a different volume first and then restoring from there. The reason is that there is usually a lot of stuff in a backup that you may not always want to restore.
Mounting the backup as a file system
So borg actually offers another way also. You can mount the backup as a volume, or you can mount the whole repo and see all the backup points made, select which one you want and then just copy the files from there to the live system.
$ sudo borg mount /bup::lenovo-170202_163423 /mnt
This will mount the backup lenovo-170202_163423 in the file system at /mnt. You can then cd to /mnt and then use cp etc to copy the files to their right places.
When done you can dismount it (otherwise other processes can’t backup, the repo is locked while mounted)
$ sudo umount /mnt
Borg uses fuserfs to mount local directories.
You may also mount the whole repository:
$ sudo borg mount /bup /mnt
Now when you go into the /mnt folder you will see all your backup names as directories:
$ ls 161204_040001 170101_203409 170113_040001 170117_040001 170121_040001 170125_010344 170128_030332 161206_040001 170108_040001 170114_040001 170118_040001 170122_214910 170125_040001 170128_040001 161218_174848 170111_040001 170115_040002 170119_040001 170123_040001 170126_040001 170129_040001 161225_040001 170112_040001 170116_040001 170120_040001 170124_040002 170127_040001 170201_082851
As you can see I generally name my backups with YYMMDD_HHMMSS just so it’s easy for me to find a specific date.
I can then cd to one of them
$ cd 170112_040001 $ ls boot etc home root var vmlinuz vmlinuz.old
When done, don’t forget to unmount the archive as no new backups can be taken while it is mounted.
There you go. Start using.