> > To be sure we are NOT running with blinders on. > We > are very aware of the issues because it impacts us > in > more ways than you can imagine. Any approach we > take > has to address a larger scope. > > I guess, every reliable OS vendor has to.
Exactly and that is exactly why "reliable OS vendors" do not flip their software delivery structure arbitarily. It takes time to understand and figure out all the issues. >So, not > really something special and hearing the "backward > compatibility" excuses again and again starts to bore > me. > Well good engineering can be boring but the devil is aways in the details. Prototyping and one off's are always more fun. > > While a solution that > > addresses 100% would be nice, having a solution > that > > addresses 65% is not acceptable either. My gut > feel > > is that it better be close to 100. > > Yes, and wrt. packaging with a soft dep flag perhaps > one might reach it in time without giving up too > much. Yes, getting 100% is a honorable aim, but the > question is: Has one the power/capacity to reach it > _in time_? At least wrt. to know how I think, there > are no questions. But on the other part I have my > doubts... And again, how really needs 100%? I would > say, 95% of potential customser can live pretty good > with 95% or even 90%, if the distro gives them the > features and performance they want/expect. > > Sure. Right now one might still to tend to say, the > remaining 5% is currently our best customer, so we > keep the 100% strategy/comaptibility and live with > what the 5% spent for it. But this is IMHO a one way > street. But what about software/comunity in this > case? To the best of my remembrance NextStep was a > nice/innovative little? thing. But to expensive -> > "no" software <-> no market <-> to slow -> > AfterStep. > Or OS/2: to slow -> no user acceptance -> no software > -> and finally even the big companies (like the > financally strong banks) replaced it with windooze - > still listening ? ;-) > Or linux: cheap, runs on cheap machines, modern GUI, > "nothing" carved into stone aka is flexible <-> > modern software <-> big community. > At least this tells me, that something has changed > since the nineties: market penetration starts today > at the users desktop (SME) and may thus find its way > into the perhaps more profitable server market. Yes, > at the moment, Solaris is set in in the server > market, but wrt. the current state I have the > feeling, that at most 10 years are left ... > > > But then again how do we measure this ? > > User acceptance is the first thing, which comes into > my mind. > We are talking about pkging here. Can you elborate what you mean by user acceptance in terms of determing pkg dependency ? Or am I missing something. > Actually that's the problem, what I see here at the > university. Even Blade 1500S stations are very slow, > the software is outdated, so no wonder, why the > students choose to work with much faster/modern > Linux/Windooze boxes. Or faster AMD boxes (from Sun ;-) Again I am not sure how this relates to pkg dependency ? Let's for the sake of argument say that you can update the pkgs for GNOME. I don't believe you can guarantee that it will improve the performance. The performance issue may be a result of host of different things. On a different note, you do have a choice now with Sparc. Ubuntu has been ported to sparc. See Need to check if it supports Blade 1500s. But just a thought. Here's what the website says (www.ubuntu.com) The current Ubuntu release supports PC (Intel x86), 64-bit PC (AMD64), Sun UltraSPARC and T1 (Sun Fire T1000 and T2000), PowerPC (Apple iBook, Powerbook, G4 and G5) and OpenPower (Power5) architectures. > Yes, I might update the pools > to Sol10 and update the unbundled software, but after > working about 3 month with Sol10, I think, it isn't > really worth. We would still have the awefully slow > GNOME 2.6 and acceptance would be still below the > bottom line. So next year, when I probably get the > budget to HW update the pools (or better, the > remaining sparc stations), I'm probably forced to buy > cheap linux boxes, since nobody wants Solaris > anymore. > It's a great pity - 8 years ago (when I > left the university) exactly the opposite was reality > :( > > > Among the many issues > > that need to be addressed is backward > compatibility. > > la la la. Sorry! > > > For example, let's say we take a radical approach > > and go with a completely new packaging scheme, in > > Nevada. > > > How will this impact people who want to > > upgrade from Solaris 10 or Solaris 9. > > Who really cares? Its a completely new system, so one > has to bite once in the sour apple and has to make a > fresh install. Windows users do that all the time > (even when they do not upgrade to a new version ;-)). > So I think, it probably has not a big impact - might > be unusual, but probably not more. And if they see, > that they really get something new, modern, fast and > a companion DVD with a lot of "uncommon" software > they might need (of course in a little bit better > quality than the current one), small wounds will heal > very fast. BTW: Has somebody ever made a survey, who > really needs live upgrades and who actually does it? > I would guess, this is a big savings potential. > > > Until recently we supported upgrades from 3 > previous > > releases, which meant we had to support Solaris 8 > > too. I am not sure what kind of backward > > compatibility is required by Linux distros like > RHAT > > or Suse. > > Not sure, what your defintion of "backward > comaptibility" is. The common practice I see (some > small companies + LUG members/students), if there is > a new release, a fresh install is made and thus all > software runs as it should ... > > > The good news is that since there are other > > OpenSolaris distros, one can now experiment with > > various options. Nexenta for example uses the > > Debian format. > > Sun package tools are good, install software (at > least for home users/new comers) is bad. BTW: I still > prefer jumpstart as the main install method, so ... > > > And of course some of the feedback > > from such efforts and others (like you) will > > definitely help. > > And I deeply hope, before there are no users left, > which may take advantage of it ... > > Regards, > jens. I think you are conflating issues here. I was talking strictly about pkging stuff. Yes, one uses pkgs to deliver software but install and pkging/patching are separate problems. One needs to address both to solve the problem completely. The current interactive install experience in Solaris is seriously broken. No arguments. We are actively working on a project called Caiman. As a start please see the install_strategy paper at http://opensolaris.org/os/community/install/announcements/#2006-03-23_solaris_installation_strategy_review . Its a very thorough analysis of the problems with Solaris install and its short comings. Starting on page 12 you will see a list of requirements - there are 31!! We will be publishing an architecture document that addresses those requirements in the next couple of weeks. As to who cares about live upgrades ? I believe a lot of people do..if they truly understand what it buys them. People who have laptops. Imagine being able to upgrade, from one build to another and never having to worry about a full reinstall. I don't think you will argue that Apple understand UI really well. About 2 releases ago they introduced something called archieved update. This is something similar to Live Upgrade. You are correct when you say that a lot of current LUG users, do a clean install. But do they have a choice ? Why wouldn't someone want a method to fall back if the release/update that they installed had problems ? This message posted from opensolaris.org
