Re: [osol-discuss] blastwave.org - any info?
This isn't good. Hopefully Dennis will drop a comment our way soon. It'll be a sad day for everyone if blastwave closes permanently. Dennis has apparently indicated, that he is no longer interested in 'hosting' the CSW packaging efforts for solaris, if he cannot dictate various things about how businesses use it. So, apparently, CSW packaging, will no longer be a project at blastwave.org. However... since I am still willing to continue my efforts to continue to do the actual coordination of day to day things, and other maintainers are also... CSW packaging will still continue, for those interested in still being involved! We will just switch to a different domain name. This new development, means that we could use an offer of some hosted solaris 8 build machines, though. (ie: if you have some thing vaguely resembling a datacenter, and you wouldnt mind setting up a build server or two matching that description for our use, it would be quite helpful. ORRR, if you wanted to give a one-time donation of hardware that is compatible with that stuff, AND are willing to pay shipping on it to far away (might be europe, might be elsewhere), please let me know. phil,- bolthole.com, please :) We are ALSO interested in more people being maintainers! So if you might be interested in giving some of your time to the cause, please also let me know. [umm.. lot of Cc's there.. think i'll take some of them out. wait.. i cant though this web forum interface. sorry folks :( ] This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXDE 1/08 features
http://bugs.opensolaris.org/view_bug.do?bug_id=6521472 according to the above link zfs install is not possible at this stage and the last update on this was the 25th Oct. ian, thanks for flag days link, it's helping me peel another layer of onionSolaris rather than just making me cry. =) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXDE 1/08 features
will this have zfs boot install to zfs root? thanks This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: How do I dual boot my machine?
I have xp on a slave drive and found I had to put the map directive in /boot/grub/menu.lst ala #-- EDITED BY USER - OK TO EDIT -- title Windows XP rootnoverify (hd1,0) map (hd0) (hd1) map (hd1) (hd0) chainloader +1 #-END BOOTADM This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: ATA CompactFlash support
has there been any movement on this in the last 11 months. thanks This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Cdrecord 2.01.01a11 in the latest snv ?
On Thu, Jul 13, 2006 at 05:19:08PM -0400, James Carlson wrote: The original reason for /usr/sfw was to prevent users from wandering into External (extremely volatile; not necessarily compatible from patch to patch) software. But with GNOME integrating into /usr/bin as External and with the realization that the pain of torquing every $PATH was much higher than the value (if any) gained from the segregation, we've decided to drop the idea. (There are other reasons behind it, but the lack of a firm grounding for differentiation by stability was the key issue.) Pffft. How about avoiding the Microsoft Explorer/Media Player factor? In other words, having Sun recognize (in comparison to what microsoft did) that yes, their customers may want to run something OTHER than the sun-shipped browser/media player/GNOME version/ Having the separation makes it feasible for your customers to choose alternative vendors for various components, and even having multiple vendors versions of similar products installed. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting dtterm to play nicely with GNOME 2.14...
On Tue, Jul 11, 2006 at 12:01:00AM -0400, Laszlo (Laca) Peter wrote: Some default X resources are set in /usr/dt/config/Xinitrc.jds. These ones seem to be related to dtterm: *XmText*background: seashell *XmTextField*background: seashell *background:#AE00B200C300 Hmm. This sounds a bit nasty to me. bad naming. It seems apparent that people arent percieving themselves as logging into jds. They are perceiving themselves logging into a GNOME environment. (just look at the subject line!) As such, I would suggest that the name of the session be changed. Even the file itself describes itself to the user as, Dthello*string: Welcome to the GNOME Desktop Environment echo Starting GNOME **NOT** welcome to JDS. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting dtterm to play nicely with GNOME 2.14...
On Sat, Jul 15, 2006 at 02:50:12PM -0400, Laszlo (Laca) Peter wrote: Even the file itself describes itself to the user as, Dthello*string: Welcome to the GNOME Desktop Environment This file has been in use (under changeable names) since GNOME 1.4, 5 years ago, so it well pre-dates JDS. yes, and i'm sure one of the old names was Xinitrc.gnome ;-) Anyway, that's just some background info. I've updated the file like this: diff -u -r1.21 Xinitrc.in -Dthello*string:Welcome to the GNOME Desktop Environment +Dthello*string:Welcome to the Sun Java Desktop System [...] -echo 'Starting GNOME' +echo 'Starting gnome-session' exec $command Is that any better? yes, I think that is definately an improvement, in that the user description and the filename now match. thanks. Personally, I think that the best result would be to just keep it as Welcome to GNOME, and toss out the whole jds marketing facade... but oh well :-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] the grubby looking install process
On Mon, Jul 10, 2006 at 08:14:58PM +0200, [EMAIL PROTECTED] wrote: ... Yes; the install program should make more sense out of the keyboard input; it doesn't do so now. Even with terminal properly set, it can't use Fx keys on anything other than a Sun type terminal (not xterm, usually) eh? F keys USED to work, if your term type was set to xterm, for quite a while.(multiple releases of solaris) You guys broke it?? :-( ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: revisiting software issues
On Mon, Jun 19, 2006 at 07:26:51PM -0700, Erast Benson wrote: On Mon, 2006-06-19 at 17:45 -0700, Philip Brown wrote: On Mon, Jun 19, 2006 at 04:00:28PM -0700, Erast Benson wrote: On Mon, 2006-06-19 at 23:46 +0100, Peter Tribble wrote: - can I request a specific version? yes Thats not exactly true. Only if the archive happens to keep old versions, or if its a gcc3 vs gcc4 thing, where people are explicitly packaging up multiple versions as current versions/variants of the software. nope. it is true. apt-get will ask user to specify particular version if will encounter 1 version of the same package. you actually just agreed with me. Note the if in your sentence. pkg-get does this too, of course: if it finds multiple versions of the same softwarename on a site, it will ask you which one you actually want. Note to others, though; gcc3 and gcc4 are technically different software, from a package management point of view, both from apt-get, and pkg-get's view. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Google Earth
On Mon, Jun 19, 2006 at 05:44:18AM -0700, UNIX admin wrote: no, it's still the java programmers fault Truth be told, I don't care whose fault it is, all I know is that it's SLOW and that the language is complicated even for the simplest of things. It's not a scripting language. Compared to many other compiled languages, it is simpler than many others. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: revisiting software issues
On Sun, Jun 18, 2006 at 09:47:21PM -0700, Hugh McIntyre wrote: Philip Brown wrote: While blastwave does it, I can't use blastwave as a part of some other solution. And that's the problem with all the package management systems - they're fine, as long as you use them in complete isolation. Exactly. Say I want PHP to run with the bundled Apache. Blastwave won't do this, unlike Fink, for example. why the heck would you want to do that, though? Say because of having an existing set of configuration against the bundled Apache and just wanting to add PHP, not starting again configuring everything else from scratch with the Blastwave version. In principle most of the config might copy across, but that's not the point. No, it really is the point. both from the it really isnt that tough point of view, and also, because it's the Right Thing To Do. It's the right thing to do, [or at least, the expected thing to do ], because you're basically changing software 'vendor' for your web infrastructure. There are multiple applications out there that 'require' certain versions of support software to run. It IS somewhat irritating at a why should I change? level.. but it is common practice, and it makes the best sense to have a reliable, supported version of the top-level stuff you actually want to run. But besides which, for 95% of migrations for SUNWapache to CSWapache, you would be able to copy over /etc/apache/httpd.conf to /opt/csw/apache/conf/httpd.conf, and have it work with ZERO changes. You dont have to change DocumentRoot, or almost anything else. You've just changed the location of your binaries from /usr/apache/bin to /opt/csw/apache/bin (Now, you'd ideally want to do this BEFORE installing CSWphp, so that the install script will automatically update 'your' httpd.conf instead of the default csw httpd.conf. but that's about the only gotcha :-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: revisiting software issues
On Mon, Jun 19, 2006 at 04:47:20PM -0700, William D. Hathaway wrote: One thing I'd like to see in Blastwave standards is the separation of bin/lib from config/data. While I was a massive fan of CSW on Solaris 9, when trying to build S10+ machines with large numbers of zones, it seemed I like I either needed to make /opt/csw local on each zone, or do lots of mount hacks. This is already IN our standards, actually. If you find any packages that are not already separated like that (with one or two exceptions), this is a bug. This violates our packaging standards, and should be treated as such. Please file a bug against the package. I believe most of our software already complies with this, or is all read-only anyway. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why is newfs and ufsdump so much slower in single user mode than in run level 3?
On Sat, Jun 17, 2006 at 08:16:38AM +0200, [EMAIL PROTECTED] wrote: Perhaps we need to understand which OS release this is exactlyu and how single user boot is done. (If it boots from a pre-S10 network image, SCSI options will be set to crawl) Also, certain boot image versions, had network drivers for certain cards that were WAAAYY behind the drivers that were on the same CD/DVD. Just fyi, in case you run into any similar yet more net-related issues. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: revisiting software issues
On Sat, Jun 17, 2006 at 04:17:42PM -0700, Hugh McIntyre wrote: Potentially what would help here is to integrate a stub pkg-get command into the base install, but out of the box this would just be a wrapper, not linked to any specific back-end repository. great idea. and actually, already proposed to sun, [or they might even have approached me about it :-) memory is a bit fuzzy now] about 6 months ago. I said Great idea! Lemme know anything I can do to help you. havent heard much back about it. While blastwave does it, I can't use blastwave as a part of some other solution. And that's the problem with all the package management systems - they're fine, as long as you use them in complete isolation. Exactly. Say I want PHP to run with the bundled Apache. Blastwave won't do this, unlike Fink, for example. why the heck would you want to do that, though? [*] in fact the ability to configure a path of sources might be preferred. For example: sun.com if the package exists, otherwise Blastwave. That way lies Evil. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: revisiting software issues
On Fri, Jun 16, 2006 at 04:16:04PM -1000, David J. Orman wrote: Sun just needs to pick something, stand behind it, and give it a bit of support (make sure things are up to Sun's high stability/etc standards.) Tee Hee... We've learned one or two things from sun's original companion cd distribution. But in some ways, me being the package control nazi has made our standards HIGHER than sun's in some places. For example, for quite a while, we were the only place to get pre-compiled packaged 32bit AND 64-bit libs for some things. Neither sunfreeware nor sun's companion cd offered them, even though they offered the 32bit versions. And beyond that, our stable packages get actual field testing in unstable, before being released to stable. I'm not aware of any public beta program for early access to companion cd packages before they are burned/released. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: revisiting software issues
On Sat, Jun 17, 2006 at 04:05:47PM +0100, Peter Tribble wrote: ... While blastwave does it, I can't use blastwave as a part of some other solution. And that's the problem with all the package management systems - they're fine, as long as you use them in complete isolation. The underlying problem is dependency hell. And Ubuntu/Blastwave/ whoever don't solve the problem - they hide it from the user and therefore don't encourage the community to solve the basic problem. You just contradicted yourself. The only way to guarantee a fix from dependancy hell (and have all the dependancies WORK, when you type [mumblety-upgrade]) is to ensure it all comes from the same place. I dont see any call for the community to solve this. it's a fact of life, living with free software. it's not a solvable problem. [unless you've come up with some miracle strategy to force free software authors to actually stick to sane release numbers, library naming, and binary compatible APIs unto themselves. ie: berkeleydb. DISGUSTING! Now, how do you suggest the community fix that issue? ] It's certainly not a USER-solvable problem. They want it to just work, usually. As such, they only guarantee compatibility, consistency, and stability amongst in their own self-contained universe. On home machines that's probably enough, but it's certainly not good enough once you need to do something the repository can't. There are multiple options, at least with blastwave, if it's software we dont already have: a) request someone at blastwave add the software you need (not guaranteed someone will pick it up) b) compile it locally against blastwave packages. yes, amazing, but this does actually work ;-) c) join up and volunteer to package it. Then you're pretty sure it will be as up to date as you need ;-) And if existing software doesnt have a feature you need.. File a feature request as a bug! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: IPsec Tunnel Reform
On Fri, Jun 16, 2006 at 09:51:31AM +0100, Darren J Moffat wrote: Philip Brown wrote: actually, it isnt all that great in non-tunnel mode either. We couldnt get it working between solaris 9 and windows xp servers, fyi. I'd like to see THAT be 100% interoperable first, personally. There are three documents on SunSolve that cover this written by Paul Wernau and reviewed by me that cover the Solaris/Windows XP interop configuration: and I think we read them all, and it Just Didnt Work. sigh. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: IPsec Tunnel Reform
On Thu, Jun 15, 2006 at 12:53:01PM -0700, Dan McDonald wrote: Hello OpenSolaris folks! I would like to open an OpenSolaris project - IPsec Tunnel Reform. Please read on if you'd like to learn more about the project. The IPsec implementation in Solaris interoperates very well with others as long as Transport Mode IPsec is used. When Tunnel Mode comes into play, we do not interoperate at all, or barely with carefully-crafted manual keys. actually, it isnt all that great in non-tunnel mode either. We couldnt get it working between solaris 9 and windows xp servers, fyi. I'd like to see THAT be 100% interoperable first, personally. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Any IDE controller Solaris 10 driver?
On Thu, Jun 15, 2006 at 03:15:21PM -0700, YJ Fan wrote: Is there any IDE controller driver availble in Solaris 10? yes. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] console font
On Mon, Jun 05, 2006 at 12:19:50PM +0530, Moinak Ghosh wrote: Philip Brown wrote: http://www.bolthole.com/solaris/drivers/vgatext.html fstobdf(1) should be able to convert to BDF fonts if one is running a fontserver. Thank you! I've updated my web page accordingly. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: What is OpenSolaris?
On Fri, Jun 02, 2006 at 05:01:42PM -0700, Erast Benson wrote: On Fri, 2006-06-02 at 16:54 -0700, Philip Brown wrote: On Fri, Jun 02, 2006 at 04:52:48PM -0700, Erast Benson wrote: sound like debdelta which has been around for years is what you are looking for. S'funny.. there was an announce on the debian-devel mailing list only a week ago, about a release of debdelta, that made it sound like it was only just recently completed and ready for production use. Didnt sound like it had been around for years, except as an experimental thing. The first mention of it, is back in oct 2002, from the original author, as I've written a couple of scripts which are designed to create xdelta diffs of debian packages. These could conceivably be used to create a delta repository, vastly reducing the download amount for an update/upgrade. But I dont think anyone has taken it seriously until now ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] console font
On Thu, May 25, 2006 at 12:24:11PM -0700, Philip Brown wrote: ... I'm too lazy to see if vgatext and ALL associated bits, are now CDDL'd. If someone will confirm this (and email my regular address off-list to prod me) then perhaps I will remember to contribute my now 5-year-old hacked vgatext drivers, that allow exactly this :-) I've finally gotten around to doing the code merge. http://www.bolthole.com/solaris/drivers/vgatext.html has a link to a tarball I hastily threw together of the resulting code. It compiles. its latest incarnation has not been tested at all (although the earlier code version definately did work) I'm putting it up now, in case it's another 2weeks +, until I get around to testing it myself (which is quite possible :-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] console font
On Sun, Jun 04, 2006 at 10:47:27PM -0700, Philip Brown wrote: http://www.bolthole.com/solaris/drivers/vgatext.html has a link to a tarball I hastily threw together of the resulting code. PS: there are two points of interest in my code: 1. it theoretically allows use of other fonts, even slightly different SIZED fonts 2. it cleans up a bunch of hardcoded numbers in the sun code, to properly use the appropriate #defines, that are ALREADY IN sys/vgareg.h shame, shame. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Sun lost one of it's biggest and oldest
On Fri, Jun 02, 2006 at 04:42:12AM -0700, Nicolas Linkert wrote: What do companies want? Most of them want a product: - that's independent from a vendor - that's why many choose Debian - and not Red Hat or SUSE - - they need a business desktop / they need a reliable server - they want professional support for it. I'd like to point out that #1 and #3 are pretty much mutually incompatible. Example: there is no TRUE business-class support for debian. (as in, 50,000 employee business level) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: What is OpenSolaris?
On Fri, Jun 02, 2006 at 04:19:23PM -0700, Erast Benson wrote: The problem I'm seeing is that SVR4 packaging system wasn't developed to inter-operate with upstream tarballs and patching system is not an easy one to enable. At least it is not as easy as with Debian or RPM. That means patches for particular upstream project A are not part of A SVR4 package itself and instead stored separately somewhere. The following is in the context of the solaris patch system, not other patch systems: (binary) patches, are to update binaries. Binaries are the results of a particular source tree. (at a particular version) upstream tarballs get integrated with a source tree, not binaries. An appropriate technical person should be merging the source together, and determining if a binary patch is needed, or whether a full new release of a package is appropriate. SVR4 packaging is primarily geared towards binaries, not source trees, IMO. Personally, I dont see that as a problem. see below. This is what other distributions do, their *source* packages usually contains upstream tarball + set of distribution patches on top of it. And sooner or later those patches will migrate to their upstream or simply rejected. Nothing says that opensolaris has to have source packages. But if it does: the SVR4 packaging system could still be used for it. Switching gears a bit, though: last I heard, debian does not have a binary patching system. just a source code packaging system, that primarily exists as original tarball + set of patches, as you noted. I'm not sure I'd call that a patching system for source code either. more like a pre-bundled, pre-determined patch set + autobuilder. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal - Simplified Solaris Device Naming (a.k.a Devname)
On Fri, Jun 02, 2006 at 03:23:25PM +0100, Darren J Moffat wrote: I think it is worse on Solaris because it looks like you can work it out and it appears to be predictable :-( well, at least once you have a particular box's naming scheme worked out, it is reasonably predictable. eri1 will ALWAYS BE eri1, the same physical adaptor, until you remove that piece of hardware. It's predictable.. just not in the fashion that people initially may think of it :-} ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: What is OpenSolaris?
On Fri, Jun 02, 2006 at 04:52:48PM -0700, Erast Benson wrote: Switching gears a bit, though: last I heard, debian does not have a binary patching system. just a source code packaging system, that primarily exists as original tarball + set of patches, as you noted. sound like debdelta which has been around for years is what you are looking for. if it's been around for years, why does virtually no-one use it? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: What is OpenSolaris?
(forgive me for changing the order of quotes a bit, but I think it makes sense, and still keeps original intentions...) On Fri, Jun 02, 2006 at 04:52:48PM -0700, Erast Benson wrote: On Fri, 2006-06-02 at 16:33 -0700, Philip Brown wrote: Nothing says that opensolaris has to have source packages. A missing capability of having source package reduces community involvement in development of a package. In Nexenta/Debian you can do: apt-get source gnome-panel than fix, rebuild and re-upload to unstable APT repository. for starters, the general community doesnt need to be able to re-upload to unstable. Only maintainers do :-) But more importantly: The critical thing here, is to have SOME kind of auto-(re)build mechanism. (and ideally, attempted-auto-update mechanism) Whether or not that is done by packages, is irrelevant. debian source packages are one way of doing it. it works. but it's not the only way that can work. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: What is OpenSolaris?
On Fri, Jun 02, 2006 at 05:12:07PM -0700, Erast Benson wrote: On Fri, 2006-06-02 at 16:59 -0700, Philip Brown wrote: for starters, the general community doesnt need to be able to re-upload to unstable. Only maintainers do :-) I'm sorry, but your statement is not always correct. Only developers do. :-) To be clear to the non-Debian folks: you presumably mean Debian Developers, not software developers in general. [Debian developers being in essence, trusted, officially approved and authorized contributors, aka [EMAIL PROTECTED] ] but.. I stand corrected ;-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun lost one of it's biggest and oldest x86 customer
On Thu, Jun 01, 2006 at 11:19:22AM -0700, Rich Teer wrote: Agreed, although I have some concern about the marketing aspects. Keep on marketing to the converted, but I think the biggest challenge for Sun's marketroids is converting the uninitiated, i.e., creating more Sun/Solaris brand awareness. absolutely. Time for another sun/solaris marketing splurge. Sun did it a year ago or so, when they started to ramp up x86 again. you started seeing solaris all over the place on the net, like slashdot, and various trade mags. It should be a yearly, or even twice yearly, thing, i think. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What would it take to run Solaris x86 on a SunPCi card?
On Thu, Jun 01, 2006 at 03:28:53PM -0700, Richard L. Hamilton wrote: What would be needed in the way of additional drivers, boot support, etc to make that happen? Is sufficient info available from publically available OpenSolaris code, etc? you shouldnt need any extra drivers, etc, etc. it should just work, in the same way that windows95, windowsxp, and linux run on it already. I think I ran solaris 8 x86 on one once, actually. Try it out and let us know what breaks ;-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Lightweight ZFS NAS requirements?
On Wed, May 03, 2006 at 07:26:13AM -0700, Tom Smith wrote: Hi. I've been thinking about building a SOHO NAS project using ZFS as some others have suggested doing but I'm curious how lightweight I can make Solaris (from a processor, memory, and install disk space) perspective and still have decent performance for a home file server. If I took some time to strip out all the unneeded parts of the system, leaving just enough to run ZFS, a web console, Samba, and the basic kernel functions, what minimum requirements do you think would be needed? If you're really really abusive, I mean, agrresive in your pruning :-) you can get the bytes for running solaris down to about 100 MB on disk. (this consists of doing a core install, then pkgrm'ing stuff, and then beyond that, actually using rm -r. but since it's a fileserver, you're probably not going to be short on disk space) you can also get the in-memory footprint down to about 64megs of RAM. this should be way under your requirements. It should be trivial to get a cheap small machine that has a 1ghz cpu with 128megs RAM, and that should be more than plenty for your needs. btw: running a web console + samba tends to spike your needs, though. 128 megs RAM will probably be minimal. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] console font
bahahaha Im reviewing changes to vgatext since my hacks, and was amused to find the following: if (happyface_boot == 0) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] console font
On Mon, May 22, 2006 at 02:36:49PM +0800, Riny Qian wrote: sure, if you're willing to recompile the vgatext driver. ;) Then you can also change the console window size from 25x80 to others. This seems a good opensolaris project :-) I'm too lazy to see if vgatext and ALL associated bits, are now CDDL'd. If someone will confirm this (and email my regular address off-list to prod me) then perhaps I will remember to contribute my now 5-year-old hacked vgatext drivers, that allow exactly this :-) (they allow for it semi-dynamically. You specify a font module to load, in vgatext.conf) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal: Virtual Console
On Thu, May 25, 2006 at 07:42:59AM -0700, Alan Coopersmith wrote: In the case that actually replaced the console driver, the VT support was described by the project team as little used and unnecessary: c) VT support. [...] mechanisms. These users can either use utilities like screen or a window system to achieve their goals. [...] It appears the ARC accepted this explanation since it the case was approved. Too bad the project team lied in their explaination. There is no way that using 'screen or a window system' aids you, when you find that your window system has locked up on your console, and you need to switch to a secondary VT on your non-networked system, to unstick it :-( but it would be nice to see this reimplemented nicely, so that both x86 and sparc would benefit from it. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Tue, Apr 18, 2006 at 06:10:31PM -0700, Alan DuBoff wrote: Blastwave essentially dropped their stable tree anyway, didn't you? Just the opposite. We finally found someone to step up to the plate and do the hard work, for free. James Lee is our official stable tree maintainer, and we've been doing very solid 'stable' releases for about 3 quarters now. This only proves that it's too hard to keep updating both trees. guess not :-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Tue, Apr 18, 2006 at 06:10:31PM -0700, Alan DuBoff wrote: Sun has staff now to handle most of what they do, but this doesn't allow Sun to work with the community. btw: there's a difference between working with the community, and meeting the needs of the community. you dont have to do #1 (in the sense of, community members get write access), to fulfil #2. There is a small, but important difference between, people can see the codebase, and submit patch suggestions to full-time sun employees, and this chunk o' code/binary is 100% maintained by a non-sun-employee opensolaris.org is, as far as I understand it, using the first model. You seem to be pushing for the second model, for this common freeware base. I believe that the first model is best both for opensolaris.org solaris code, and also for any affiliated sun-blessed common set of freeware. But my point being, that would require dedicated sun employees for the task... which sun seems to be moving away from. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Wed, Apr 19, 2006 at 01:57:42PM -0400, Dave Miner wrote: Eric Boutilier wrote: I'm not sure Nexenta's implementation is the way to go though. It seems to me that Phil's pkg-get -- being designed around Sun's implementation of the SVr4 packaging standard -- seems like the better candidate, or maybe something new based on the patch software (that is currently used for updating Solaris)... We'd welcome discussion and work on any of these alternatives over in the Install and Packaging community. Well, perhaps not the patch alternative, at least not at this time - the patch technology is just sooo fragile... Solaris patching isnt particularly bad. [It has its faults, but its been in use for over a decade now] Debian's, from what I here, is the fragile one. It's too bad that pkg-get doesnt support downloading updates via patches though... sigh... it's not really something that blastwave needs, so it's not a priority for me. But if someone at Sun were to approach me, and suggest, hey, we'd like to use pkg-get to handle patches as well, what do you think of this high-level approach.?, I would be more than willing to consider it. PS: I'm trimming out the botched trailing Re: in the middle of the subject line, to try to get this thread to sort better by subject. Hopefully, others will do the same. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Tue, Apr 18, 2006 at 07:50:35PM -0400, Laszlo (Laca) Peter wrote: On Tue, 2006-04-18 at 14:44 -0700, Philip Brown wrote: Interesting. This is not a deliberate thing. Apparently, it's just a side-effect of using sun compilers with the -fast option. The magic compiler option you need is -xregs=no%frameptr sounds like that turns OFF frameptr, not re-enables it after -fast removes it. aha. -xregs=%frameptr would seem to be the magic. Although it does apparently slow down performance. Is it really so important to have dtrace have extra visibility into the openssl shared libs? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
On Mon, Apr 17, 2006 at 11:02:20PM -0700, Erast Benson wrote: On Mon, 2006-04-17 at 22:08 -0700, ken mays wrote: Going back to the comments about Nexenta build system: Nexenta build system == Debian build system The equation above means that NexentaOS following Debian Policy[1] as close as possible. This is done on purpose. Since a) we now can collaborate with Debian community and push our changes upstream; b) we can easily migrate huge amount of packages under NexentaOS APT repository. The thing about all that, is that it forces the machine to be closer and closer to a linux machine, until eventually, it becomes nothing more than a linux machine with a user-invisible solaris kernel. In constrast, one of the core (unwritten, I guess) principles about packaging at blastwave, is to provide all the free stuffs, while still keeping everything firmly sticking to SOLARIS/SVR4 policy. Not Debian policy. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Mon, Apr 17, 2006 at 04:23:17PM -0700, Alan DuBoff wrote: So, how would it be possible to build a large set of libraries that everyone could update and use together? Is this at all possible? Sun has basically proposed to work with the community, and that is happening, albeit slowly...so would it at all be possible to work with the community and create one large set of libraries we all work with and update together? Hate to say it, but: no, because of all the qualifiers you put in. If you take some out, then yes it is possible. possible.. but not likely. For example, if you simply take out with the community, it is possible. The reason being, of some people's hard requirements that the libraries they use be from sun. from sun + the community is NOT from sun. Sun would have to go 180 degrees in the direction they have gone, and hire full-time staff, to keep the important stuff up to date, solely by sun's efforts. Sun would have to then have a split-versioning strategy, where one version of the libs would get used by cdrom-burned releases, but then newer versions of the libs were easily and automatically downloadable via the net, so people can more easily/quickly keep up to date. and then keep their team actually busy working on keeping the libs highly up to date. However, there are still multiple problems with this: 1. things change slowly in core solaris for a reason. some of sun's customers are very change-averse. So, to have bits in sun-shipped solaris, change rapidly, would possibly alienate that important userbase. [it might be possible if sun split out that stuff to a separate chunk, and said, ok, we commit to stability for stuff over here, but stuff on this GNOME cdrom/whatever we do not commit to keeping unchanged for x number of years, or even x number of months] 2. Some of the issues of keeping nasty open source libs up to date, is then that you have to recompile a buncha stuff, because there is an extreme lack of API stability in the open source world. It's the linux disease of oh, you should just recompile everything 3. Sun would have to actually comit to the long-term expenditure of creating and maintaining such a team. Hurdle #1 there, is sun actualy doing the comitting. Hurdle #2, which at this point is far bigger, would be in convincing everyone else that sun is actually serious this time. I for one would not believe it for at least 2 years after it was started. The cost to convert everything, and then get dumped after a year, is simply too high to take a risk on it at this point. Re-engineer 1500 packages... and then re-engineer them AGAIN? no thanks. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
On Tue, Apr 18, 2006 at 05:54:15PM -0500, Eric Boutilier wrote: Philip Brown wrote: The thing about all that, is that it forces the machine to be closer and closer to a linux machine, until eventually, it becomes nothing more than a linux machine with a user-invisible solaris kernel. Gong! -- You violated my pet peeve -- one of the two[1] flagrant abuses of the word Linux. Your punishment: 1000 sentences: Nexenta boxes are Debian/Nevada machines, they are not Linux machines. Nexenta boxes are Debian/Nevada machines, they are not Linux machines. Pffft... everyone here understands what is meant, and it's a lot easier than trying to describe, closer to 'one of those types of machines that is based around what is commonly called a linux distribution, and/or a Linux Standards Base compliant system in addition to adhering to all the system-administration admin level issues, which may or may not be specified in the LSB mentioned hereabove :-) [1] The other one is using Linux Community to refer to all users and implementors of open-source and open operating systems -- well, that isnt even close to being accurate :-P whereas mine was clearly just a contraction :-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Sat, Apr 15, 2006 at 03:35:52AM +0200, Robert Milkowski wrote: Saturday, April 15, 2006, 2:27:45 AM, PB writes... PB Basically, blastwave packages are set up to be binary distributions, not PB developer distributions. PB If you want to compile other stuff against our packages, you are encouraged PB to become a maintainer and add to the collection, using our nice clean PB build servers ;-) Sorry, internal software only. fair enough... [...] What if I want to compile our own software linked with Solaris OpenSSL (to get Niagara HW acceleration for example) and linked with other open source libraries provided by Blastwave? What if then these libraries depend on openssl provided by Blastwave... and things get messy here. That does indeed get messy.But the thing is... in a way, this is sun's fault :-) it should provide patches to openssl to enable niagra acceleration, and then blastwave can use those patches, and then blastwave ssl will have that acceleration too. [really, it should give the patches to openssl.org. but barring that, it would be nice to see a patch set just posted somewhere, like opensolaris.org] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On Sat, Apr 15, 2006 at 02:13:11AM +0200, Robert Milkowski wrote: Hello James, Thursday, April 13, 2006, 2:06:40 PM, you wrote: JC Hugh McIntyre writes: JC That's also what Debian does. That fixes the dependency problem, but JC doesn't fix the path problem. JC The path problem for libraries is that if one installs as JC /opt/csw/lib/libfoo.so.1 JC and the other installs as JC /opt/sfw/lib/libfoo.so.1 JC then one can't really satisfy the other. The user is forced straight JC into LD_LIBRARY_PATH or crle(1) hell, and that's just not right. We do use Blastwave on our servers and I must say that I realy don't like all the problems with doubled libraries (like openssl). Sometimes you even endup linking with the library from blastwave while you were expecting something else - due to dependencies. sfunny, we at blastwave, dont seem to have any linking problems, compiling against our stuff :-) Basically, blastwave packages are set up to be binary distributions, not developer distributions. If you want to compile other stuff against our packages, you are encouraged to become a maintainer and add to the collection, using our nice clean build servers ;-) If you are compiling stuff on your own machines, and you dont WANT blastwave libs linked in... simplest thing is to just remove /opt/csw/bin from your $PATH, and pretend the blastwave packages dont exist for purposes of your compile. Contrariwise, if you DO want to compile against blastwave stuff, then remove /opt/sfw/bin from your path, add in /opt/csw/bin first in your PATH, and it's all good. (If you also follow the other build notes specified in our build standards) In NEITHER case, should you mess with LD_LIBRARY_PATH, or crle. That's what actually leds to the most problems. Properly compiled software does not use or need crle or LD_LIBRARY_PATH to work. They only mess things up. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
Hi folks, I was informed there was a bit of a broohaha over here, about packaging up open source binaries for solaris and opensolaris. So, as the author of pkg-get, and the creator/leader of the CSW packaging efforts living on blastwave.org, I thought I'd poke my head in and wave. *wave*. I've been skiming through some of the archives on this subject thread. I'd like to think that I can offer a calm and cool response to any outstanding issues or questions reguarding blastwave/CSW packaging. I'm on too many mailing lists as it is, so this will probably be a short-term (few weeks) visit :-) But I'll do my best to pay attention during that time. At this point, there's only one clear thing that i'm not sure people have explained: Why blastwave offers packages that are redundant to some sun ones. This issue came up wy back 5 years(?) ago when I started things off. We initially tried to build on top of Sun shipped stuff, which at that time, was all living in /opt/sfw. It didnt work. The libs themselves worked fine enough. But the problem is that open-source software is very undisciplined about any kind of binary or API compatibility. The majority of new stuff, always seems to demand the latest new stuff from the other projects that it compiles against. This means that if we wanted to offer foo 2.0, which depended on bar 1.1, but sun only shipped bar 1.0 ... we were stuck with either not offering foo 2.0 at all, or offering our own bar 1.1 for foo 2.0 Then, if we were shipping bar 1.1 ourselves, it made no sense to have our other stuff that also used bar, compile against sun's bar 1.0, when we had the newer,better,whatever bar 1.1 Now, eventually, sun caught up, and shipped bar 1.1 But by that time, we were already shipping packages that depended on CSWbar, not SFWbar. It would be really bad policy to go back and force-recompile and repackage CSWfoo to depend on SFWbar, when SFWbar is going to be out of date again soon enough. At an early point, (mostly for laziness reasons :-) we tried to go with, use SFWbar, unless we need a newer version, then compile against CSWbar. But this eventually dwindled to such a small percentage, there was no longer any real gain to depending on the SFW versions any more. So I made the decision to simplify the user experience ;-) This also hopefully gives end users/admins the cleaner option of, If you like the way CSWgnome looks, you can standardize on it, and eventually pkgrm SFW/SUNWgnome* cleanly, without worrying about, 'oops, I can remove all those sun gnome packages EXCEPT those special ones over there...' There's no clean way to manage that last EXCEPT piece. It was cleaner to just treat Solaris as the pure base OS, and ignore all the SUNWgnome/SFWgnome type stuff. This becomes even more of an issue in the fact that we support our latest version of gnome, on sun's oldest officially supported OS release: Solaris 8. Sun doesnt support SUNWgnome fully on sol8. (last time I checked anyway). We do. Given that we have to do the full gnome dependancy build on sol8 anyway... it would make life far too complicated to ship two very differently linked versions of gnome; one for sol8, and one for sol10. The single version approach is actually beneficial to the USERS, as well as the blastwave maintainers!! This way means that our users can NFS-export out a single /opt/csw, to ALL their solaris 8, 9, and 10 machines, and have gnome work *exactly the same way* on all of them. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [blastware-discuss] [osol-discuss] Re: Can Solaris/OpenSolaris do what Linux has failed to do?
On Fri, Jul 15, 2005 at 01:24:14PM -0500, Eric Boutilier wrote: I have to admit to knowing almost nothing about Ret Hat Inc's position (in theory or practice) on POSIX. i think its about the same as most other linux places: We'll follow POSIX as much as possible... or until we dont feel like it :-) [mostly, it isnt their choice, its a matter of how closely the usual GNU tools installed with linux follow it. Which usually follows my above statement] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
