Is rpitc still maintained by Gibbio? - Printable Version

+- ARMTC Forum (
+-- Forum: Raspberry Pi 1 – Thin Client Project (
+--- Forum: General Discussion (
+--- Thread: Is rpitc still maintained by Gibbio? (/showthread.php?tid=1480)

Is rpitc still maintained by Gibbio? - greavette - 21-01-2015

I'm curious...does Gibbio still maintain rpitc? I don't see him on the forums at all anymore.

Or is Gibbio one of the Admins (DaWest or Admin) here on the forum?

rpitc is perfect for our small business (I've donated twice to Gibbio for his hard work). I hate to see development stop.


RE: If rpitc still maintained by Gibbio? - admin - 21-01-2015

Hey Greavette Smile
we are (Gibbio & DaWast) still working on the project.
We want to leave SoftFloat for the (more supported) HardFloat. But, there is some problem, first of all Raspberry is an ARMv6 and it doesn't support Thumb2 and NEON. So, due to this, for example, there is no official supported Citrix client.

But... We hope to release something very soon... atm we are looking at:
- Citrix: include the non-official accelerated client (
- XFCE instead of LXDE: this will solve the full screen issue with xFreeRDP and will give more user friendly tool to configure the ThinClient
- Other clients: vWorkspace will be dropped, VMWare Horizon is working (without PCoIP). Other clients will be rebuilded.

RaspberryPi is great, a little piece of hardware that can do almost everything just for 35€. Also, and maybe the best about RPi is the community. I hope to see soon a new RaspberryPi board Smile

RE: If rpitc still maintained by Gibbio? - greavette - 21-01-2015

Hey Gibbio, glad to see you are still working on this (it's Charles...we've emailed back and forth before in the past when you were kind enough to provide a hardfloat image for us).

Glad to hear you are still actively working on rpitc. I look forward to your next release that is hardfloat. In our office we like to use VirtualHere for our redirect of USB devices connected over IP (currently we use Silex USBoverIP hardware devices but doing this over a Pi reduces our costs greatly and reduces the number of hardware we need at each workstation).

I've been playing with an idea (not entirely mine) that now I wonder would benefit your work on rpitc as well. It's a drastic change from the way rpitc is setup currently but I wonder if this might help with your trying to support all these remote connections.

rpitc has been great in our office but I continue to look for ways that would benefit me in it's administration. If you have time to respond I'd like to run something by you:

What if we used an LTSP Server to serve up rpitc? As a test I installed PI-LTSP ( and it worked great. This uses an LTSP server and assumes no DHCP on LTSP (which is security router already has one). I like this project because it builds one common image that gets put onto all my SD Cards that I use in my Pi's. In this common image it points each Pi to the LTSP server. When the Thin Client Pi starts up, the thin client gets a login from LTSP. You login with whatever clients you have created on LTSP. In my case I had in each Clients Startup the rdesktop auto login instruction I created for rpitc to auto login to the workstation each client needs to use. Once you've made the connection to the LTSP server from the Pi, everything runs on the Pi but in Ram...You can even take the SD Card out if you like (I tried it and my rdesktop connection from my Pi to my windows server still worked). Cuts down on SD Card wear and I don't care about power failures now corrupting my Cards. I'm wondering if using a full Ubuntu/Debian install of an LTSP Server would assist you in being able to support the clients that a hardfloat Raspbian Image can't now?
  • Pros for using Pi-LTSP:
  • I like Pi-LTSP because its one common image put on every Pi (really just a couple of files that tell the Pi to point to the LTSP server).
  • I setup each client (user account) on my LTSP server and for each user I add in whatever I want each user to do (in each users autologin I'll start whatever I want to start just like I do for rpitc).
  • Administration means I login to the one LTSP server and do all my work. There is nothing to push out to my thin clients. Currently if I want to make a change to a thin client or many thin clients I have to SSH into each. Not a big deal but again I like the one place for Administration.
  • In a Prod environment I would use an LTSP in a cluster (just to be safe).
  • LTSP does have a graphical user management panel so the Admin can connect to any Pi Thin Client to take over (just like VNC).
  • The guy who created this system has wizards and menus for easy setup. Adding new users, backups, creating shared folders for each Pi to use. It's a slick system.
  • I love the slick bootup video you show when a Thin Client starts. hopefull it would be easy to add this to the LTSP startup for each Thin Client once they login.
  • The best part in my opinion is that the set of files that get put onto each thin client's SD card never need to be updated (or at least very rarely). You have a stack of cards with the exact same files on each. If a Card does need to be replaced you drop it in and do absolutely nothing to the card to get it working for that thin client. All the customized tools/instructions/scripts still live on the LTSP server.
  • Cons:
  • It does add the complexity of an LTSP Server to the mix which may not be good for some people to have to install in their network. Must ensure your network and LTSP can handle the traffic this would cause.
  • You now have a single point of faiure for all Thin Clients not connecting (you can alleviate this using a clustered LTSP, but again a more complicated setup).
  • I did tests on my own home network and I was successful in auto connecting to my windows VM from my Pi after I logged into the Pi-LTSP (couldn't even tell again I was doing this through Linux) but I wonder if performance would be a concern here? Again the Pi is doing all the work for the connecting to the remote computer...but adding more traffic as the LTSP server has to push the image to the thin client adds more traffic.
  • Since we are pushing the image to each Pi we are still limited in how our Apps run from the limited Pi resources (it won't make anything run faster on the Pi).

I welcome hearing your thoughts on this idea Gibbio. It's a drastic change from what you are currently doing and I'm not suggesting how you are building rpitc is wrong...but I'm curious if using an LTSP Server and incorporating all the goodness you've put into rpitc would fix some of the issues you have now with moving to hardfloat and would make the administration of a thin client that much easier.


RE: Is rpitc still maintained by Gibbio? - greavette - 21-01-2015

As I think about this further, would this mean that a common image on every Pi (which just points to the LTSP server) could make it easier to incorporate other hardware devices? I'm totally guessing here but might it be possible to have this one rpitc image on LTSP run on whatever hardware you want (Raspberry Pi, Banana Pi, Cubie Truck..etc).

I don't know much about the architecture of these other hardware devices..just putting this out there as a suggestion to see if this is an easier solution from an LTSP server.

I'll stop babbling now and await your's or anyone else's replies to my suggestion.

RE: Is rpitc still maintained by Gibbio? - Arag Mond - 22-01-2015

I think LTSP is an good idea, I looked the link in your post. That's a good project I think.

RE: Is rpitc still maintained by Gibbio? - greavette - 23-01-2015

Hi Arag Mond,

I think it's a good idea as well. I've installed it on my home network for testing and was very impressed with how easy it was to setup and to use. I still need to test it more (and if I can figure out how I'd really like to add in Gibbio's rpitc startup video when I login over ltsp) but so far it's a very slick system.

I've been chatting with the developer of Raspi_LTSP. If I hear anything new I will let you all know.


RE: Is rpitc still maintained by Gibbio? - greavette - 23-01-2015

I was chatting with the developer of Raspi_LTSP yesterday and he informed me of some new updates He is putting in. I support our small office using Raspberry Pi Thin Clients remotely so these new features have me excited as I'm not on prem to physically make changes.

The first new update will have the LTSP server auto check the files on the Pi's SD Card and auto-update them if need be. Seeing as kernel updates are required every 3-6 months this auto update feature would be great for our office. This all happens with zero input from the user of the Thin Client.

Second thing I discovered was the developer is putting in an auto discovery feature. I had inquired about clustering LTSP or possibly using BerryBoot with two versions of Raspi_LTSP each pointing to a different LTSP server (kept in sync using rsync) but this new auto server discovery sounds even better with no hard coded IP address. It would allow each Raspberry Pi Thin Client to discover an LTSP via UDP broadcast packets. Ideally you would still have two LTSP servers running and in sync (I would put each LTSP server on each of my Proxmox Nodes) but only one would be broadcasting its presence. When
one LTSP server goes offline I would turn on the broadcast discovery on my backup LTSP server and have the Raspberry Pi's reboot to connect to the backup. Minimizes downtime and again nothing to do on the Raspberry Pi's themselves.

The more I think about it the more this Raspi_LTSP helps to make the Raspberry Pi's more like thin clients. Even the way they receive their image from the LTSP server (albeit via files on the SD card) make it as close as we can get to a PXE boot like a real Thin Client. Smile

Maybe I'm missing some very important points to consider with regards to Raspi_LTSP so I do hope the Admins on rpitc can weigh in with their thoughts on this for small business. I do value their opinions.