Re: Help: Mac as a Terminal
Re: Help: Mac as a Terminal
- Subject: Re: Help: Mac as a Terminal
- From: Cláudio Rodrigues <email@hidden>
- Date: Thu, 01 Mar 2007 19:23:19 -0500
- Thread-topic: Help: Mac as a Terminal
I must disagree here. :-)
Both RDP and ICA are way more efficient than anything out there in terms of
remote desktop protocols. Have you tried X over a 56K line? ICA and RDP both
work great.
Secondly any dual CPU server with 4GB RAM is able to handle 50-70 concurrent
users these days if running Windows 2003 Server. Citrix may add more users
on top of that due to DLL rebasing and binding.
Machines with 8GB RAM are never used for TS/Citrix unless you are running
Windows Server 64-bit (as in 32-bit you have the 2GB Kernel memory limit).
And we usually use these servers as the client, in a typical client/server
solution; we never use it as the whole client/server.
I really wish OS X had something like Windows Terminal Services where
multiple users could connect to an OS X box and get a full graphical
session, all at the same time and with the same level of performance we have
when using RDP/ICA over all kinds of connections (from 28kpbs links to LAN).
And on the costs you mentioned, remember that TS as of today offers as much
as Citrix at the protocol level; the extra bells and whistles Citrix offers
would normally apply for much larger installations than a 20 user
deployment. 20 users can be easily handled with a single CPU box and with no
Citrix at all.
Just my $0.02 as I have been doing Citrix/TS deployments ranging from 10 to
10,000 users for the past 10 years. :-)
Cláudio Rodrigues
CEO, TSFactory Inc.
Microsoft MVP
Windows Server - Terminal Services
http://www.tsfactory.com
> From: Andrew Satori <email@hidden>
> Date: Mon, 26 Feb 2007 20:31:19 -0500
> To: Colin Cornaby <email@hidden>
> Cc: Brent Austin <email@hidden>, <email@hidden>
> Subject: Re: Help: Mac as a Terminal
>
> Not to put to fine a point on this, but ....
>
> This is a design decision that should have been made before line of
> code was written. That said, now you are boxed in.
>
> Without knowing a bit more about your application, we can only make
> assumptions. Generally speaking, a client server design is the model
> you are probably looking at, with your data in a server based RDBMS
> and you are then accessing it via your Cocoa Clients, running in a
> full OSX installation, probably on something like an iMac (which is
> smaller than many Network Computer / Thin-Clients). Ideally in a
> restricted mode that only allows that application for the default users.
>
> This is the only way you are going to run a Cocoa app on many clients
> against a central server today.
>
> Now, this has some limitations, and in the Windows world is
> considered very much to be 'old school', having been largely replaced
> by n-teir architectures. Most RDMS client access libraries aren't
> very WAN friendly. Meaning that you aren't going to want to run your
> application over anything less than broadband, and anything less than
> ethernet will be a noticeable slowdown, however in an ethernet
> environment, it remains one of the easiest and most efficient
> implementations, and I'm guessing would be the easiest path from
> where you are. Of course, the means a multi-user scalable database,
> which pretty much rules CoreData / SQLLite.
>
> Ok, so the short answer is, No, the Mac doesn't support what you are
> implying you want. So let's talk about your alternatives.
>
> On Windows, you have Terminal Services or Citrix, which are basically
> the same technology with slightly different implementations. In both
> cases, your application and database live on a central server. Then
> each thin-client connects to the server and creates an 'instance' for
> it's workspace, which is a full user login of Windows behind the
> scenes, even though only a single application may be presented. The
> application is then displayed over the wire to the workstation,
> usually in what amounts to sending it over the wire as a screen
> scrape. This is neither fast, nor particularly user friendly, nor is
> it as cost efficient as people seem to believe. First, you need a
> much more significant server to handle multiple interactive
> sessions. General rule of thumb, a 4 processor server with 8gb of
> ram will generally start to cap out at about 20 clients, and if the
> DB is on the same server, performance will tail off much faster than
> that.
>
> Then there is the Unix, X-Windows way. This is by far the most
> effective thin-client methodology, as X-Windows handles this quite
> well, and you can then use inexpensive Thin-Client devices that are X-
> Windows clients that actually boot off the network and display
> locally. To a certain degree, you might be able to get this working
> using GnuStep to reuse some of your Cocoa code in an X-Windows
> environment.
>
> Of the non-Mac alternatives, this is also the 'cheapest' as the thin-
> client's are more readily available.
>
>
> This sounds all fine and dandy but let's get down to cases and Cocoa,
> because I'll honestly tell you that despite everything above, I
> believe that the Mac and Cocoa are your best bet:
>
> Case Windows: $35,950 (round figures no development, support or
> installation costs)
> Server:
> $15,000.00 -- Dell 6850, basic configuration, Windows Server w/ 20
> cals
> $ 4,950.00 -- Citrix MetaFrame w/ 20 clients
> Thin-Clients:
> $ 650.00 x20 -- Wyse Winterm 941GXL w/o monitor
> $ 150.00 X20 -- Generic 17" LCD Monitor
>
> Case Unix (Sun & Solaris): $23,690 (round figures no development,
> support or installation costs)
> Server: $ 9,995.00 -- Sun Fire T2000 QuadCore Niagra (left in the
> most basic spec, probably adequate for 20 users, barely
> $ 115.00 X1 -- package of 25 smartcards for session storage
> Thin-Clients:
> $ 679.00 x20 -- Sun Ray 2 with Keyboard and 17 LCD monitor, and
> session cards.
>
> Case Mac:
> Server: $ 7,295.00 -- Apple Xserve, bumped to 146gb disk, 8gb RAM and
> dual 2.66, Added unlimited Apple Remote Desktop
> for central management of the Mac Clients
> Not-So-Thin-Clients: $27,275 (round figures no development, support
> or installation costs)
> $ 999.00 x20 -- iMac Core Duo
>
>
> None of these cases address cost of development tools, database
> engines, infrastructure or other forces, and these can WILDLY skew
> these numbers.
>
> I've done all three of these deployments in my career, they all have
> pluses and weaknesses, and there is the possibility of some mix and
> match, and more importantly, there is quite a bit to be said for
> design decisions based upon the planned deployment model.
>
> I'll address some things that may be relevant. Cocoa is a wonderful
> development environment (though in it's current form, access to
> RDMS's data requires more work than it probably should). It is also
> free per developer. On the Sun/Unix platform, you can use GCC and
> and a mix of Open Source like Eclipse, and with Solaris, dtrace is a
> wonderful tool. Sun's Developer Studio is a good tool, and I believe
> it is now Free as well, though I cannot confirm that, I haven't kept
> up with it in the last couple of years. Visual Studio is the tool of
> choice on Windows, for good reasons.
>
> On the Database side, you have options from free to very non-free
> ranging from the low end with MySQL, to the mid-range with PostgreSQL
> and into the high end with Oracle (and a lot in the in between groups
> like OpenBase, FrontBase, MSSQL, Informix, Sybase, IBM etc...).
> Nearly all of them offer client-server libraries, JDBC or ODBC driver
> interfaces.
>
>
> And that brings the other two options. Use Java and use Java Thin-
> Clients (though they aren't in truth 'thin-clients' in that they have
> local computers that just execute Java applications). Or write the
> entire thing as a web application and use a thin-web client as your
> terminal.
>
> In the interest of the best user experience I cannot recommend the
> last two options, though plenty of people obviously do (been to the
> movies lately and used a self-service kiosk?)
>
> So, hopefully, this gives you some food for thought. I personally
> would opt for the Mac & Cocoa, because of the intrinsics and the
> development tools. But that is a choice you'll have to make on your
> own.
>
>
> Andy
>
>
>
>
> On Feb 26, 2007, at 7:15 PM, Colin Cornaby wrote:
>
>> I'm assuming you're talking about something similar to Citrix or
>> Windows Terminal Services.
>>
>> As of now there is no way to do this on the Macintosh. You probably
>> want to explore writing your own client/server implementation for
>> your application. Or use an existing solution like the Citrix or
>> Windows Terminal Services clients for the Macintosh, and simply
>> have your Macintosh users log into a Windows version of the
>> application, although this option is not as nice as simply having a
>> Mac OS X application.
>>
>> -Colin
>>
>> On Feb 26, 2007, at 3:41 PM, Brent Austin wrote:
>>
>>> I know very little about terminal/emulation. The reason I am
>>> writing you
>>> is because I have a very specific question regarding using an os x
>>> comp
>>> as a terminal. I am in the process of developing an information
>>> management system that is a native cocoa app with a secure database
>>> backend. What I would like to do, once the app is developed, I
>>> would like
>>> to be able to implement in
>>> the following way: OS X and IMS application installed on main XServer
>>> then have multiple (as needed) terminals that access the main server
>>> and are able to utilize the app and database as necessary each
>>> terminal
>>> independent of each other. What I mean by terminal is a Mac Display,
>>> Keyboard, and Mouse but no cpu. You would just securely login at the
>>> terminal and then have your own instance of the IMS app to do what
>>> you
>>> need. Is this possible on a Mac?
>>>
>>>
>>>
>>> _____________________________________________________________________
>>> _______________
>>> Finding fabulous fares is fun.
>>> Let Yahoo! FareChase search your favorite travel sites to find
>>> flight and hotel bargains.
>>> http://farechase.yahoo.com/promo-generic-14795097
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> Do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>> 40mac.com
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden