Thin Clients: How They Are Made
Earlier, I wrote about thin clients . Like, why are they needed, who needs them and what is the use of them.
And now a little sad truth about the fact that there is a thin client in fact.
No matter how marketers howl about the special properties of the TC, it's just a computer. Often with the usual BIOS, in which you can take and load your OS. In especially advanced cases, you will have to build a special kernel for this OS or play with kernel parameters, but usually it’s just a computer. In mini-itx format or less. No fans. Such computers before the release of Atom were exotic, since the appearance of Atom - practically “computer like computer”, only less.
I have not seen a single mainstream manufacturer that would make thin clients something like the print server does (a very special board, at least too much ...). The main reason is that the thin client, although it is a dumb terminal from a logical point of view, should in fact have very, very decent performance.
What is this performance for? Firstly, to handle network traffic. With the real use of TC as a platform for remote desktop, RDP traffic does not at all look like the promised 22-64 kilobits. Flickering ads in a web browser, a launched video on YouTube, an open presentation in a powerpoint, or just an html email in Outlook - and here you have units, if not tens of megabytes of peak traffic. And it must be processed all. And the faster, the less lags the workplace.
The second - the received must be drawn. Personally, my experience with iron says to me that a lot of "small" platforms (including unichrome on VIA) suffer from video performance.
Third, you need to process RDP requests for working with flash drives (read / write) ... All this I want to do with the speed of the desktop. So, the speed of the TC simply physically cannot be lower than a certain boundary. For VIA, the lower part follows C3 (~ 600MHz), for Vortex86SX - the higher, the better (I have never seen a non-lagging vortex). Normal comfortable work comes from gigahertz and higher.
Yes, that’s the reality: the machine, with the performance of a powerful 90s server, works as a “responsive” dumb terminal.
This is the reason why there are no thin clients on the arm. More precisely, there are, but they are not very popular, because they slow down. The processor is simply not enough to draw (decode and process) the stream that needs to be shown.
Here lies a subtle swindle. Yes, we can show the work of RDP without brakes on any rubbish. In 16 colors, 640x480 and on static applications a la notepad / 1C 7.7. But if you put at least 16 bits, 1280x1024, add sound scrolling, play (albeit not in full screen) animations, extensive graphic fragments, encrypt and transmit all this traffic, it will become clear that this is such a decent job. And any buyer does not check the shopping mall under ideal conditions, but in a real load. This means that he rejects everything that seems to him to be inhibited.
However, back to how they are made.
To begin with about TC with local loading.
Iron is taken. Cheaper, preferably. But in the format. Usually this is still a Via or an atom, although there are geodes.
The programmer takes 1-2 pieces, often to outsource. And the task is set "need a thin client." Need to? Let's do it. There is a thinclient template in the builder for CE, and we get such a typical picture for everyone:
Excluding the Russian language, 99% of thin clients on CE look like this. And the merit of this is not the creators of the shopping center, but Microsoft.
Then there are two options: either it is given “as is” to the client, or it is completed. As a person who actively participated in finishing this, I can say that there is not much, but a lot needs to be fixed. We periodically purchase competitors' products, we look - about half of these problems have not been resolved, and they hang like tails. About what tails and what to check, I will write a little later.
For linux, everything is more complicated - there is no “ready-made" configurator. So even if the programmer can combine x-server with rdesktop, then he still has to write something. And then the dancing begins. Someone is trying to use fwm, someone icewm, someone else some wm, with the goal of "not drawing the menu yourself." Someone is attaching text configurators to ncurses with one starting session.
In most cases, writing the simplest configurator (since it is written most often from scratch, then the settings there are 1-2-3-4), this is given with the words "ready." And again dopilivanie.
Sometimes people start writing a powerful enterprise system ... in Java. Inside the thin client. Fearfully? That's right, it's impossible to look at this on a GHz C7 without tears.
Sometimes this is done in the form of a web interface with a local browser (in this case, people “get free” remote administration).
In most cases, the main headache of the linux version is the size, Russian layout and hardware support (yes, if you think that Linux works well with hardware, try setting the screen resolution, switching the port to KVM and loading the TC - you will not get what they wanted).
Under CE, the headache is one - iron. There are negligible drivers for CE, and some of them are of such quality that it is better not to (for example, I watched a wonderful driver for a USB card reader (smart card reader) that requested a pin by drawing a request on top of all other windows. This was good until then until another window was formed that wanted to draw there, after which it was impossible to read anything on the screen).
But most importantly, the thin client is a software product. In its complexity, of course, it is inferior, for example, to the sql server, but still requires infrastructure for development and debugging. The complexity of the TC is much higher than that of the print server than even the router. It is not the understanding that the thin client is sophisticated software that leads to cap-making.
And most hardware companies are completely unprepared to engage in full-scale software development - almost always it turns out to be a designer assembled by one or another limited force. Companies are trying worse to do it on their own, companies are better - they are outsourced. I want to note that this list is not a Russian IT-trifle, but quite well-known brands like HP, Fujitsu and Wyse.
Until now, there has not been a manufacturer who has not tried to adapt existing solutions, hardware and software, but picked it up and made it from scratch. I think that whoever does this will get the whole market. Because the market is objectively waiting for cheap, simple, reliable shopping malls. Instead, they are offered slightly redone Linux, CE or WES on ordinary hardware, which you can buy without buying a TC.
Yes, even this is easier than self-assembly. But the difference in the volume of work between “this” and “ideal TK” is about the same as that between the collection of a computer from a set under its own “brand” and the manufacture of a laptop.
And now a little sad truth about the fact that there is a thin client in fact.
No matter how marketers howl about the special properties of the TC, it's just a computer. Often with the usual BIOS, in which you can take and load your OS. In especially advanced cases, you will have to build a special kernel for this OS or play with kernel parameters, but usually it’s just a computer. In mini-itx format or less. No fans. Such computers before the release of Atom were exotic, since the appearance of Atom - practically “computer like computer”, only less.
I have not seen a single mainstream manufacturer that would make thin clients something like the print server does (a very special board, at least too much ...). The main reason is that the thin client, although it is a dumb terminal from a logical point of view, should in fact have very, very decent performance.
What is this performance for? Firstly, to handle network traffic. With the real use of TC as a platform for remote desktop, RDP traffic does not at all look like the promised 22-64 kilobits. Flickering ads in a web browser, a launched video on YouTube, an open presentation in a powerpoint, or just an html email in Outlook - and here you have units, if not tens of megabytes of peak traffic. And it must be processed all. And the faster, the less lags the workplace.
The second - the received must be drawn. Personally, my experience with iron says to me that a lot of "small" platforms (including unichrome on VIA) suffer from video performance.
Third, you need to process RDP requests for working with flash drives (read / write) ... All this I want to do with the speed of the desktop. So, the speed of the TC simply physically cannot be lower than a certain boundary. For VIA, the lower part follows C3 (~ 600MHz), for Vortex86SX - the higher, the better (I have never seen a non-lagging vortex). Normal comfortable work comes from gigahertz and higher.
Yes, that’s the reality: the machine, with the performance of a powerful 90s server, works as a “responsive” dumb terminal.
This is the reason why there are no thin clients on the arm. More precisely, there are, but they are not very popular, because they slow down. The processor is simply not enough to draw (decode and process) the stream that needs to be shown.
Here lies a subtle swindle. Yes, we can show the work of RDP without brakes on any rubbish. In 16 colors, 640x480 and on static applications a la notepad / 1C 7.7. But if you put at least 16 bits, 1280x1024, add sound scrolling, play (albeit not in full screen) animations, extensive graphic fragments, encrypt and transmit all this traffic, it will become clear that this is such a decent job. And any buyer does not check the shopping mall under ideal conditions, but in a real load. This means that he rejects everything that seems to him to be inhibited.
However, back to how they are made.
To begin with about TC with local loading.
Iron is taken. Cheaper, preferably. But in the format. Usually this is still a Via or an atom, although there are geodes.
The programmer takes 1-2 pieces, often to outsource. And the task is set "need a thin client." Need to? Let's do it. There is a thinclient template in the builder for CE, and we get such a typical picture for everyone:
Excluding the Russian language, 99% of thin clients on CE look like this. And the merit of this is not the creators of the shopping center, but Microsoft.
Then there are two options: either it is given “as is” to the client, or it is completed. As a person who actively participated in finishing this, I can say that there is not much, but a lot needs to be fixed. We periodically purchase competitors' products, we look - about half of these problems have not been resolved, and they hang like tails. About what tails and what to check, I will write a little later.
For linux, everything is more complicated - there is no “ready-made" configurator. So even if the programmer can combine x-server with rdesktop, then he still has to write something. And then the dancing begins. Someone is trying to use fwm, someone icewm, someone else some wm, with the goal of "not drawing the menu yourself." Someone is attaching text configurators to ncurses with one starting session.
In most cases, writing the simplest configurator (since it is written most often from scratch, then the settings there are 1-2-3-4), this is given with the words "ready." And again dopilivanie.
Sometimes people start writing a powerful enterprise system ... in Java. Inside the thin client. Fearfully? That's right, it's impossible to look at this on a GHz C7 without tears.
Sometimes this is done in the form of a web interface with a local browser (in this case, people “get free” remote administration).
In most cases, the main headache of the linux version is the size, Russian layout and hardware support (yes, if you think that Linux works well with hardware, try setting the screen resolution, switching the port to KVM and loading the TC - you will not get what they wanted).
Under CE, the headache is one - iron. There are negligible drivers for CE, and some of them are of such quality that it is better not to (for example, I watched a wonderful driver for a USB card reader (smart card reader) that requested a pin by drawing a request on top of all other windows. This was good until then until another window was formed that wanted to draw there, after which it was impossible to read anything on the screen).
But most importantly, the thin client is a software product. In its complexity, of course, it is inferior, for example, to the sql server, but still requires infrastructure for development and debugging. The complexity of the TC is much higher than that of the print server than even the router. It is not the understanding that the thin client is sophisticated software that leads to cap-making.
And most hardware companies are completely unprepared to engage in full-scale software development - almost always it turns out to be a designer assembled by one or another limited force. Companies are trying worse to do it on their own, companies are better - they are outsourced. I want to note that this list is not a Russian IT-trifle, but quite well-known brands like HP, Fujitsu and Wyse.
Until now, there has not been a manufacturer who has not tried to adapt existing solutions, hardware and software, but picked it up and made it from scratch. I think that whoever does this will get the whole market. Because the market is objectively waiting for cheap, simple, reliable shopping malls. Instead, they are offered slightly redone Linux, CE or WES on ordinary hardware, which you can buy without buying a TC.
Yes, even this is easier than self-assembly. But the difference in the volume of work between “this” and “ideal TK” is about the same as that between the collection of a computer from a set under its own “brand” and the manufacture of a laptop.