ajtaylor

Oi, I don't have a beard - though if I wasn't ginger I might consider it :-)

As you say, the SunRay has next to nothing in it - it's essentially a graphics card, USB controller, audio controller, and network controller, and not much else apart from a boot prom. The UNIX server is responsible for redirecting the graphics from the X server to the correct SunRay token - a token being either the MAC address of the sunray unit, a smartcard, or a user id, and for doing load balancing/routing of session to correct sunray server, etc. (Because when a Sunray unit comes up, it "binds" to one server, but your disconnected session may not be on that server, when you re-connected it has to get to the right server) Unlike Windows, where session reconnects take time (generally not a huge amount of time, but time), with Sunray, it's instantaneous ; if you're using smartcards, then it's literally shove in the card, and off you go. (Although you can use policies to dictate whether users need to enter passwords, etc, as well as the card). You can also use multiple sunray units next to each other to give you multiple screens using xinerama, and it's smart enough to know to turn off the screen spanning when you're on a sunray that's not connected to multiple screens. I've seen a lot of allegedly thin clients, but none are anywhere near as thin as Sunray. It's just a shame there's no sunray server for Windows. However, people like the Cutter Project can help you make the UNIX side of things invisible, and manage it for you. I seriously recommend getting a demo.

I completely agree. I'm pretty certain ('cos I have stats that prove it) that outside of IT lessons, the main "legitimate" computer usage is Word/Powerpoint/Browser. I need fat clients to drive whiteboards, and in the IT suites.

9 years! Blimey - are they really still able to cope with current apps after that long? i.e. can the machines you bought 9 years ago run Office 2007 at an acceptable pace? I wouldn't recommend thin client for your IT suite - that's where you want to do the interesting stuff, but for, say, a group of machines in a corridor, or backs of classrooms, etc, they are ideal. Low maintenance, low power, deploy and forget. Even in the staffroom; it'd be great to have a few machines in there that you didn't have to visit, so you wouldn't get pestered to do all those extra jobs every time you went in... I'm seriously considering putting in lots of SunRays for our junior end (2-6) ; they tend to use web applications or tux paint, for which sunrays on Solaris would be ideal. As I'm the only full time IT guy (and I'm teaching/HoD too), these are ideal, as I can deploy and leave them alone. When I took this job on, the whole school was terminal server based but using ancient desktops running XP as clients - i.e. fire the machine up, come back 30 minutes later and use Remote Desktop Connection to logon. That was just too restrictive and has caused more problems than it fixed as all my users are now very under confident; they're so used to not being able to sort things out for themselves that they won't even try. So I've gone round and made everything fat client again, and given many people admin rights for their own machines (but backed by a robust automated build system for when it all goes wrong). Next step is to put some thin client back in, but only where it's appropriate for the task. As I say, to my mind that's mostly browser/office apps. You can do much more with thin clients, but you can do that much more more easily with fat clients, so I advocate using thin only for the simple stuff. I kinda regard the EEE as an extension of it - a portable "thin-ish client" ; i.e. you'd only use it for the simple stuff, but it's still incredibly useful. 90% of what our kids need to do is research and write up, so a browser and openoffice is perfect. Same for staff.

I'd be interested to know how he's done the maths. The average life of a desktop PC is what, around 3 years? So, every 3 years, you're going to replace a desktop for around £250 or more, install it, deploy it, etc. Thin client, you should be able to just leave it alone for at least 5 years, probably a lot more. Yes, you will have server costs, but again, they're a one off (although upgrades are always nice). You save, as you say, on licensing and manpower, as well as a huge saving on energy. Getting Ubuntu to talk to an AD domain should be pretty straightforward - if you want a hand, feel free to PM me.

I used to work for Sun; I used a SunRay everyday for 6-7 years. When we switched from workstations to SunRays, the power company thought we'd shut the site down, the energy saving was that huge. The current generation of SunRays with the inbuilt LCDs use something 4.5-7 watts, whereas a desktop uses around 100. The power saving is only one side of things, though. The biggest advantage and disadvantage of thin clients is the locking down that comes with it - it's easy to restrict what users can and can't do. This makes them great for browsing and office applications, but for not much else. Andy at the Cutter Project will be able to tell you more about Windows integration, but to my mind, you're best off just using them on UNIX (Linux or Solaris) with Firefox and OpenOffice or even Google Docs. Use fat clients to do fat client type stuff, e.g. media and the like. Use thin clients to do 90% of what people want ; browser and office. No need to worry about Windows for that. The admin side of things is pretty straightforward with SunRays. If you don't need to use Citrix or Tarantella for Windows support, then all you need is a fairly beefy server or two, a Solaris (or Linux if you must) installation, slap the SunRay server software on, answer a few questions, and off you go. The devices give you fairly good troubleshooting, providing you dig out the sunsolve infodoc on what the error codes mean (e.g. 21D, etc), which tells you the corresponding actions to take for each error code. If my users were confident enough to cope with the idea of having more than one office suite (2007 + OpenOffice), I'd put in SunRays running OpenOffice and Firefox on Solaris in communal areas. One last thing - I was in support, primarily OS & kernel, but one of my specialities was Sunray, particularly in the early days. In the 8 years I worked at Sun, I remember replacing only 2 SunRay units for customers. I'm sure there were more failures than that, but they really were pretty robust machines. No moving parts (apart from the speaker), and a very very very simple internal design with very little heat or power being put through them.

