On 6/4/07, Richard Elling <Richard.Elling at sun.com> wrote: > perl is the poster child... see below... > > Brian Gupta wrote: > > On 6/3/07, *Richard Elling* <Richard.Elling at sun.com > > <mailto:Richard.Elling at sun.com>> wrote: > > > > Brian Gupta wrote: > > > Joseph, > > > > > > I have made an effort to incorporate your comments into a new list. > > > > > > Primary Drivers: > > > ---------------------- > > > 1) There is a desire for a minimal/core OpenSolaris distro, that > > other > > > distro packagers can leverage to create their own distros. Building a > > > distro from this core *may*, in the future, allow other distros > > to also > > > be hosted at OpenSolaris.org. This OS core must, for the sake of > > > practicality, allow layers to be added on top to get to Nevada. > > > > I think this is the wrong model. If you presume that layers can be > > built > > upon each other to arrive at a end application, then you risk > > missing the > > application's requirements. In truth, application requirements should > > drive the distro, but the interdependencies are often unknown, and > > perhaps > > unknowable. Perhaps this is the problem you are trying to solve? > > Or are you just confusing modular with layered? > > > > > > I suppose I do mean modular. In particular I an referring to the ON > > consolidation. As I understand, the whole of ON is required to build a > > distro today. This seems odd to an outsider like myself, because Perl is > > in ON. Although there is talk of moving Perl outside of ON, it seems > > unlikely as other components within ON that rely on Perl. Saying for a > > moment that I am a distro builder. What if the driver for my distro > > doesn't need Perl, how do I go about removing it? (I am probably > > completely missing something simple, please forgive). Also when you say > > that application requirements should drive the distro, I think it's > > pretty clear, that we are talking about multiple drivers, that include, > > but are not limited to application requirements. > > [ignore the history that sys admins used to claim that they would not install > Solaris because it didn't include perl]
Well, I think what sysadmins wanted was official support for Perl so that they could write scripts in Perl, and know that it was a stable method. (Vs. sh scripting). There was no need to include this in ON. > kstat is written in perl and is part of the Extended System Utilities package > which also includes awk, compress, sort, and friends. So if you did a simple > dependency graph, it is likely that a system administrator would want awk, > therefore requiring perl. This is just one example of how interdependent > complexity is a real problem and why thinking of software in layers will > cause trouble. Ideally the minimum would include a kernel, and nothing else. Obviously this is not particularly usable, so there should be an easy option to add modules and the busybox shell that is currently being developed within the opensolaris community. > > > 2) Currently their is no Open development platform. The only allowed > > > development platform is, a closed source, proprietary platform: Sun > > > Solaris (Express). Ideally guardianship for this development platform > > > should be moved into the community. (Yes this seems in opposition to > > > bullet #1, but keep reading) This is a "Free Speech" issue, which > > not > > > everyone cares about, but it is an important facet of the open source > > > movement. (After all it's not FreeSolaris.org). In addition by not > > > prioritizing this the status quo is likely to continue for some > > time. > > > (IE: Why fix "what isn't broken"? We need to put out a slightly > > impaired > > > totally open source distro. If the missing closed source > > functionality > > > turns out to be important, open source replacements are going to > > be made. > > > > This doesn't make sense to me. I kinda like NVidia (and other) > > products, > > which will likely be closed source for a very, very long time. Why > > would > > we handicap Solaris by not having NVidia support? OTOH, if the > > approach > > is to encourage open source, then that is a different task, and one that > > seems to be already in progress. At the end of the day, consumers want > > something that works, and limited resources may be best spent making > > things > > work. > > > > > > Well, for one, Article Two of the OpenSolaris.org constitution expressly > > forbids this. This is why I had another bullet that talked about > > developing a standard methodology, that all distros could leverage, for > > downloading and installing *optional* closed source packages, as part of > > the install process. > > > > As for "only allowed development platform," I've never known those > > words > > to have any affect on a developer, except in Redmond ;-). > > > > > > Well, I was told that to contribute to NV, I had to be running on SXCE > > latest minus 2 or better. > > Contributors should be aiming for the current target, no? Let me try and say this again. Are we contributing to Solaris or OpenSolaris. The current structure blurs the line and confuses the issue. I'd like to think we are contributing to Open Solaris. Second best would be a clear understanding that we are contributing to Solaris. The hazy distinction as it currently exists is not ideal. > > The barrier is complexity and I don't see how this proposal makes > > things > > simpler. How can we make things simpler? > > > > > > Complexity? It is more an issue of unfamiliarity, and a lack of bundled > > ecosystem. Part of designing and building this distro, would include > > building an ecosystem around the distro. When I install OpenSolaris, why > > is there not an option to grab "cc"? Why is there no standard > > OpenSolaris repository of packages? (How can this be "developed" without > > a real world implementation?) > > If the proposal is to repackage everything, then that has a completely > different set of constraints. This gets revisited every other year or so. > For current Solaris customers, there are many constraints, which is why > it is what it is. Ok let us start the conversation regarding these constraints. As a current Solaris customer, I am not aware of any constraints. I am assuming that it will still be possible to take all the granular packages and build a full OS with them. Does the fact that ON is one package vs twenty(arbitrary example) really make that much of a difference, when it comes to customer constraints? > > > 3) Current HW requirements are a bit on the high end. I can't run > > this > > > on an old 386, or for that matter on an old P/PII I have lying > > around. > > > And the thought is that Sun wouldn't include such projects in it's > > > Solaris distribution, for ecconomic and support reasons. Ideally > > Solaris > > > should be able to run on a 386 w/ 4MB of RAM (High end I know) > > > Realistically let's call the target i486DX, 8MB RAM, and 200MB > > HD. The > > > community can determine the supported hardware list. > > > > Stop global warming! Stop running old, weak, power-hungry > > computers! :-) > > > > > > If you are comparing CPUPower/Watt you are correct. From a chassis/watt > > perspective, many older computers had much lower power profiles. > > > > But more seriously, there was an effort, about 18 years ago, to shrink > > SunOS down so that you could run it on a 4 MByte workstation. The > > compromises > > made took years to undo, even as the technology evolved such that you > > can't buy machines that small anymore. We've been living with the warts > > from this effort for a long time. I see this as struggle of moving > > forward > > versus backward, along the technology curve. The horse and buggy was > > eventually replaced by the automobile, but it took a long time to make > > automobiles not look like buggies. My recommendation is to not look at > > going backwards as a feature, it has little real market value. > > > > > > Hmm... I think you are missing something if you think that the primary > > driver behind the Open Source(Linux) movement was/is "market value". > > From my perspective, it was intellectual curiosity, needs to fill a > > functions for oneself or ones group (then giving that code away for > > others to leverage and enhance), geek factor, altruism, and > > pride/recognition (etc). All that market value stuff, is build on this > > as an afterthought. > > You are nicely describing a market and I think you are trying to describe > the requirements of that market. Meanwhile, young Linus Torvalds was hacking on a tiny kernel, just a toy. He announced it on comp.os.minix: I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. Also see http://www.faqs.org/docs/artu/ch02s03.html for some historical info > > Also, could you link me to a page that might > > "explain the warts"? > > Hmmm... that would require a lot of work to assemble. All of the fixes > implemented so far are in the bug database and ARC cases. The fundamental > problem is that if you are counting every byte, then you make structures > too small, spend too many CPU cycles managing small bits of memory, and > performance suffers when you have a lot of memory. I think it is safe to > say that machines will have more memory in the future, not less. Why not make page sizes configurable at boot? It would be a pretty powerful feature. (As it is with Linux I think you have to recompile the kernel to change page sizes). > > Incidentally, I happen to own 30 horses and 3 buggies, it is a fun > > hobby, > > but I don't think we're targeting hobbiests, are we? > > > > > > Ok then, who exactly are we targeting? In my thought, we need to win > > back the educational, hobbyist and research hearts and minds. > > (OpenSolaris, not Solaris). > > Hey, you made the proposal, you should be able to identify the market. Please don't play these word games. I assumed you were including yourself when you said "we're targeting". I in fact took "we're" to mean Sun, and possibly the OpenSolaris community as a whole. > > > 4) Sun (Ian/Indiana/Others) wants a second Solaris distro that > > will be > > > the Fedora to Sun's RHEL (Solaris). They wish to do this and > > still leave > > > a clear migration path from one distro to another. (Unlike Fedora). > > > > Yes! I think we can all get behind this sort of vision. But making > > a better > > Fedora than Fedora may not be the best strategy. We can be more > > clever than > > that. > > > > > > Exactly. I just used Fedora as an analogy. Being more clever is very > > good. Let's start talking about what this means. > > Yes. New thread needed. This thread is that thread to discuss. Feel free to let us know some of the things that would make our model better? > > > Although this may be considered a commercial driver outside of the > > > community, let's keep in mind who makes the community possible. I > > as a > > > member of the community want to see our host prosper, and > > continue to be > > > able to provide support to our community. (If this was a Linux > > vendor > > > launching a new community distro, there wouldn't be nearly as much > > > opposition) > > > > I don't think you're seeing opposition to a new distro. I think you're > > seeing a recognition that yet-another-distro doesn't necessarily solve > > the long-term problem of building the best platform for innovation. > > > > > > Can you elaborate what you mean by this? (best platform for innovation). > > In my vision, Solaris is the best platform for innovation. Wanna develop new > software? Solaris. Wanna deploy a big friggin' database? Solaris. Wanna > build clusters? Solaris. ... I don't think you can make such an ambitious statement. e.g. Is Solaris the best platform for innovation in the embedded space? Is it the best platform for Smartphones? (Even Sun is advocating Linux here). Is it the best platform, for deploying nouveau clustering? Is it the best platform for developing new webservers? I think that while there is a desire to be that platform, there is one thing standing in the way. Sun. Sun seems to still have a "not invented here" attitude in certain areas. > > If we accept the vision of a distro that can take OpenSolaris forward > > > > to the next level, what would that next level look like? > > > > > > Going forward that is for us to create. In the beginning it would look > > alot like SXCE. (Plus and minus) > > Agree 110% > SXCE is a good start, but only a start. We agree. I add to this that the installation and packaging should be flexible enough to allow building a root image that just has a kernel and bootstrapping code, all the way to a full "fat" OS with a, Ubuntu universe like, collection of applications and tools. As you selected applications, the dependency data could trace dependencies all the way to the kernel module level. There would also be the option to build from pre-designed OS templates, e.g. - "Full OS - FOSS only" or "Full OS - FOSS+". brian
