Erik de Castro Lopo wrote:
Andrew Coppin wrote:
Windows has more package management facilities than most people realise.
For example, go install Office 2007. In fact, just install Excel 2007,
not the whole thing. Windows Installer can automatically figure out that
you *do* need to install the Spell Checker (since Excel uses that), but
you do *not* need to install the Grammar Checker (since only Word and
PowerPoint use that, and you haven't selected to install those). Not
only does it decide what to install, but you can query it
Thats a specific installer for a specific program.
It is. But my point is, it's not the program installer itself that
provides all this functionallity. It's the Windows operating system. A
3rd party program can, for example, ask if component X of MS Office is
installed, and if so, where it's located. You can set things up so that
if some 3rd party needs to access a feature of MS Office that isn't
currently installed, it installs it (if the installation files are
cached; it used to ask for you to insert the install CD). For native
Windows stuff, there are ways to check what version of DirectX is
installed and update it if necessary; you don't have to write that code
yourself, it's provided by the OS. Just like under (say) Debian, you
don't have to implement apt-get yourself, it's provided for you.
About the only thing *not* provided is the ability to automatically
fetch the installer for whatever it is you need. And that's because
usually to obtain the installer, you need to *pay money* to whatever
company it is that *sells* it.
The whole problem with windows is that every 3rd party program is
responsible for its own installation and removal and is free to
do that in its own way. It also encourgaes monolithic installers,
installers that include everything.
Each application can of course install itself in its own way. For some,
that's as simple as unzipping an install image and putting it somewhere
convinient. For others, it means running an elaborate installation
program. But, the point I'm trying to get at is, there *is* a standard
installation system (which you can of course choose not to package your
application with), and if you use it, it gives you things like
dependency resolution and telling you what stuff is installed where and
so on.
I agree with your last point, however; not having a central location
where software can be obtained from *does* encourage monolithic
installers. The installer is essentially a mini repo that contains the
package and all its dependences; it then uses Windows to decide which
[if any] of those dependencies are already installed or else need to be
installed.
However, the software you are complaining about is mostly FOSS
software that had its genesis on Linux/Unix and assumes that
build dependencies can be resolved at compile time and that
install dependencies can be resolved at install time. Windows
of course fails these two assumptions completely.
On Linux, if I do, say, "cabal install zlib", it falls over and tells me
it can't find the zlib headers. So I go install them, rerun the command,
and it works. On Windows, I issue the same command and it falls over and
says that autoconf doesn't exist. It doesn't even *get* to the part
where it looks for header files!
Interestingly, even though everybody claims that it's "impossible" to
support C bindings on Windows, gtk2hs has managed it somehow. If you try
to built it, it complains that it can't find the GTK+ headers. Go
install those, add them to the search path, and suddenly it builds just
fine. No problems with it. Go figure...
Until something like apt-get becomes popular, widespread and
well supported, you are going to continue to feel pain.
As I say, gtk2hs builds just fine today. (The upstream packaging of the
Windows GTK+ port leaves a little to be desired, but that's not a
Haskell problem.) It's as trivial as unpacking a few zip files and
tweaking the search path.
hoping that Linux and Mac devs will fix windows problems
is not going to get you anywhere.
How about hoping that Linux and Mac devs are going to realise that
Windows doesn't have some of the problems that people claim it does?
Hmm, thinking about it... nah, that's not happening anytime soon either. ;-)
I
guess it depends on whether you think your students are going into
datacenter support (probably Unix) or desktop support or application
development (obviously all desktops are Windows).
Here's a funny thing. I know a large number of professional software
engineers and people who mix that with sys admin work. Only a tiny
fraction of those people write code for the windows platform. Do I
conclude from my data that most developers develop for Linux?
...which leads us back to my "I guess it depends" then?
My "obviously all desktops are Windows" was not meant to be entirely
serious. But it's not exactly a revelation to state that Windows has
much greater penetration in the desktop market than either Linux or
indeed Mac OS. Linux is much more popular now than it used to be (e.g.,
I can remember when you had to wear open-toed sandals and eat lentil
burgers in order to run Linux), but it's not yet anywhere near the level
of popularity of Windows.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
