Thin clients: how to make them
A little earlier, I wrote about thin clients . They say why they are needed, who needs them and what is the use of them.
And now a little sad truth about what a thin client really is.
No matter how many marketers howl about the special properties of TC, it's just a computer. Often with the usual bios, in which you can take and load your OS. In especially neglected cases, you will have to build a special kernel for this OS or play with the 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, from the moment of appearance of Atom - practically “a computer as a computer”, only smaller.
')
I have not seen a single mainstream vendor who would make thin clients something like the print server does (a very special fee, a minimum of too much ...). The main reason is that the thin client, although it is a dumb terminal from a logical point of view, should actually have a very, very good performance.
What is this performance for? First, to handle network traffic. In terms of the actual use of TC as a platform for remote desktop RDP traffic is not at all like the promised 22-64 kilobits. Flickering ads in a web browser, a running video on YouTube, an open presentation in powerpoint or just an HTML letter in an outlook - and here you have a few, if not tens of megabits, peak traffic. And it must be processed all. And the faster, the less lags the workplace.
The second - the resulting must be drawn. Personally, my experience with iron says that so many “small” platforms (including uniahrom on VIA) suffer from video performance.
Third, you need to process RDP requests for work with flash drives (read / write) ... I want to do all this with the speed of the desktop. So, the speed of the TC simply physically can not be below a certain limit. For VIA, the lower part goes along C3 (~ 600 MHz), for Vortex86SX - the higher, the better (I have never seen a lagging vortex). Normal comfortable work comes from gigahertz and above.
Yes, such is the reality: the machine, with the performance of a powerful server of the 90s, works as a “responsive” dumb terminal.
This is the reason why there are no thin clients on the arma. More precisely, it is, but unpopular, because it inhibits. Tritely not enough processor to draw (decode and process) the stream that you want to show.
Here lies the delicate muhlezh. Yes, we can on any trash to show the work of RDP without brakes. In 16 colors, 640x480 and on static applications a la pad / 1C 7.7. But if you put at least 16 bits, 1280x1024, add sound prokidy, playback (albeit not full screen) animation, extensive graphic fragments, encryption and transmission of all this traffic, it becomes clear that this is quite a decent job. And any buyer does not check TC in ideal conditions, but in real load. So, rejects everything that seems to him to be inhibited.
However, back to how they are made.
To begin with about shopping mall with local loading.
Iron is taken. It is desirable cheaper. But in the format. Usually, this is still a Via or an atom, although there are also geodes.
A programmer takes 1-2 pieces, often to outsource. And the task is "need a thin client." Need to? Let's do it. In the CE builder, there is a thinclient template, and we get this 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 TC, but Microsoft.
Then there are two options: either it is given “as is” to the client, or dopilivaetsya. As a person who actively participated in finishing this, I can say that there is not much there, but a lot to be corrected. We periodically purchase the products of competitors, we see that in about half of these problems have not been resolved, and so hang tails. About what tails and what to check, I will write a little later.
For linux everything is more complicated - there is no “ready” configurator. So even if the programmer can combine the x-server with rdesktop, then he will still have to write something. And here begin priplyasyvaniya. Someone is trying to use fwm, someone is icewm, someone else is some kind of wm, with the goal of “not drawing the menu myself”. Someone attaches text configurators to ncurses with one starting session.
In most cases, having written the simplest configurator (since it is written most often from scratch, then there are 1-2-3-4 settings), this is given with the words “done”. And finish again.
Sometimes people take on writing a powerful enterprise system ... on java. Inside a thin client. Fearfully? That's right, look at this on gigahertz C7 without tears is impossible.
Sometimes this is done in the form of a web interface with a local browser (in this case, people “for free” receive remote administration).
In most cases, the main headache of linux versions is size, Russian layout and iron support (yes, if you think that Linux works well with hardware, try setting the screen resolution, switching the port to KVM and downloading the TC - you will not get what they wanted).
Under CE, one headache is iron. There are very few drivers for CE, and some of them are of such quality that it is better not to (for example, I observed a wonderful driver for a USB card reader (smart card reader) who requested a pin, drawing a request on top of all other windows. It was good until , until another window was formed that wanted to draw there. After that, it was impossible to read anything on the screen).
But most importantly, a thin client is a software product. By its complexity, of course, inferior, for example, sql server, but still requires infrastructure for development and debugging. The complexity of the TC is much higher than the print server than even the router. It is not the understanding that a thin client is complex software and leads to hats.
And the majority of hardware companies are completely unprepared to engage in full-scale software development - almost always it turns out the designer, assembled by one or other limited forces. Companies are trying to do this worse on their own, better companies are outsourcing. I want to note that in this list is not a Russian IT-trifle, but quite famous brands like HP, Fujitsu and Wyse.
Until now, there was no manufacturer who would not try to adapt existing solutions, hardware and software, but took and made it from scratch. I think the one who does this will get the whole market. Because the market is objectively waiting for cheap, simple, reliable TC. Instead, they are offered a slightly reworked Linux, CE or WES on regular hardware, which can be bought without buying a TC.
Yes, even it is easier than self-collecting. But the difference in the amount of work between “this” and “ideal TC” is about the same as between collecting a computer from a bundle under its own “brand” and making a laptop.
And now a little sad truth about what a thin client really is.
No matter how many marketers howl about the special properties of TC, it's just a computer. Often with the usual bios, in which you can take and load your OS. In especially neglected cases, you will have to build a special kernel for this OS or play with the 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, from the moment of appearance of Atom - practically “a computer as a computer”, only smaller.
')
I have not seen a single mainstream vendor who would make thin clients something like the print server does (a very special fee, a minimum of too much ...). The main reason is that the thin client, although it is a dumb terminal from a logical point of view, should actually have a very, very good performance.
What is this performance for? First, to handle network traffic. In terms of the actual use of TC as a platform for remote desktop RDP traffic is not at all like the promised 22-64 kilobits. Flickering ads in a web browser, a running video on YouTube, an open presentation in powerpoint or just an HTML letter in an outlook - and here you have a few, if not tens of megabits, peak traffic. And it must be processed all. And the faster, the less lags the workplace.
The second - the resulting must be drawn. Personally, my experience with iron says that so many “small” platforms (including uniahrom on VIA) suffer from video performance.
Third, you need to process RDP requests for work with flash drives (read / write) ... I want to do all this with the speed of the desktop. So, the speed of the TC simply physically can not be below a certain limit. For VIA, the lower part goes along C3 (~ 600 MHz), for Vortex86SX - the higher, the better (I have never seen a lagging vortex). Normal comfortable work comes from gigahertz and above.
Yes, such is the reality: the machine, with the performance of a powerful server of the 90s, works as a “responsive” dumb terminal.
This is the reason why there are no thin clients on the arma. More precisely, it is, but unpopular, because it inhibits. Tritely not enough processor to draw (decode and process) the stream that you want to show.
Here lies the delicate muhlezh. Yes, we can on any trash to show the work of RDP without brakes. In 16 colors, 640x480 and on static applications a la pad / 1C 7.7. But if you put at least 16 bits, 1280x1024, add sound prokidy, playback (albeit not full screen) animation, extensive graphic fragments, encryption and transmission of all this traffic, it becomes clear that this is quite a decent job. And any buyer does not check TC in ideal conditions, but in real load. So, rejects everything that seems to him to be inhibited.
However, back to how they are made.
To begin with about shopping mall with local loading.
Iron is taken. It is desirable cheaper. But in the format. Usually, this is still a Via or an atom, although there are also geodes.
A programmer takes 1-2 pieces, often to outsource. And the task is "need a thin client." Need to? Let's do it. In the CE builder, there is a thinclient template, and we get this 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 TC, but Microsoft.
Then there are two options: either it is given “as is” to the client, or dopilivaetsya. As a person who actively participated in finishing this, I can say that there is not much there, but a lot to be corrected. We periodically purchase the products of competitors, we see that in about half of these problems have not been resolved, and so hang tails. About what tails and what to check, I will write a little later.
For linux everything is more complicated - there is no “ready” configurator. So even if the programmer can combine the x-server with rdesktop, then he will still have to write something. And here begin priplyasyvaniya. Someone is trying to use fwm, someone is icewm, someone else is some kind of wm, with the goal of “not drawing the menu myself”. Someone attaches text configurators to ncurses with one starting session.
In most cases, having written the simplest configurator (since it is written most often from scratch, then there are 1-2-3-4 settings), this is given with the words “done”. And finish again.
Sometimes people take on writing a powerful enterprise system ... on java. Inside a thin client. Fearfully? That's right, look at this on gigahertz C7 without tears is impossible.
Sometimes this is done in the form of a web interface with a local browser (in this case, people “for free” receive remote administration).
In most cases, the main headache of linux versions is size, Russian layout and iron support (yes, if you think that Linux works well with hardware, try setting the screen resolution, switching the port to KVM and downloading the TC - you will not get what they wanted).
Under CE, one headache is iron. There are very few drivers for CE, and some of them are of such quality that it is better not to (for example, I observed a wonderful driver for a USB card reader (smart card reader) who requested a pin, drawing a request on top of all other windows. It was good until , until another window was formed that wanted to draw there. After that, it was impossible to read anything on the screen).
But most importantly, a thin client is a software product. By its complexity, of course, inferior, for example, sql server, but still requires infrastructure for development and debugging. The complexity of the TC is much higher than the print server than even the router. It is not the understanding that a thin client is complex software and leads to hats.
And the majority of hardware companies are completely unprepared to engage in full-scale software development - almost always it turns out the designer, assembled by one or other limited forces. Companies are trying to do this worse on their own, better companies are outsourcing. I want to note that in this list is not a Russian IT-trifle, but quite famous brands like HP, Fujitsu and Wyse.
Until now, there was no manufacturer who would not try to adapt existing solutions, hardware and software, but took and made it from scratch. I think the one who does this will get the whole market. Because the market is objectively waiting for cheap, simple, reliable TC. Instead, they are offered a slightly reworked Linux, CE or WES on regular hardware, which can be bought without buying a TC.
Yes, even it is easier than self-collecting. But the difference in the amount of work between “this” and “ideal TC” is about the same as between collecting a computer from a bundle under its own “brand” and making a laptop.
Source: https://habr.com/ru/post/90763/
All Articles