On 05 Jan 2005 23:19:39 -0800, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Bengt Richter) writes: >> What do you think of automated secure importing/installing from a >> remote server? You know, you try to import something and it imports >> a stub that was included as a battery-place-holder and that has >> basic help info and will give you reasonable options in directing >> the installation of the full thing (or subset you are interested in). > >You mean for Python modules, in ordinary operation? I'd hate that. >For things like apt-get, used for installing nonstandard programs or >getting security updates, I guess it's about as good as one can hope >for. The user has to activate it explicitly though. I definitely >don't want my computer opening internet connections unless I >specifically ask it to. Doing otherwise is almost spyware. I agree 1000% !! Importing a stub should get you an imported stub that prints info as it imports, so you know its not functional. And just gives you the options to type help(themodule) or if you know you want to go ahead, themodule.install() -- and nothing would touch the internet until you gave a final "yes" to an "Are you sure" at the end of a what-will-happen-if-you-say-yes summary. I didn't mean any activity that you don't control. Just activity that you can control easily. > >This may sound a little extreme but my distribution philosophy is I'd >like to get closer to an environment where users normally never >install any software of any type, ever. Microsoft cornered the OS >market cornered by acheiving something pretty close to this: they >deliver Windows with no installation needed. When people buy new >computers, Windows is already on the hard drive, so the user just >turns the computer on and Windows is there. It makes a lot of sense for a "core" plus a delivered specific application base, but IMO if you try to cover the world with a monolith you will inevitably still have the problem of getting the latest version of particular packages for bug fixes or enhancements. The more you have in your giant collection the more that will be true. > >Fedora Core (what I'm running now) isn't shipped that way by any >computer makers that I know of, but it makes up for it by having lots >of applications included. So I buy a new computer, put in the >bootable Fedora DVD-ROM, and sit back for half an hour while a >one-time installation runs. That's about as close as I can get to >just turning on the new computer and having Fedora already there. > >> I don't see why every gee whiz thing has to be on your hard disk >> from the first. And for those that want a big grabbag, the stubs >> ought to be designed to to be runnable from a configured script, so >> you can turn it loose and see what's up IRL. > >If I have a 400 gig hard drive, I don't see why I need 99.99% of it >empty instead of 99.0% after I do my OS install. I don't want to >hassle over downloading stuff for hours or days at a time, or about >what components depend on other components, if the distro can just >include it. I just tried to install a Python program that uses >wxPython, except that meant I had to download both wxPython and >wxWidgets, and the installations failed because of some version >mismatch between the current wxWidgets distro and the version of GTK >included with FC3. I spent an hour or so messing with it and then >said screw it and gave up on the GUI part of that program. I'm more >technical than most users (I'm a programmer) yet this installation >stuff is too much hassle even for me. So I'd really rather that all >that stuff be pre-configured. There are several parts to those frustrations. But you are presuming that they would have been solved for you and put on a DVD with all dependency problems resolved. Ok, let's assume that. In that case, an installation stub module could just as well have the solution built into it as to what versions etc are needed to make the module work. With a large collection, you may need several versions of some support libs. To bring a large collection into version-alignment ISTM you need a version freeze across too many libraries of different kinds with different development schedules and resources to make it reliable. So you're still going to need the ability to add updates and new modules and more. I'd rather see effort going into making that process simple and reliable (and fully controlled by the user -- i.e. no unauthorized hidden internet activity!!) than to solve the same version problems for some mega DVD make file where you don't have the script and config info in a concise single-problem stub form, and can't ask here for help finding an updated stub. It's a matter of being able to limit the problem you need to solve when something particular doesn't work. When your wxPython-using program didn't work, wouldn't it have been nice to have downloaded a standard stub program (with older stub versions still available if you have an older system) and have it tell you what was missing that it needed before you decided to let it continue and get those things? Or choose not to? With broadband most apps will be ready before you can make fresh coffee, or maybe watch the Simpsons. Otherwise what? Send for a new DVD? Yes, core stuff + plenty of compatible goodies in a distro is a good idea, but problems are inevitable, and IMO it's more important to have a standard reliable way to solve problems than to have them "solved" on periodic monoliths DVDs that can't ever be problem free. > >If a system has N downloadable components that are supposedly >independent, there are 2**N combinations of them that anyone might >have installed. In reality the indepdence is never that complete, so >something can easily go wrong if you pick a combination that hasn't >been tested and debugged by someone, and there's no way to test more >than a few of the possibilities. So I'd rather that all N components >already be included with the OS so that the combination will have been >tested by the distro maintainers before the end user has to deal with You are asking a lot from these distro maintainers if you expect recent versions of everything, and for them to watch for new stuff to evaluate and include after researching compatibility problems. They aren't in the best position to do that. The author/s of the new stuff is/are. And if such authors had a standard stub module they could prepare, then distros could include those, and you would find version updates for those rather than trying to solve the integration problems yourself. And if there were still bugs, a new version would likely be posted here after some discussion. And then everyone could have an easy download of the new stub, and be able to go for coffee. I think if python.org had a trusted-software registry that could be a flat CSV text file of names, versions, urls, sizes, and md5 digests and maybe some trust level, then the stubs could access that for a standard way of finding components. Or course for a DVD distro, stubs could access the DVD rather than the internet for things at the DVD's version level. I realize this problem has been "solved" with various RPM and app-loading methods, but I think python could wrap its solution nicely. I don't think distutils and setup.py is easy enough to create (at least I have been somewhat frustrated in using it effectively), though it deals with a lot of what has to be done. >it. Hard drives and distro media (DVD) are big enough now that it's >quite reasonable for distros to include just about everything that >most users could want. Agreed for some "core" set. How shall we define what belongs in the "core?" ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
