Article:		Creating Easy-to-Deploy Unix Applications for OS X
Subject:		Another Perspective
Date:		2003-11-02 21:17:13
From:		anonymous2
While the ideals behind the article are good ones for the most part I think it is very unrealistic to expect unix to blossom into a user friendly flower. Unix is not user friendly and I don't think a change on the behalf of developers alone would be enough to reverse that. Fink simplifies the installation of unix applications on Mac OS X. I think the number of unix apps mainstream mac users would or could benefit from are few. If an app is beyond command line complexity the interfaces be it TCL or whatever have you will be other worldly to mac users. I mean its a nice idea but I think its fairly impractical. Fink makes it about as easy as it will get with what is already out there and thats the real core of this problem. I have a hard time understanding why the author is encouraging new apps to be developed in a more friendly way as a solution to "the promise of thousands of unix apps". I mean - if we are only talking about new software - that kind of kills off the notion of anything legacy which is the core of this problem. So ... in a word ... fink. Even in the world of "real" Unix they use package managers - I can think of at least three off the top of my head. It is the standard way of dealing with most of these problems. While it doesn't address the issue of configuration I think tweaking a powerful unix app is part of the fun. I mean its even considerable as an issue separate from getting these thousands of unix apps running. You don't configure it unless it is already running, right? To that end some unix configuration files are a real #$#@$ but I don't think that will change any time soon. I find that to be the real merit of the article - encouragement to simplify configuration. If need be developers can provide a "basic" and "advanced" set of configuration files limiting the work that needs to be done while allowing the fine tuning that more complex unix configuration files tend to offer. /ramble

Showing messages 1 through 2 of 2.

• Another Perspective
  2003-11-03 03:20:00  roseman [Reply | View]
  
  
  Well, that's certainly one point of view, though not one I particularly agree with (and don't get me started on package managers!). The interesting challenge to me, and what the article was about, was how developers can retain the fantastics productivity benefits associated with some Unix developer tools, while still producing apps that are targeted at more mainstream users. Using primarily Unix technologies needn't restrict applications to the Unix elite audience. Fink and friends solve one problem, but not the problem mainstream users are interested in.
  
• Another Perspective
  2003-11-03 12:20:01  anonymous2 [Reply | View]
  
  
  Well I suppose my own perspective is skewed. I consider myself to be a mainstream user but I'm also a hobbyist programmer. I find the subject to be very interesting so I hope I wasn't insulting with my first comment.
  
  Fink coupled with Apple's X11 it makes harvesting the available applications easy. I guess I was confused about the point of the article because it mentions a missing "explosion" of unix apps on the mac platform.
  
  I agree that the development and deployment process could be simplified but I think there are some other things that need to happen before that can.
  
  Specifically look at the problem and suggested solution for dependencies. You suggested developers bundle the libs with the application. Specifically look at the problem and suggested solution for dependencies. You suggested developers bundle the libs with the application. I don't have much personal experience with embedding sqlite or any other technology in an app binary but in most Cocoa situations developers simply include the program in the app bundle. This isn't applicable to generic unix coding so including a subset is the best advice. I must say though when dealing with some of the more dependent libs on Unix it is difficult to separate the necessary functionality and I wonder how much this would add in terms of time to deployment.
  
  If we are to use subsets where should they be installed? I'm not posing this question as an obstacle. I am honestly curious about solutions. Where should developers install these library subsets. With many versions of the various libs out there some apps may rely upon features not found in certain versions of a given library so these would have to be installed to application dependent locations. This could develop a good deal of bloat.
  
  Might be an interesting project to develop a standard set of embed-able unix libs. Isn't that where a majority of the problem lies?
  
  Perspective Anonny