On Fri, 01 Apr 2011 21:36:55 -0700, Chris Telting <christopher...@telting.org> wrote: > On 04/01/2011 17:51, Polytropon wrote: > > On Fri, 01 Apr 2011 16:58:04 -0700, Chris > > Telting<christopher...@telting.org> wrote: > >> Just in a thoughtful mood and thought I'd to the question to the cloud. > > Oh the joy of cloud computing, erm... discussion. :-) > Wasn't that the a subplot of the hitch hikers guide? That the sum of > human consciousness is just a cloud computer? New term, old idea.
Basically, yes. The computer IS a(nother) world. > What I'm saying I'd like to see is minimal installs. If you need a > feature like for instance LDAP or SQL then you need to install that > port. Need another feature? Install yet another port. I would like that, too - modularity on the basis of precompiled packages. The problem would be the integration of features on runtime base, as you correctly mentioned. Metaports or metapackages could be used to define common configurations, e. g. "mplayer + mencoder with OSD fonts and all the codecs" or "OpenOffice with german localization, no KDE, no Gnome, no CUPS, but with dictionaries". That would be very nice to have. > The program > should detect that new programs/libraries are available or at a minimum > enable them though uncommenting a line in a conf file. I would say config file (maybe with good defaults) would be a good approach. I'm somewhat suspicious about all the autodetect magic, because in worst case, it just doesn't work, or is unpredictable. > And that's the mess I don't like. It's like the six degrees of > separation rule. Installing one application sometimes means installing > 100 other ports/packages with features the average user has no need or > interest in yet. I'm just saying we should have to need to > install/compile all those packages when we don't need them and we should > have to need to recompile ports just to add a new capability. The difference is "we need" vs. "the program needs". Some requirements are obvious (e. g. a Gtk program needs Gtk libraries), but others are debatable (e. g. the Gtk "File Open..." dialog defaults to incorporating SAMBA libraries, but if you're not going to use that, _you_ will have no use for them). > Well I decided I wanted to try to setup pulseaudio as a network sound > server on a headless computer and it pulled in X. Yes, that's a good example. Others have already mentioned that certain typical server functionality also may incorporate X or at least some of its components - on a server that doesn't have a GPU and run any X functionality. > Sure I could > recompile just for that one computer. But that isn't elegant. The > storage space doesn't matter. It's just the most used argument. :-) > What annoys me is the installation time > and the longer compile time as well as to some extent downing time. Well, that's worth mentioning, but the reply would be: "You have two systems in parallel, while one installs, the other one runs." :-) But I see your point. > The point would be that the programs wouldn't have those features > enabled by default, you have to configure them or the program can > auto-detect. So THAT would be understandable - config file is often better, or maybe a hierarchical desision: if config file is present, use it; if not, try to autodetect. > If it worked like like would like then you wouldn't be able to play > those files unless you downloaded another package or compiled the ports > for the mp3 library. Same as it works on windows. Don't have a codec.. > then you need to install one... As I mentioned above, a "typical use" or "full-featured" metaport or metapackage would be good; just imagine you could "pkg_add -r mplayer-full" and it would install ALL the codecs, as well as the mencoder part, without any further questions or interactions. On the other hand, the "simple" default port would install with minimal requirements (in regards to dependencies), which could also be very useful in certain cases, especially when the government wants it that way. :-) > See above. What I want to see is minimal installs with all features > being usable once you install the optional components. And run time > detection for programs shouldn't be all that difficult or computation > intensive. The program would just consult pkg_info or another similar > but faster database (and maybe somewhat platform independent) of what's > installed on the system. Understood and seconded: It sounds like an interesting approach. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
