We did work with a full blown OSX Server in 2004 - indeed many issues on NFS were Ok, but NIS was a problem - or we could not figure it out. We used it as server for developers, running X-grid, SVN, WebObjects servers for a couple of EC networks, but never deployed it fully as a departmental-level server, due to the NIS issues. For a while it also hosted the protein-ccd server. We wanted to move to Kerberos if I recall correctly, but since my colleague Serge Cohen moved out and our IT are mac-o-phobic I opted to continue with Linux.
The Server was decommissioned a few weeks ago, and will likely get a second life in Soleil/Ipanema, but I think as an electric heat generator - almost as good on it as my old 8-proc Alpha (2000) ;-) A. On 23 Jan 2013, at 15:05, Bosch, Juergen wrote: > I assume nobody of you is running an actual Osx server ? I mean the upgrade > to a full server version of the commonly distributed normal Osx releases ? > > I have not done it yet but I do think many of the issues mentioned regarding > NFS/NIS could be addressed there. Regarding the missing macpro upgrades I > expect to see new machines with thunderbolt connectivity in the next 4 > months. And I will buy my third macpro then to run it as a true server. > > Jürgen > > Sent from my iPad > > On Jan 23, 2013, at 5:21, "Peter Keller" <pkel...@globalphasing.com> wrote: > >> On Wed, 2013-01-23 at 01:54 -0700, James Stroud wrote: >>> On Jan 22, 2013, at 11:20 PM, Nat Echols wrote: >>>> The real difficulty is integrating Macs into a >>>> Linux-centric environment, for example configuring NFS, NIS, etc. >>> >>> That's because NFS and NIS are antiquities left over from the days of >>> mainframes. Distributed file systems and user information databases >>> are designed for an environment of many workers and few machines, when >>> the typical graphics workstation cost $50,000. These days, we argue >>> whether to spend an extra $200 on a $500 computer. We have moved to a >>> new paradigm: many workers with many more machines, with each machine >>> having essentially mainframe levels of storage and computing power. >> >> Technically there is something in what you say as a pattern for >> day-to-day work (for some people, although not all), but I think that >> describing the debate in terms of modern vs. antiquated is missing the >> point completely. The real difference between local vs. centralised >> storage is to do with responsibility for the hardware and the data that >> it contains. >> >> Local workstation storage is OK for the following kinds of cases: >> >> (i) the data that are stored locally have no value, so it doesn't matter >> if they are lost (either through hardware failure, misbehaving software >> or accidental deletion). >> >> (ii) the user has the expertise and the time to set up and maintain a >> strategy for recovering data that are lost from local disks >> >> (iii) the institution that the user works for allows the user to include >> data on local workstation disks in the institution's regular backup >> operations >> >> When none of these apply, there is a real, contemporary case for using >> something like NFS, where the storage is centrally maintained and backed >> up. The cost of storage has fallen of course, but what that means is >> that the real questions now are about the value of the data. In some >> fields, you could store your entire career's data on a few USB memory >> sticks, but I doubt that many people would want to do that without >> having made other copies somewhere else, and the same applies to local >> workstation storage too :-). >> >> There are other considerations in favour of connecting a workstation to >> networked services: if you use more than one machine it can be an >> incredible pain to be constantly moving data around from one to the >> other, and to keep track of what the authoritative versions are. Having >> independent, local user id's and passwords on every workstation can also >> cause difficulties. I could go on.... >> >>> In other words, instead of NFS, you should run git. >> >> This is simply not an option for many crystallographers, who do not have >> a background in software development or data management. Advocating and >> supporting git (or indeed any content/version management system) for >> those kind of users is a losing battle: they see it as an unnecessary >> complication to their daily work, and will avoid using it as far as they >> can. >> >> Regards, >> Peter. >> >> -- >> Peter Keller Tel.: +44 (0)1223 353033 >> Global Phasing Ltd., Fax.: +44 (0)1223 366889 >> Sheraton House, >> Castle Park, >> Cambridge CB3 0AX >> United Kingdom
