In 2012, I wrote an article about default configuration for an operating system and the challenges involved with it. For a related, but slightly different topic, I thought it would be useful to share some of my experiences in setting up environments for more or less technically limited people.

Please note that this is just a pointer and a suggestion and the needs and wants of real people may and will vary.

Relevant visual elements

Panel

The first thing I would suggest to do is to remove any unnecessary panel applets (and panels, where appropriate). Automatically hidden panels can be really hard to use, especially for those users who have limited experience with mice or other problems that affect hand-cursor coordination. These can vary anywhere from bad eyesight to difficulties with accurate movement or simply having a hard time understanding the concept of a cursor.

What is relevant in the panels for a simple desktop experience? If you are striving for the simplest possible configuration, I would say that you only need launchers for applications, window list of open applications, a clock and a shutdown button with no choice of logout, suspend or other actions. With this setup, I recommend using the confirmation dialog to prevent unwanted shutdown cycles.

When deciding which launchers to show, please remember that you can enable access to the full application menu on right-clicking the desktop. Because of that option, it's not always worth the trouble to try to add a launcher for every application, especially if they are used only rarely. Consider picking ones that users need daily, weekly or monthly, depending on how much you want to avoid right-clicking.

I believe people that want or need a simple desktop want to see anything that they think is irrelevant. This is especially true to indicators, because they use symbols that are more or less hard to understand for a technically limited person.

There are a few exceptions: If you're setting up a laptop that's actually unplugged now and then, you might want to show the battery indicator. If you have a laptop that needs to be used in various locations, you'll want to show the network manager as well. If controlling volume is necessary, you might want to consider whether the sound indicator or shortcut keys (Fn+Fx in laptops) are the better choice.

Desktop

In addition to the panel launchers, it's wise to add launchers for the desktop as well along with a shutdown button. Make sure the launchers user generic names instead of application names eg. Email instead of Mozilla Thunderbird. It's usually wise to bump up the icon and label size up as well. If the users will not run several applications at a time, you can simply drop the panel and only use the desktop icons. If you want to show the clock without a panel, you can use a simple Conky setup. Conky is available in the Ubuntu repositories.

Other accessibility considerations

If the users have problems with their eyesight, there are a few things that can help make the system more usable for them.

The first one is adjusting the font and DPI settings. Bumping up the font size by just one step and increasing the DPI value makes the text more easily readable. Xubuntu has a very legible default font, even in smallish fonts, but it's good to remember you can change the font as well

The other thing you can do is change the window border theme. The default Xubuntu theme is designed to be elegant and keep out of the way, but sometimes this is not ideal. If the user has a hard time seeing where a window ends and the other starts, it might be a good idea to try another window border theme. On the other hand, if too many buttons is the problem - or you simply don't need or want to enable some features - you can remove some of the window buttons as well.

There is also many accessibility congifuration options under the Accessibility tab in Window Manager Tweaks found in the Settings Manager. The one I tend to turn off is rolling up windows with the mouse wheel. This prevents the accidentally "disappearing" windows.

Accessibility version of Greybird?

Currently, Greybird, the Xubuntu default theme, ships two window border themes: a regular and a compact one. It has been brought up to discussion by me and others that we should ship an accessibility version as well. This accessibility version would sport bigger window buttons as well as a bigger border to grab for resizing the window.

So far, the accessibility on the drawing board phase and not much has been done yet, as it's currently one of the most low priority items for the development teams of Xubuntu and Shimmer. That being said, all constructive feedback is welcome. Furthermore, if we see a lot of people asking for the accessibility version, it's likely that its priority will be bumped up at least a little.

Smoother user experience

Since we are talking about a simple desktop experience, I can assume at least part of our target group is people who don't either understand or want to understand why updating is important or how to install updates. For this reason, I'd simply turn on the automatical security updates but turn off all manual updates.

Depending on the situation, I would make sure apport will not pop up and ask to send new bug reports. It's self-evident that bug reports are important, but if the user doesn't understand or want to understand the importance, it's better to turn any reporting that needs user input off. The possibility that these users with the simplest possible desktops would run into bugs that haven't been already found is really rare. Moreover, the possibility of developers getting further information from these users are really slim.

While I don't use autologin myself and can't suggest using it for security reasons, setting it up might save a lot of frustration. But please, only use autologin after a good assessment of the situation and understanding the security considerations related to that.

Manual maintenance needs

Even though a system can run smoothly without daily maintenance, manual maintenance is sometimes required. I've been maintaining a few computers for family remotely during the years, and the two tools I've needed the most are an SSH server and remote desktop viewing ability - for which I'm currently using an X11vnc setup.

While SSH is usually fine for most of the regular maintenance, being able to view (and use) the desktop remotely has been an invaluable help in situations where the user can't describe the issue accurately enough via text or voice based communication. This is even more useful if the computer is far from you and you have limited possibilities to access it physically.

Naturally, you need to take security considerations into account when accessing a computer remotely. Making servers listen on unusual ports and securing with them firewalls is highly encouraged.

Summary

There are numerous opinions on the best desktop configuration, both in the look and feel. However, if you are setting a system up for somebody else, you will need to consider how they usually use the computer and how you could support their workflow to make the experience smoother.

Xfce allows a great deal of customizability by default. On top of that, the Xubuntu team has worked to bring the users even more tools that can help them configure their system. The options brought by these alone give you a vast amount of different things you can control. This article is just scratching the surface for even those options. If you want to go deeper, there is always more software on the Ubuntu repositories that can help you set up the system in the way you like it.

