[Haskell-cafe] Re: Hackage on Linux

[Andrew Coppin]

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.