I seem to remember there was an emacs bundle that would do this - possibly part of gnus, but it's been a while since I used gnus to read my mail, so I could be imagining it!

One of the biggest gaps in most people's education/skills is the ability to solve problems rationally and consistently, which is, IMHO, essential for any computing related work. Fortunately, it's something that can be taught, but I've not encountered any schools that do - they might teach what they call problem solving, usual maths related, but rarely do they teach practical problem solving.

Found the answer... Had to have IPv6 enabled on at least one interface. Why the hell that's not checked for by the installer, given how catastrophically the installation fails (can't uninstall, can't install anything else), leaving one having to hack out registry keys to remove exchange, I don't know.

Stupid, stupid question time... Why the hell can I not install Exchange 2007 SP1 on a brand-new, completely clean Windows 2008 64-bit (Standard or Enterprise) install? All I've done is: a) Install 2008 64-bit (Enterprise, initially, but also tried Standard) b) Download updates c) Setup as DC/DNS d) Install IIS/ASP/AD LS pre-requisites e) Run Exchange 2007 SP1 setup. f) Choose typical install g) Enter my org name h) Choose yes to "I have Outlook 2003/Entourage" j) Waited The Edge transport service always fails to start, and the installation bombs out. Can't go forward, can't go uninstall. "Service 'MSExchangeTransport' failed to reach status 'Running' on this server" - [6/20/2008 12:23:08 AM] [2] Generated Watson report with dump for the service MSExchangeTransport [6/20/2008 12:23:08 AM] [2] [ERROR] Unexpected Error [6/20/2008 12:23:08 AM] [2] [ERROR] Service 'MSExchangeTransport' failed to reach status 'Running' on this server. [6/20/2008 12:23:08 AM] [2] Ending processing. [6/20/2008 12:23:08 AM] [1] The following 1 error(s) occurred during task execution: [6/20/2008 12:23:08 AM] [1] 0. ErrorRecord: Service 'MSExchangeTransport' failed to reach status 'Running' on this server. I must be doing something wrong - I'm sure lots of other people have installed Exchange on 2008. Being a UNIX man, I'm at sea with debugging this stuff!

I believe some functions of php5 understand http_proxy - you could try setting http_proxy in either the environment for apache, or in httpd.conf ?

As Geoff says, Apache itself wouldn't be making connections for you. What exactly are you trying to achieve, and in what language? If it's php, what function are you using to grab data from this other site, and what version of php?

Sorry, I know I'm being an argumentative pedant (I can't help it!), but what do you mean by swap nfs server? The way I read it is that you're using NFS to serve up swap space in someway, but I must be misunderstanding you!

Really? How can you determine that? Unlike Windows, there really shouldn't be that much extra data flying back and forth with a Linux (gnome/kde or any other window manager) login. You'll have, not necessarily in this order: - auth data (a few bytes) - name service lookup for the automounter (a few bytes) - mount (a few bytes) - source .profile - read gconf settings (assuming gnome) - read Desktop Shouldn't be a lot else... Seriously, there's really no reason not to use NFS - it's a much lighter weight protocol than smb/CIFS, and the whole Linux desktop login is much much much lighter weight than Windows profiles. You also have to remember that whereas Windows will copy the user's profile to the box, then work on it locally, the Linux/UNIX way is just to read/write it on the NFS share. It really doesn't care whether the user data is local or remote, it doesn't even know about it! If you actually look at how it's implemented (I'm talking Solaris here, 'cos that's what I know, but I can't imagine Linux does it much differently), the desktop manager and login has no idea where the "profile" data is, all it has is a bunch of file descriptors that point to vnodes. It calls read() (or write) and then the OS works out what flavour of read op it needs - vnode maps to an inode or rnode, and the vnode contains a vnode_ops pointer to a struct which maps out what actual function to call for each op, e.g. read -> nfs_read. This is how the OS works out that a file in /dev can be rm'd from the f/s (unlink -> ufs_unlink or ext3_unlink), but when you open it it opens the actual device rather than the file.

Sorry, but on what are you basing that? NFS is most certainly not a dog, and most certainly works very well for a large number of clients - that's what it is designed for! Having run an NFS server that served 25,000 simultaneous clients, supported many customers with huge NFS deployments (100,000 clients), fixed some bugs in NFS and the Solaris automounter, and done that job from a thin client with my home directory and applications all living on NFS, alongside 45,000 users, I can confidently say that you've got something wrong somewhere - maybe you've got a duff NFS implementation somewhere (I mean in the distro), a badly configured server, or something odd going on with your network.