OpenSolaris, VMWare, Sun Developer Network
I'm wanting to play with OpenSolaris... Solaris seems technically cool, I have a lot of respect for the engineering prowess of Sun, and ZFS and DTrace have gotten a lot of publicity and seem cool.
To a certain extent experimenting with OpenSolaris runs contrary to my overall feelings on operating systems at this point, which is that the important thing is a convenient, well-thought-out packaging and package-update mechanism, with the largest possible number of things packaged for it, and ideally available from one or a few trusted sources. This is why I like Debian so much.
Another issue is whether such an experiment is the right way to handle the fact that there are always too many things to learn. Software is all about lots and lots of precise and largely arbitrary details, resulting in a stiff learning curve when trying to use something new. (And, correspondingly, great gains in power that come only from deep familiarity with a system.) It is a key professional skill to manage this learning effectively: on the one hand, it is easy to get too deeply entrenched in what you already know how to use, and miss out on opportunities arising elsewhere; on the other, it is easy to obsess over always learning new things from the beginning, when gaining further skill with things you already use and know a little about would be more valuable.
But despite such concerns--hey, new toy. Looks shiny and fun right now. Could be a pain in the ass to actually get it working.
Anyway, I'm planning to run OpenSolaris under VMWare. VMWare, by the way, looks really fucking sweet. I've only used it a little, but... cool. Papers about it, which I read back at UT... cool. It's proprietary, but the VMWare Server Console is beer-free, and has at least a bit to play around with.
So the holdup at this point is the Sun Developer Network, or as the military refers to it, the SDN. (This is a joke; as a fun parlor game, if the military were to use SDN, what would it stand for?) Any similarities in name or intent between the SDN and the MSDN are purely coincidental.
I'm familiar with the general concept of Developer Networks, but have long held them to be tools of the Evil Proprietary Establishment, and have not learned the details, or joined one (which I vaguely considered to be too expensive to contemplate, anyway). But Sun's is free. I think it has recently morphed from something else, upgraded its website, acquired new superpowers, etc. It's pointed to by OpenSolaris.org. But I can't download any fucking software from it.
Rediculous. (And yes, I do know how to spell.)
It's funny how so much of everything comes down to doing things right.
Labels: tech
posted by Scott @ 01:42
1 Comments:
To a certain extent experimenting with OpenSolaris runs contrary to my overall feelings on operating systems at this point, which is that the important thing is a convenient, well-thought-out packaging and package-update mechanism, with the largest possible number of things packaged for it, and ideally available from one or a few trusted sources.
I've recently come to the conclusion that even the bests package management systems are simply bandaids over a much bigger problem. The unixes are simply broken when it comes to installing software. The traditional unix way is to have an app spread all across the filesystem: binaries in /usr/bin, setuid binaryies in /usr/sbin, libraries in /usr/lib, config in /etc, docs in /usr/man, etc. This sucks because it allows for easy collisions between different apps and makes it very hard to uninstall an app. The obvious alternative to this is to have all the files required for an app to be under a single directory for that app, i,e, /usr/Gimp contains bin, lib, conf, man, drivers directories in it. Then package management becomes very easy. To install an app, you untar it in /usr. To delete, you remove the the app's directory. To update it, replace the directory with a new version downloaded from the app's site.
The command-line culture that grew up around unix makes this inversion difficult. Managing $PATH would be messy and explicit command-line invocation of a binary not in the path would be a lot more verbose. Still, the benefits would be enormous.
The app's directory could have a well-defined structure and include some very useful information, such as a script to start and stop the app if it is a server, an explicit listing of its runtime and linktime dependencies (no more numbered rc files), even an icon for visual display. This would also make auto-update of software, which is almost impossibly hard on unixes, trivial.
GoboLinux appears to be moving in this direction and Mac OS X also does some of this. Solaris seems like it would be a great place to try and suss out how to do a better job of this because Sun controls the whole stack and because there aren't that many binary architectures to support.
I realize that this is probably never going to happen, but I can dream, right?
Post a Comment
<< Home