If you have other ideas and suggestions for simple and/or accessible desktops, feel free to drop them in the comments. If you write (or have written) a blog article about customizing Xubuntu, especially ones that cover accessbility issues, I'd like to hear back from those as well.

Happy configuring!

25 Jan 2015 11:38pm GMT

With the appearance of Snappy Ubuntu steps into the world of embedded systems. Ubuntu Snappy is designed in a way that will make it safe to run in critical environments from drones over medical equipment to robotics, home automation and machine control. The automatic rollback features will prevent you from outages when an upgrade fails, application confinement prevents you from apps, servers and tools doing any evil to your system and the image based design makes upgrades happen in minutes instead of potentially hours you are used to from package based upgrade systems.

By its design of separating device, rootfs and application packages strictly Snappy provides a true rolling release, you just upgrade each of the bits separately, independent from each other. Your Home Automation Server software can just stay on the latest upstream version all the time, no matter what version or release the other bits of your system are on. There is no more "I'm running Ubuntu XX.04 or XX.10, where do i find a PPA with a backport of the latest LibreOffice", "snappy install" and "snappy upgrade" will simply always get you the latest stable upstream version of your software, regardless of the base system.

Thanks to the separation of the device related bits porting to yet unsupported hardware is a breeze too, though since features like automated roll-back on upgrades as well as the security guarding of snap packages depend on capabilities of the bootloader and kernel, your port might operate slightly degraded until you are able to add these bits.

Let's take a look what it takes to do such a port to a NinjaSphere developer board in detail.

The Snappy boot process and finding out about your Bootloader capabilities

This section requires some basic u-boot knowledge, you should also have read https://developer.ubuntu.com/en/snappy/porting/

By default the whole u-boot logic in a snappy system gets read and executed from a file called snappy-system.txt living in the /boot partition of your install. This file is put in place by the image build software we will use later. So first of all your Bootloader setup needs to be able to load files from disk and read their content into the bootloader environment. Most u-boot installs provide "fatload" and the "env import" commands for this.

It is also very likely that the commands in your snappy-system.txt are to new for your installed u-boot (or are simply not enabled in its build configuration) so we might need to override them with equivalent functions your bootloader actually supports (i.e. fatload vs load or bootm vs bootz).

To get started, we grab a default linux SD card image from the board vendor, write it to an SD card and wire up the board for serial console using an FTDI USB serial cable. We stop the boot process by hitting enter right after the first u-boot messages appear during boot, which should get us to the bootloader prompt where we simply type "help". This will show us all the commands the installed bootloader knows. Next we want to know what the bootloader does by default, so we call the "printenv" command which will show us all pre-set variables (copy paste them from your terminal application to a txt file so you can easier look them up later without having to boot your board each time you need to know anything).

Inspecting the "printenv" output of the NinjaSphere u-boot you will notice that it uses a file called uEnv-NS.txt to read its environment from. This is the file we will have to work with to put overrides and hardware sepcific bits in place. It is also the file from which we will load snappy-system.txt into our environment.

Now lets take a look at the snappy-system.txt file, an example can be found at:
http://people.canonical.com/~ogra/snappy/snappy-system.txt

It contains four variables we can not change that tell our snappy how to boot, these are snappy_cmdline, snappy_ab, snappy_stamp and snappy_mode. It also puts the logic for booting a snappy system into the snappy_boot variable.
Additionally there are the different load commands for kernel, initrd and devicetree files and as you can see when comparing these with your u-boot "help" output they use commands out installed u-boot does not know, so the first bits we will put into our uEnv-NS.txt files are adjusted version of these commands. In the default instructions for the NinjaSphere for building the Kernel you will notice that it uses the devicetree attached to an uImage and can not boot raw vmlinuz and initrd.img files by using the bootz command. It also does not use an initrd at all by default but luckily in the "printenv" output there is at least a load address set for a ramdisk already, so we will make use of this. Based on these findings our first lines in uEnv-NS.txt look like the following:


loadfiles_ninja=run loadkernel_ninja; run loadinitrd_ninja
loadkernel_ninja=fatload mmc ${mmcdev} ${kloadaddr} ${snappy_ab}/${kernel_file_ninja}
loadinitrd_ninja=fatload mmc ${mmcdev} ${rdaddr} ${snappy_ab}/${initrd_file_ninja}
kernel_file_ninja=uImage
initrd_file_ninja=uInitrd


We will now simply be able to run "loadfiles_ninja" instead of "loadfiles" from our snappy_boot override command.

Snappy uses ext4 filesystems all over the place, looking at "printenv" we see the NinjaSphere defaults to ext3 by setting the mmcrootfstype variable, so our next line in uEnv-NS.txt switches this to ext4:

mmcrootfstype=ext4


Now lets take a closer look at snappy_boot in snappy-system.txt, the command that contains all the magic.
The section "Bootloader requirements for Snappy (u-boot + system-AB)" on https://developer.ubuntu.com/en/snappy/porting/ describes the if-then logic used there in detail. Comparing the snappy_boot command from snappy-system.txt with the list of available commands shows that we need some adjustments though, the "load" command is not supported, we need to use "fatload" instead. The original snappy_boot command also uses "fatwrite" to touch snappy-stamp.txt. While you can see from the "help" output, that this command is supported by our preinstalled u-boot, there is a bug with older u-boot versions where using fatwrite results in a corrupted /boot partition if this partition is formatted as fat32 (which snappy uses). So our new snappy_boot command will need to have this part of the logic ripped out (which sadly breaks the auto-rollback function but will not have any other limitations for us ("snappy upgrade" will still work fine as well as a manual "snappy rollback" will)).

