Hi Martin, * Martin Bochnig (martin at martux.org) wrote: > On Thu, May 28, 2009 at 7:48 AM, Rich Reynolds <rich at redstar-assoc.com> > wrote: > > Glenn Lagasse wrote: > >> > >> * Dave Miner (dminer at opensolaris.org) wrote: > >>> > >>> Personally, I don't get the enthusiasm that's been expressed for > >>> ?supporting this particular installation mode. ?I tend to believe that > >>> ?it's > >>> due to habit of long-time Solaris users who haven't had network ?package > >>> repo's; it was less inconvenient to have a pile of extra, mostly ?useless > >>> bits lying around and adding overhead to upgrades than to have ?to hunt > >>> up a > >>> DVD in the event that some of those bits were needed later ?on. ?I'd never > >>> want to do this with any Linux distro, either (and ?didn't, when I was > >>> using > >>> them a lot). > >> > >> That echoes my sentiments precisely (even the part about not doing this > >> on any Linux distro) for whatever it's worth. > >> > >> Cheers, > >> > > There is a large segment of the present SunOS user community for whom > > network package repo's are doable, but not with out a GREAT deal of work and > > GREATER gnashing of teeth... ? they have no connection to > > pkg.opensolaris.org or any other .org/.com/... domain. their standard > > requirement is that all the stuff show up on media that can be trusted to > > have come from the vendor. Now you know the population of which I speak, and > > the massive headaches they will have deploying... > > > > just a thought from an under represented user segment... > > > > rich > > > > > > BTW I have been install the whole wad since 3.2... > > > > In large 1000+ multiuser organizations like Universities it is a > common practice to install everything. Because everyone needs > something different. Even if just for curiosity.
Ok, in that type of environment, they aren't going to use a liveCD/DVD to do their installs. They'll use AI and network boot their clients to do automated installation rollouts. Just like they did in legacy Solaris using Jumpstart. > Or is Solaris targetting only handheld users in the future? > If so, then it would be a good idea to bring down minimum memory > requirements below the 1.5GB mark. Or at least to assign more swap by > default, if a low-mem system is detected. > I see a contradiction here: On one side (Sun's own bandwdith, > customer's installed "wad" sleeping on hdd) every importance is > directed in minimization and optimization. > On the other hand memory and cpu usage looks horrendously wasteful. > > But one should keep the balance, imo: Never has the price per GB (both > on hdd, as well as net bandwidth) been remotely as cheap, as today. > > > On the other side of the coin: What is more expensive to an organization: > > A) Developing an algorithm in months that allows them to find out > which exact set of packages they need (then install that selection > with IPS, which nicely resolves the further dependencies). I'd argue that such an effort isn't months. And that yes, customers do in fact install minimized environments in legacy Solaris installation rollouts. There are lots of reasons for this, the least of which being bandwidth concerns. > B) Installing [redistributable] from the then existing DVD and then > move forward with what they should primarily be interested in: Using > that software. Soon and quickly getting to that point! Without having > to learn any new concepts that require reading more than 1 page during > installation. > > Last year I applied for a job as UNIX admin at math.tu-berlin.de . > During the interview it came out that they were going to switch the > remaining few Solaris boxes to Linux FC. I started a small fight with > that clue-less "boss". And neither did I get the job, nor could I > convince that lady to move back to Solaris. She is probably still in > the mis-belief, that Solaris is "complicated, expensive and not > modern", shrug. > > What ever: That's the reality. Reality can be ignored. Or faced. > Do you think it would increase chances to convince folks like her that > switching to OpenSolaris saves costs and complexity, if you then tell > her "Well, first ... this is pkg, please read the manuals first ... > "? I'm not sure I understand what you're getting at here. Legacy Solaris shops are going to have to do some reading to adopt OpenSolaris/Solaris Next. There's no way around that. There's a ton of new technology and enhancements that you're not going to magically subsume into your consciousness without doing some reading. People didn't automatically know how to use ZFS and DTrace when they were introduced in Solaris 10. > > The Package-Manager GUI is a good answer, I agree. > But not for everybody out there. Anyway not during initial-installation time. > Network repos have their strength in keeping systems up-to-date while > offering high un-interrupted RAS (together with goodies like SMF, > fmstat, beadm, snapshots/rollbacks and time-slider and so on). > > But for initial installations (not follow-up-maintenance upgrades) > off-DVD installs are > > * fastest Do you have numbers to back this up? In all possible scenarios? Installing from USB stick is very much quicker than installing from our liveCD for instance. I'll bet that installing from a geographically close IPS mirror is going to be pretty darn fast as well. > * easiest I don't agree. How do you qualify easiest? > * your system does not necessarily be online (reliably online!) over > the whole period of installation. In India or China maybe you can go > to a friend, download the DVD and take it home. How do you accomplish > this with a Repo? You download the liveCD from your friend's house, go home, perform an initial install that gets you up and running and then when you feel that you need additional packages you go back to that same friend's house (with an offering of their favorite beverage) and download the packages you need. And your friend might even be happy that you only downloaded what you needed instead of gb's worth of things that you don't. Or, you download a 'repo-on-dvd' image and take that home with you. Cheers, -- Glenn
