[Haskell-cafe] Re: Hackage on Linux
andrewcoppin at btinternet.com
Sat Aug 28 04:55:04 EDT 2010
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
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
> 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. ;-)
>> 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.
More information about the Haskell-Cafe