After making all the changes our "snappy_boot_ninja" will look like the following in the uEnv-NS.txt file:


snappy_boot_ninja=if test "${snappy_mode}" = "try"; then if fatload mmc ${mmcdev} ${snappy_stamp} 0; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; fi; fi; run loadfiles_ninja; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootm ${kloadaddr} ${rdaddr}


As the final step we now just need to set "uenvcmd" to import the variables from snappy-system.txt and then make it run our modified snappy_boot_ninja command:


uenvcmd=fatload mmc ${mmcdev} ${loadaddr} snappy-system.txt; env import -t $loadaddr $filesize; run snappy_boot_ninja


This is it ! Our bootloader setup is now ready, the final uEnv-NS.txt that we will put into our /boot partition now looks like below:


# hardware specific overrides for the ninjasphere developer board
#
loadfiles_ninja=run loadkernel_ninja; run loadinitrd_ninja
loadkernel_ninja=fatload mmc ${mmcdev} ${kloadaddr} ${snappy_ab}/${kernel_file_ninja}
loadinitrd_ninja=fatload mmc ${mmcdev} ${rdaddr} ${snappy_ab}/${initrd_file_ninja}


kernel_file_ninja=uImage
initrd_file_ninja=uInitrd
mmcrootfstype=ext4


snappy_boot_ninja=if test "${snappy_mode}" = "try"; then if fatload mmc ${mmcdev} ${snappy_stamp} 0; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; fi; fi; run loadfiles_ninja; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootm ${kloadaddr} ${rdaddr}


uenvcmd=fatload mmc ${mmcdev} ${loadaddr} snappy-system.txt; env import -t $loadaddr $filesize; run snappy_boot_ninja


Building kernel and initrd files to boot Snappy on the NinjaSphere

Snappy makes heavy use of the apparmor security extension of the linux kernel to provide a safe execution environment for the snap packages of applications and services. So while we could now clone the NinjaSphere kernel source and apply the latest apparmor patches from linus' mainline tree, the kind Paolo Pisati from the Ubuntu kernel team was luckily interested in getting the NinjaSphere running snappy and did all this work for us already, so instead of cloning the BSP kernel from the NinjaSphere team on github, we can pull the already patched tree from:

http://kernel.ubuntu.com/git?p=ppisati/ubuntu-vivid.git;a=shortlog;h=refs/heads/snappy_ti_ninjasphere

First of all, let us install a cross toolchain. Assuming you use an Ubuntu or Debian install for your work you can just do this by:


sudo apt-get install gcc-arm-linux-gnueabihf


Now we clone the patched tree and move into the cloned directory:


git clone -b snappy_ti_ninjasphere git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git
cd ubuntu-vivid


Build uImage with attached devicetree, build the modules and install them. All based on Paolos adjusted snappy defconfiig:


export CROSS_COMPILE=arm-linux-gnueabihf-; export ARCH=arm
make snappy_ninjasphere_defconfig
make -j8 uImage.var-som-am33-ninja
make -j8 modules
mkdir ../ninjasphere-modules
make modules_install INSTALL_MOD_PATH=../ninjasphere-modules
cp arch/arm/boot/uImage.var-som-am33-ninja ../uImage
cd -


So we now have a modules/ directory containing the binary modules and we have a uImage file to boot our snappy, what we are still missing is an initrd file to make our snappy boot. We can just use the initrd from an existing snappy device tarball which we can find at cdimage.ubuntu.com.


mkdir tmp
cd tmp
wget http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/vivid-preinstalled-core-armhf.device.tar.gz
tar xzvf vivid-preinstalled-core-armhf.device.tar.gz


Do you remember, our board requires an uInitrd … the above tarball only ships a raw initrd.img, so we need to convert it. In Ubuntu there is the u-boot-tools package that ships the mkimage tool to convert files for u-boot consumption, lets install this package and create a proper uInitrd:


sudo apt-get install u-boot-tools
mkimage -A arm -T ramdisk -C none -n "Snappy Initrd" -d system/boot/initrd.img-* ../uInitrd
cd ..
rm -rf tmp/


If you do not want to keep the modules from the -generic kernel in your initrd.img you can easily unpack and re-pack the initrd.img file as described in "Initrd requirements for Snappy" on https://developer.ubuntu.com/en/snappy/porting/ and simply rm -rf lib/modules/* before re-packing to get a clean and lean initrd.img before converting to uInitrd.

Now we have a bootloader configuration file, uImage, uInitrd and a dir with the matching binary modules we can use to create our snappy device tarball.

Creating the Snappy device tarball

We are ready to create the device tarball filesystem structure and roll a proper snappy tarball from it, lets create a build/ dir in which we build this structure:


mkdir build
cd build


As described on https://developer.ubuntu.com/en/snappy/porting/ our uInitrd and uImage files need to go into the assets subdir:


mkdir assets
cp ../uImage assets/
cp ../uInitrd assets/


The modules we built above will have to live underneath the system/ dir inside the tarball:


