Virtual Desktop Infrastructure (VDI) is a common industry term that has come to mean "all the real work is done on the servers". While VDI technically refers only to VMWare’s implementation of this ideal (now called VMWare View), in practice the term has been expanded to include all similar technologies. In a VDI setup, the …
If it's not an open protocol you are going to end up with a lot of perfectly working, perfectly adequate zero clients you cannot use any more since the maker has moved onto something new and won't provide whatever software is needed to integrate it into your new system.
And yes, despite of all the marketing buzz, "zero desktops" still are full fledged computers with CPU, RAM, ROM and obviously a network connection. They could turn out to also be a security nightmare. To judge this, one would also need the protocol specifications.
Pano's protocols are open. As to tbe CPU, nope. AFAIKT, there is a NIC, very primitive graphics chip and a PLC managing between. The PLC could be viewed as a CPU (maybe), excepting there is no OS, nor any way to do generic computation on the device. It's a dumb terminal, not a thin client.
The Pano Zero Client is a true Zero Client and not a "full fledged computer". It has no RAM no processor and no OS on the endpoint in no way a security nightmare.
Even if it is based on a PLC, it will still have some software, some memory and some processing power otherwise it couldn't do very much. The PLC would need to be configured at power up and that requires all of the above be it embedded in the PLC or an external micro processor.
The zero in "Zero Client" is just marketing speak for 'very little' in the way of client processing.
I don't think you understand what a PLC is. There is no software, no memory. There is a PLC that does that "convert network into display" entirely in hardware. Not in software. Not qith a flashable firmware. Not using RAM or a CPU. The NIC itself is more complex than the entire rest of the unit.
It is not a thin client at all. Your understanding of the tech is inadequate.
Was that aimed at me?
I'm not trying to argue that this is a "full fledged computer" but there is always another way of looking at things...
I'll admit my VLSI design skills are a bit rusty as it's been a while since I last programmed a Xillinx FPGA (and let's not use PLC in this context as it has other connotations) but FPGAs do contain memory (several lots of) and software (a configuration program 'written' in Verilog or VHDL) so the logic blocks can be configured to make the chip do something.
FPGAs can contain full blown processor cores on the die or can be configured as well known processor cores. I'm not suggesting that Pano Logic are doing this, just that it is not good to believe everything the marketing people say.
While it is possible to take the Verilog/VHDL program and FPGA design and bake true hard coded PGAs akin to an ASIC the operation will still be the same.
I won't even mention the RAM for the frame buffer...
The only solution that will work long term
...is shared responsibilities between workstations and servers. When the server goes down (and you know it will at some point), independent workstations can still be used.
Been there, done that, but better
Poor substitute for SunRay's. The product was done before but better.
Yay for complexity
The thing that gets me with thin/anorexic*/whatever clients is that you now need two boxes, the client, and a horribly expensive server. Of course, that server can serve more clients, and it's a good excuse to "have to" upgrade your network if you wanted to do that anyway, but it also is more complexity and more hardware that can fail. And also more trouble for "the users" to report just what doesn't work to-day. It does say something about the manageability of the software that the end result is overall less trouble to manage the shop.
I know that it simply is no longer socially acceptable any longer, but I suspect that plenty of office work (reading and writing memos**, filling in forms, what-have-you) would probably still be served fine, functionally, by a text-only terminal possibly on a serial line to the mainframe in the basement. It might be a good excercise (ObXref the GPS jamming discussion) to try anyway (for a while) just to identify and cut out a lot of fluff and get back some productivity.
* That "zero" client is marketese anything but a complete absence of hardware cannot live up to.
** Let's not forget that email is really "electronic memo" in conception and original execution.
15 years ago...
I worked on a Proof of Concept for virtual desktops and Citrix running NT 3.51. It was the first quad socket x86 server (or maybe server, for that matter - I never really asked what we had running in our massive Sun and HP-UX boxes we had in the lab) I had ever seen.
The server requirements are still horribly expensive (as you put it) and all the rest just really doesn't make sense except for, maybe, point of sale terminals and such - which could just as easily, and more often are run text based.
Eventually I think we'll get to the point where a commodity solution of some sort will change the existing fat desktop and laptop landscape. Hell if I know what that will look like... but it won't look like overpriced dumb terminals running overkill fat OSs on massively and overly expensive servers that cause the street lights to dim when you power them up, running screen paints back and forth over the network. They've been trying to square peg, round hole this solution as a better mousetrap for business desktops for 15 years : /
"It does say something about the manageability of the software that the end result is overall less trouble to manage the shop."
That's not always true though. If you need to keep any fat clients around, for any purpose, managing them properly is worth doing. Thin clients (and their VDI servers and images) are then a whole extra set of management overhead because you've got two systems in place.
And, if you're managing your PC estate well in the first place (automated OS deployment, automated application delivery, sleep/hibernate when idle, etc), the supposed benefits of VDI largely disappear (except for some niche cases), while the benefits of local OS and apps remain. It's generally cheaper and less power hungry, too.
VDI is essentially a solution to the problem "how can we sell more servers?".
"VDI is essentially a solution to the problem "how can we sell more servers?""
I was thinking the same thing about VDI. I currently manage a network which is a mixture of desktop PCs and thin/zero clients connected to Citrix XenApp (what was metaframe) servers. When I first started with Citrix your limit was about 20-30 users per server, less if your users were doing anything clever.
Now I can get 100 users on a server without it really breaking sweat and the servers cost me less money than they used to.
Virtualising servers is condensing traditional server loads onto less hardware.
The first time I saw VDI was in HP's product bulletin, they were advertising a system where you had a low power PC on your desktop driven by a workstation blade in the server room. So instead of a desktop PC you buy a cheap desktop PC and a server blade which means you also need a slot in a blade chassis. If that's not simply a way to sell more servers I don't know what is.
Diskless workstations with remote boot NICs...
Seem to remember those from ooh, twenty years ago...
How is this going to appeal to the typical certified Microsoft dependent IT manager, who measures his success not by how little he costs the business and how much the business gets in return, but by *how much* his empire costs the business (the ever-increasing size of the budget and the "estate" as features to boast about on the CV and the Linked-In page)?
Hey Palmer, remember when Gates said "You can be Larry's friend, or you can be my friend", back in the days of the Network Computer? Did you back the right one?
Looks poor, it doesn't even have front facing audio and USB. It's almost a cube so doesn't lend itself to mounting on the back of a monitor or under a desk. Headphones and microphone input are on the same connector.
I'm really liking the zero client concept, we're running the wyse xenith boxes. They boot and display a login prompt within a couple of seconds and use around 5W running.
If you are using VMware View for the server end Samsung do a nice 24" LCD with an integrated Teradici Zero Client.
Plug Ethernet, USB Keyboard and USB Mouse into the monitor and you have a client.
Wrong acronym, I think.
PLC = Programmable logic controller.
Programmable => it has a CPU (and in many cases, an embdedded OS).
There's not a PLC in this Pano box. It makes no sense in any circumstances.
There's a Pano video on youtube, which I watched yesterday. Before, I had been somewhat sceptical.
If the video is to be believed, they use the LAN (LAN, not WAN) conceptually as an extended PCI bus (or similar).
The IO is conceptually similar to generic PC IO, but it gets its data from, and sends its data to, a box rather further away than the traditional few centimetres in a PCI-bus based box.
It's not going to be good for high bandwidth stuff (which is mostly local to the server anyway) or for ultra low latency l33t gaming stuff but for the 90%+ of corporate boxes that do little more than email and spreadsheets and the like I can see it making some sense
I wish them luck.
PLC means a small IC whose processing can be changed by flashing it. It is essentially a mini-CPU whose logic structre can be altered. In most cases, onlg if you remove it, put it in the right device, anx then flash it with special device.
Now the end model can have a custom IC instead of the PLC, but almost nobody does that anymore. (They just solder on an appropriately flashed PLC, which you can't alter later.)
This PLC - or custom IC - does mot need RAM to work. (Or not always.) It is no different than a "hardware H.264 video decoder." A little dedicated chip that does ONE THING, and is incapable of anything else.
Yes, a PLC can fit there: it depends on the configuration of said PLC, and if it has the "flash me" pins wired to anything.
Pano's zero clients cannot be flashed. PLC or custom IC, the effect is the same: a piece of dedicated hardware - absent the need for ram or any form of software - that turns betwork lackets into images on the screen.
A dumb terminal.
What trevor describes would not normally be called a PLC
"PLC means a small IC whose processing can be changed by flashing it. "
Please stop digging yourself deeper, Trevor. You are likely embarrassing both yourself and the people at Pano, where your article is front page news. Pano, if you are behind this, please find out what PLC really means.
Either way, the widely understood definition of PLC is a programmable logic controller, a smart (not dumb) device typically used for some kind of automation. Look it up. Size from a (big) matchbox to most of a 19" rack, depending on required functionality. Does lots of automation-style IO, which often takes up much more space than the processing.
What I think Trevor's trying to describe is what many people who know the field would recognise as an FPGA (aka Field Programmable Gate Array) chip. They're very clever but rather too complicated for me to define clearly here right now; in some ways they're an alternative to the huge expense of making a dedicated single-purpose logic chip.
If you're making these things in sufficient volume, and the logic programming is fixed for the foreseeable future, you can replace the FPGA with a dedicated custom IC, which will have significant one-time setup costs but may save quite a few dollars per chip in production costs.
Calling whatever's in a Pano a PLC is just silly, when the PLC industry and the FPGA industry both have clear and distinct positions in the technology market.
"a piece of dedicated hardware - absent the need for ram or any form of software - that turns betwork lackets into images on the screen."
Indeed. And keystrokes and mouse movements into something that the hardware and drivers at the far end can recognise. Just like the video shows.
An FPGA is more accurate, you are correct. The widget I am describing is indeed an FPGA. (I do make mistakes!) I apologise.
The whole of the Pano device however is a bit hard to define without thinking of PLCs: they are a dedicated device that takes a fixed input type and delivers a fixed output type. They have very near real-time requirements on that, but no real extensibility beyond that.
Indeed, the Pano devices remind me a lot of the mid-80s PLCs, with the exception that instead of controlling a robot arm or some such, it’s taking a packet from the NIC and doing something slightly more interesting with it. (Remember EEPROM?)
I remember putting a lot of those out where the configs were tested, loaded and then locked down so that they could never, ever be changed. Many of the things are probably still in service. Converting the inputs they receive into the appropriate outputs.
Modern PLCs of course can be – and often are – hugely more complex. But the old ones – from the 80s – are the closest I analogy I can build.
You can’t reprogram a pano device to speak a different protocol. You can’t patch or update them. It’s not necessary. All they are designed to do is take information they receive form the NIC, convert it to display, and take input from mouse/keyboard and send it back. It’s elegant, simple.
Just like those old EEPROM logic boards of yore.
Message received and understood.
"The widget I am describing is indeed an FPGA. (I do make mistakes!) I apologise."
You're welcome (we all make mistakes, they're great things to learn from so long as not too many people get hurt too much).
Anyway, thanks for the article on an interesting looking concept which I hadn't previously seen.
FPGAs are great too. www.fpga4fun.com is worth a look (for those of a certain geeky type).
It's been so long since I have worked with either.
When I last worked on either of those technologies, it was late 80s, early 90s. I was somewhere in the 10-15 years old range, building robots, sensor packages, thermostats and displays. (Oh, and lasers. A lot of work with lasers back then.)
FPGAs weren't really a THING then. They were JUST coming into the mainstream about the time I got out of Deep Hardware and moved on to networking. Back then, what we would call an FPGA today was essentially a primitive PLC. (Well, not quite, FPGAs are more akin to a roll-your-own logic gate factory in a box, whereas PLC were just firmware computers that could use - but didn't require - things like RAM.)
I guess my foot-in-mouth here should serve as a great example of what happens when the tech moves on, but your experience with it doesn’t. I just ordered a bunch of sample FPGA kits, and I am going to build me some robots in the lab, just so that I actually learn something from this incident. If you're going to embarass yourself on the internet, at least take the time afterwards to learn more about the thing you got wrong.
OK, I've looked at their more detailed marketing specifications. Those boxes talk via UDP/IP. They access DHCP-Servers and they even talk to an "Infrastructure Manager".
Those boxes definitely have a CPU in their FPGA. FPGAs load their logic from (typically external) flash during bootup. Probably also their RAM (FPGAs are a RAM-based technology, so manufacturers typically add additional RAM to them) gets loaded there.
Since they certainly have a CPU, it'll probably execute it's code from RAM. The CPU will also need to parse data like the response from the DHCP server, and the RAM probably holds recently received packets. So there might be an attack vector here.
Other than that, if the material is to be believed, it's some sort of "PCI over UDP" which frankly could be done with just an FPGA once your hardware is initialized. However there is no mention of any actual security. It seems like if you just spoof UDP packets you might access the hardware. Just imagine spoofing a "login" screen and capturing the UDP packets which contain the keystrokes.
The protocol doesn't seem to be open, what they call "open" is supporting 3 manufacturers and providing a little board for system integrators. That is not open.
So please Register, if you want to write a sensible article at least use the marketing material. If you want a good article, look at the communication between those devices and their severs.
There may even be a completely different attack vector. Since apparently the PC gets simulated hardware. It might be possible to spoof USB over the network. So essentially any member of the network could spoof USB drives and keyboards, which is all you need to infect a Windows PC. And since that Windows PC has access to the same network you have, it can infect others.
So it probably will be a security nightmare.
- Updated Microsoft Azure goes TITSUP (Total Inability To Support Usual Performance)
- Review Apple takes blade to 13-inch MacBook Pro with Retina display
- Munich considers dumping Linux for ... GULP ... Windows!
- Game Theory The agony and ecstasy of SteamOS: WHERE ARE MY GAMES?
- Pic iPhone 6 flip tip slips in Aussie's clip: Apple's 'reversible USB' leaks