Is it a coincidence that in this, the week Darth becomes Darth, I wiped my older GX100 at home and installed XP sp2? I was already running XP on my newer eMachines. This makes my basement a de facto Windows-only zone. My wife's iMac remains our email/surfing/iPhoto mainstay upstairs.
My old Dell has been a Linux/FreeBSD testbed for years, running everything from Red Hat to SuSE to Gentoo to Mandriva, but Friday night I finally decided to focus on what I/we actually use to get stuff done.
I am not against Linux. If all I wanted were Apache web services, MySQL or PostgreSQL or Oracle, and/or Samba file services, I'd pick FreeBSD or a major Linux (RH or SuSE) in a heartbeat. These are safe, reliable, cheap, run fast on affordable hardware, and for those server apps are very proven.
They do not, however, hold a candle to Microsoft or Apple on the desktop, particularly in games, nonlinear video editing, and Office productivity tools. Even Openffice looks and works better on Windows and OS X than on Linux. Most of my time is spent using or supporting desktops, so it makes more sense to build a deeper understanding of Windows and OS X.
Solaris I have to know because our web servers run it. We also run FreeBSD, but just for Samba and Amanda, and these require little daily support. I need to keep up to date on basic Solaris and FreeBSD skills,and on Apache and related technologies, but most of my time goes elsewhere.
From a technical perspective I much favor OS X. It's cleaner, safer, and more attractive than Windows. Most of the software on my Mac mini just works, and I never have to worry much about viruses and spyware. "Tiger" remains my main work environment, and I support a small OS X Server for local DHCP, Netboot, and possible (in time) FMPro Server services.
Windows by contrast demands babysitting. That's a blessing and curse. Despite many efforts by Microsoft to improve Windows security and reliability to the point that XP sp2 is adequate for most users - iff patches plus anti-virus and anti-spyware software are maintained - there is still enough support required to keep me employed for years to come.
If ever I start a "real" company, I may make it all-Mac. The labor I'd save with a Netboot environment and XServers at the core, not to mention free client licensing, would far outweigh the up-front hardware costs and limited software availability. No need for a full-time IT staff.
But as long as I have a mortgage I'll probably rely indirectly on Microsoft to pay bills. Apple may be the Maytag of PCs, but who wants to be that repairman? If not for Windows, what would I do all day? I also happen to love games, and whatever Microsoft's failings, they make it easy to build great apps. See an earlier posting for more about games and nonlinear video editing.
For all these reasons I might as well accept the sad fact that I'm a Microsoftie. Resistance was futile; Dark Side was strong; pick your analogy. Job security, my desire and ability to tinker with registries, and games and videos matter more to me than the elegance or security of the platform.
Sorry Linux, but if my experience is any indication you're doomed to remain even more niche than Apple on the desktop. Look at the metric system - better does not necessarily guarantee acceptance. People get entrenched. I may be retired long before Windows (inevitably) loses its dominant position.
I'm so glad we're talking about doing FMPro7 Server
Advanced with a new G5 tower. What else is there?
MS Access (IIS security?) and one immature option
coming in OpenOffice that I looked at recently. Most
users can't do their own Perl/MySQL nor ASP.NET,
much less the Oracle stuff Jo once wanted for BIS.
Think of what we have saved in IT labor by enabling
power users to build and support their own solutions.
That's not even considering how entrenched we are
with FMPro - that is, the hundreds of hours a major
migration to any other environment would require.
Report formatting alone would take a huge effort.
We will not regret this upgrade. About pricing, see
Separate from Advanced Server (get that regardless),
it looks as if we do as I say for FMPro 7 desktops and
buy 50 at once, it's at least 40% off retail. To upgrade
would be about 40% off, so it probably wouldn't save
us anything to upgrade from FMPro 6 vs. site license.
Those 50 seats will cost at least $5k for all, as Steve
said, probably more, in addition to Advanced Server,
but we could probably then forego further upgrades
for at least a couple years. Version 7 is a major step
up. If too expensive, we could probably delay most
of the client upgrades, but at least upgrade all those
who will build or test FMPro databases for the web.
That includes a few of us in IT plus Emily and Dave.
A big thing for me is not having to worry about which
staff get which license. Under the 10-pack deal if we
exceeded the limits of any 10-pack the integrated
license checkers could complain. Jo was adamant
about avoiding that embarrassment after it happened
in some meeting (before my time, but remembered).
With a site license I can embed FMPro in images and
save maybe 10 minutes per desktop deployment not
having to install particular licenses afterwards. That's
like getting a free day over the course of any all-staff
PC rollout, more time over the course of a few years.
A few individual upgrades (a ten-pack?) won't break
the bank, but ultimately I'd get that site license. If we
could swing the site license concurrent with the new
PCs we could take advantage of embedding FMPro
in [the next Windows and desktop PC] rollout...
---- Way back on 28 Apr 2005, David Farmer declared:
NAT is EVIL! There I have balanced the universe again. :)
Well, actually NAT is a tool and like most tools it is morally neutral.
Also like most tools in the hands of a professional or someone else
who knows what they are doing, it can be useful and even a good
thing. However, in the hands of someone who doesn't know what
they are doing, most any tool can be bad and even dangerous.
---- Brad's response ----
Thanks for the detailed response. I obviously don't
share your concern over NAT drawbacks, particularly
in the cases of firewire, VPC, or home configs, but
you do make an interesting case with good details.
Generally speaking, you raised valid criticisms,
but based on extensive experience I'll explain in
more detail (for the last time, I promise) why I
still think NAT is actually good for some things.
The main drawback is NAT breaks an external admin's
ability to ID (e.g. traceroute) which node behind
NAT is causing or experiencing net problems, and to
directly reach the IP address from outside the NAT.
A few apps will also misbehave, but most users don't
do videoconferencing and such. Surfing, email, ssh,
some VPN clients, most other client apps work fine.
There are benefits. NAT also frustrates hackers and
prevents users from running world-reachable servers.
I'm not saying NAT is a firewire, but it does help
and can be used in conjunction with a real firewall.
Breaking central control of course matters when you
manage ten thousand nodes (as you do). More nodes,
more of a problem, but not every department needs to
be seen that way. Some small shops could easily and
safely operate as locally-managed abstractions. If
you find major network probs coming from IP address
X, kill X - temporarily. Then it's that admin's prob.
If you don't see any probs on a given IP, why worry?
A local NAT would not scale well beyond a couple of
hundred nodes (including printers, etc.) but in one
smaller org I ran NAT for 200+ PCs over four years.
Success depends on a halfway-competent admin, a few
compromises, and intelligence when troubleshooting.
Where I worked we paid just a few hundred bucks per
month for shared Internet over most years, saving
taxpayers over the period maybe ten thousand bucks
vs. allocating around 200 real IPs. Many use this
logic at home: Cable modem plus router is usually
much cheaper than getting several real IPs in DSL.
Responses to Krukenberg claims about limitations:
1. Global addressibility - so what? My home
boxes (OS X, Windows, and Linux) all work
fine behind a cable/DSL router. See above.
2. Global uniqueness - again, so? As long as
the provider (at home, Comcast) is able to
associate a problem with a particular IP,
they can blame or restrict the main node.
3. Persistence of host-to-address binding -
Breaks a few apps, kills remote control
from outside NAT, but otherwise no big.
4. Address structure - I don't buy this.
From outside, one whole NAT world can
be seen as one IP address (as VPC can).
The local admin can map what's inside.
5. Deployability of applications - Partly
true. Apps are usually not deployed from
way up top but from departmental servers.
In NAT I could deploy apps from server(s)
in my LAN, and NAT can span buildings if
the respective network is so configured
(not here; it was where I last worked).
6. Reliability - Why would NAT be any less
reliable than "proper" routing? I've seen
over a million emails route fine via NAT.
Reliability depends on hardware and a good
provider, not on how the IPs get assigned.
7. Scalability - yes, limited, but I see no
inherent issues up to around 200+ nodes.
8. Private address spaces and VPNs - a
concern if remote access into the boxes
matters, less so if key servers get real
IP addresses using secondary NICs - as I
set it up to reach GroupWise from home.
---- the next is from Dave ----
Most people don't know what NAT really is, how it works, what its
limits are, what it breaks....
---- Brad's response ----
Most folks won't care. See above about the
apps I can use at home without caring it's
NAT. I setup the same for several relatives,
including one who does all her work for IBM
over a VPN connection via NAT + cable modem.
Comcast has never had a reason to complain.
---- the next is from Dave ----
Lets look at another tool, a hand gun, this is a very useful tool in
some situations. But I don't think anyone would argue that it is not
dangerous in the wrong hands. I'll also note that the University has
rules about having hand guns on campus, counter to the way the
state legislature thinks things should be, I'll add.
---- Brad's response ----
That is not a good analogy. The default behavior
of a handgun is to destroy things. It takes skill
and thought to avoid nasty results. This is not
the case with NAT, which in typical uses - VPC
or cable/DSL routers, requires almost no skill
to configure and use safely and effectively.
---- also from Dave ----
I know, you have a weak argument when you have to bring hand
guns into the argument. Here are some much better arguments!
[the discussion goes on in this vein, but this is enough]
Recently I've speculated with [two coworkers]
what we might do long-term about the many
smaller databases we have, especially in the
event that one key database support person
were to leave. Not that we anticipate this.
One thought has been to narrow our focus to
a smaller set of tools more commonly used in
other UMN libraries, including Ruby and PHP.
New databases could be built for web access,
and databases already in FileMaker or Access
could be gradually rewritten around MySQL or
PostgreSQL backends. We have server space.
Until this week I've been all for migrating
to more open-source, UNIX-based tools. For
apps that need to be very scalable, that are
enterprise in nature, or that must integrate
with other open-source tools like cookieauth,
Ruby, PHP, and Perl make a lot of sense.
For smaller/departmental databases, though,
higher priorities can include fast/easy dev,
fine-grained control over the look and feel
of forms and reports, and quick tweaks later.
Desktop database tools were built with these
needs in mind. FileMaker (especially), Access,
and maybe the HSQLDB-based database to be in
OpenOffice 2.0 (hsqldb.sourceforge.net) ease
and speed construction of small databases.
I for one love FileMaker. It is nicely cross-
platform (vs. Access) and very mature/proven
(vs. hsqldb), and we have a huge investment
in both locally-developed databases and local
expertise. Nothing in the larger open-source
client/server world, except maybe the beta
of OpenOffice 2, comes close in enabling the
non-programmer to develop powerful databases.
Moreover, were we to move FMPro databases to
PostgreSQL or MySQL with front-ends in PHP,
Ruby, VB.NET, whatever, we'd be taking on for
a long time to come all responsibility for
database migration and subsequent tweaks to
the databases. This would run counter to one
of the ideas from that IT Assessment process
- empowering users to support themselves.
From a management perspective I may want a
lot of control over departmental databases,
but from the perspective of users it may
seem, to put it nicely, counter-productive
to take away a tool that already works well.
Bottom line: our goals should include making
computing as transparent and comvenient as
possible for our users, to provide the tools
they need, and to teach/help them to fish vs.
doing all the fishing (dev work) for them.
For smaller databases, I think we should keep
FileMaker Pro and try to take better advantage
of it, boosting what we have (v7, web access).
From March 2005 - note that I've since had second thoughts about becoming too dependent on Terminal Server as a single point of failure for Macs needing to run Windows apps. I liek systems to be self-sufficient, and a good eMac with VPC is moreso than an RDP client to Terminal Server. Open to discussion. Anyhow...
---- original message ----
Dave and one of the student workers helped
me verify Friday and Monday that we can now
run Aleph via RDP on that shared CCR eMac
via Windows Terminal Server from Biomed1
(which does double-duty for helpdesk tests).
RDP is a free client for Terminal Server from
Microsoft, available for Windows and OS X.
I set up RDP on that eMac to automatically
login to Biomed1 as user "biomcirc" and to
immediately run c:\al400\circ\bin\circ.exe,
starting in directory c:\al400\circ\bin. Users
never see a Windows desktop nor notable
delay, just Aleph. Closing Aleph closes RDP.
When printing, one chooses either locally-
connected printer(s) or CCR_A or CCR_B.
I can easily add printer CIRC_A to the list.
Three questions remain: (a.) how well it can
work for concurrent Aleph users, which we
can test using the existing Circ PCs and a
Win2K RDP client from k:\systools\software,
(b.) how well an Intermec USB adapter does
with handheld scanners - I'll test that soon,
and (c.) whether our superiors will OK this.
I have already seen that Aleph via Terminal
Server seems faster and starts MUCH faster
than via VPC, that Terminal Server can end
the need to support decentralized Windows
software at Circ PCs, and that requirements
on the client are easy: any current Mac with
512 mb RAM (demands less, but get 512+).
The goal of this for me is to reduce desktop
support. Having only OS X on Mac Minis at
Circ desks will do that. Terminal Server is
easy to support and cheap under U deals,
and we already have Biomed1 as a server
that can do double-duty. If ever we need to
part out Biomed1 to keep Biomed2 alive we
can fall back to using VPC7 for Aleph. Dave
has already helped verify that Aleph works
with VPC7 (pending handheld scan tests).
Why not just use thin clients if we're going to
use Terminal Server? (a.) Thin clients aren't
much cheaper than Mac minis, (b.) with true
thin clients there'd be no VPC7 fallback, (c.)
local Macs enable all other apps, including
browsers and FMPro, to run in native OS X,
(d.) desktop OS X is safer than any WIndows
configuration, (e.) a local OS may be needed
for flash drives, and (f.) many student workers
already favor OS X and would welcome this.
I'd replace all Circ PCs, except maybe Copy
Center, with Mac Minis. Warranties on those
five 866MHz PCs have long since expired. If
that went well, I'd consider doing the same
for other student worker stations and/or any
willing FTEs who do not depend on certain
Windows-only clients like Illiad or Novell's.
If we don't try this we'll have to pay at least as
much for PCs and then maintain Windows
on every Circ desk, rather than one shared
Terminal Server. The chance to easily move
staff to Macs only comes around so often. I
say take it now, even if only for Circ staff. If
not via Terminal Server, then using VPC7.
From Fedbruary '05, for U of MN Bio-Medical Library
As some of you know, Dave has been helping me
evaluate how well Aleph 16 runs atop OS X. I
have been hoping that using OS X in certain
capacities, e.g. at the Circ/CCR desks, might
decrease maintenance over time. The jury is
still out on that, but here's what I've seen:
---- OS X Pros ----
First, thanks to the intro of $499 Mac Minis,
gradual decreases in the prices of other Macs,
and the fact that the U now licenses Virtual
PC 7 for OS X, the base price of buying a Mac
and running Windows apps on it is comparable
to the cost of a reliable PC - e.g. a Dell
Optiplex (not a consumer-oriented Dimension).
Consumer Reports and others rate Apple way
above other vendors for reliability, so from
that perspective it's easy to justify Macs.
My own experience, and that of almost all
regular Mac users, seems to confirm that a
Mac with OS X is a very reliable and stable
platform, certainly as good as any other PC.
One other pro, and this is a huge point for
Macs, is that OSX-native apps and configs
are easy to secure and maintain. Unlike
Windows, OS X has never been subject to a
significant virus or spyware outbreak. Holes
in OS X security are rare and patched fast.
Some argue that's only because OS X gets
less attention with its small market share,
but I believe that the UNIX foundation of
OS X coupled with smart development choices
in the Aqua interface make OS X inherently
more secure that Windows. For example, with
few exceptions (all patched), rogue code
cannot just install itself atop OS X. Even
if you login as admin, installers ask you
for permission to do anything significant.
I have run OS X since its beta in 1999 on
a home eMac and have NEVER had a security
or virus problem, and I surf a lot of sites
and mess with it a lot. Steve can probably
say the same about public Macs. One just
has to apply period patches (very easy).
---- OS X Cons ----
There are few cons to running OS X, but in
some cases they may be significant. First,
if an app you require (Aleph, Illiad, Ariel)
is Windows-only then you probably need to
run Virtual PC atop OS X. This works well,
but there are drawbacks: (a.) VPC starts a
lot slower than native OS X apps, (b.) VPC
demands a lot of memory - increasing the
minimum hardware requirements slightly,
and (c.) some apps behave differently.
For example, Aleph 16 works great on Dave's
Mac once VPC is started, but the start time
can be up to a minute depending on what else
is running. One could launch VPC at login,
but this is still less than ideal. VPC can
print fine to a Mac's default printer but
apparently needs tweaking to see special
configs, e.g. extra trays and settings.
One quirk is that the Internet Explorer (IE)
now included with Macs is old, version 5.x.
You can of course run other browsers like
Safari (my favorite), Firefox, or Opera on
OS X, but a few $^$@ websites demand
not just IE but the latest version of IE.
Most importantly, Windows within VPC has
many of the same security issues as Windows
on x86 hardware, requiring extra care. If a
user only uses VPC for a particular app and
uses native OS X apps for everything else -
FileMaker, Office, email, surfing - then the
risk is small, but one must be careful.
I saw that some installs and updates don't
work well within XP atop VPC7, including
Windows Update and the Sun JRE 1.5x setup.
We got around the latter be installing an
older Microsoft Java runtime in two parts
(to enable printing Aleph loan receipts),
but I can see how such workarounds might
be cause for concern over coming years.
One extra cost if we were to move Circ
staff to Macs would be a USB adapter for
the Intermec hand scanners, raising the
cost per desktop by at least about $95.
Our scanners are PS/2 only be default.
A last con or at least consideration for
OS X, as with Linux, is that techs must
then know how to support at least two
operating systems. I'm not too concerned
about this, having worked for years with
both, but some consider this a downside.
--- Summary and a Bit About Linux ---
Some might say any computing environment
that ties you to a single vendor is risky.
In Apple's case I consider that poppycock,
both because Apple will be around for at
least as long as the average life of most
any PC (five years or more) and because
this can be more advantage than drawback.
OS X is nicely tailored to run on Apple
hardware, whereas Windows and Linux have
to content with a thousand different x86
configs. Buying into any complex system
forces choices. Macs offer fewer choices
in hardware and software, but enough for
most purposes, and it's very high-quality.
Given the idiosyncracies I have seen with
VPC7 I must qualify my otherwise unbridled
enthusiasm for OS X. Windows apps start
slower on VPC7, and some Windows apps may
have some trouble. To the degree that one
can use native OS X (whenever possible)
and otherwise deal with rare quirks in
in VPC7, I'd certainly recommend Macs.
I should note that SuSE Linux has many of
the same security/reliability advantages
of OS X and runs nicely on most modern x86
hardware. The main drawbacks of SuSE are
(a.) the user interface and many of the
free open-source apps are not as polished
as those included in or available for OS X,
(b.) running Windows on SuSE Linux demands
the purchase of VMWare or other extras,
whereas VPC7 is free for U-owned equipment.
I'd certainly choose SuSE Pro (about $80)
over most other Linux versions. It's very
complete, reliable, and works on a wide
variety of x86 hardware, including laptops.
That said, I'd choose OS X over Linux for
almost any end user because the interface
and apps are cleaner and easier to use.
Questions and comments welcome.