A few months ago I took over as Product Manager for the Linux and Android Receivers as well as retaining the roadmap for HDX Graphics.
Some weeks back I went through my first release of the Linux Receiver with the 13.2 release. So I thought I’d highlight what’s new, ask for feedback on where we are and also ask what you’d like to see in future releases.
The $100 Linux Receiver Question – What you want to see in future releases?
I’m a huge fan of the $100 question. I’ve blogged about this and the methodology before, here.
I’d be interested to hear where customers and partners think we should invest in:
- New product features?
- Better documentation, more how-to-webinars/YouTube videos, is there a particular web site that should be revamped?
- Automated support tools, error messages?
- Client side instrumentation and monitoring?
- Investing time with particular partners?
- Expand certification labs to broaden our hardware support for particular emerging hardware?
- Quality/bug fixes – are you happy with the feature set but feel quality should be the priority
The Rules
Internally some groups at Citrix use a “How would you spend $100?” model to prioritize changes, and if you were interested in providing feedback following that model, it would be ideal. If you’ve never used this model before, it’s pretty simple. Write down the things (up to 5 max) you’d want to see (optionally with a “why” beside them), and then given a budget of $100. Spend the $100 by allocating it to your desired functionality, and anything with a zero is removed. This has the benefit of focusing on the high value changes without worrying about complexity. If you’d like to provide input, please do so in the comments section below this blog
In the meantime here’s an update on what we released with Receiver 13.2 for Linux, including new features such as support for Russian localisation!
So What Was New with Receiver 13.2 for Linux
Release Date: Jun 30, 2015
Receiver for Linux enables users to access virtual desktops and hosted applications delivered by XenDesktop and XenApp from devices running the Linux operating system. Receiver for Linux is available in English, German, Spanish, French, Japanese, Simplified Chinese and Russian.
New features in this release
- Supports the unified experience that is enabled in conjunction with the centrally managed app selection capabilities introduced in StoreFront 3.0
- TLS 1.0, 1.1, 1.2 support, TLS 1.0 was available in the Linux Receiver 13.1 release. Block the use of weak SSL encryption methods, instead support the newer TLS encryption methods (v1.0, 1.1 and 1.2). This includes prevention of the POODLE SSL fallback exploit
- Russian – new localization
- Full 64 bit support, now includes the HDX Session technology. The whole 64bit package is now built 64bit, so no longer requires 32bit compatibility libraries to be installed on x86_64 platforms. (Session Launch Technology was supplied as 64 bit in 13.1)
- Improved support for physical Desktop use cases. The new WebReceiver variant of the Debian package has the dependencies required to connect to WebReceiver sites and does not install the dependencies required for the SelfService UI. This package is compatible with more Linux Distributions than the full package
Virtually Visual 
The main thing is to get software emulation in place to be able to move away from needing H.264 firmware decoding. The Pi 2 is a prime example of something that works well, but not well enough with without the H.264 decoding, but which could be turned to great by going to software emulation. The JPEG fallback just doesn’t quite cut it. With more movement towards H.265 anyway, H.264 will rapidly become less interesting and it’s easier to throw more CPU power at the decoding as CPU power advancements keep making strides even for thin clients. So, I vote $100 for the thinwire plus implementation support ASAP that Martin shows works so well on his blog at http://www.martinrowan.co.uk/2015/08/citrix-receiver-linux-raspberry-pi-2-using-raspbian-wheezy/ I hope any of this makes sense — it’s late and I’m tired!
LikeLike
$50 – Fix the worst of the many, many selfservice UI deficiencies. Specifically:
$15 – Give us full control of all settings via the web UI, like wfcmgr did, or at least give us more options than the current miserable allocation! Selfservice is in improvement as far as PNAgent integration is concerned, but it’s a **huge step backwards** from wfcmgr as far as tailorability goes. We now lack any kind of UI to persistently set the vast majority of INI file settings, and instead have to do this via shell scripting after consulting your woefully inadequate and inaccurate online INI file settings documentation.
$10 – Provide options to use HTTP instead of HTTPS, or to turn off server validity checking. I realize your security people will hate this, but you *must* make some concessions to practicality. The majority of Receiver users either have no clue how to set up (self-signed / private CA) PKI properly, or are too cheap to pay for Internet-signed certificates, or both. Consequently the majority of users can never get the selfservice UI to work, and give up and use the StoreFront web UI instead. It should be noted that the Windows version of Receiver allows use of HTTP via a registry hack, but Linux receiver does not!
$10 – Give the selfservice binary some useful command-line options, in particular the ability to point it an initial URL to connect to (either using a matching StoreCache entry, or creating one if there is none) and the ability to set fullscreen mode (I know you can do this by editing StoreCache.ctx-template, but I want the ability to select fullscreen or windowed at run-time!).
$5 – Have selfservice invoke wfica via wfica.sh, like the browser plugin / mailcap rule does, so that I at least have the option of setting a bunch of INI file options in that (since your web UI supports hardly any of them). At present selfservice calls wfica directly, so that I have to apply such tweaks before starting selfservice.
$5 – Add an option to quit (exit) selfservice. Your app does not have my permission to pwn my desktop for all eternity, and I shouldn’t have to use window manager controls to kill it!
$5 – Fix the “Log Off” option so that it does what the user expects. We get constant customer complaints that logging off “does nothing”, because they are expecting it to clear the icons and return to a logon screen, not just deauthenticate.
$20 – Fix the /dev/random problem
Hardcoding use of a blocking software entropy source is unacceptable! “Quiet” embedded Linux thin client systems cannot generate (kernel) entropy fast enough, which results in Receiver **failing to start for no visible reason** – at least until the user waves their mouse around a lot! I have had to resort to udev (pre-systemd) and LD_PRELOAD (systemd) hacks to work around this by aliasing /dev/random to /dev/urandom. You need to give us the ability to specify the entropy source via INI file setting. If you can’t / won’t do that, then at least check for /dev/hwrng and use that first if available, and if you do have to use /dev/random, then at least open it O_NONBLOCK and **tell the user what is happening** if you get EWOULDBLOCK!
$8 – Die, GStreamer, Die!
Do you know who likes/wants/uses GStreamer? Nobody, that’s who! I already have to have MPlayer/MPX for digital signage, and in future probably XBMC/KODI as an end-user app, I don’t want the additional footprint of a *third* rendering engine to perform the same function just because Citrix happen to like it! Please ditch your GStreamer integration in favour of a more flexible – if less seamless – arrangement whereby you launch multimedia payback helpers in accordance with mailcap and mime.types (as per xdg-open). If we want window embedding, it’s still possible to do this via some mailcap customisation using the features of the rendering engine of *our* choice (not yours!).
$10 – Ixnay on the private CA certificate stash
Please use the host-provided CA certificate store rather than using your own (I grow tired of deleting keystore/cacerts and symlinking it to /etc/ssl/certs!). This means that you would have to support a couple of different schemes – the /etc/ssl/certs/ Debian-like scheme (which is already compatible with your own), and the /etc/pki/tls/certs/ca-bundle.crt CentOS-like scheme, but the payoff would be worth it in reducing customer support requests from at least some of the users/admins who have no clue about SSL (which is, apparently, most of them!).
$5 – Browser plugin that works with Chromium and/or modify the correct mailcap file
Apparently customers have decided that Firefox is worse than Hitler (don’t see what the problem is myself!), and all insist on Chrome. We don’t give them that, of course, we give them upstream Chome – Chromium – instead. And npica.so doesn’t work on it. If a browser plugin for Chrom[e|ium] isn’t possible, then at least please put your application/x-ica tweaks in the /etc/mailcap file that xdg-open uses (and ditch the /usr/local/lib/netscape tweaks – *nobody* uses Mozillla-based browsers that are that old!).
$5 – Fix the X11 cursor brain-damage
Another tweak that I keep having to apply every time is setting DisableXRender=True in All_Regions.ini, to work around your “black square” cursor rendering bug. Our tech Jay Sorg already provided you with a fix for this, but you aren’t using it. Here’s the relevant excerpt from that email:
— cut —
You could consider using XcursorImageLoadCursor instead of XRenderCreateCursor?
It uses the XCursor and XRender extensions.
Below is the way we create alpha cursors in FreeRDP that always works.
If you like, I can change the demo(cc.c) example so it works.
void xf_Pointer_New(rdpContext* context, rdpPointer* pointer) {
XcursorImage ci;
xfInfo* xfi = ((xfContext*) context)->xfi;
memset(&ci, 0, sizeof(ci));
ci.version = XCURSOR_IMAGE_VERSION;
ci.size = sizeof(ci);
ci.width = pointer->width;
ci.height = pointer->height;
ci.xhot = pointer->xPos;
ci.yhot = pointer->yPos;
ci.pixels = (XcursorPixel*) malloc(ci.width * ci.height * 4);
memset(ci.pixels, 0, ci.width * ci.height * 4);
if ((pointer->andMaskData != 0) && (pointer->xorMaskData != 0))
{
freerdp_alpha_cursor_convert((uint8*) (ci.pixels), pointer->xorMaskData, pointer->andMaskData,
pointer->width, pointer->height, pointer->xorBpp, xfi->clrconv);
}
((xfPointer*) pointer)->cursor = XcursorImageLoadCursor(xfi->display, &ci);
xfree(ci.pixels);
}
— cut —
$2 – PowerPC Linux port?
It’s futile even asking, I know, but I’d be remiss if I didn’t spend some of my budget on requesting some kind of Receiver solution for PowerPC (32-bit) Linux, other than the Java client. Although much less popular than ARM, some embedded devices use PowerPC Linux, and it might also be found on recycled IBM Power server hardware and PowerPC Apple Macs. Higher-end PowerPC hardware has Altivec extensions that could allow pretty decent performance.
LikeLike
Just wondering if the item Paul mentioned ‘Fix the “Log Off” option so that it does what the user expects. We get constant customer complaints that logging off “does nothing”, because they are expecting it to clear the icons and return to a logon screen, not just deauthenticate.’ is going to be fixed? This is a major issue for my users who share thin clients.
LikeLike