mkdir system
cp -a ../modules/* system/


Our boootloader configuration goes into the boot/ dir. For proper operation snappy looks for a plain uEnv.txt file, since our actual bootloader config lives in uEnv-NS.txt we just create the other file as empty doc (it would be great if we could use a symlink here, but remember, the /boot partition that will be created from this uses a vfat filesystem and vfat does not support
symlinks, so we just touch an empty file instead).


mkdir boot
cp ../uEnv-NS.txt boot/
touch boot/uEnv.txt


Snappy will also expect a flashtool-assets dir, even though we do not use this for our port:


mkdir flashtool-assets


As last step we now need to create the hardware.yaml file as described on https://developer.ubuntu.com/en/snappy/porting/


echo "kernel: assets/uImage" >hardware.yaml
echo "initrd: assets/uInitrd" >>hardware.yaml
echo "dtbs: assets/dtbs" >>hardware.yaml
echo "partition-layout: system-AB" >>hardware.yaml
echo "bootloader: u-boot" >>hardware.yaml


This is it ! Now we can tar up the contents of the build/ dir into a tar.xz file that we can use with ubuntu-device-flash to build a bootable snappy image.


tar cJvf ../device_part_ninjasphere.tar.xz *
cd ..


Since I personally like to re-build my tarballs regulary if anything changed or improved, I wrote a little tool I call snappy-device-builder which takes over some of the repetitive tasks you have to do when rolling the tarball, you can branch it with bzr from launchpad if you are interested in it (patches and improvements are indeed very welcome):


bzr branch lp:~ogra/+junk/snappy-device-builder


Building the actual SD card image

Install the latest ubuntu-device-flash from the snappy-dev beta PPA:


sudo add-apt-repository ppa:snappy-dev/beta
sudo apt-get update
sudo apt-get install ubuntu-device-flash


Now we build a 3GB big image called mysnappy.img using ubuntu-device-flash and our newly created device_part_ninjasphere.tar.xz with the command below:


sudo ubuntu-device-flash core --size 3 -o mysnappy.img --channel ubuntu-core/devel-proposed --device generic_armhf --device-part device_part_ninjasphere.tar.xz --developer-mode


.. and write the create mysnappy.img to an SD card that sits in the SD Card Reader at /dev/sdc:


sudo dd if=mysnappy.img of=/dev/sdc bs=4k


This is it, your NinjaSphere board should now boot you to a snappy login on the serial port, log in with "ubuntu" with the password "ubuntu" and if your board is attached to the network i recommend doing a "sudo snappy install webdm", then you can reach your snappy via http://webdm.local:4200/ in a browser and install/remove/configure snap packages on it.

If you have any problems with this guide, want to make suggestions or have questions, you can reach me as "ogra" via IRC inthe #snappy channel on irc.freenode.net or just mail the snappy-devel@lists.ubuntu.com mailing list with your question.

25 Jan 2015 5:22pm GMT

Hi,

From 2010 until this very moment, I have volunteered and invested my time to help tons of people from all over the world. The key was 'helping'. In most cases, I had no idea what are their real names? how do they look like? their nationality? colour? religion? personal life? etc. That was the best part of all. You help others without knowing anything about them except they are:

• Humans.
• Need Help.

What could be better than this?

Words fail me here. I can't summarize all these years in one post and guess will never do. That requires a book which I'm planning to write, one day hopefully. Why a book? simply because I was doing that on daily basis, 24/7/365 and it was like a full-time job. I've been the most active contributor ever. That definitely needs a book in case I would like to document it and share that unique experience.

In 21-January-2015, I was talking to someone so close, so precious and so has been and still my real life mentor. We were discussing about my real life, what I have done, what I'm doing, what I'm suppose to do, what I'm not suppose to do, etc. It was long discussion.

Suddenly, we came to a huge disagreement about the path I have decided to walk through. Due to that disagreement, the discussion, which turned to be an argument, had to reach to a dead end.

The call ended and a moment of silence from both side after that.

I then started to think with myself about what happened. It took me nearly a day until I started to figure out what I must do and what should happen. At first, I was so confused and feeling so bad. Once I started to take some actions, things started to get more clear and I had a better vision.

In one single day, I have decided to step down from 5 different projects at the same time.

Examples:

• Stepping down from StartUbuntu Project.
• Stepping down from LXDE Forum.
• Stepping down from Ubuntu Quality Social Media.
• Other projects.

Out of 5 projects I stepped down from, 3 of them are mine (I founded them).

It was the toughest and hardest decision I have ever taken for the last 5 years since I have started all that in 2010 (being a volunteer). Of course, I have taken much harder decisions in my real life but I'm talking about my life as a volunteer. That was the toughest of all.

Such action requires a lot of energy, maybe courage too. Above all, it requires thinking out-of-the box (differently).

Once I took that one, I decided to go for the next step and the next decision:

Self Development.

A totally new chapter in my life. New page, new path, new beginning. Above all, new way of thinking. Thinking differently.

Because:

Actions Speak Louder Than Words.

I will not write about my next move yet. I will start some paper planning and start following what I have planed for myself.

I've been the brain behind so many projects. I have helped lots of people and many projects. It is time to work on myself. If I can't be useful to my own self, how can I be useful to others? I don't know how I was helpful for so many people? maybe I wasn't after all? I don't know how it happened and I don't want to think about that at the moment. All what I want truly is to start working so hard on myself. Develop and improve myself. It is to be or not to be. It is super serious and super high priority.

I must admit and confess that I was chasing the wrong dream. That is why I have contacted my real life mentor and apologized to the misunderstanding that happened between us and all. I hope he can forgive me and above all, I hope he understands.

I'm forever thankful as I got the wake up call that was in bad need to.

Enough talk, time for actions.

Oh, and I must also admit that after stepping down from my roles with 5 different projects, I felt much better. At first, I was feeling so bad and down. But the next day, when I breathed, I did that with LESS burden and stress. I then realized what I have done to myself all that time. Needless to say, it was so stupid to burn myself out that way. While I have done good things to others, I have done so bad things to myself. Never too late and better late than never. I don't think I could have done that without stepping down. that action made me think clearly and better. Less burden means more focus and more energy on less and fewer things.

FWIW, I don't think I will step down from ToriOS and Ubuntu GNOME. And I don't think I will put Kibo on hold. I will however limit my activities and keep low profile.

To the one who is always there for me, spending time, energy and efforts to offer the honest and the best advice ever, THANK YOU SO MUCH wherever you are!

Thank you for reading this.

P.S.
Yes, I shall share the progress of myself development in case this will help anyone out there, wherever there is

25 Jan 2015 11:30am GMT

$ sudo apt-get install python-yaml python-icalendar python-flask python-pygithub

api_token: 6b36b3d7579d06c9f8e88bc6fb33864e4765e5fac4a3c2fd1bc33aad
bind_address: ::0
bind_port: 5000
repositories:
- repository: your-user-name/your-project
- repository: your-user-name/another-project

$ ./github_icalendar/main.py github-ics.cfg

24 Jan 2015 11:07pm GMT

Last night I learned the worst kind of news, my friend and valuable member of the Linux community here in San Francisco, Eric P. Scott (eps) recently passed away.

In an excerpt from a post by Chaz Boston Baden, he cites the news from Ron Hipschman:

I hate to be the bearer of bad news, but It is my sad duty to inform you that Eric passed away sometime in the last week or so. After a period of not hearing from Eric by phone or by email, Karil Daniels (another friend) and I became concerned that something might be more serious than a lost phone or a trip to a convention, so I called his property manager and we met at Eric's place Friday night. Unfortunately, the worst possible reason for his lack of communication was what we found. According to the medical examiner, he apparently died in his sleep peacefully (he was in bed). Eric had been battling a heart condition. We may learn more next week when they do an examination.

He was a good friend, the kind who was hugely supportive of any local events I had concocted for the Ubuntu California community, but as a friend he was also the thoughtful kind of man who would spontaneously give me thoughtful gifts. Sometimes they were related to an idea he had for promoting Ubuntu, like a new kind of candy we could use for our candy dishes at the Southern California Linux Expo, a toy penguin we could use at booths or a foldable origami-like street car he thought we could use as inspiration for something similar as a giveaway to promote the latest animal associated with an Ubuntu LTS release.

He also went beyond having ideas and we spent time together several times scouring local shops for giveaway booth candy, and once meeting at Costco to buy cookies and chips in bulk for an Ubuntu release party last spring, which he then helped me cart home on a bus! Sometimes after the monthly Ubuntu Hours, which he almost always attended, we'd go out to explore options for candy to include at booth events, with the amusing idea he also came up with: candy dishes that came together to form the Ubuntu logo.

In 2012 we filled the dishes with M&Ms:

The next year we became more germ conscious and he suggested we go with individually wrapped candies, searching the city for ones that would taste good and not too expensive. Plus, he found a California-shaped bowl which fit into our Ubuntu California astonishingly theme well!

He also helped with Partimus, often coming out to hardware triage and installfests we'd have at the schools.

At a Partimus-supported school, back row, middle

As a friend, he was also always welcome to share his knowledge with others. Upon learning that I don't cook, he gave me advice on some quick and easy things I could do at home, which culminated in the gift of a plastic container built for cooking pasta in the microwave. Skeptical of all things microwave, it's actually something I now use routinely when I'm eating alone, I even happened to use it last night before learning of his passing.

He was a rail fan and advocate for public transportation, so I could always count on him for the latest transit news, or just a pure geek out about trains in general, which often happened with other rail fans at our regular Bay Area Debian dinners. He had also racked up the miles on his favorite airline alliance, so there were plenty of air geek conversations around ticket prices, destinations and loyalty programs. And though I haven't really connected with the local science fiction community here in San Francisco (so many hobbies, so little time!), we definitely shared a passion for scifi too.

This is a hard and shocking loss for me. I will deeply miss his friendship and support.

24 Jan 2015 8:10pm GMT

Día U - 8395
Comencé a oír la extraña palabreja de Linux, allá por principios de los años 90 de la mano de PC Actual. Por esa época yo sólo jugaba (no sabía hacer otra cosa) con mi Spectrum...

Día U - 7300
Pasaron los años y mis estudios valieron para convencer a mis padres de que era necesario un potente 486DX. El MS-DOS se portaba bien en aquel hardware y seguro que ahora adoro la Shell debido a reminiscencias de esos viejos tiempos...

Día U - 6935
A pesar de mi pasión por la informática, no conocí a Windows 95. Sus requerimientos de 4MB de RAM (= 25.000 ptas de la época) provocaban que actualizar el ordenador fuera excesivamente caro, aunque Microsoft anunciara el oro y el moro....
Tras la muerte del 486 un flamante AMD a 800Mhz entró en el hogar y en el año 96 instalé mi primer Linux, un Mandrake que venía en un CD de PC World... ignorante de mi, en la instalación gráfica me cargué el Windows 98. Y Mandrake apenas duró unas horas... porque tenía un modem (cof, cof, winmodem) de 56Kb y claro... los winmodem se llevaban no mal, sino fatal con Linux. Así que el resto de años escogí usar un PC con Windows 98/ME/XP e Internet, o un poderoso Linux sin Internet... La elección era clara... :$

Día U - 6205
Y olalá, el ADSL se extendió por España y con ello el cambio a un router en condiciones... Así que volví a intentarlo otra vez con un CD de SUSE. Se notaba y mucho la mejoría de KDE en esos años. SUSE molaba, pero... yo tenía mucho cacao mental con tanta distribución y muchas ganas de probar cosas nuevas. Mandriva tomó el relevo, wow Mandriva... ¡que buen hacer! Y poco a poco entraba en un mundo grandioso, casi que infinito y necesitaba recorrerlo para saber a dónde pertenecía ;)

Nunca mejor dicho ;)

De Mandriva pasé a Ubuntu (5.04/5.10?). La primera vez que probé GNOME sus aplicaciones me parecieron demasiado simples. Cada vez leía más sobre Linux, haciendo que probase Linux Mint y la nostalgia hizo que probase la nueva openSUSE...

Y al final, volví a donde me sentí más a gusto, a MS-DOS... jajajaja noooo que es broma ;P Volví al XP :S Era donde más cómodo me sentía.

Día U - 2920
Y por fin, en el 2007 todo cambió. La versión 6.06 de Ubuntu me convenció, no por su libertad (tenía un lío sobre qué era libertad ¡que pa qué!), si no, porque era algo nuevo, atrayente, tenía un auténtico halo cool. Quería/necesitaba probarlo. Y cumplió. Me sorprendió por su estabilidad, facilidad de uso y acabé enganchado a la sencillez de GNOME. Desde entonces no encontré otro SO en el que me sienta tan a gusto. Y eso es lo importante al fin y al cabo :)


Día U - 2190
Y cada vez más y más, me adentré en la jungla, donde a cada paso descubres un mundo nuevo. Aprendes qué es libertad y aprendes a valorarla, ves que el imposible es posible, no hay límite...

Día U - 14
Y volvieron a pasar años y más años; Años en los que he visto atacar naves en llamas más allá de Ori... uys no... eso es otra historia... En todos estos años, sí ví caer auténticos imperios como Nokia o RIM, ví otros imperios robados como la manzana a Steve. Ví nacer renqueantes SO como Android que se engulló con patatas a la informática móvil. También ví como Windows 10 presume de convergencia cuando Mark la presentó años ha. Y es que, en este mundillo, cuya prehistoria se remonta a apenas unas décadas, no hay nada escrito.

El 6 de Febrero del 2015, todo termina y todo comienza

Remember, remember the 6th of February... con un Ubuntu un poco olvidado (a mi pesar) de su escritorio, haciéndolo muy bien en el mercado de servidores/nube, va a entrar en el mercado de los móviles con paso firme... El próximo día 6 Ubuntu presentará el primer modelo de Ubuntu Phone. Un Ubuntu Phone que no sólo tiene dinero y tiempo invertidos, también tiene invertidos sueños e ilusión, incluso, tiene invertido tanto como su propio futuro.
¿Triunfará? Pregunta-ylo a la nublina, sólo ella te lo dirá nos canta Llan de Cubel. Pero al menos, hay que ser paisanos y quien quiera peces que moje el culo. Ubuntu ha demostrado que tiene las ideas claras y ya está en el camino de alcanzar un sueño
Ubuntu, a valiente no te gana nadie. ¡Chapó!

24 Jan 2015 11:40am GMT

Passwords are always going to be vulnerable to being cracked. Fortunately, there are solutions out there that are making it safer for users to interact with services on the web. The new standard in protecting users is Universal 2nd Factor (U2F) authentication which is already available in browsers like Google Chrome.

Mozilla currently has a bug open to start the work necessary to delivering U2F support to people around the globe and bring Firefox into parity with Chrome by offering this excellent new feature to users.

I recently reached out to the folks at Yubico who are very eager to see Universal 2nd Factor (U2F) support in Firefox. So much so that they have offered me the ability to give out up to two hundred Yubikeys with U2F support to testers and will ship them directly to Mozillians regardless of what country you live in so you can follow along with the bug we have open and begin testing U2F in Firefox the minute it becomes available in Firefox Nightly.

If you are a Firefox Nightly user and are interested in testing U2F, please use this form (offer now closed) and apply for a code to receive one of these Yubikeys for testing. (This is only available to Mozillians who use Nightly and are willing to help report bugs and test the patch when it lands)

Thanks again to the folks at Yubico for supporting U2F in Firefox!

Update: This offer is now closed check your email for a code or a request to verify you are a vouched Mozillian! We got more requests also then we had available so only the first two hundred will be fulfilled!

24 Jan 2015 12:20am GMT

Ubuntu Global Jam, Vivid edition is a few short weeks away. It's time to make your event happen. I can help! Here's my officially unofficial guide to global jam success.

Steps:

1. Get your jam pack! Get the request in right away so it gets to you on time.
2. Pick a cool location to jam
3. Tell everyone! (be sure to mention free swag, who can resist!?)

23 Jan 2015 5:08pm GMT

We're preparing Lubuntu 15.04, Vivid Vervet, for distribution in April 2015. With this early Alpha pre-release, you can see what we are trying out in preparation for our next version. We have some interesting things happening, so read on for highlights and information.

• Regular users who want to help us test by finding, reporting, and/or fixing bugs
• Lubuntu developers

You can get more information here.

23 Jan 2015 4:36pm GMT

Softpedia writes about our new Alpha 2 release

Kubuntu 15.04 Alpha 2 Is the Most Exciting Release in a Long Time

The first thing people will likely notice is the new look of the distribution and they won't be disappointed.

An even more impressive review, this time of Plasma 5 on Utopic, is from Ken Vermette.

Plasma 5.2 - The Quintessential Breakdown

23 Jan 2015 12:30pm GMT

Closer and closer we creep towards the release of Vivid Vervet. Alpha 2 testing went well with flying colors thanks to the likes of:

• Brendan Perrine
• Nio Wiklund
• Phill Westside
• Dave Kokandy

23 Jan 2015 1:44am GMT

The Ubuntu community team has recently set up Find-a-Task, which is a small tool that helps new contributors find a task to start working on. If you click around (long enough), you will also find Xubuntu tasks in there. How nice of us!

There's one problem though… The content is unfortunately maintained in a private environment, and there's no easy way to see all the tasks. What if you wanted to check if a very similar task, or exactly the same task, already exists?

Stop the clicking already! I wrote a simple Greasemonkey script that outputs the full index of Find-a-Task instead of showing you the different categories and tasks one by one. The easiest way to install the script is to click on the Raw -button on the Gist.

The team has only started gathering these tasks around the community. Some have already came in, but there's room for a lot more expansion.

If your team wants to add some tasks, join the #ubuntu-community-team IRC channel on Freenode and shout your tasks out loud. The community team will update the tool with your tasks as long as you provide them the name, description, target URL and the desired category for each task.

Go add a task… quickly!

23 Jan 2015 1:39am GMT

So you've got yourself a subreddit. Now you need to configure it. Boy, what a hard time /r/lubuntu had trying to get flair figured out. Unfortunately, the reddit group is our newest channel to connect with the larger community, so I didn't have a lot of help.

See the issue was that we already had this spritesheet created by our Artwork God, Rafael Laguna. He actually had made another one to make this fantastic stylesheet, using Naut (look at that winking Snoo!), so I was confident this would be easy.

However, I had quite a bit of problems trying to get background-position to behave right. It looked like it was going all over the place. In looking at tutorials, none of them, even the most helpful, covered what to do if you have a spritesheet. Instead, they all assume you just have individual images.

There were several problems I had going on including extra padding and incorrectly sized images on the spritesheet that created issues. The spritesheet was remade with more Lubuntu specific images (well, at least for half of them).

Making it a single row of equal-sized (16x16) images made things easier. The ah ha moment came when realizing that background-position moves the background relative to the canvas. It does NOT move the background on the canvas. So we needed to use negative numbers and all was well.

And yet, there was another problem: there's optional text that can go with the flair. Unfortunately, it was included in the span that was styled with our background spritesheet. It was appearing right on top of the flair and there was no way around this looking at the HTML.

<span class="flair flair-lxqt" title="Release Mgr. | QA Head">Release Mgr. | QA Head</span>
  ::before
  "Release Mgr. | QA Head"
</span>

Enter the ::before pseudo element. Note I didn't say selector. The following code creates an an element that sits before the element that it acts on, which is, in this case, the flair class. So before we see any flair things, we have an blank element that is 4 pixels away from the flair class (which includes the image and the text) and and that is 4 pixels away from the next element, which happens to be the text. It also makes sure that our spritesheet is in there and that we're selecting 16x16 bits of it.

.flair::before {
   margin: 0 4px 0 4px;
   display: inline-block;
   content:"";
   background: url(%%reddit-sprite%%) no-repeat scroll top left;
   min-width: 16px;
   min-height: 16px;
}

And lastly, we need the specific positioning. Remember that the element that has the margin and everything is the pseudo element, so we need to use ::before on these as well. We'll also make sure to use the specific classes we created in the "edit flair" option in reddit Moderation Tools, so that we can act specifically on these.

.flair-lxde::before { background-position: 0px 0px !important; }
.flair-lxqt::before { background-position: -16px 0px !important; }
.flair-lenny::before { background-position: -32px 0px !important; }
.flair-user::before { background-position: -48px 0px !important; }
.flair-invader::before { background-position: -64px 0px !important; }
.flair-orb::before { background-position: -80px 0px !important; }

I basically hacked this together through inspecting elements at r/PixelDungeon (which is currently my favourite roguelike game and one that I hope to rewrite using Python and Kivy, if anyone's interested in helping) since they have all sorts of fantastic functionality going on. Kudos to them.

I do hope this helps save someone the sanity that I lost yesterday. ;)

23 Jan 2015 12:41am GMT

Hey all, a new version of Ubuntu Calculator App Reboot is on the store, ready for the your tries! As usual, please report any bug you find on Launchpad, so we can fix them!

Don't worry about the number of version, I know it is passed from 0.1.4 to 2.0.73, it's a bit strange but now makes more sense: the major release is 2, because it's the reboot, but we don't have still a stable version, and so the 0. The last number is the bzr commit.

Let me show you some of the changes Bartosz and Giulio did in last week - I was busy with an importat exam at uni, so I did nothing, but I'm sure I'll have more time next week ;-)

Translations

Bartosz enabled translations in the project, so since the next version you should see the app in your language, if someone has made translations. So, if you have some spare time, take a look to our translation page and make calculator available in your language!

Copy feature

Bartosz has also implemented the possibility to copy a calc from the multiselection mode (you just have to longclick on a calc)

Scrolling

In the previous version of reboot app, when you started the app not all the keyboard was visible. Now, thanks to Giulio, this has been fixed, the app opens in the right position.

Full changelog

Here the full changelog:

• #64 Fix scrolling position on app startup on devices. (Giulio Collura)
• #65 Adding autopilot tests for calculation after gathering result. (Bartosz Kosiorek)
• #66 Add feature to copy selected calculation from the history. (Bartosz Kosiorek)
• #67 Add keyboard support for Calculation keyboard. (Bartosz Kosiorek )
• #68 Fix ScrollableView behavior with few items visible. (Giulio Collura)
• #69 Improve manifest.json generation. (Giulio Collura)
• #70 Launchpad automatic translations update.
• #71 Fix translation generation. (Bartosz Kosiorek)
• #72 Launchpad automatic translations update.
• #73 Updated math.js to 1.2.0. (Riccardo Padovani)

Ciao,
R.

22 Jan 2015 9:00pm GMT

The second alpha of the Vivid Vervet (to become 15.04) has now been released!

Pre-releases of the Vivid Vervet are *not* encouraged for anyone needing a stable system or anyone who is not comfortable running into occasional, even frequent breakage. They are, however, recommended for Ubuntu flavor developers and those who want to help in testing, reporting and fixing bugs as we work towards getting this release ready.

Alpha 2 includes a number of software updates that are ready for wider testing. This is quite an early set of images, so you should expect some bugs.

While these Alpha 2 images have been tested and work, except as noted in the release notes, Ubuntu developers are continuing to improve the Vivid Vervet. In particular, once newer daily images are available, system installation bugs identified in the Alpha 2 installer should be verified against the current daily image before being reported in Launchpad. Using an obsolete image to re-report bugs that have already been fixed wastes your time and the time of developers who are busy trying to make 15.04 the best Ubuntu release yet. Always ensure your system is up to date before reporting bugs.

This alpha features images for Kubuntu, Lubuntu, Ubuntu GNOME, UbuntuKylin and the Ubuntu Cloud images.

Kubuntu

Kubuntu uses KDE software and now features the new Plasma 5 desktop. The Alpha-2 images can be downloaded at:

http://cdimage.ubuntu.com/kubuntu/releases/vivid/alpha-2

More information on Kubuntu Alpha-2 can be found here:

https://wiki.ubuntu.com/VividVervet/Alpha2/Kubuntu

Lubuntu

Lubuntu is a flavour of Ubuntu based on LXDE and focused on providing a very lightweight distribution. The Alpha-2 images can be downloaded at:

http://cdimage.ubuntu.com/lubuntu/releases/vivid/alpha-2/

More information on Lubuntu Alpha-2 can be found here:

https://wiki.ubuntu.com/VividVervet/Alpha2/Lubuntu

Ubuntu GNOME

Ubuntu GNOME is an flavour of Ubuntu featuring the GNOME desktop environment. The Alpha-2 images can be downloaded at:

http://cdimage.ubuntu.com/ubuntu-gnome/releases/vivid/alpha-2/

More information on Ubuntu GNOME Alpha-2 can be found here:

https://wiki.ubuntu.com/VividVervet/Alpha2/UbuntuGNOME

UbuntuKylin

UbuntuKylin is a flavour of Ubuntu that is more suitable for Chinese users.

The Alpha-2 images can be downloaded at:

http://cdimage.ubuntu.com/ubuntukylin/releases/vivid/alpha-2/

More information on UbuntuKylin Alpha-2 can be found here:

https://wiki.ubuntu.com/VividVervet/Alpha2/UbuntuKylin

Ubuntu Cloud

Ubuntu Cloud images can be run on Amazon EC2, Openstack, SmartOS and many other clouds. The Alpha-2 images can be downloaded at:

http://cloud-images.ubuntu.com/releases/vivid/alpha-2/

Regular daily images for Ubuntu can be found at:

http://cdimage.ubuntu.com

If you're interested in following the changes as we further develop Vivid, we suggest that you subscribe to the ubuntu-devel-announce list. This is a low-traffic list (a few posts a week) carrying announcements of approved specifications, policy changes, alpha releases and other interesting events.

http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce

A big thank you to the developers and testers for their efforts to pull together this Alpha release!

Originally posted to the ubuntu-devel-announce mailing list on Thu Jan 22 15:04:50 UTC 2015 by Walter Lapchynski

22 Jan 2015 4:52pm GMT

The second Alpha of Vivid (to become 15.04) has now been released!

The Alpha-2 images can be downloaded at: http://cdimage.ubuntu.com/kubuntu/releases/vivid/alpha-2/

More information on Kubuntu Alpha-2 can be found here: https://wiki.ubuntu.com/VividVervet/Alpha2/Kubuntu

22 Jan 2015 3:52pm GMT