Planet HantsLUG

Syndicate content
Planet HantsLUG - http://hantslug.org.uk/planet/
Updated: 7 min 28 sec ago

Steve Kemp: A diversion on off-site storage

Wed, 26/03/2014 - 18:53

Yesterday I took a diversion from thinking about my upcoming cache project, largely because I took some pictures inside my house, and realized my offsite backup was getting full.

I have three levels of backups:

  • Home stuff on my desktop is replicated to my wifes desktop, and vice-versa.
  • A simple server running rsync (content-free http://rsync.io/).
  • A "peering" arrangement of a small group of friends. Each of us makes available a small amount of space and we copy to-from each others shares, via rsync / scp as appropriate.

Unfortunately my rsync-based personal server is getting a little too full, and will certainly be full by next year. S3 is pricy, and I don't trust the "unlimited" storage people (backblaze,etc) to be sustainable and reliable long-term.

The pricing on Google-drive seems appealing, but I guess I'm loathe to share more data with Google. Perhaps I could dedicated a single "backup.account@gmail.com" login to that, separate from all-else.

So the diversion came along when I looked for Amazon S3-comptible, self-hosted, servers. There are a few, most of them are PHP-based, or similarly icky.

So far cloudfoundry's vlob looks the most interesting, but the main project seems stalled/dead. Sadly using s3cmd to upload files failed, but certainly the `curl` based API works as expected.

I looked at Gluster, CEPH, and similar, but didn't yet come up with a decent plan for handling offsite storage, but I know I have only six months or so before the need becomes pressing. I imagine the plan has to be using N-small servers with local storage, rather than 1-Large server, purely because pricing is going to be better that way.

Decisions decisions.

Categories: LUG Community Blogs

Tony Whitmore: The goose that laid the golden eggs, but never cackled

Tue, 25/03/2014 - 20:48

I’ve wanted to visit Bletchley Park for years. It is where thousands of people toiled twenty-four hours a day to decipher enemy radio messages during the second world war, in absolute secrecy. It is where some of the brightest minds of a generation put their considerable mental skills to an incredibly valuable purpose. It is also where modern computing was born, notably through the work of Alan Turing and others.

So I was very pleased to be invited by my friend James to visit Bletchley as part of his stag weekend. After years of neglect, and in the face of demolition, the park is now being extensively restored. A new visitors’ centre will be introduced, and more of the huts opened up to the public. I have no doubt that these features will improve the experience overall, but there was a feeling of Trigger’s Broom as I looked over the huts closest to the mansion house. Never open to the public before, they looked good with new roofs and walls. But perhaps a little too clean.

And it really is only the huts closest to the house that are being renovated. Others are used by the neighbouring National Museum of Computing, small companies and a huge number are still derelict. Whilst I hope that the remaining huts will be preserved, it would be great if visitors could see the huts in their current dilapidated state too. The neglect of Bletchley Park is part of its story, and I would love to explore the derelict huts as they are now. I would love to shoot inside them – so many ideas in my head for that!

Most of the people working there were aged between eighteen and twenty-one, so you can imagine how much buzz and life there was in the place, despite the graveness of the work being carried out. Having visited the park as it is today, I wish that I had been able to visit it during the war. To see people walking around the huts, efficiency and eccentricity hand-in-hand, to know the import and intellect of what was being carried out, and how it would produce the technology that we all rely on every day, would have been incredible.

Pin It
Categories: LUG Community Blogs

Steve Kemp: New GPG-key

Mon, 24/03/2014 - 20:26

I've now generated a new GPG-key for myself:

$ gpg --fingerprint 229A4066 pub 4096R/0C626242 2014-03-24 Key fingerprint = D516 C42B 1D0E 3F85 4CAB 9723 1909 D408 0C62 6242 uid Steve Kemp (Edinburgh, Scotland) <steve@steve.org.uk> sub 4096R/229A4066 2014-03-24

The key can be found online via mit.edu : 0x1909D4080C626242

This has been signed with my old key:

pub 1024D/CD4C0D9D 2002-05-29 Key fingerprint = DB1F F3FB 1D08 FC01 ED22 2243 C0CF C6B3 CD4C 0D9D uid Steve Kemp <steve@steve.org.uk> sub 2048g/AC995563 2002-05-29

If there is anybody who has signed my old key who wishes to sign my new one then please feel free to get in touch to arrange it.

Categories: LUG Community Blogs

Steve Kemp: So I failed at writing some clustered code in Perl

Mon, 24/03/2014 - 10:41

Until this time next month I'll be posting code-based discussions only.

Recently I've been wanting to explore creating clustered services, because clusters are definitely things I use professionally.

My initial attempt was to write an auto-clustering version of memcached, because that's a useful tool. Writing the core of the service took an hour or so:

  • Simple KeyVal.pm implementation.
  • Give it the obvious methods get, set, delete.
  • Make it more interesting by creating a read-only append-log.
  • The logfile will be replayed for clustering.

At the point I was done the following code worked:

use KeyVal; # Create an object, and set some values my $obj = KeyVal->new( logfile => "/tmp/foo.log" ); $obj->incr( "steve" ); $obj->incr( "steve" ); print $obj->get( "steve" ) # prints 2. # Now replay the append-only log my $replay = KeyVal->new( logfile => "/tmp/foo.log" ); $replay->replay(); print $replay->get( "steve" ) # prints 2.

In the first case we used the primitives to increment a value twice, and then fetch it. In the second case we used the logfile the first object created to replay all prior transactions, then output the value.

Neat. The next step was to make it work over a network. Trivial.

Finally I wanted to autodetect peers, and deploy replication. Each host would send out regular messages along the lines of "Do you have updates made since $time?". Any that did would replay the logfile from the given unixtime offset.

However here I ran into problems. Peer discovery was supposed to be basic, and I figured I'd write something that did leader election by magic. Unfortunately Perls threading code is .. unpleasant:

  • I wanted to store all known-peers in a singleton.
  • Then I wanted to create threads that would announce and receive updates.

This failed. Majorly. Because you cannot launch the implementation of a class-method as a thread. Equally you cannot make a variable which is "complex" shared across threads.

I wrote some demo code which works without packages and a shared singleton:

The Ruby version, by contrast, is much more OO and neater. Meh.

I've now shelved the project.

My next, big, task was to make the network service utterly memcached compatible. That would have been fiddly, but not impossible. Right now I just use a simple line-based network protocol.

I suspect I could have got what I wanted using EventMachine, or similar, but that's a path I've not yet explored, and I'm happy enough with that decision.

Categories: LUG Community Blogs

Martin Wimpress: Memory consumption of Linux desktop environments

Sun, 23/03/2014 - 14:30

For the last 9 months or so I've spent my spare time working with the MATE Desktop Team. Every so often, via the various on-line MATE communities, the topic of how "light weight" MATE is when compared to other desktop environments crops up and quite often XFCE is suggested as a lighter alternative. After all MATE and XFCE both provide a traditional desktop environment based on GTK+ so this suggestion is sensible. But is XFCE actually "lighter" than MATE?

I've found MATE to be (subjectively) more responsive that XFCE and there have been two recent blog posts that indicate MATE has lower memory requirements than XFCE.

Given that I'm comfortably running MATE on the Raspberry Pi Model B (which has just 512MB RAM) I've been stating that MATE is well suited for use on resource constrained hardware and professional workstations alike. This is still true, but I've also said that MATE is lighter than XFCE and I might have to eat humble pie on that one.

The topic of measursing desktop environment resource use came up on the #archlinux-tu IRC channel recently and someone suggested using ps_mem.py to gather the memory usage data. ps_mem.py provides a far more robust mechanism for gathering memory usage data than I've seen in previous comparisons.

So the seed was planted, I created seven VirtualBox guests and set to work comparing the memory requirements of all the Linux desktop environments I could.

Damn it, just tell me what the "lightest" desktop environment is!

OK, for those of you who just want the final answer, with none of the explaination, here it is:

| Desktop Environment | Memory Used | | ---------------------|------------:| | LXDE | 84.9 MiB | | Enlightenment 0.18.5 | 89.6 MiB | | XFCE 4.10.2 | 105.8 MiB | | MATE 1.8.0 | 121.6 MiB | | Cinnamon 2.0.14 | 167.1 MiB | | GNOME3 3.10 | 256.4 MiB | | KDE 4.12 | 358.8 MiB | Bullshit! How did you come up with these numbers?

TL;DR

All the VirtualBox VMs are 32-bit with 768MB RAM and based on the same core Arch Linux installation. I achieved this using my ArchInstaller script which is designed for quickly installing reproducible Arch Linux setups.

Each VM differs only by the packages that are required for the given desktop environment. The desktop environments native display manager is also installed but if it doesn't have one then lightdm was chosen. LXDE, XFCE, MATE, Cinnamon and GNOME all have gvfs-smb installed as this enables accessing Windows and Samba shares (a common requirement for home and office) in their respective file managers and the KDE install includes packages to provide equivalent functionality. You can see the specific desktop environment packages or package groups that were installed here:

Each VM was booted, logged in and any initial desktop environment configuration was completed choosing the default options if prompted. Then ps_mem was installed, the VM shut down and a snapshot made.

Each VM was then started, logged in via the display manager, the desktop environment was fully loaded and waited for disk activity to settle. Then ps -efH and ps_mem were executed via SSH and the results sent back to my workstation. When the process and memory collections were conducted there had been no desktop interaction and no applications had been launched.

Your numbers are wrong I can get xxx desktop to run in yyy less memory!

Well done, you probably can.

Each virtual machine has VirtualBox guest additions, OpenSSH, Network Manager, avahi-daemon, ntpd, rpc.statd, syslog-ng and various other bits and bobs installed and running. Some of these are not required or have lighter alternatives available.

So, while I freely accept that each desktop environment can be run in less memory, the results here are relative to a consistent base setup.

However, what is important to note is that I think the Cinnamon results are too low. Cinnamon is forked from GNOME3 and the Arch Linux package groups for Cinnamon only install the core Cinnamon packages but none of the GNOME3 applications or components that would be required to create a full desktop environment.

So comparing Cinnamon with the other desktops in this test is not a fair comparison. For example, GNOME3 and KDE default installs on Arch Linux include all the accessibility extensions and applications for sight or mobility impaired individuals where as Cinnamon does not. This is just one example of where I think the Cinnamon results are skewed.

The RAM is there to be used. Is lighter actually better?

No, and Yes.

I subscribe to the school of thought that RAM is there to be used. But;

  • I want to preserve as much free RAM for the applications I run, not for feature bloat in the desktop environment. I'm looking at you KDE.
  • I want a fully integrated desktop experience, but not one that is merely lighter because it lacks features. I'm looking at you LXDE.
  • I want a consistent user interface that any of my family could use, not one that favours style over substance. I'm looking at you Enlightenment.

Another take on lightness is that the more RAM used, the more code that needs executing. Therefore, higher CPU utilisation and degraded desktop performance on modest hardware. This could also translate into degraded battery performance.

This is why I choose MATE Desktop. It is a fully integrated desktop environment, that is responsive, feature full, has reasonable memory requirements and scales from single core armv6h CPU with 512MB RAM to multi core x86_64 CPU with 32GB RAM (for me at least).

Without the full stats it never happened. Prove it!

He is the full data capture from ps_mem.py for each desktop environment.

LXDE Private + Shared = RAM used Program 176.0 KiB + 37.5 KiB = 213.5 KiB dbus-launch 308.0 KiB + 38.0 KiB = 346.0 KiB dhcpcd 320.0 KiB + 85.5 KiB = 405.5 KiB rpcbind 352.0 KiB + 76.0 KiB = 428.0 KiB lxdm-binary 388.0 KiB + 79.0 KiB = 467.0 KiB lxsession 560.0 KiB + 34.0 KiB = 594.0 KiB crond 576.0 KiB + 51.0 KiB = 627.0 KiB systemd-logind 476.0 KiB + 280.0 KiB = 756.0 KiB avahi-daemon (2) 584.0 KiB + 191.5 KiB = 775.5 KiB at-spi-bus-launcher 764.0 KiB + 53.5 KiB = 817.5 KiB systemd-udevd 4.6 MiB + -3890.5 KiB = 817.5 KiB menu-cached 612.0 KiB + 211.0 KiB = 823.0 KiB gvfsd 496.0 KiB + 332.0 KiB = 828.0 KiB lxdm-session 628.0 KiB + 226.0 KiB = 854.0 KiB at-spi2-registryd 772.0 KiB + 83.5 KiB = 855.5 KiB VBoxService 764.0 KiB + 93.0 KiB = 857.0 KiB rpc.statd 704.0 KiB + 165.5 KiB = 869.5 KiB ntpd 712.0 KiB + 174.5 KiB = 886.5 KiB accounts-daemon 4.8 MiB + -3888.0 KiB = 1.0 MiB gvfsd-fuse 896.0 KiB + 267.5 KiB = 1.1 MiB gvfsd-trash 5.0 MiB + -3765.0 KiB = 1.4 MiB upowerd 5.1 MiB + -3691.5 KiB = 1.4 MiB gvfs-udisks2-volume-monitor 5.1 MiB + -3774.0 KiB = 1.5 MiB udisksd 1.0 MiB + 505.5 KiB = 1.5 MiB dbus-daemon (3) 1.2 MiB + 531.0 KiB = 1.7 MiB (sd-pam) (2) 1.7 MiB + 276.0 KiB = 1.9 MiB syslog-ng 1.0 MiB + 1.0 MiB = 2.1 MiB systemd (3) 1.4 MiB + 940.0 KiB = 2.3 MiB lxpolkit 1.3 MiB + 1.2 MiB = 2.5 MiB sshd (2) 2.3 MiB + 665.0 KiB = 3.0 MiB NetworkManager 2.6 MiB + 502.5 KiB = 3.0 MiB VBoxClient (4) 11.2 MiB + -7782.5 KiB = 3.6 MiB polkitd 3.2 MiB + 696.5 KiB = 3.9 MiB openbox 2.9 MiB + 1.9 MiB = 4.8 MiB lxpanel 5.2 MiB + 61.5 KiB = 5.3 MiB systemd-journald 3.6 MiB + 1.8 MiB = 5.4 MiB pcmanfm 7.0 MiB + 1.6 MiB = 8.5 MiB nm-applet 16.4 MiB + 504.0 KiB = 16.9 MiB Xorg --------------------------------- 84.9 MiB ================================= Enlightenment Private + Shared = RAM used Program 172.0 KiB + 46.5 KiB = 218.5 KiB dbus-launch 316.0 KiB + 40.0 KiB = 356.0 KiB dhcpcd 336.0 KiB + 87.5 KiB = 423.5 KiB rpcbind 560.0 KiB + 37.0 KiB = 597.0 KiB crond 580.0 KiB + 54.0 KiB = 634.0 KiB systemd-logind 688.0 KiB + 67.5 KiB = 755.5 KiB systemd-udevd 480.0 KiB + 276.0 KiB = 756.0 KiB avahi-daemon (2) 700.0 KiB + 133.5 KiB = 833.5 KiB ntpd 768.0 KiB + 78.5 KiB = 846.5 KiB VBoxService 580.0 KiB + 267.0 KiB = 847.0 KiB tempget 544.0 KiB + 312.0 KiB = 856.0 KiB enlightenment_start 764.0 KiB + 94.0 KiB = 858.0 KiB rpc.statd 600.0 KiB + 280.5 KiB = 880.5 KiB at-spi-bus-launcher 624.0 KiB + 298.0 KiB = 922.0 KiB at-spi2-registryd 724.0 KiB + 309.5 KiB = 1.0 MiB accounts-daemon 784.0 KiB + 386.5 KiB = 1.1 MiB enlightenment_fm 952.0 KiB + 395.0 KiB = 1.3 MiB efreetd 1.0 MiB + 517.0 KiB = 1.5 MiB dbus-daemon (3) 5.3 MiB + -3781.0 KiB = 1.7 MiB udisksd 1.2 MiB + 483.0 KiB = 1.7 MiB (sd-pam) (2) 1.6 MiB + 234.0 KiB = 1.9 MiB syslog-ng 1.1 MiB + 1.0 MiB = 2.1 MiB systemd (3) 1.4 MiB + 814.5 KiB = 2.2 MiB lightdm (2) 1.3 MiB + 1.1 MiB = 2.4 MiB sshd (2) 2.6 MiB + 575.5 KiB = 3.2 MiB VBoxClient (4) 2.4 MiB + 781.0 KiB = 3.2 MiB NetworkManager 10.9 MiB + -7741.5 KiB = 3.3 MiB polkitd 6.2 MiB + 68.5 KiB = 6.3 MiB systemd-journald 11.3 MiB + -2300.0 KiB = 9.1 MiB nm-applet 16.3 MiB + 426.0 KiB = 16.7 MiB Xorg 19.9 MiB + 1.5 MiB = 21.4 MiB enlightenment --------------------------------- 89.6 MiB ================================= XFCE Private + Shared = RAM used Program 176.0 KiB + 31.5 KiB = 207.5 KiB dbus-launch 292.0 KiB + 26.5 KiB = 318.5 KiB gpg-agent 312.0 KiB + 36.0 KiB = 348.0 KiB dhcpcd 324.0 KiB + 84.5 KiB = 408.5 KiB rpcbind 484.0 KiB + 94.0 KiB = 578.0 KiB xfconfd 560.0 KiB + 31.0 KiB = 591.0 KiB crond 584.0 KiB + 49.0 KiB = 633.0 KiB systemd-logind 476.0 KiB + 250.0 KiB = 726.0 KiB avahi-daemon (2) 600.0 KiB + 163.5 KiB = 763.5 KiB at-spi-bus-launcher 624.0 KiB + 169.0 KiB = 793.0 KiB at-spi2-registryd 620.0 KiB + 180.0 KiB = 800.0 KiB gvfsd 752.0 KiB + 49.5 KiB = 801.5 KiB systemd-udevd 764.0 KiB + 54.5 KiB = 818.5 KiB sh 768.0 KiB + 57.5 KiB = 825.5 KiB VBoxService 764.0 KiB + 91.0 KiB = 855.0 KiB rpc.statd 708.0 KiB + 163.5 KiB = 871.5 KiB ntpd 712.0 KiB + 168.5 KiB = 880.5 KiB accounts-daemon 856.0 KiB + 177.5 KiB = 1.0 MiB gvfsd-fuse 828.0 KiB + 229.5 KiB = 1.0 MiB gvfsd-trash 992.0 KiB + 285.0 KiB = 1.2 MiB tumblerd 1.0 MiB + 252.0 KiB = 1.3 MiB upowerd 5.1 MiB + -3728.5 KiB = 1.4 MiB gvfs-udisks2-volume-monitor 5.1 MiB + -3802.0 KiB = 1.4 MiB udisksd 1.1 MiB + 354.0 KiB = 1.5 MiB xfce4-notifyd 1.2 MiB + 489.0 KiB = 1.7 MiB (sd-pam) (2) 1.3 MiB + 493.5 KiB = 1.8 MiB dbus-daemon (3) 1.5 MiB + 460.0 KiB = 1.9 MiB Thunar 1.7 MiB + 266.0 KiB = 1.9 MiB syslog-ng 5.4 MiB + -3474.5 KiB = 2.0 MiB lightdm (2) 1.1 MiB + 1.0 MiB = 2.1 MiB systemd (3) 1.4 MiB + 682.5 KiB = 2.1 MiB panel-6-systray 1.6 MiB + 637.5 KiB = 2.2 MiB xfce4-session 1.9 MiB + 529.5 KiB = 2.4 MiB xfsettingsd 1.6 MiB + 896.5 KiB = 2.5 MiB panel-2-actions 1.3 MiB + 1.2 MiB = 2.5 MiB sshd (2) 2.3 MiB + 574.0 KiB = 2.9 MiB NetworkManager 2.6 MiB + 446.5 KiB = 3.0 MiB VBoxClient (4) 2.5 MiB + 585.5 KiB = 3.0 MiB xfce4-power-manager (2) 2.1 MiB + 1.1 MiB = 3.2 MiB xfwm4 11.2 MiB + -7865.0 KiB = 3.5 MiB polkitd 3.1 MiB + 1.3 MiB = 4.4 MiB xfce4-panel 3.8 MiB + 1.6 MiB = 5.4 MiB xfdesktop 6.2 MiB + 63.5 KiB = 6.3 MiB systemd-journald 10.5 MiB + -2789.5 KiB = 7.8 MiB nm-applet 22.6 MiB + 844.5 KiB = 23.4 MiB Xorg --------------------------------- 105.8 MiB ================================= MATE Private + Shared = RAM used Program 172.0 KiB + 29.5 KiB = 201.5 KiB dbus-launch 248.0 KiB + 57.5 KiB = 305.5 KiB rtkit-daemon 312.0 KiB + 33.0 KiB = 345.0 KiB dhcpcd 324.0 KiB + 84.5 KiB = 408.5 KiB rpcbind 440.0 KiB + 89.0 KiB = 529.0 KiB dconf-service 560.0 KiB + 29.0 KiB = 589.0 KiB crond 580.0 KiB + 46.0 KiB = 626.0 KiB systemd-logind 548.0 KiB + 116.0 KiB = 664.0 KiB gconfd-2 544.0 KiB + 182.0 KiB = 726.0 KiB gconf-helper 580.0 KiB + 146.5 KiB = 726.5 KiB at-spi-bus-launcher 480.0 KiB + 248.0 KiB = 728.0 KiB avahi-daemon (2) 696.0 KiB + 47.5 KiB = 743.5 KiB systemd-udevd 612.0 KiB + 163.0 KiB = 775.0 KiB at-spi2-registryd 4.6 MiB + -3935.0 KiB = 777.0 KiB gvfsd 768.0 KiB + 56.5 KiB = 824.5 KiB VBoxService 764.0 KiB + 89.0 KiB = 853.0 KiB rpc.statd 704.0 KiB + 160.5 KiB = 864.5 KiB ntpd 732.0 KiB + 148.5 KiB = 880.5 KiB accounts-daemon 808.0 KiB + 202.5 KiB = 1.0 MiB gvfsd-trash 860.0 KiB + 154.0 KiB = 1.0 MiB gvfsd-fuse 1.0 MiB + 249.0 KiB = 1.3 MiB upowerd 5.0 MiB + -3758.5 KiB = 1.4 MiB gvfs-udisks2-volume-monitor 5.1 MiB + -3810.0 KiB = 1.4 MiB udisksd 1.4 MiB + 377.0 KiB = 1.8 MiB (sd-pam) (2) 1.7 MiB + 267.0 KiB = 1.9 MiB syslog-ng 1.5 MiB + 476.5 KiB = 1.9 MiB dbus-daemon (3) 1.5 MiB + 412.5 KiB = 1.9 MiB polkit-mate-authentication-agent-1 1.4 MiB + 591.5 KiB = 2.0 MiB lightdm (2) 1.4 MiB + 884.0 KiB = 2.2 MiB systemd (3) 5.9 MiB + -3514.5 KiB = 2.5 MiB mate-screensaver 1.3 MiB + 1.2 MiB = 2.5 MiB sshd (2) 2.0 MiB + 559.5 KiB = 2.5 MiB mate-session 1.9 MiB + 675.5 KiB = 2.6 MiB notification-area-applet 2.0 MiB + 734.0 KiB = 2.7 MiB mate-power-manager 2.2 MiB + 579.0 KiB = 2.8 MiB NetworkManager 2.6 MiB + 417.5 KiB = 3.0 MiB VBoxClient (4) 2.8 MiB + 678.0 KiB = 3.4 MiB marco 11.2 MiB + -7886.5 KiB = 3.5 MiB polkitd 2.7 MiB + 930.0 KiB = 3.6 MiB wnck-applet 3.5 MiB + 304.5 KiB = 3.8 MiB pulseaudio 2.7 MiB + 1.2 MiB = 3.9 MiB mate-volume-control-applet 3.0 MiB + 1.0 MiB = 4.0 MiB clock-applet 3.6 MiB + 1.1 MiB = 4.7 MiB mate-settings-daemon 3.7 MiB + 1.2 MiB = 4.9 MiB mate-panel 7.0 MiB + 314.0 KiB = 7.3 MiB systemd-journald 6.1 MiB + 1.5 MiB = 7.6 MiB caja 7.8 MiB + 1.1 MiB = 8.8 MiB nm-applet 17.2 MiB + 1.2 MiB = 18.4 MiB Xorg --------------------------------- 121.6 MiB ================================= Cinnamon Private + Shared = RAM used Program 240.0 KiB + 55.5 KiB = 295.5 KiB rtkit-daemon 312.0 KiB + 32.0 KiB = 344.0 KiB dhcpcd 340.0 KiB + 83.5 KiB = 423.5 KiB rpcbind 384.0 KiB + 78.5 KiB = 462.5 KiB dbus-launch (2) 556.0 KiB + 28.0 KiB = 584.0 KiB crond 576.0 KiB + 44.0 KiB = 620.0 KiB systemd-logind 548.0 KiB + 110.0 KiB = 658.0 KiB gconfd-2 460.0 KiB + 246.0 KiB = 706.0 KiB avahi-daemon (2) 540.0 KiB + 179.0 KiB = 719.0 KiB gconf-helper 584.0 KiB + 167.0 KiB = 751.0 KiB at-spi-bus-launcher 620.0 KiB + 152.0 KiB = 772.0 KiB at-spi2-registryd 616.0 KiB + 170.0 KiB = 786.0 KiB gvfsd 748.0 KiB + 45.5 KiB = 793.5 KiB systemd-udevd 772.0 KiB + 54.5 KiB = 826.5 KiB VBoxService 700.0 KiB + 129.5 KiB = 829.5 KiB ntpd 760.0 KiB + 87.0 KiB = 847.0 KiB rpc.statd 4.7 MiB + -3940.5 KiB = 863.5 KiB accounts-daemon 860.0 KiB + 162.0 KiB = 1.0 MiB gvfsd-fuse 816.0 KiB + 210.5 KiB = 1.0 MiB gvfsd-trash 5.0 MiB + -3866.0 KiB = 1.2 MiB upowerd 5.1 MiB + -3753.5 KiB = 1.4 MiB gvfs-udisks2-volume-monitor 1.1 MiB + 283.0 KiB = 1.4 MiB udisksd 1.1 MiB + 319.5 KiB = 1.4 MiB cupsd 5.3 MiB + -3709.0 KiB = 1.7 MiB csd-printer 1.6 MiB + 219.0 KiB = 1.8 MiB syslog-ng 1.4 MiB + 582.5 KiB = 1.9 MiB lightdm (2) 1.6 MiB + 512.5 KiB = 2.1 MiB dbus-daemon (4) 1.4 MiB + 1.0 MiB = 2.4 MiB systemd (4) 1.3 MiB + 1.1 MiB = 2.4 MiB sshd (2) 1.8 MiB + 624.5 KiB = 2.4 MiB (sd-pam) (3) 2.3 MiB + 335.0 KiB = 2.7 MiB colord 2.2 MiB + 519.0 KiB = 2.7 MiB NetworkManager 2.6 MiB + 447.5 KiB = 3.0 MiB VBoxClient (4) 2.5 MiB + 695.5 KiB = 3.2 MiB polkit-gnome-authentication-agent-1 6.7 MiB + -3304.0 KiB = 3.5 MiB cinnamon-screensaver 11.2 MiB + -7914.5 KiB = 3.5 MiB polkitd 7.0 MiB + -3244.0 KiB = 3.8 MiB cinnamon-session 3.5 MiB + 343.5 KiB = 3.9 MiB pulseaudio 5.2 MiB + 56.5 KiB = 5.3 MiB systemd-journald 3.8 MiB + 2.0 MiB = 5.8 MiB nm-applet 5.4 MiB + 1.9 MiB = 7.3 MiB cinnamon-settings-daemon 8.1 MiB + 1.1 MiB = 9.2 MiB cinnamon-launch 8.4 MiB + 2.0 MiB = 10.3 MiB nemo 32.0 MiB + -5304.5 KiB = 26.8 MiB Xorg 37.5 MiB + 5.3 MiB = 42.9 MiB cinnamon --------------------------------- 167.1 MiB ================================= GNOME3 Private + Shared = RAM used Program 172.0 KiB + 33.5 KiB = 205.5 KiB dbus-launch 272.0 KiB + 14.0 KiB = 286.0 KiB ssh-agent 244.0 KiB + 48.5 KiB = 292.5 KiB rtkit-daemon 312.0 KiB + 30.0 KiB = 342.0 KiB dhcpcd 324.0 KiB + 21.0 KiB = 345.0 KiB systemd-localed 324.0 KiB + 22.5 KiB = 346.5 KiB systemd-hostnamed 324.0 KiB + 82.5 KiB = 406.5 KiB rpcbind 364.0 KiB + 77.0 KiB = 441.0 KiB dconf-service 564.0 KiB + 27.0 KiB = 591.0 KiB crond 536.0 KiB + 60.5 KiB = 596.5 KiB obexd 560.0 KiB + 47.5 KiB = 607.5 KiB bluetoothd 592.0 KiB + 41.0 KiB = 633.0 KiB systemd-logind 556.0 KiB + 102.0 KiB = 658.0 KiB gconfd-2 544.0 KiB + 170.0 KiB = 714.0 KiB gconf-helper 620.0 KiB + 125.0 KiB = 745.0 KiB at-spi2-registryd 500.0 KiB + 249.0 KiB = 749.0 KiB avahi-daemon (2) 592.0 KiB + 158.5 KiB = 750.5 KiB at-spi-bus-launcher 620.0 KiB + 137.0 KiB = 757.0 KiB gvfsd 720.0 KiB + 44.5 KiB = 764.5 KiB systemd-udevd 692.0 KiB + 105.0 KiB = 797.0 KiB gdm 688.0 KiB + 140.0 KiB = 828.0 KiB gvfsd-burn 704.0 KiB + 128.5 KiB = 832.5 KiB ntpd 768.0 KiB + 84.0 KiB = 852.0 KiB rpc.statd 744.0 KiB + 123.5 KiB = 867.5 KiB accounts-daemon 720.0 KiB + 257.5 KiB = 977.5 KiB (sd-pam) 852.0 KiB + 131.0 KiB = 983.0 KiB gvfsd-fuse 776.0 KiB + 257.0 KiB = 1.0 MiB zeitgeist-daemon 956.0 KiB + 161.5 KiB = 1.1 MiB gdm-simple-slave 1.0 MiB + 188.0 KiB = 1.2 MiB upowerd 1.0 MiB + 261.5 KiB = 1.3 MiB gvfs-udisks2-volume-monitor 1.1 MiB + 216.0 KiB = 1.3 MiB udisksd 1.1 MiB + 298.5 KiB = 1.4 MiB cupsd 1.1 MiB + 469.5 KiB = 1.6 MiB gdm-session-worker 1.3 MiB + 314.0 KiB = 1.6 MiB gsd-printer 1.5 MiB + 285.5 KiB = 1.7 MiB gnome-keyring-daemon 1.6 MiB + 207.0 KiB = 1.8 MiB syslog-ng 1.0 MiB + 912.5 KiB = 1.9 MiB systemd (2) 1.3 MiB + 661.0 KiB = 2.0 MiB mission-control-5 1.6 MiB + 421.0 KiB = 2.0 MiB gnome-session 1.7 MiB + 398.5 KiB = 2.0 MiB colord 1.6 MiB + 511.5 KiB = 2.1 MiB zeitgeist-datahub 1.3 MiB + 1.0 MiB = 2.3 MiB sshd (2) 1.8 MiB + 624.0 KiB = 2.5 MiB gnome-shell-calendar-server 2.1 MiB + 399.0 KiB = 2.5 MiB NetworkManager 2.2 MiB + 468.5 KiB = 2.6 MiB dbus-daemon (3) 2.4 MiB + 839.5 KiB = 3.2 MiB evolution-source-registry 2.6 MiB + 647.0 KiB = 3.3 MiB gnome-control-center-search-provider 3.5 MiB + 355.5 KiB = 3.8 MiB pulseaudio 3.4 MiB + 1.0 MiB = 4.4 MiB tracker-miner-fs 3.3 MiB + 1.7 MiB = 5.0 MiB goa-daemon 4.4 MiB + 749.5 KiB = 5.1 MiB polkitd 4.0 MiB + 1.8 MiB = 5.8 MiB nm-applet 5.2 MiB + 857.5 KiB = 6.1 MiB tracker-store 6.6 MiB + 58.5 KiB = 6.7 MiB systemd-journald 5.8 MiB + 1.9 MiB = 7.7 MiB gnome-settings-daemon 6.4 MiB + 2.5 MiB = 8.9 MiB evolution-alarm-notify 9.1 MiB + 1.6 MiB = 10.7 MiB Xorg 10.1 MiB + 1.1 MiB = 11.2 MiB seahorse 11.9 MiB + 2.5 MiB = 14.4 MiB epiphany 18.9 MiB + 2.6 MiB = 21.6 MiB WebKitWebProcess 24.3 MiB + 972.0 KiB = 25.3 MiB evolution-calendar-factory 57.9 MiB + 5.2 MiB = 63.2 MiB gnome-shell --------------------------------- 256.4 MiB ================================= KDE Private + Shared = RAM used Program 68.0 KiB + 7.0 KiB = 75.0 KiB start_kdeinit 72.0 KiB + 13.5 KiB = 85.5 KiB kwrapper4 120.0 KiB + 21.0 KiB = 141.0 KiB agetty 172.0 KiB + 25.5 KiB = 197.5 KiB dbus-launch 292.0 KiB + 26.5 KiB = 318.5 KiB gpg-agent 312.0 KiB + 30.0 KiB = 342.0 KiB dhcpcd 324.0 KiB + 81.5 KiB = 405.5 KiB rpcbind 556.0 KiB + 25.0 KiB = 581.0 KiB crond 596.0 KiB + 40.0 KiB = 636.0 KiB systemd-logind 496.0 KiB + 234.0 KiB = 730.0 KiB avahi-daemon (2) 700.0 KiB + 96.5 KiB = 796.5 KiB ntpd 768.0 KiB + 44.5 KiB = 812.5 KiB VBoxService 768.0 KiB + 83.0 KiB = 851.0 KiB rpc.statd 832.0 KiB + 40.5 KiB = 872.5 KiB systemd-udevd 832.0 KiB + 51.5 KiB = 883.5 KiB startkde 728.0 KiB + 264.5 KiB = 992.5 KiB accounts-daemon 516.0 KiB + 638.0 KiB = 1.1 MiB nepomukserver 652.0 KiB + 519.5 KiB = 1.1 MiB kdm (2) 1.0 MiB + 346.0 KiB = 1.4 MiB upowerd 848.0 KiB + 686.0 KiB = 1.5 MiB klauncher 1.2 MiB + 465.0 KiB = 1.6 MiB (sd-pam) (2) 1.3 MiB + 298.0 KiB = 1.6 MiB udisksd 1.6 MiB + 225.5 KiB = 1.8 MiB akonadi_control 1.6 MiB + 151.0 KiB = 1.8 MiB syslog-ng 1.1 MiB + 967.5 KiB = 2.0 MiB systemd (3) 1.6 MiB + 408.5 KiB = 2.0 MiB dbus-daemon (2) 668.0 KiB + 1.5 MiB = 2.1 MiB kdeinit4 1.3 MiB + 1.0 MiB = 2.3 MiB sshd (2) 1.4 MiB + 1.4 MiB = 2.8 MiB kio_trash (2) 2.2 MiB + 1.0 MiB = 3.2 MiB klipper 2.8 MiB + 383.5 KiB = 3.2 MiB VBoxClient (4) 2.9 MiB + 454.0 KiB = 3.3 MiB NetworkManager 2.5 MiB + 989.0 KiB = 3.4 MiB ksmserver 3.3 MiB + 542.0 KiB = 3.8 MiB kuiserver 3.2 MiB + 875.0 KiB = 4.1 MiB kglobalaccel 3.4 MiB + 743.0 KiB = 4.1 MiB akonadi_migration_agent 3.5 MiB + 741.5 KiB = 4.2 MiB polkit-kde-authentication-agent-1 3.8 MiB + 638.5 KiB = 4.4 MiB knotify4 3.9 MiB + 892.0 KiB = 4.8 MiB akonadi_maildispatcher_agent 3.9 MiB + 954.5 KiB = 4.8 MiB nepomukfileindexer 4.1 MiB + 930.5 KiB = 5.0 MiB nepomukfilewatch 4.1 MiB + 1.2 MiB = 5.3 MiB akonadi_newmailnotifier_agent 5.3 MiB + 50.5 KiB = 5.4 MiB systemd-journald 4.4 MiB + 1.0 MiB = 5.4 MiB korgac 4.2 MiB + 1.2 MiB = 5.4 MiB akonadi_nepomuk_feeder 4.7 MiB + 850.5 KiB = 5.6 MiB kactivitymanagerd 13.4 MiB + -7873.5 KiB = 5.7 MiB polkitd 14.1 MiB + -7803.5 KiB = 6.5 MiB akonadiserver 5.9 MiB + 905.5 KiB = 6.8 MiB nepomukstorage 5.6 MiB + 1.8 MiB = 7.4 MiB akonadi_sendlater_agent 5.7 MiB + 2.2 MiB = 8.0 MiB kmix 5.9 MiB + 2.4 MiB = 8.3 MiB akonadi_archivemail_agent 6.0 MiB + 2.4 MiB = 8.3 MiB akonadi_folderarchive_agent 6.0 MiB + 2.4 MiB = 8.4 MiB akonadi_mailfilter_agent 11.9 MiB + -1763.0 KiB = 10.2 MiB kded4 13.4 MiB + -1419.0 KiB = 12.1 MiB kwin 12.2 MiB + 3.0 MiB = 15.2 MiB akonadi_agent_launcher (4) 13.8 MiB + 3.2 MiB = 17.1 MiB krunner 65.1 MiB + -44927.5 KiB = 21.3 MiB mysqld 33.7 MiB + 111.5 KiB = 33.8 MiB virtuoso-t 37.4 MiB + -816.5 KiB = 36.7 MiB Xorg 38.3 MiB + 7.8 MiB = 46.1 MiB plasma-desktop --------------------------------- 358.8 MiB ================================= Final thoughts

On Arch Linux at least, XFCE has lower resource requirements than MATE. When I said different in the past I was wrong, unless you use openSUSE in which case I was probably right, maybe.

LXDE does achieve what it set out to do as it is indeed a the lightest weight desktop environment I tested.

Anyone want to share some humble pie?

Categories: LUG Community Blogs

Steve Kemp: That is it, I'm going to do it

Sat, 22/03/2014 - 15:49

That's it, I'm going to do it: I have now committed myself to writing a scalable, caching, reverse HTTP proxy.

The biggest question right now is implementation language; obviously "threading" of some kind is required so it is a choice between Perl's anyevent, Python's twisted, Rubys event machine, or node.js.

I'm absolutely, definitely, not going to use C, or C++.

Writing a a reverse proxy in node.js is almost trivial, the hard part will be working out which language to express the caching behaviour, on a per type, and per-resource basis.

I will ponder.

Categories: LUG Community Blogs

Alan Pope: Running Core Apps on the Desktop

Fri, 21/03/2014 - 13:20

One of the (many) challenges with creating a new mobile platform is that of bootstrapping app developers. The Ubuntu SDK – based on well known tools like Qt & QtCreator and supporting HTML5, C++ & GL – we can run our applications both on mobile devices and standard Ubuntu desktops.

With our convergence plans being a core component of Ubuntu over the coming releases, we can take advantage of this when testing mobile apps.

Developers can create & users can test applications without having to commit funds to a dedicated Ubuntu mobile device. Of course in the future Ubuntu mobile devices will be ubiquitous but for now we can support those users, testers and developers right now to use Ubuntu mobile apps on the desktop.

So with the Core Apps Hack Days just around the corner, now is a great time to install the core apps on your desktop and help test them, file bugs and contribute patches!

For users of Ubuntu 13.10 and Trusty (14.04) we have a Core Apps Daily PPA which has builds of all the core apps. Installing them is a cinch on 13.10 and 14.04 via the PPA & touch-coreapps metapackage:-

sudo add-apt-repository ppa:ubuntu-touch-coreapps-drivers/daily
sudo apt-get update
sudo apt-get install touch-coreapps

Note: This has been tested on 13.10 and 14.04 but not on previous releases.

If you later wish to remove them simply use sudo ppa-purge ppa:ubuntu-touch-coreapps-drivers/daily or just sudo apt-get autoremove touch-coreapps.

Once installed you should see icons for all the core apps in your dash

We welcome constructive feedback and bug reports about all aspects of the Core Apps. You can find us in #ubuntu-app-devel on freenode and details of where to file bugs can be found on the Core Apps wiki pages.

You can get started with developing apps on Ubuntu via the SDK, the documentation for which is at developer.ubuntu.com.

Categories: LUG Community Blogs

Alan Pope: March 2014 Core Apps Hack Days!

Fri, 21/03/2014 - 12:26

Hack Days are back!

On March 25th – 27th 2014 from 09:00 – 21:00U UTC we’re having another round of Core Apps Hack Days as we Sprint towards the final Ubuntu 14.04 release in April.

This time we’re concentrating our focus on 6 main apps, but we welcome new contributions to all the core apps. We’re identifying all the bite-size bugs which would be ideal for new developers, and we have some more chunky work for more experienced developers looking for more of a challenge. Getting involved is really easy and it’s fun and friendly.

Music & Reminders will be the focus on Tuesday 25th.

  

Clock & Calendar on Wednesday 26th.

  

Weather & Calculator on Thursday 27th.

  

That said, we don’t want to limit contributions to just those days, and of course welcome community developers getting involved at any time of day or night!

We’ve detailed on the HackDays wiki page how you can get involved and all the other details. Head over there for more information.

David, Michael & myself will be around on IRC in #ubuntu-app-devel as always to co-ordinate and run the Hack Days. We’ll also be able to test on multiple mobile devices as well as desktops and laptops. We can review code and get completed work landed into trunk and on devices promptly. We’ll also have and other Core Apps community & Canonical platform developers around to consult and mentor where required.

If you’ve ever considered developing on Ubuntu, but not got around to it, now is a great time to join. There’s plenty to do for people of all levels, developing Free Software for a very wide audience. Join us and lets make the Core Apps rock!

Categories: LUG Community Blogs

Debian Bits: Debian Project Leader elections 2014

Fri, 21/03/2014 - 00:00

It's again that time of the year for the Debian Project: the elections of its Project Leader! Starting on March 31st, and during the following two weeks, the Debian Developers will vote to choose the person who will guide the project for one year.

Among this year's candidates there is the current DPL, Lucas Nussbaum, who admits that "the workload involved in being the DPL is just huge," and motivates his nomination with the need for stability in the project in this release cycle, especially after the difficult decision about the default init system. In his platform, Lucas speaks of technical and social steps to improve the project: from reproducible builds for a more secure archive to a renewed effort to run Debian on new platforms (especially smartphone and tablets); from a more welcoming approach to prospective contributors to an easier collaboration with organizations.

The only other candidate left after Gergely Nagy withdrew his nomination, is former Release Manager Neil McGovern. Neil's platform focuses mainly on the need to "ensure that we cater to our users, and there's millions of them. From those running the latest software in unstable, to people who simply want a rock solid core release." In his opinion "the size of Debian is increasing, and will reach a point where we're unable to guarantee basic compatibility with other packages, or the length of time it takes to do so becomes exponentially longer, unless something changes." To fix this problem, Neil proposes the implementation of PPAs (Personal Package Archives), the modernisation of the current build and infrastructure system as well as generally supporting the various teams.

The campaigning period will last until March 30th: the candidates are already engaged in debates and discussions on the debian-vote mailing list where they'll reply to questions from users and contributors.

Categories: LUG Community Blogs

Steve Kemp: Time to mix things up again

Thu, 20/03/2014 - 12:19

I'm currently a contractor, working for/with Dyn, until April the 11th.

I need to decide what I'm doing next, if anything. In the meantime here are some diversions:

Some trivial security issues

I noticed and reported two more temporary-file issues insecure temporary file usage in apt-extracttemplates (apt), and libreadline6: Insecure use of temporary files - in _rl_trace.

Neither of those are particularly serious, but looking for them took a little time. I recently started re-auditing code, and decided to do three things:

  • Download the source code to every package installed upon this system.
  • Download the source code to all packages matching the pattern ^libpam-, and ^libruby-*.

I've not yet finished slogging through the code, but my expectation will be a few more issues. I'll guess 5-10, given my cynical nature.

NFS-work

I've been tasked with the job of setting up a small cluster running from a shared and writeable NFS-root.

This is a fun project which I've done before, PXE-booting a machine and telling it to mount a root filesystem over NFS is pretty straight-forward. The hard part is making that system writeable, such that you can boot and run "apt-get install XX". I've done it in the past using magic filesystems, or tmpfs. Either will work here, so I'm not going to dwell on it.

Another year

I had another birthday, so that was nice.

My wife took me to a water-park where we swam like fisheseses, and that tied in nicely with a recent visit to Deep Sea World, where we got to walk through a glass tunnel, beneath a pool FULL OF SHARKS, and other beasties.

Beyond that I received another Global Knife, which has now been bloodied, since I managed to slice my finger open chopping mushrooms on Friday. Oops. Currently I'm in that annoying state where I'm slowly getting used to typing with a plaster around the tip of my finger, but knowing that it'll have to come off again and I'll get confused again.

Linux Distribution

I absolutely did not start working on a "linux distribution", because that would be crazy. Do I look like a crazy-person?

All I did was play around with GNU Stow, and ponder the idea of using a minimal LibC and GNU Stow to organize things.

It went well, but the devil is always in the details.

I like the idea of a master-distribution which installs pam, ssh, etc, but then has derivitives for "This is a webserver", "This is a Ruby server", and "This is a database server".

Consider it like task-selection, but with higher ambition.

There's probably more I could say; a new kitchen sink (literally) and a new tap have made our kitchen nicer, I've made it past six months of regular gym-based workouts, and I didn't die when I went to the beach in the dark the other night, so that was nice.

Umm? Stuff?

Have a nice day. Thanks.

Categories: LUG Community Blogs

Debian Bits: Working in a possible LTS for Debian Squeeze

Thu, 20/03/2014 - 11:15

The Debian Security Team announced in the bits from their last meeting that they're considering to ask for the addition of a new suite to provide long term support (LTS) for Squeeze.

Quoting their announcement:

  • It needs to be pointed out that for this effort to be sustainable actual contributions by interested parties are required. squeeze-lts is not something that will magically fall from the sky. If you're dependent/interested in extended security support you should make an effort to contribute, either by contributing on your own or by paying a Debian developer/consultant to contribute for you. The security team itself is driving the effort, NOT doing it. Some team members will contribute to it individually, however.

  • Anyone interested in contributing, please get in touch with team@security.debian.org. We'll setup an initial coordination list with all interested parties. All policies / exact work will be sorted out there.

This means this is still not something settled and if you or your company is insterested in joining this effort, you should contact the security team ASAP. So they can see if there is enough people and resources to launch the LTS.

Categories: LUG Community Blogs