I disagreed with that. WarpIn is freeze and Paul Ratcliffe only fix bugs from time to time but he does not add new functionality.
Try contacting him asking for new features and let us know what he replies.
I didn't say that WarpIn is frozen. Paul will do new features, if the person asking can tell him exactly how to do it (in which case they should probably just do it, and present Paul with the finished product). If they can't, they will take a lot of abuse from Paul. It has happened more than once to me, and I have seen him do the same to others. I do know that Alex T. is working with him to get the Arca Noae package manager to work with WarpIn, but I haven't seen any results from that, yet.
Does Warpin need any new features, after all it does what it sets out to do - install a program. It is not a system maintenance tool and was never intended as such. RPM/YUM is not a system maintenance tool though people are trying to use it as such on eCS.
I don't entirely agree with that. WarpIn could easily be used as a maintenance tool. In fact Chuck M. did eventually start to use it with eCSMT, before he quit doing that. ECSMT was supposed to be a system maintenance tool, but eCS became pretty static, and eCSMT seems to be abandoned. RPM/YUM is also just a package installer, but it adds a few features that could be handy, if they would work consistently. Consistency has improved a lot, since Arca Noae rattled the chain, while trying to get a package manager to work with YUM, but I still don't have a good feeling about YUM.
That leaves the home/hobby user who, generally, knows what they are doing with their systems.
Unfortunately, that is not entirely true. My guess would be that less than 10% of those users actually know what they are doing with their systems. The other 90% are the ones who are targeted by things like WarpIn, and YUM. The idea is to make it easy for those who don't know, to be able to get it right (or close enough to work).
Not sure why you're suggesting Martin work on CUPS? Last I checked, he has no involvement, other than maybe testing some components...
Well, testing, and feedback, was what I meant. Better that than wasting countless hours chasing something that doesn't need to be fixed, is likely to cause problems, and isn't important anyway.
I just want to RPM/YUM to officially support "Moving unixroot tree away from the root directory" : ) , which is not going to happen according to bww
I still need to ask WHY? There is no point in doing that, and it isn't going to improve the way that OS/2 works, even if doing it doesn't cause problems. I will agree that RPM/YUM really should put things where OS/2 has always put them, but that makes the whole project much more difficult, and those who are doing it seem to want to simplify the whole thing so they don't need to do as much work. I can't blame them for that, but surely they could have found a better way.
What I would like to see, is a 64 bit OS/2 or, at least, better operation on multi core 64 bit processors (maybe something for the 4OS guys to think about).
I haven't seen any problems with multi core processors (up to 4 cores). A 64 bit OS/2 is one of those impossible dreams. Nobody, on earth, knows enough about the kernel to be able to do it. The best that might be possible, would be to drop in a 64 bit *NIX kernel, and tweak it to work with the rest of OS/2 (which also needs major updates to work in 64 bit mode). I am sure that the OS/4 guys think about it every day, but they seem to be circling hard, just trying to figure out what the kernel actually does.
I think there is some room to improve memory allocation, IF they can figure out how that works. I also think there is room to expand on what QSINIT does with memory above the 4 GB mark, and make that available to programs, outside of the normal OS/2 memory allocation scheme. In fact, the only time I ever see my own systems use more than 2 GB of memory, is when I start up virtual machines that allocate the memory. So, a 64 bit OS/2 is really not necessary. What is necessary, is to find a way around the per process memory limits, and part of that problem is over use of shared memory (DLLs), which limits the amount of private memory available. If private memory could be allocated from the space above 4GB, that part would be solved (until shared memory eats up the rest).
RPM/YUM is not a system maintenance tool though people are trying to use it as such on eCS.
In fact neither YUM, or WarpIn (or ZIP, or RAR, or ARJ, or...), is suitable for that sort of thing (but they can be made to work). On my own systems, I have experimented with using RSync to do system maintenance. I set up one system the way I want it, then use RSync to make the rest the same (including the FHS directory structure, if you like). You do need to account for files that might be in use, when the sync takes place (an alternate boot system solves that, if you need to go that far), and you need to account for those files that should be unique to each system (the RSync filters do that). Some planning is required, but once it is working, it is pretty easy to adapt it to new machines, new programs, etc. Updates could be done over the internet, if desired, or you can load up a USB disk drive (or stick), then do the updates from that. Of course, you need some control over the systems, so that somebody doesn't change something on you (but that is probably the case anyway). There are tools to do almost anything you want. Many of them are so complicated that users have no clue how to use them (especially those tools ported from *NIX), although once you work through the useless stuff, the rest is pretty easy (in most cases).