on Sun, Mar 06, 2005 at 11:28:22AM -0800, Michael Dean (michaelldean@xxxxxxxxxxxxx) wrote:
>
> Leon Brooks wrote:
>
> >On Saturday 05 March 2005 09:57, Michael Dean wrote:
> >
> >>My main point, which I probably didn't communicate well enough, is
> >>that the real battle is NOT at the device level, the operating system
> >>level, not even at the middleware level, but at the user application
> >>level. And here, the Linux/BSD GUI is still nothing more than a poor
> >>copy of other's.
> >>
> >GUI, singular?
> >
> >Trollie, go home. You obviously know squat about window managers.
Memo to Mr. Dean: '^-- ' is a signature delimiter. Don't include it
above your reply block.
You should also be aware that your _own_ content is *NOT* prefixed with
'>' characters (those indicate quoted text) within your own post. For
more on general email conventions, I'd recommend:
"Email Quoting" from the Jargon File.
http://www.catb.org/~esr/jargon/html/Email-Quotes.html
> I am presenting concepts, but Leon, you are fast to judge and fast to
> label, but you can't deal with concepts, especially if they conflict
> with your ideological stance. A sure sign of an inflexible personality..
Ironic entertainment value noted.
> We all know there is a proliferation of windows managers in the Linux
> world, most with some unique functionality, but as a group, still NRFPT
> on the desktop of average users, teachers intent on teaching content,
> and students mastering content. Perhaps for a programmer, this
> proliferation is good, because, after all, the more freedom we have to
> choose, the better.
I noted some years ago that the concept of the "office suite", as in: a
bundle of applications sold as a bundled unit, was effectively dead.
The concept was born of an economic imperative: by selling four apps
for the cost of one and a half, the standalone competitive market for
the three apps a given customer wasn't specifically interested in, fell
markedly. It was a strategy initially adopted by Microsoft to drive
Lotus out of the market.
Interoperability is another matter entirely, and really needn't require
apps be of a single suite, but that inter-application communications
standars. Which, incidentally, GNOME and KDE are providing in a
generalizable sense (though I _still_ think OLE type stuff is a horrible
hack). While support costs for multiple alternatives are a slight
concern, there's no reason a system cannot be provided with multiple
offerings (browsers, word processors, databases, etc.), within reason.
Too, this gives a competitive marketplace of ideas in which different
concepts can be tried and tested against one another.
The IT department could make a persuasive argument that installing both
the Microsoft and Ami suites was cost-prohibitive. The same doesn't
hold for OOo vs. KOffice vs. Abiword/Gnumeric.
Which has what to do with window managers?
Back in the day, one of the neat things I picked up about my university
shell account was that it was trivial to migrate my personal
customizations from one system or account to the next, by copying my
dotfiles and personal scripts into the new account. Later it turned out
that window manager configs are similarly portable. And while I try to
avoid gratuitious customizations, there's usage and finger-habits I've
picked up over the years which are now drilled into me. Working without
them is an exercise in constant minor frustrations. As it turns out,
my current desktop environment is, in my two decades' tech experience,
the one I've used for the longest period of time. I'm no longer forced
to change environments by OS upgrades or even by switching between
vendors. While I've made incremental modifications over the years, the
base is now very stable. Comforting, that.
For support needs, it is useful to have a baseline interface. However
the presence of a useful and consistent ecommandline also means that
it's possible to address and fix many issues via scripts rather than
some arcane (and unrepeatable) set of menu navigations.
> Well, from the perspective of actual users, not the perspective of
> programmers, that is BAD! Users don't want to master a dozen ways of
> doing things, they even resist mastering one!
...but having mastered -- or at least established a small corner of
light within -- one, there's a value in knowing that the investment has
long-term persistance.
> For instance, lets take the field of statistical analysis software.
> SPSS has been adopted in undergraduate classes, but to actually get the
> work out in corporate America, it is SAS all the way. SAS is the
> largest private software company, and is revered for its treatment of
> employees. Go on any job board, look in any newspaper job classifieds,
> rarely will you find any statistical skill required other than SAS.
Oddly enough, it turns out that I've got some experience in this area.
While SAS is widely used, it's now under assault on several fronts:
- In the legacy MS Windows world, MS SQL Server + Crystal Reports is
an increasingly significant competitor. Any old SAS hand will tell
you the capabilities are markedly different....but often the
alternative is _sufficient_ (or perceived as same), which is what
matters. Craigslist currently lists 85 SAS postings, and 58 for
crystal. Sometimes these are combined requirements, hrm, only one
of the above.
- SAS have been losing ground for much of the past five years on "Open
Platforms" (Unix & GNU/Linux), while increasing both legacy MS
Windows and mainframe as a percentage of total sales. This is
probably due to a number of factors, including SI's emphasis on
F-500 accounts, F-500 accounts emphasis on legacy MS Windows, and
the increasing cost and feature competitiveness of alternatives
available on Unix and GNU/Linux.
- SAS is expensive for individual contractors/consultants. Pricing
for my GNU/Linux desktop would be ~$6k. Annually. That's not
change I've got lying around, and the work, frankly, doesn't justify
it. SI are attempting to address this with "lite" versions (with
correspondingly restrictive limitations on capabilities), but seem
to have themselves in a neat little Christensian bind.
> There is also a nifty open source program call VisTa, which attaches to
> Excel.
Pains me to say it, but there's a hell of a lot of data analysis which
happens on spreadsheets. Of course, much of it's buggy as hell (and
some isn't). There's also scaling problems. But it's there.
> There is also the S language and its open source analog R.
S is pretty much dead, though it may still be developed on some
proprietary Unices. Its proprietary cousing, S-Plus, has a steady
following in some circles, largely among statisticians. R is making a
stealthy but steady progress in the field, I'd say it's about 5-8 years
behind where GNU/Linux is now, within its respective circles. Much of
the core S-Plus community (E.g.: Venables & Ripley, et al) are now
active R developers. R is used _heavily_ in academia, in academic-based
pharmaceuticals research, and among several healthcare and financial
firms.
> And there is a dozen or so other propritary packages as well. But ONE
> takes the lion's share of users. Why? Because SAS has put together all
> the crucial pieces --especially training, support, quality.
Um. "Marketing".
Not that SAS can market its way out of a paper bag, but as the old joke
about the two hikers and the bear goes, you only have to outrun the
other hiker.
I've looked into what's required for data analysis and reporting. For
the most part, it's:
- A data language. In SAS, the DATA Step. Elsewhere: Perl, awk,
Python.
- A procedural control language. In SAS, 'Macro'. Elsewhere: Perl,
Python, bash...
- A statistical language/facility. In SAS, SAS/STAT. Elsewhere: R,
specialized libraries in other languages.
- Graphics. In SAS: SAS/GRAPH. Elsewhere: R, gnuplot, various
plotting libs in Perl, Python.
- A report genererating capability. In SAS: PROC REPORT and ODS.
Elsewhere, HTML, Postscript, and PDF generator capbilities.
- A data store. Need not be a relational database (SAS's own dataset
format isn't), but should offer at least a rectangular data format.
There's really not much intrinsic to SAS which exceeds the combined
capabilities of tools used elsewhere. In the specific case of Unix and
GNU/Linux, there are a lot of shops which have implemented what might
have been a "SAS job" using existing shell and scripting tools.
> My point is that a new process must take place before schools, other
> than computer science departments of universities, will take Open Source
> seriously.
IME: people will see it when they believe it. Oh, and if you can back
it up with money, they'll be even more interested. That said, some
useful points:
> - First, conduct a systematic and thorough needs assessment.
Advisable in any event.
> - Second, document the school/admin processes -- i.e. how they do
> things in the real world now.
First: this presumes you're replacing existing school management
software, etc. Personally I'd look at a low-threshold, felxible
requirements project which can demonstrate cost, stability,
functionality, and flexibility. IBM's Redbook series on GNU/Linux
migrations suggests some useful principles, among which, incremental
approaches are key.
> - Third, assist the school in formulating their goals, objectives --
> their purpose related to automation.
Sure.
> - Fourth, Calculate and Demonstrate a ROI for the school. DO NOT use
> Total Cost of Ownership(TCO). Microsoft chose that on purpose, but
> it is only part of the necessary equation.
Again: any computed value is going to have less persuasive power than
actual experience. I'd say: be prepared to substantiate your benefits,
particularly quantifiable financial benefits. Don't use these as an
initial selling point. It's *much* harder to argue against a box full
of receipts, particularly when the box is all but empty, than a study.
> - Fourth, search the world over for single BEST Practice applications
> software that meets their purpose, as well as the BEST practice
> middleware software underlying these best practice software
> applications..
Sure: Picking appropriate solutions is key...
> Schools are tired of being picked clean by specialized proprietary
> software. $25,000 for a library management system is outrageous,
> when Greenstone is available. Start at the highest level of
> abstraction -- the user software -- and work down the stack.
Scaling the approach here matters too. I'd not be looking at high-level
management software until a year or more into a project. Start with the
easy stuff: standalone labs, hotdesk systems. Move to file/print and
Internet-facing servers. Look at value-add services: spam, virus, and
web filtering. Complex, integrated systems such as school management,
state reporting requirements (a *huge* concern), library management,
attendence, and financial systems, call for:
- Careful planning.
- A high level of confidence on both school and vendor sides. Buy-in
on all sides.
- Phased implementation with strong emphasis on zero downtime
implemnetation.
You're going to have a far better success rate with this if:
- You've demonstrated GNU/Linux / FLOSS capabilities in other areas.
- You've demonstrated your own level of expertise -- including your
own assessment of when to call in outside help -- on earlier
projects.
- That existing GNU/Linux / FLOSS projects are providing increased
functionality and benefits at lower cost, while legacy MS Windows
systems continue to require hand-holding, special assistance, and
expensive vendor support.
> - Fifth, Cover ALL the OSI layers. At the hardware level, for
> instance, Linux suffers from lack of device drivers for some anti
> open source video boards, 3com encryption boards where they
> partnered with Microsoft, etc. Also, over the last few years a
> majority of schools in our area bought either Mac G3's
Um. G3s are, like, eight years old. Well supported under most PPC
GNU/Linux distros (including, um, Ub<RandVowel>tu and Debian). Apple
supersceded the G3 with the G4 in 2000, and is currently selling
G5-based kit.
> or Dell boxes. Dell's BIOS for their laptops and desktops are
> VERY similar, and generalized distributions like Knoppix and
> Gnoppix (your little KDE and Gnome WM's) just don't work without
> lots of manual fiddling.
Not in my experience. Got specifics?
Mind, Compaq, back in the day, with its specialized partition-on-disk,
back in the day, was a bit of a curve.
That said: yes, hardware compatibility is a concern.
Oh, I'd avoid Broadcom like the plague. GPL-violators *and* unsupported
to boot.
> Try it and see. So work on this layer is needed. Apple G3's can
> easily accomodate a specialized open source distribution. And so
> on up the abstraction ladder. Whether at the operating system
> layer I would choose Linux kernel, MACH kernel (as Jobs did a
> decade or more ago) or OpenBSD would be addressed in terms of which
> best meets the needs of the client school, not which is hyped the
> greatest as commercial products in the marketplace.
Debian-supported arches:
Intel x86/IA-32/i386, Motorola 68k/m68k, Sun SPARC/sparc, Alpha,
Motorola/IBM PowerPC/powerpc, ARM, MIPS/mipsel, HP PA-RISC/hppa,
IA-64/ia64.
As yet unreleased are AMD64 and Hitachi SuperH/sh, available on
development branch..
There are also ports to non-Linux kernels: Debian
GNU/Hurd/hurd-i386, Debian GNU/NetBSD netbsd-i386/netbsd-alpha,
Debian GNU/kFreeBSD / kfreebsd-gnu.
> - Sixth, sidestep the perceived and actual installation nightmares by
> creating a bootable reference CD with all the stuff on it. If the
> school's name is St. Mary's Elementary School, then the name of the
> distribtion is St. Mary's Elementary School Systems Software, or
> something like that -- the ultimate fork!
I'd split this in two parts:
- Chroot install methods based on an existing bootable distro (e.g.:
Knoppix) bypass most of the issues of getting the _installer_ itself
running on a given piece of hardware.
- Automated installers (Kickstart, FAI) are useful where there's
sufficient standardization, and quantity, of kit to allow for
process automation. Requires a bit of up-front work.
- Debian allows specification of package lists (or alternatively
virtual packages) for quick builds of preferred configurations.
Process:
- Configure system with desired packages.
- Run: 'dpkg --get-selections > packages.txt' You can trim any
^lib' entries from same, these can (and generally are) specified
by dependencies anyway.
- On to-be-built box:
# dpkg --get-selections < packages.txt; apt-get dselect-update
Of course, you can pre-create such lists and host them someplace for
fetching. Or they can be provided as virtual packages: a package
which doesn't install anything on its own account, but has
dependencies on those packages you'd like to be installed. This,
incidentally, is a pretty good description of Progeny Linux's
current business model.
The package list can be as complete or partial as you like. If you
only care about OpenOffice.org and TuxPaint, just mention their
respective packages, and any other deps will be carried along.
While it's possible to "build" a custom distro, that's likely overkill.
Of course, there's nothing to keep you from branding your specific
Debian package collection as specific to a site. One school of thought
says every given Debian install is its own custom distro.
> - Seventh, devise, staff and guarantee training, upgrades, service and
> support through your own organizationfor years to come. This is a
> legitimate profit center! Cut and run just does not cut it in the
> schools.
Profit-center and education are somewhat orthogonal.
I'd emphasize the self-sustainability of the initiative (kids and staff
could pick up quickly, the initiative could propogate to other local
gov't operations). If you're looking for sustainability, you're going
to need a multi-district base, and had best plan for it. And spin-off
benefits (local consulting, etc.) should be part of your own business
model mix.
Peace.
--
Karsten M. Self <kmself@xxxxxxxxxxxxx> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Microsoft Trustworthy Computing:
http://www.aaxnet.com/editor/edit033.html
Attachment:
signature.asc
Description: Digital signature