As I am writing another post, it got me thinking about privacy. Isn’t it interesting how much one’s perception of a certain problem can change even though one’s opinion has not.
I clearly remember discussions on a popular tech forum more than 15 years ago. Every once in a while some user might start complaining that they want their content removed. This oftentimes starts when someone wants to leave or quit using the service and is typically accompanied by some form of dissatisfaction or even a fight. As far as I know, by far most forums on the internet have the same opinion on this issue: one can clear his user account, however the statements/posts/comments stay on-line, as they are part of the discussion of the time. It is similar to how one would say what is on his mind and you cannot make other people “unhear” what you just said and you cannot erase it from their memory afterwards either.
Nowadays, there is so much focus on privacy issues, while we put much more information on (public) social networks. We expect all kinds of “privacy features” of these social networks, even though they are just straw men.
Some user posted a link on how you should delete your Skype account. And upon a quick first scan of this article, I was astounded of the fact that there wasn’t a simple ‘click to delete this account’ button. It actually takes a few seconds before you realize that this is the very same issue as 15+ years ago: this random user wanted to clear his account including his participation at the time.
It is interesting to think about how one can sometimes respond “on a reflex” due to the many recent popularized/hyped discussions on privacy, while the other side of the coin are the users themselves …
There are some things that you would rather not find out for yourself. That does not mean, however, that they are not useful to see at all. One of those things that I had wondered about was how harddisk SMART failures/errors are shown. For those who are familiar with Smartmontools know that smartctl can produce quite some information when started as:
smartctl –all /dev/sda
However, there’s this handy switch ‘-H‘ (i.e. “smartctl -H /dev/sda“) which supposedly shows you its health status. Now when everything is fine, the disk’s health is reported as ‘PASSED‘. This is nice, but the PASSED case isn’t particularly interesting. What does it look like, when it is not ‘PASSing’? Well, then it looks like this:
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 129 129 140 Pre-fail Always FAILING_NOW 561
Now, I have to say that this wasn’t anything unexpected. After all, the PC was suffering from continuous read errors yesterday. But, it is good to know that there is something serious going on, instead of some random unexplained anomaly, which is definitely confirmed by above message and failure details. It does not mean that the details are perfectly accurate, however if you love your data, it’s better to err on the side of caution. Especially given subtle hints like these.
Debian is known for its rock solid, stable releases. Unfortunately these releases tend to contain packages that are somewhat dated, because they have been stabilised for a while before they were finally added and Debian is released. This can be somewhat frustrating.
Recently “rolling release” distributions have become more popular. I believe that this is in large part due to ArchLinux, which is a popular rolling release distribution. ArchLinux is a fine distribution, but it tends to be somewhat low level. Installation for example is limited to (text mode) terminal commands. A good learning experience for sure, but not for everyone.
Another option is to use Debian Testing.”Testing” is now what is going to be the next release of Debian once it has stabilised.”Testing” contains newer packages than the current release and depending on the type of application this often means the newest release.When the freeze happens,”Testing” will stop including new packages in order to stabilize to become the next release. The stabilization period is supposed to be short, although this is not always the case. You can help with this by running testing and reporting bugs as you find them.
After the release has happened you can decide to keep using the current release, as the package manager is often configured to get packages based on the name of the release which by then has officially been released. Or you can change this to ‘testing’ to keep yourself on “Testing” indefinitely.
My experience thusfar is that even Debian Testing is pretty stable. I have not had a serious breakdown in quite a while, although I have temporarily had a program that segfaulted. This was quickly fixed however. As you understand you should not do this on a computer that is of critical importance. Basically, if you require this computer to work at all times, don’t take the chance.
Debian Testing contains packages that have “soaked” for a few days in unstable. If within that time problems are detected, the package will not be promoted to Testing. This helps to ensure that you do not get caught by biggest/baddest mistakes. If this is enough insurance for you and you want Debian with newer packages than what is currently available in Debian Stable, give it a try!
Also: Start updates with ‘apt-get -u upgrade‘ in order to: 1. see what’s being offered, and 2. prevent accidentally deleting packages that get removed due to missing dependencies. Do ‘apt-get -u dist-upgrade‘ once in a while when you have some time to carefully check wat is being proposed. ‘dist-upgrade‘ is more enthusiastic and will remove packages if required.
There seems to be a bug in Linux kernel version 3.10.
The Asus Zenbook Prime UX32VD, which has an Intel HD4000 video card, boots into Linux and when the video mode switches, ends up with a blank screen. You can see that the backlight of the screen isn’t off, so it is not related to the screen lighting.
For me, what fixed this problem was to disable Secure Boot and to enable CSM support in the BIOS. When using UEFI mode (w/ or w/o Secure Boot) and booting into Linux, I run into this problem and there nothing else to do other than to reboot. When booting into a version 3.9 kernel the problem simply isn’t there. Also, when I disable Secure Boot and enable CSM (compatibility mode for non-UEFI supported systems) this problem also disappears.
This problem does not seem to be related to any distribution in particular. The problem exists both on Fedora 19 and Debian testing (Jessie).
UPDATE: https://bbs.archlinux.org/viewtopic.php?id=167463 and https://bugzilla.redhat.com/show_bug.cgi?id=989084 both seem to be related. They talk about the work around of setting vendor-controlled brightness or adjusting brightness. This is reasonable since the lowest brightness actually does result in a blank screen, however this does not work for me.
The patch that is discussed seems to solve the problem. I have not tried this yet, but for some of you this may be the solution you have been waiting for.
UPDATE 2013-12-13: I can now confirm that this issue is resolved in Debian jessie’s linux image version 3.11.10-1. (See http://ftp-master.metadata.debian.org/changelogs//main/l/linux/linux_3.11.10-1_changelog)
According to the changelog they fixed an issue with brightness level set to 0. This does indeed fix the problem and I am happily booting an EFI-enabled (CSM disabled) system again.
There’s supposed to be a very fancy, witty first post here. But … I haven’t thought of it yet, so until then here’s a cheesy placeholder.