On Sat, Sep 8, 2012 at 2:50 AM, Shawn Walker <[email protected]> wrote: > On 09/07/12 17:04, Philip Brown wrote: >> >> So far, I get the impression that all IPS related stuff is in python. >> but I guess I should ask, before getting TOO deep in code... are there >> any non-python (Ideally, simple C) libraries, for doing things like >> parsing repo catalog files and other repo-ness ? > > > Not at this time. > > -Shawn
That's the main issue with IPS and also with Sliminstall/Caiman. But especially with IPS, since pkg does a 1000 times heavier workload, than textinstall, gui-install and distro_const together. For the caiman consolidation using an interpreted language may even make sense. But for IPS it was the biggest wrong decision of its history and is its major flaw of its implementation. After a steep learning curve I even applaude to most of IPS's concepts. But the main question remains: Why not C??? On a side note: It is not just about wasted resources such as up to (what was the highest I saw?) 500MB, 600MB or even 700MB during "Creating Plan" as part of some meta installations . I appreciate that you have worked on improving these numbers, and that your code I'm working with is 2 years old. Running pkgdepend also needs endless amounts of cpu cycles and memory, there I repeatedly witnessed 680MB while resolving deps for consolidations such as XNV. But you can work and fix and improve: It is per definition _never_ going to be as quick and (indeed!) slim, as a C program doing the same or better job. On a funny side note: Yes, the openness of Caiman has found an end with its integration into OS/Net, just a week ago. And this is another sad step towards shittily breaking your own word. But although I rarely posted to caiman-discuss, I used to be a vibrant reader of what they had to write about their code. I checked- and tried out over 30 distinct versions of slim_install (on sun4u and sun4v). And I would like to thank the Caiman team for their work. But let's come to the point: It appears that I at home wasn't the only one, who didn't get their python backends to function properly (and to detect installation target disks) on a single of my 26 different SPARC platforms, with its latest addition, a V490 Quad 1.5GHz USIV and 32GB. And as you may recall, (snv_133/) snv_134 was the only CD.iso based version of Caiman on SPARC that actually shipped as OpenSolaris. It was that infamous OpenSolaris 2010.03, that was promised to ship, was not cancelled, but never was brought to market. Nevertheless, at least we could download its dev version from genunix.org. And: Interestingly, if you analyse the Caiman/slim_install bits a bit closer, you find, that they got textinstall to detect disks _only_, by having _disabled_ the build of some backends written in Python. If memory serves, it was not libdiskmgt alone, but at least one further lib. The C libs with these names had been developed behind closed doors more than 10 years ago. And they functioned well and did not waste a single resource. One was able to install and run Solaris 8/9/10FCS on machines with as little as 128MB or sometimes 64MB of memory. The CPU's didn't get hogged like now (although it were humble 200MHz processors or even 75MHz). NOW Sun, then Oracle pay millions to the developers in order to re-implement everything in Python. It is a waste not only of your customers' resources, but also of your very own (cpu/memory/engineers). But what did I say: Yes, the C libs from /usr/snadm/lib, were efficient, humble, versatile and STABLE. They just worked and did so well. That did its part in contributing to Solaris' popularity and widespread adoption. The Python reimplementation? If it works, then it is unbelievably wasteful and takes forever. But back the the SPARC snv_134 example: It didn't work ___at all___. And for this reason even Sun/Oracle themselves disabled the new implementation and linked the frontend C-interface against the old 10 years old C-libs. And then it suddenly functions on SPARC and snv_134 textinstall detects disks! For which reason so much wastefullness on all corners? Why not C? p.s. If you don't believe what I say, you don't even need access to a SPARC system. It is enough to check out slim_install's hg, looks for the in134 version hgtag and verify with your own eyes. Thank you guys for your code that you have thrown over the wall year over year. I don't back a few of your design decisions, but I don't regret it for myself, but rather for Solaris' success. So many millions of engineering hours could have spent easily as for an implementation of IPS in C, in the first place. Or do you think, the more resources your software consumes (or wastes), the higher your customer's demand for buying newer hardware from you? No, many will simply migrate to Lintel ..., or have done that already. That's what makes me sad :( Sorry for my criticism, but that stuff bugs me for years. It needed to be said. Regards and good luck, Martin _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
