[Fri Mar 25 10:21:59 CET 2011]

The folks at Security Dark Reading have published an interesting piece on the dangers of HTTPS:

With the new HTTPS setting, millions of people are now able to protect their private —and not so private— postings from prying eyes on airplanes, at coffee shops, or anywhere else they might browse their favorite social network sites. Facebook was cheered by the security community for finally taking this fundamental step in protecting the sessions and data of users.

Enterprise IT organizations, on the other hand, aren't so sure about the new security measures. Their first question: How do you monitor what's coming in and out of the corporation if all of the transports are encrypted?

The perils of social networks have been researched and reported many times. The reality is that any transport method out of an organization —whether via physical media or private message in a social network— is a potential avenue for data leakage. When these avenues become encrypted, security staff lose the ability to monitor these sessions and understand what's going out the door. Essentially, the increased client security of these websites decreases the enterprise security response capabilities of those tasked with protecting corporate data.

In other words, the other side of the coin. So, what does the author propose as a solution? Basically, the use of web proxies, such as Squid. I know, pain in the neck! Still, if you do care about the network traffic coming into and (above all) out of your network, the other choice is to go back to plain HTTP for this sort of transactions, which is far from ideal. {link to this story}

[Fri Mar 11 14:51:36 CET 2011]

HPC In the Cloud publishes an interview with Christian Tanasescu, Vice-President of Software Engineering at SGI where, among other things, he muses about the growing importance of smartphones and tablets:

Cloud computing is morphing the client-server model. On the server side, the path is going from supercomputers to datacenters to co-located datacenters to the ubiquitous use of the cloud. On the client side, the world is moving from the workstation/PC to netbooks, tablets and location-aware smart phones. I think this trend leads to fewer, very large data centers with their own co-located power plants providing cloud access to millions and eventually billions of mobile clients. The new smart phones coming onto the market will have enough compute capabilities to replace the business notebook and will plug into a docking station to perform basic office work using cloud-based applications and storage.

The model Tanasescu is talking about makes perfect sense. By now, lots of people (especially among the young) don't have a land line (and don't plan to ever get one), and neither do they own a desktop PC. All they need to be permanently in touch with everybody else is a smartphone and a tablet, netbook or, at the most, a laptop. Computing is becoming more and more mobile. That is hardly a secret anymore. However, the interesting thing to me is that, as we rely more and more on smaller and smaller devices, the service providers on the other hand have to scale up to supercomputers and large clusters in order to build the cloud. {link to this story}

[Tue Mar 8 15:43:49 CET 2011]

Earlier today, I wanted to download a YouTube video to watch it directly from my hard drive and ran into an issue with the clive command:

$ clive http://www.youtube.com/watch?v=f4hw4dd0zqc
fetch http://www.youtube.com/watch?v=f4hw4dd0zqc ...done.
error: no match: `(?-xism:&video_id=(.*?)&)'

It is a well known issue. The root cause is that YouTube keeps changing the way it encodes the URLs pointing to the actual video files. I understand that is beyond the control of the developers working for the project. Yet, the fact remains that there is another tool that seems to be far more reliable than clive: youtube-dl. It's there in the default repos on Ubuntu 10.10, so it cannot be easier to install.

Now, if you give youtube-dl a try, you will notice that it also shows a similar error while downloading the video file. What to do next? It certainly didn't seem to help much, right? Sure, except that youtube-dl makes it very easy to upgrade to the latest version of the script without a need to perform any manual operation or rely on the maintainers of your favorite Linux distribution. Simply run the following command:

$ sudo youtube-dl -U
Updating to latest stable version...
Updated to version 2011.02.25c

Nifty, huh? That way, the project can easily deploy the latest version of their script, which will allow their users to catch up with Google's latest changes to the URL. {link to this story}

[Thu Mar 2 20:51:41 CET 2011]

Just ran into an issue that most likely plenty of other people have seen out there. Since my laptop dual boots Windows and Linux, I use a FAT32 partition to share music and other files between the two operating systems (yeah, it sucks that Windows can only work with Microsoft's own filesystems). However, such a primitive filesystem truly doesn't understand much of file ownership and permissions and, by default, only root can write to them. So, this is a problem that needs to be fixed or I won't be able to change the metadata for my MP3 from within Rhythmbox run as a regular user. No, running the usual chown and chmod commands will not help since, as I said, FAT32 is too primitive to deal with file ownership and permissions. The solution? You need to remount the filesystem with a set of particular options that could be easily added to your fstab file:

UUID=4244-378A  /mnt/music  vfat rw,exec,umask=0000,uid=1000,gid=1000,auto 0 0 

{link to this story}