What kind of overhead would ".nib"s have? As long as you can see the interface it doesn't matter how it is processed. The actions from buttons, tables, mouse clicks, etc., would only need be sent to the server. Also, all the nibs could be loaded at run time (there would be a slower initial launch, but the app would become much more snappy during use) and nibs really aren't that big to begin with. Why vector based Aqua, give the client the interface. This would only not work with games, and you'd have to be a complete idiot to try to run anything that intensive over 10 or even 100, let alone wireless.
What kind of overhead would ".nib"s have? As long as you can see the interface it doesn't matter how it is processed. The actions from buttons, tables, mouse clicks, etc., would only need be sent to the server. Also, all the nibs could be loaded at run time (there would be a slower initial launch, but the app would become much more snappy during use) and nibs really aren't that big to begin with. Why vector based Aqua, give the client the interface. This would only not work with games, and you'd have to be a complete idiot to try to run anything that intensive over 10 or even 100, let alone wireless.
Nibs are basically just serialized objects. They can be (and have been) easily streamed. They already can be, have been, and are, loaded dynamically. There's nothing stopping Apple from streaming them over networks and building GUIs with them, because NeXT did just that. The objects don't have their appearance hard-coded, which is how you can switch between Aqua and brushed metal with a single checkbox setting in Interface Builder.
However, the client would either have to have a local repository of all the TIFFs that Aqua relies on, or OS X would have to stream them (at least once) or Apple would have to replace Aqua with an interface that doesn't require them. I note that the flat grey "pro" interface in the latest version of FCP is a step in that direction, even if Apple didn't mean it to be one.
The games/OpenGL/streaming media thing is a bit trickier, though, simply because Apple has put so much effort into seamlessly integrating graphics-intensive effects and tools into the Mac "digital hub," and into OS X. Only a complete idiot would buy a Mac and expect it not to have the advantages Apple advertizes. (Yes, it would have those advantages when you were sitting at the machine proper, but that inconsistency is still less than ideal.)
The games/OpenGL/streaming media thing is a bit trickier, though, simply because Apple has put so much effort into seamlessly integrating graphics-intensive effects and tools into the Mac "digital hub," and into OS X. Only a complete idiot would buy a Mac and expect it not to have the advantages Apple advertizes. (Yes, it would have those advantages when you were sitting at the machine proper, but that inconsistency is still less than ideal.)
Right, but keep in mind the "thin" clients would require a host machine, so it isn't like "joe sixpack" is going to waltz into an apple store and buy a thin client. I think this will be the other end of the Xserve arena... To clarify, XServe installations will have the ability to serve [apps, computing and storage] to thin and fat clients. I don't think Apple will force anyone to dump their room full of iMacs or G4 Towers and replace them with thin clients. It's not an either/or proposition. It will handle both, with ease.
Now that I have given it more thought, I don't think a "thin" client will ever be useful in a generic home environment [My home is different ]. It is however, the next leap up from NetBoot. Cache the interface, send the events, retrieve results.
Lather, Rinse, Repeat.
The Future's so bright, I've got to wear shades 8)
In Pre-Press (or whats left of it) there is loads of use for thin clients. Most people use it in one form or the other ie OPI. Every stores their data on a network server, Netboot is already available, the only thing left would be to load the apps from a server.
OKIE-DOKIE Folks ... we better get one thing clear real fast...
OPTION A:
There are thin clients that actually LOAD the app FROM the server, so the App actually runs on the client machine ...
OPTION B:
There are thin clients that do no such thing, the apps runs on the server, and only the control and interface is run from the client (XWindows, WindowsXP, Citrix) with interface instructions being the only thing sent back and forth from the server and client.
While a thin client may be able to do both, they are NOT the same thing, and each scenario has it's own distinct advantages and disadvantages ...
There are thin clients that do no such thing, the apps runs on the server, and only the control and interface is run from the client (XWindows, WindowsXP, Citrix) with interface instructions being the only thing sent back and forth from the server and client.
Heh. That reminded me: At Reed College we had an AppleTalk network of Macs set up that way in 1988 or so, running Word off a Mac II. It was slow, but absolutely rock solid.
Quote:
WHICH are we talking about again?
If we're not talking about B, I strongly encourage that we talk about B in this thread, because it's much closer to the definition of a "thin client." If the client runs the app locally, it's not thin.
Nibs are basically just serialized objects. They can be (and have been) easily streamed. They already can be, have been, and are, loaded dynamically. There's nothing stopping Apple from streaming them over networks and building GUIs with them, because NeXT did just that. The objects don't have their appearance hard-coded, which is how you can switch between Aqua and brushed metal with a single checkbox setting in Interface Builder.
I couldn't agree more that OSX should be the standard OS across all of Apple's computers, and that making a thin client with a scaled down OS really defeats the purpose of buying a Mac and increases Apple's support headaches exponentially ...
... but still, if you've already got OSX running on a G3 (and a G3 is all it would take if all you're doing is running interface arithmetic), and all that G3 does is run Apps on the server (with drawing commands being handles natively on the client) then what does it matter if you're running over even 10bt? Citrix runs just peach over fast modems!
If you've already got Aqua, all you have to deal with are NIB files ... well, stick a checksum on those suckers and update accordingly I say.
At which point I have to ask - what am I missing here?
Nibs are basically just serialized objects. They can be (and have been) easily streamed. They already can be, have been, and are, loaded dynamically. There's nothing stopping Apple from streaming them over networks and building GUIs with them, because NeXT did just that.
Are you talking about the old remote display technology? NXHosting? If so, that's not quite right. The client knew nothing about the nibs or the appearance at all. What was streamed between client and server was postscript - literally the drawing commands necessary to render the interface. The new window server architecture can't do that directly because it lacks a postscript interpreter.
Those aren't thin client's you are running, they are fat clients which have centrally repositited applications storage. The app isn't running over the network, it is downloaded and runs locally. One possible solution for configuration management, but one that uses (wastes?) much more bandwidth than other solutions.
Um... yes, they are thin clients. All the apps execute on the server. Notice I said unix machines are where the client is running. Can't run x86 apps on a 604 with any kind of speed, particularly not MS Office apps! Emmulation? Way too slow for office 2000. Recoded apps? no.
And I made a mistake in my post - there are actually about 250+ users being served by the 5 servers and this is supposedly less than 80% of their capacity. My firm has a long history using this type of arrangement on windows centralised servers. (Being a little vague on purpose.)
Are you talking about the old remote display technology? NXHosting? If so, that's not quite right. The client knew nothing about the nibs or the appearance at all. What was streamed between client and server was postscript - literally the drawing commands necessary to render the interface. The new window server architecture can't do that directly because it lacks a postscript interpreter.
But we now have the ability to send nibs over... or we could stream DisplayPDF, just like DPS in the NeXT era
But we now have the ability to send nibs over... or we could stream DisplayPDF, just like DPS in the NeXT era
I don't see how 'sending nibs over' is going to work. A nib relies on a couple of things to work:
- external frameworks for code and resources: AppKit, any shared libraries used by palletes.
- application binary: you almost always have instances of your Controller objects represented in your nib and the File's Owner. Those representations are serialized objects as well but they are only proxies to the real deal in the binary.
now, theoritcally, you could slip some Distributed Objects messaging in there but my gut feeling is that it would be ridiculously slow: totally swamped by remote messageing overhead.
If you have the frameworks and palletes installed already why not install the application binary too? That's not very thin to me.
As for streaming PDF: It's not "just like DPS." That was my point about not having a Postscript interpreter. It's probably more efficient just to send over bitmaps than to send over PDF. By the time the window server gets things everything is a bitmap anyhow. the window server is basically managing regions of video memory; it's actually quite 'dumb' compared to DPS. All of the drawing is actually done at a different level, in the individual libraries however they want (Quartz, OpenGL, Java2D).
It does make things like the compositing of Quartz Extreme possible but it doesn't really buy you anything as far as remote display goes.
At least I don't see how. Maybe you could elaborate on your ideas?
I don't see how 'sending nibs over' is going to work. A nib relies on a couple of things to work:
- external frameworks for code and resources: AppKit, any shared libraries used by palletes.
...
If you have the frameworks and palletes installed already why not install the application binary too? That's not very thin to me.
The two big advantages of thin clients is that hardware and support costs are drastically reduced. This can still be the case for clients which locally store frameworks and do processing on interface widgets. The frameworks required for OS X and cocoa are relatively small when compared to all of the various programs run by users on a company's LAN. Updates to frameworks can be quickly transfered when a client is found to be out of date.
What this does is decrease the typical bandwidth required by clients while still reaping the benefits of administering only one copy of each program bundle for all users on the LAN (or WAN possibly). By installing frameworks on the client, low-end broadband connections become more than adequate for running fully-native, remote applications. This isn't the case for streaming interface images rather than widget definitions and user input. Typical broadband performance would lead to a noticeably lagged GUI.
When designing a marketable thin or fat client, there are more design goals than just minimizing client costs by decreasing processing power. The cost of giga-bit switches makes it such that minimizing bandwidth requirements becomes almost as important as minimized local processing requirements. Currently, I think the most economical tradeoff is to have frameworks stored on clients with just enough processing power to handle the rendering of widget interaction.
There are thin clients that actually LOAD the app FROM the server, so the App actually runs on the client machine ...
OPTION B:
There are thin clients that do no such thing, the apps runs on the server, and only the control and interface is run from the client (XWindows, WindowsXP, Citrix) with interface instructions being the only thing sent back and forth from the server and client.
Those are by no means the only two options.
Furthermore you could do both at once on the same machine i.e. A) downloading a tiny java applet that doesn't need to communicate with the server at all once it has downloaded and running a big heavy process mostly on the server with only the GUI on running the client.
The two extremes
THIN: a classic dumb terminal which is basically the equivalent of having a *really* long cable for your monitor and keyboard as you are directly accessing the server.
FAT: Normal desktop i.e. may as well not be attached to a network as it doesn't use it for anything.
Different technologies (or even applications of a single technology) can be placed between these extremes.
Some examlpes VNC, Remote X Windows, unix command line access, Java applets, applet front ends for servlets, web pages, server generated web pages (PHP, JSP etc.), JNPLI(?) launched Java apps, web pages with client-side javascript, apps loaded from central servers, remote document hosting, rendering clusters, centralised network log-in, various combinations of the above etc. etc.
"In client/server applications, a client designed to be especially small so that the bulk of the data processing occurs on the server. The term thin client is an especially popular buzzword now because it serves as a symbol dividing the computer industry into two camps. On one side is a group led by Netscape and Sun Microsystems advocating Java -based thin clients running on network computers. The other side, championed by Microsoft and Intel, is pushing ever-larger applications running locally on desktop computers.
Although the term thin client usually refers to software, it is increasingly used for computers, such as network computers and Net PCs, that are designed to serve as the clients for client/server architectures. A thin client is a network computer without a hard disk drive, whereas a fat client includes a disk drive. "
Basically there are two concrete statements that sum up the thin client - "no hard disk drive" (or memory card, etc where applications load from) and "the bulk of data processing occurs on the server". That's it, the rest is just different views of such. They really have nothing to do with where an application is run from, however. I have installed many, many client server applications. Look at JDEdwards software - a classic example of a client/server application. That client is larger than an OS in some cases.
The point being, thin client has always been a very loose term; I think most people would agree that it defines what I stated in the previous paragraph. Who cares if someone implements something that causes the definition of a term to change, though? I could care less, as long as it serves a purpose in a better way. Whether it runs a frickin app locally or off a server is moot.
That said, I think Apple's implementation could include a VERY small client, basically a CPU, RAM and a flash that allows it to boot off the xServer cluster. The OS and apps reside on the server, with the client basically sending/receiving requests - a true client/server implementation. And no, the OS doesn't have to be a re-written micro OS or anything. Just use what is necessary to run a thin client and forget about packaging the rest in the OS image.
Thank you for the definition... but it will be impossible to reach consensus on what is and what is not a 'thin-client'.
Its like trying to classify all vehicles as either a car or truck. Vehicles can be partially both, completely both, completely one and partially the other, partially one and none of the other, or neither of both.
But seriously, is a mini-van a car or a truck? Is the Isuzu Trooper a car or a truck? Attempting to make this type of classification is a fairly useless endeavor.
thin-client-ness is not a discrete attribute of hardware or software. It is common to exhibit some but not all thin-client attributes, to exhibit a partial degree of thin-client-ness.
Thank you for the definition... but it will be impossible to reach consensus on what is and what is not a 'thin-client'.
Its like trying to classify all vehicles as either a car or truck. Vehicles can be partially both, completely both, completely one and partially the other, partially one and none of the other, or neither of both.
But seriously, is a mini-van a car or a truck? Is the Isuzu Trooper a car or a truck? Attempting to make this type of classification is a fairly useless endeavor.
thin-client-ness is not a discrete attribute of hardware or software. It is common to exhibit some but not all thin-client attributes, to exhibit a partial degree of thin-client-ness.
And to that end, does it really matter? The point being that remote GUI login will allow a new class of hardware to exist in the MacOS universe. This hardware would be a boon in some situations, others perhaps not. Now though, we start seeing the Enterprise come into focus.
Comments
Originally posted by macserverX
What kind of overhead would ".nib"s have? As long as you can see the interface it doesn't matter how it is processed. The actions from buttons, tables, mouse clicks, etc., would only need be sent to the server. Also, all the nibs could be loaded at run time (there would be a slower initial launch, but the app would become much more snappy during use) and nibs really aren't that big to begin with. Why vector based Aqua, give the client the interface. This would only not work with games, and you'd have to be a complete idiot to try to run anything that intensive over 10 or even 100, let alone wireless.
Nibs are basically just serialized objects. They can be (and have been) easily streamed. They already can be, have been, and are, loaded dynamically. There's nothing stopping Apple from streaming them over networks and building GUIs with them, because NeXT did just that. The objects don't have their appearance hard-coded, which is how you can switch between Aqua and brushed metal with a single checkbox setting in Interface Builder.
However, the client would either have to have a local repository of all the TIFFs that Aqua relies on, or OS X would have to stream them (at least once) or Apple would have to replace Aqua with an interface that doesn't require them. I note that the flat grey "pro" interface in the latest version of FCP is a step in that direction, even if Apple didn't mean it to be one.
The games/OpenGL/streaming media thing is a bit trickier, though, simply because Apple has put so much effort into seamlessly integrating graphics-intensive effects and tools into the Mac "digital hub," and into OS X. Only a complete idiot would buy a Mac and expect it not to have the advantages Apple advertizes. (Yes, it would have those advantages when you were sitting at the machine proper, but that inconsistency is still less than ideal.)
Originally posted by Amorph
The games/OpenGL/streaming media thing is a bit trickier, though, simply because Apple has put so much effort into seamlessly integrating graphics-intensive effects and tools into the Mac "digital hub," and into OS X. Only a complete idiot would buy a Mac and expect it not to have the advantages Apple advertizes. (Yes, it would have those advantages when you were sitting at the machine proper, but that inconsistency is still less than ideal.)
Right, but keep in mind the "thin" clients would require a host machine, so it isn't like "joe sixpack" is going to waltz into an apple store and buy a thin client. I think this will be the other end of the Xserve arena... To clarify, XServe installations will have the ability to serve [apps, computing and storage] to thin and fat clients. I don't think Apple will force anyone to dump their room full of iMacs or G4 Towers and replace them with thin clients. It's not an either/or proposition. It will handle both, with ease.
Now that I have given it more thought, I don't think a "thin" client will ever be useful in a generic home environment [My home is different
Lather, Rinse, Repeat.
The Future's so bright, I've got to wear shades 8)
Originally posted by dobby
In Pre-Press (or whats left of it) there is loads of use for thin clients. Most people use it in one form or the other ie OPI. Every stores their data on a network server, Netboot is already available, the only thing left would be to load the apps from a server.
OKIE-DOKIE Folks ... we better get one thing clear real fast...
OPTION A:
There are thin clients that actually LOAD the app FROM the server, so the App actually runs on the client machine ...
OPTION B:
There are thin clients that do no such thing, the apps runs on the server, and only the control and interface is run from the client (XWindows, WindowsXP, Citrix) with interface instructions being the only thing sent back and forth from the server and client.
While a thin client may be able to do both, they are NOT the same thing, and each scenario has it's own distinct advantages and disadvantages ...
So ... WHICH are we talking about again?
Originally posted by OverToasty
OPTION B:
There are thin clients that do no such thing, the apps runs on the server, and only the control and interface is run from the client (XWindows, WindowsXP, Citrix) with interface instructions being the only thing sent back and forth from the server and client.
Heh. That reminded me: At Reed College we had an AppleTalk network of Macs set up that way in 1988 or so, running Word off a Mac II. It was slow, but absolutely rock solid.
WHICH are we talking about again?
If we're not talking about B, I strongly encourage that we talk about B in this thread, because it's much closer to the definition of a "thin client." If the client runs the app locally, it's not thin.
Originally posted by Amorph
Nibs are basically just serialized objects. They can be (and have been) easily streamed. They already can be, have been, and are, loaded dynamically. There's nothing stopping Apple from streaming them over networks and building GUIs with them, because NeXT did just that. The objects don't have their appearance hard-coded, which is how you can switch between Aqua and brushed metal with a single checkbox setting in Interface Builder.
I couldn't agree more that OSX should be the standard OS across all of Apple's computers, and that making a thin client with a scaled down OS really defeats the purpose of buying a Mac and increases Apple's support headaches exponentially ...
... but still, if you've already got OSX running on a G3 (and a G3 is all it would take if all you're doing is running interface arithmetic), and all that G3 does is run Apps on the server (with drawing commands being handles natively on the client) then what does it matter if you're running over even 10bt? Citrix runs just peach over fast modems!
If you've already got Aqua, all you have to deal with are NIB files ... well, stick a checksum on those suckers and update accordingly I say.
At which point I have to ask - what am I missing here?
Thanks in advance
OT
Originally posted by Amorph
Nibs are basically just serialized objects. They can be (and have been) easily streamed. They already can be, have been, and are, loaded dynamically. There's nothing stopping Apple from streaming them over networks and building GUIs with them, because NeXT did just that.
Are you talking about the old remote display technology? NXHosting? If so, that's not quite right. The client knew nothing about the nibs or the appearance at all. What was streamed between client and server was postscript - literally the drawing commands necessary to render the interface. The new window server architecture can't do that directly because it lacks a postscript interpreter.
Originally posted by AirSluf
Those aren't thin client's you are running, they are fat clients which have centrally repositited applications storage. The app isn't running over the network, it is downloaded and runs locally. One possible solution for configuration management, but one that uses (wastes?) much more bandwidth than other solutions.
Um... yes, they are thin clients. All the apps execute on the server. Notice I said unix machines are where the client is running. Can't run x86 apps on a 604 with any kind of speed, particularly not MS Office apps! Emmulation? Way too slow for office 2000. Recoded apps? no.
And I made a mistake in my post - there are actually about 250+ users being served by the 5 servers and this is supposedly less than 80% of their capacity. My firm has a long history using this type of arrangement on windows centralised servers. (Being a little vague on purpose.)
MM
There are also rumours of a Tablet both large and small.
Is the small one a wireless thin client?
Is the large one a networked client?
They would be the Sun Ray equivilent but with style!
It would only need a stand with ethernet, firewire and usb ports and it would be complete.
Dobby.
Originally posted by hardcore
Are you talking about the old remote display technology? NXHosting? If so, that's not quite right. The client knew nothing about the nibs or the appearance at all. What was streamed between client and server was postscript - literally the drawing commands necessary to render the interface. The new window server architecture can't do that directly because it lacks a postscript interpreter.
But we now have the ability to send nibs over... or we could stream DisplayPDF, just like DPS in the NeXT era
Originally posted by visigothe
But we now have the ability to send nibs over... or we could stream DisplayPDF, just like DPS in the NeXT era
I don't see how 'sending nibs over' is going to work. A nib relies on a couple of things to work:
- external frameworks for code and resources: AppKit, any shared libraries used by palletes.
- application binary: you almost always have instances of your Controller objects represented in your nib and the File's Owner. Those representations are serialized objects as well but they are only proxies to the real deal in the binary.
now, theoritcally, you could slip some Distributed Objects messaging in there but my gut feeling is that it would be ridiculously slow: totally swamped by remote messageing overhead.
If you have the frameworks and palletes installed already why not install the application binary too? That's not very thin to me.
As for streaming PDF: It's not "just like DPS." That was my point about not having a Postscript interpreter. It's probably more efficient just to send over bitmaps than to send over PDF. By the time the window server gets things everything is a bitmap anyhow. the window server is basically managing regions of video memory; it's actually quite 'dumb' compared to DPS. All of the drawing is actually done at a different level, in the individual libraries however they want (Quartz, OpenGL, Java2D).
It does make things like the compositing of Quartz Extreme possible but it doesn't really buy you anything as far as remote display goes.
At least I don't see how. Maybe you could elaborate on your ideas?
Originally posted by hardcore
I don't see how 'sending nibs over' is going to work. A nib relies on a couple of things to work:
- external frameworks for code and resources: AppKit, any shared libraries used by palletes.
...
If you have the frameworks and palletes installed already why not install the application binary too? That's not very thin to me.
The two big advantages of thin clients is that hardware and support costs are drastically reduced. This can still be the case for clients which locally store frameworks and do processing on interface widgets. The frameworks required for OS X and cocoa are relatively small when compared to all of the various programs run by users on a company's LAN. Updates to frameworks can be quickly transfered when a client is found to be out of date.
What this does is decrease the typical bandwidth required by clients while still reaping the benefits of administering only one copy of each program bundle for all users on the LAN (or WAN possibly). By installing frameworks on the client, low-end broadband connections become more than adequate for running fully-native, remote applications. This isn't the case for streaming interface images rather than widget definitions and user input. Typical broadband performance would lead to a noticeably lagged GUI.
When designing a marketable thin or fat client, there are more design goals than just minimizing client costs by decreasing processing power. The cost of giga-bit switches makes it such that minimizing bandwidth requirements becomes almost as important as minimized local processing requirements. Currently, I think the most economical tradeoff is to have frameworks stored on clients with just enough processing power to handle the rendering of widget interaction.
Originally posted by OverToasty
OPTION A:
There are thin clients that actually LOAD the app FROM the server, so the App actually runs on the client machine ...
OPTION B:
There are thin clients that do no such thing, the apps runs on the server, and only the control and interface is run from the client (XWindows, WindowsXP, Citrix) with interface instructions being the only thing sent back and forth from the server and client.
Those are by no means the only two options.
Furthermore you could do both at once on the same machine i.e. A) downloading a tiny java applet that doesn't need to communicate with the server at all once it has downloaded and
The two extremes
THIN: a classic dumb terminal which is basically the equivalent of having a *really* long cable for your monitor and keyboard as you are directly accessing the server.
FAT: Normal desktop i.e. may as well not be attached to a network as it doesn't use it for anything.
Different technologies (or even applications of a single technology) can be placed between these extremes.
Some examlpes VNC, Remote X Windows, unix command line access, Java applets, applet front ends for servlets, web pages, server generated web pages (PHP, JSP etc.), JNPLI(?) launched Java apps, web pages with client-side javascript, apps loaded from central servers, remote document hosting, rendering clusters, centralised network log-in, various combinations of the above etc. etc.
"In client/server applications, a client designed to be especially small so that the bulk of the data processing occurs on the server. The term thin client is an especially popular buzzword now because it serves as a symbol dividing the computer industry into two camps. On one side is a group led by Netscape and Sun Microsystems advocating Java -based thin clients running on network computers. The other side, championed by Microsoft and Intel, is pushing ever-larger applications running locally on desktop computers.
Although the term thin client usually refers to software, it is increasingly used for computers, such as network computers and Net PCs, that are designed to serve as the clients for client/server architectures. A thin client is a network computer without a hard disk drive, whereas a fat client includes a disk drive. "
Basically there are two concrete statements that sum up the thin client - "no hard disk drive" (or memory card, etc where applications load from) and "the bulk of data processing occurs on the server". That's it, the rest is just different views of such. They really have nothing to do with where an application is run from, however. I have installed many, many client server applications. Look at JDEdwards software - a classic example of a client/server application. That client is larger than an OS in some cases.
The point being, thin client has always been a very loose term; I think most people would agree that it defines what I stated in the previous paragraph. Who cares if someone implements something that causes the definition of a term to change, though? I could care less, as long as it serves a purpose in a better way. Whether it runs a frickin app locally or off a server is moot.
That said, I think Apple's implementation could include a VERY small client, basically a CPU, RAM and a flash that allows it to boot off the xServer cluster. The OS and apps reside on the server, with the client basically sending/receiving requests - a true client/server implementation. And no, the OS doesn't have to be a re-written micro OS or anything. Just use what is necessary to run a thin client and forget about packaging the rest in the OS image.
Its like trying to classify all vehicles as either a car or truck. Vehicles can be partially both, completely both, completely one and partially the other, partially one and none of the other, or neither of both.
But seriously, is a mini-van a car or a truck? Is the Isuzu Trooper a car or a truck? Attempting to make this type of classification is a fairly useless endeavor.
thin-client-ness is not a discrete attribute of hardware or software. It is common to exhibit some but not all thin-client attributes, to exhibit a partial degree of thin-client-ness.
Originally posted by dfiler
Thank you for the definition... but it will be impossible to reach consensus on what is and what is not a 'thin-client'.
Its like trying to classify all vehicles as either a car or truck. Vehicles can be partially both, completely both, completely one and partially the other, partially one and none of the other, or neither of both.
But seriously, is a mini-van a car or a truck? Is the Isuzu Trooper a car or a truck? Attempting to make this type of classification is a fairly useless endeavor.
thin-client-ness is not a discrete attribute of hardware or software. It is common to exhibit some but not all thin-client attributes, to exhibit a partial degree of thin-client-ness.
And to that end, does it really matter? The point being that remote GUI login will allow a new class of hardware to exist in the MacOS universe. This hardware would be a boon in some situations, others perhaps not. Now though, we start seeing the Enterprise come into focus.