-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://www.opensourcemac.org/ How many of these are available through MacPorts? Might be worth letting them know that using MacPorts can make their audiences life easier. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGXOPAjE2ksZfa4ZURAvmyAJ9v4dNTA3ufnb+5BrgN1UVikl4GBwCfQ6/i z2XAH8GoclZjmfh/Yee4raY= =hlHQ -----END PGP SIGNATURE-----
On 29-May-07, at 22:38 , paul beard wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
How many of these are available through MacPorts? Might be worth letting them know that using MacPorts can make their audiences life easier.
Given the target audience, and that these aren't pure unix solutions, I can't imagine how this would make their life easier. Different audiences, different solutions. I would be interested how you came to your conclusion. Andre
paul beard wrote:
How many of these are available through MacPorts? Might be worth letting them know that using MacPorts can make their audiences life easier.
Most of them contain an auto-updater (Sparkle [1]) which conflicts with MacPorts. Imagine an user installs such an Application through MacPorts and then the auto-updater installs a new version in the /Applications/MacPorts area. I don't think we got a way to handle this. If they offer a way to be build without auto-updater it would be ok to create Portfiles for them. Rainer [1] http://sparkle.artworkapp.com/
On May 30, 2007, at 8:35 AM, Andre-John Mas wrote:
Given the target audience, and that these aren't pure unix solutions, I can't imagine how this would make their life easier. Different audiences, different solutions. I would be interested how you came to your conclusion.
Um, these are open source software packages that, while they can be packaged, can also be built from source. It seemed there was some overlap and an opportunity to build the mindshare associated with MacPorts by explaining that many of those applications are available in an integrated package management system. I wasn't suggesting they were interchangeable, merely that MacPorts offered some of the same tools with a lot more useful stuff besides. The idea was to give people who might feel adventurous or who have experience with compiing ported applications a choice. Choice is good. And expanding MacPorts' base is better. I'm getting a sense that people who use double-clickable installers are somehow not "our sort of people." Goodness knows we can always use more snobbery ;-) -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem?
On 30-May-07, at 12:40 , paul beard wrote:
On May 30, 2007, at 8:35 AM, Andre-John Mas wrote:
Given the target audience, and that these aren't pure unix solutions, I can't imagine how this would make their life easier. Different audiences, different solutions. I would be interested how you came to your conclusion.
Um, these are open source software packages that, while they can be packaged, can also be built from source. It seemed there was some overlap and an opportunity to build the mindshare associated with MacPorts by explaining that many of those applications are available in an integrated package management system.
I wasn't suggesting they were interchangeable, merely that MacPorts offered some of the same tools with a lot more useful stuff besides. The idea was to give people who might feel adventurous or who have experience with compiing ported applications a choice. Choice is good. And expanding MacPorts' base is better.
I'm getting a sense that people who use double-clickable installers are somehow not "our sort of people." Goodness knows we can always use more snobbery ;-)
No snobbery intended. For me it was more that people who are used to drag and drop installs aren't necessarily going to want to play around with the command-line - if someone comes up with a simple to use and elegant GUI that just works, then I might reconsider my remarks. Something else MacPorts would need to support is the ability to move the application. I doubt /opt/local would be the right place for the applications. Even if they were in /Applications it is not necessarily the final resting place, since some people like to group application types together, for example /Application/Movie Viewers/ Would there be a way for MacPorts to support file references, rather than just file paths, so it could keep track where the application have been moved to? I know MacOS X offers the ability, but is this something we might consider adding to MacPorts? Andre
On May 30, 2007, at 9:40 AM, paul beard wrote:
I'm getting a sense that people who use double-clickable installers are somehow not "our sort of people." Goodness knows we can always use more snobbery ;-)
I wouldn't argue that at all. I would instead argue that MacPorts is simply not READY to serve people who use double-clickable installers. That has always been a design goal of MacPorts, but it's not there yet. It has a ways to go. It doesn't even know how many of its ports even build at a given time yet, much less have them all packaged up and ready to double click on. :-) - Jordan
On May 30, 2007, at 10:37 AM, Jordan K. Hubbard wrote:
I wouldn't argue that at all. I would instead argue that MacPorts is simply not READY to serve people who use double-clickable installers. That has always been a design goal of MacPorts, but it's not there yet. It has a ways to go. It doesn't even know how many of its ports even build at a given time yet, much less have them all packaged up and ready to double click on. :-)
True, the project has yet to come of age, but I still think a directory of open source/packages for OS X could mention MacPorts for those who do need a little more flexibility/are comfortable with the Terminal. -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem?
On 5/30/07 10:37 AM -0700, Jordan K. Hubbard wrote:
On May 30, 2007, at 9:40 AM, paul beard wrote:
I'm getting a sense that people who use double-clickable installers are somehow not "our sort of people." Goodness knows we can always use more snobbery ;-)
I wouldn't argue that at all. I would instead argue that MacPorts is simply not READY to serve people who use double-clickable installers. That has always been a design goal of MacPorts, but it's not there yet. It has a ways to go. It doesn't even know how many of its ports even build at a given time yet, much less have them all packaged up and ready to double click on. :-)
I use double-clickable installers and, though seemingly less and less, Macports via CLI. Some people MUST use double-clickable installers because they have little or no chance of doing even simple command invocation from a CLI, much less dealing with the manifold vagaries *nix ports. There is another notion that, though not necessarily, goes along with the double-clickable installer that is not part of the gestalt of Macports, IMHO. That is that the double-clickable installer contains all that's needed to install the package on it's target. I use a larger proportion of older equipment running older OSs than newer stuff using current issue OSs and have found port things that once worked, no longer do ... repeatedly. However, if I dredge up an old installer on an old machine with an old OS and double-click it, it still seems to get the job done as a rule. -- Walter M. Pawley <walt@wump.org> Wump Research & Company 676 River Bend Road, Roseburg, OR 97470 541-672-8975
Jordan K. Hubbard wrote:
On May 30, 2007, at 9:40 AM, paul beard wrote:
I'm getting a sense that people who use double-clickable installers are somehow not "our sort of people." Goodness knows we can always use more snobbery ;-)
I wouldn't argue that at all. I would instead argue that MacPorts is simply not READY to serve people who use double-clickable installers. That has always been a design goal of MacPorts, but it's not there yet. It has a ways to go. It doesn't even know how many of its ports even build at a given time yet, much less have them all packaged up and ready to double click on. :-)
I would agree with that. I would say that once you have a binary repository, and a very, very easy to use gui installer, then and only then, is it going to be ready for the average user. Normal people look at the command line like it's some sort of arcane magic. Normal people don't want to take half an hour to compile mozilla from source rather than taking 2 minutes to download it. If you were installing binaries, and if you had a nice gui, to handle not only installing the software but also to handle seamlessly keeping it up to date, then I think it would be a GREAT tool for your average user. Until then they are going to stick to installing via drag and drop .app folders.
On May 31, 2007, at 2:52 PM, Rick Gigger wrote:
If you were installing binaries, and if you had a nice gui, to handle not only installing the software but also to handle seamlessly keeping it up to date, then I think it would be a GREAT tool for your average user. Until then they are going to stick to installing via drag and drop .app folders.
Isn't this some of what Port Authority was doing? I haven't used it in a long time, but I thought it held out the promise of this kind of elegant simplicity. -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem?
Rick Gigger <rick@alpinenetworking.com> on Thursday, May 31, 2007 at 2:52 PM -0800 wrote:
I'm getting a sense that people who use double-clickable installers are somehow not "our sort of people." Goodness knows we can always use more snobbery ;-)
I wouldn't argue that at all. I would instead argue that MacPorts is simply not READY to serve people who use double-clickable installers. That has always been a design goal of MacPorts, but it's not there yet. It has a ways to go. It doesn't even know how many of its ports even build at a given time yet, much less have them all packaged up and ready to double click on. :-)
I would agree with that. I would say that once you have a binary repository, and a very, very easy to use gui installer, then and only then, is it going to be ready for the average user. Normal people look at the command line like it's some sort of arcane magic. Normal people don't want to take half an hour to compile mozilla from source rather than taking 2 minutes to download it.
If you were installing binaries, and if you had a nice gui, to handle not only installing the software but also to handle seamlessly keeping it up to date, then I think it would be a GREAT tool for your average user. Until then they are going to stick to installing via drag and drop .app folders.
Didn't Steve Jobs once say that the problem of people not being familiar with a keyboard would be "solved by biology"? I sometimes wonder if the pickup rate for Unix skills isn't increasing faster than our ability to provide an alternative for many of the utility type apps for which we have ports. No I'm not being a snob. Installing stuff is difficult and I'd like it as much as anyone, but I can't help but wonder sometimes. Mark
On May 31, 2007, at 5:40 PM, markd@macports.org wrote:
I sometimes wonder if the pickup rate for Unix skills isn't increasing faster than our ability to provide an alternative for many of the utility type apps for which we have ports.
Maybe, but the command line is never going to be an option for the average person. SR
On May 31, 2007, at 4:12 PM, Steven Rogers wrote:
Maybe, but the command line is never going to be an option for the average person.
Much as I hate generalizations like that, I see the truth in what you say. Perhaps the middle way will be some kind of gestural input system, more finely-nuanced that drag and drop but not as brutally repetitive as typing. -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem?
Steven Rogers <srogers1@austin.rr.com> on Thursday, May 31, 2007 at 4:12 PM -0800 wrote:
Maybe, but the command line is never going to be an option for the average person.
Sure, but probably 75% of the ports we have will never be *used* by the average person either, at least until the apps change in some future app usage revolution. That's what I think gets missed in most of our arguments over GUIs on this list. If we made them all installable with one-click right now, many people would get excited and install them and ask "What do I do now?" And then we'd have to point them to the command-line. Mark
Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> on Thursday, May 31, 2007 at 6:29 PM -0800 wrote:
FYI, Fink provides users with installs for Emacs.app etc.
I don't use emacs, but I assume that corresponds to our aqua/emacs-app We have a number of pure GUI apps like that too, but they are in the minority. Mark
On May 31, 2007, at 10:32 PM, markd@macports.org wrote:
I don't use emacs, but I assume that corresponds to our
aqua/emacs-app
If only life was so simple... Installing that package (as of about a month ago) gets one an ALPHA version of emacs. Starting it up generates a warning about possible data loss! If one wants a recent, relatively stable version of emacs that acts like a native Mac application the proper incantation is: sudo port install emacs-devel +carbon -Michael Dakin
--On 30 May 2007 10:37:37 -0700 "Jordan K. Hubbard" <jkh@brierdr.com> wrote:
On May 30, 2007, at 9:40 AM, paul beard wrote:
I'm getting a sense that people who use double-clickable installers are somehow not "our sort of people." Goodness knows we can always use more snobbery ;-)
I wouldn't argue that at all. I would instead argue that MacPorts is simply not READY to serve people who use double-clickable installers. That has always been a design goal of MacPorts, but it's not there yet. It has a ways to go. It doesn't even know how many of its ports even build at a given time yet, much less have them all packaged up and ready to double click on. :-)
- Jordan
No, but MacPorts might be used to install such software on machines managed by system admins who do see the advantage. For example, they might be University or company Sys Admins who manage a lot of machines. Or, I might prefer to use MacPorts to install such software for my Mum. SSH and MacPorts might be a better solution than ARD over a cheap broadband connection, for example. -- Ian Eiloart IT Services, University of Sussex x3148
Le 07-06-01 à 05:59, Ian Eiloart a écrit :
--On 30 May 2007 10:37:37 -0700 "Jordan K. Hubbard" <jkh@brierdr.com> wrote:
On May 30, 2007, at 9:40 AM, paul beard wrote:
I'm getting a sense that people who use double-clickable installers are somehow not "our sort of people." Goodness knows we can always use more snobbery ;-)
I wouldn't argue that at all. I would instead argue that MacPorts is simply not READY to serve people who use double-clickable installers. That has always been a design goal of MacPorts, but it's not there yet. It has a ways to go. It doesn't even know how many of its ports even build at a given time yet, much less have them all packaged up and ready to double click on. :-)
- Jordan
No, but MacPorts might be used to install such software on machines managed by system admins who do see the advantage. For example, they might be University or company Sys Admins who manage a lot of machines.
Or, I might prefer to use MacPorts to install such software for my Mum. SSH and MacPorts might be a better solution than ARD over a cheap broadband connection, for example.
The key, as pointed here, is the targetted audience. There is no good tool to rule them all. The real question is "for who and what should MacPorts be really good, and is it ?" I use MacPorts to install Gimp and would never use Gimp.app. I download Smultron and would never build it from source. And I'm not (too) schizoid. The other question is "what can be learned from that opensource mac site ?" I would answer that some editoral is always most welcome. How about a "feature app of the week" on the home page ? (but I won't do it) yves
participants (12)
-
Andre-John Mas
-
Ian Eiloart
-
Jean-Christophe Helary
-
Jordan K. Hubbard
-
markd＠macports.org
-
Michael Dakin
-
paul beard
-
Rainer Müller
-
Rick Gigger
-
Steven Rogers
-
Walt Pawley
-
Yves de Champlain