Re: [osol-discuss] Some Why?-Questions
Then you'll have to re-create your package. If I put the work, which was normally done in postinstall, postremove, preinstall and preremove into SMF, how can I ensure that the sysadmin doesn't accidentally enable package's SMF method which does the equivalent of preremove or postremove? That's fine, we'll just have to disagree. No we won't, because this is costing money. Where can I send the bill, please? See this blog entry for more information: http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting This must be the Nth time you have pointed me to that blog, so let me in turn point certain things out: a) you seem to only echo what others have mused on the subject, and seem to explicitly hold that which they have mused about as absolute right and correct way to do and even think about things b) I have read that blog about five minutes after it was posted, and it was posted on September 7, 2007 And I knew, right there and then, that we're going to be in heaps of trouble, if that vision was allowed to continue. Engineers aren't infallible. We make mistakes too, and are subject to the NIH syndrome, and oft times subject to living in our own little perfect worlds. The key to success is listening to our customers, study how they use the product, ask them what their needs are, spend the time with them in the trenches, instead of isolating oneself, and trying to solve non-existent problems by making them even worse. And your customers, paying customers, in this day and age, are mostly experienced system administrators or even better, system engineers, who know exactly what the issues are and what they want and need. They don't need someone else to tell them what they want, nor do they need someone else to decide what's good for them. You view usage of SMF as an abuse, but I view it as a change of execution context. pkg(5) doesn't say that you can't have scripting, it just says that you can't have scripting as part of the package execution context. Perhaps you can come up with a solution for my first question above, on how to stop a sysadmin from inadvertently running an SMF method which must not execute until the package is removed? And what about these SMF methods lingering around for the life of the package? All the fancy musings, and all the fancy blog entries can not hide the fact that IPS is an artificial solution which has not been thouroughly thought through. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
But Sun has always been engineering rather than marketing driven, and frankly, that's why I like them. :-) When they were engineering driven, I was their biggest fan. But that has not been the case for at least six years now, and possibly longer. Now they are just marketing driven, and Sun is infamous for having notoriously bad marketing which does not understand the product they are trying to market, nor do they understand the target audience they are marketing to, at all. This is not something that has happened over night, it has been this way for the past twenty years or so in the history of SUNW. In the end, we need to move on in a constructive way. They're not oing to axe IPS and replace it with SysV packages or anything else. It's here to stay. Same goes for AI and OpenSolaris as a whole. OK, let's do something constructive: how about adding postinstall, postremove, preinstall and preremove actions to IPS? How about implementing Flash(TM) or the equivalent of compressed flash archives? How about migrating the Python code to C? How's that for constructive suggestions? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Quick Question. pkginfo -q equivalent in IPS
The issue has been thought about and wrote about in great detail. I would refer you, in particular, to Bart's excellent overview of dependency resolution and the problems faced with it: http://blogs.sun.com/barts/entry/satisfaction That's because Mr. Smaalders chose to try to solve a problem which had already been solved, by engineers at sgi, almost twenty years prior! You (plural) have unnecessarily complicated the issue. All you had to do was tack a 128-bit steadily increasing integer to every subproduct (subsytem, subpackage, package), and simply automatically increase the serial number come new revision. The software management subsystem only has to check whether the serial number is higher than that of the product installed on the system, and if it is, the product is automatically marked for upgrade. And if you wanted to be really, really fancy, where you want a third party to be able to upgrade YOUR package and then have THEIR package be upgraded whenever SUNW issues a newer revision, all you had to do was add namespaces to the serial numbers. This, by the way, is how inst(1M) in sgi IRIX solved that problem. Like I wrote above, almost twenty years prior! SAT solver, while being a very clever solution, is also a misleading one, because it is only a partial solution, and is also neither a complete, nor the BEST solution to the problem Mr. Smaalders is trying to solve. If a package says that it needs dependencies a, b, and c. Then it has claimed that it cannot work correctly without those dependencies. So when testing, you are verifying the existing definition. Not saying that my modus operandi is correct in this instance, but I'm used to the FREEDOM OF CHOICE to disregard dependencies when I test a specific package's installation or removal, because not all dependencies are immediate. In fact, a lot of them a purely logical, so they are non-critical to package installation and removal. Things have not been thought through. And claims to the contrary are bad for IPS in the long run. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Quick Question. pkginfo -q equivalent in IPS
And there is also such a thing as premature optimisation. A solution that scales well to 600 million records may not be appropriate for a much smaller number. Premature optimization is the root of all evil. As the students of The art of UNIX programming, none of us here would ever do any such thing as premature optimization; it is against our principles of engineering. What we do in this particular case is overengineering, or rather using an engineering philosophy which I would define as if we can solve it for an unlimited number of clients / x million times higher load, then we have also solved it for one single client and small load. There's a big difference there, between premature optimization and overengineering in anticipation of abuse. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Quick Question. pkginfo -q equivalent in IPS
pkg list ...and pipe the output to grep. That avoids the overhead of interpreter startup time, etc. ...So rather than fix the root cause, you are saying to use a workaround? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
What would the benefit of that be? The target audience, which is sysadmins and system engineers, is familiar with C, and the project stands to benefit from that expertise. Not to mention that C will give you maximum performance, short of writing IPS in assembler. The fact that some portions already had to be (re)written in C is proof enough that Python is not the best solution for the end product. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
Significant portion of softwares in use at large software installations for high-traffic providers such as Google are written in Python. So what? Let me get this straight: just because Google does something, XYZ should also do that something? You mean, like ME TOOs that I've been writing about? Nice. It is important to keep in mind that algorithms generally matter more than choice of programming language. That is, in my experience only, quite a naive view of the industry and programming. By choosing Python, you (plural) chose a programming language just because Google does it, and because it's hip, not because it is the best tool for the job. In fact, you pretty much chose a tool that most people are unfamiliar with, unless they too want to be hip and cool at all costs. You've basically forced any would-be contributor to go an learn Python, a language they might not need or want for anything else, if they want to fix, revise or otherwise collaborate with you on the project. I look at the choices that were made for IPS, and keep help but keep wondering, WHY? Who makes these decisions? What were they THINKING? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
Significant portion of softwares in use at large software installations for high-traffic providers such as Google are written in Python. Something else just occurred to me: since Google does it, why don't we go and tell the ZFS team to ditch C, and simply migrate it all to Python? If Google is doing it, THEN IT'S THE WAY TO GO! No ifs, buts, or maybes. I personally would pay for the plane ticket, lodging, and any other expenses just so I can be there to see Jeff Bonwick's face when that suggestion is made. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
The viability and growth of a tool's community is important when considering choice of development tools and language. What are you saying? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
Welcome to a meritocracy. Those that do the work get to make the decisions as they've earned the right to do so. In this, you are correct. But I also believe that you are in for a surprise: we will see what the acceptance rate of your decisions and your product will be. And also, we will see what good is a product if it will be shunned and not accepted by the very people whose problems it was meant to solve. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
Here you go. Thanks. These docs should tell you ALMOST everything you want to know about IPS-style packaging versus the SVR4 packaging method. You can also do direct SVR4 publishing to an IPS repo. If preremove, postremove, postinstall and preinstall scripts aren't allowed/possible, what exactly gets imported / pulblished if the SVR4 has no physical payload except to do all the work with the pre and post scripts? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
See man pkgsend.1, specifically the generate subcommand, in builds 118 or later. Although I'd strongly recommend build 129 or later due to the significant improvements that have been made since then. So, that explains a whole lot. Last time I studied this technology was at build 114. The full list of publication tools are: pkgdepend(1) pkgdiff(1) -- build 130+ pkgmogrify(1) pkgrecv(1) pkgsend(1) Please note that pkgsend will allow you to import an existing SVR4 package (minus class action scripts), directory, or tarball as the basis for a new package. The man page explains all of this. Yeah, so what happens if my SVR4 package doesn't deliver any files, but does all the work in those scripts instead? I still disagree about two main things, and those are that 1. there should be no pre- and postinstall scripts, i.e. only files should be delivered and 2. that SMF should be *ABUSED* as a backdoor for executing those. The fundamental problem is that the IPS packaging team believes that the definition of a PACKAGE is ONLY that of *FILES*, while customers (aforementioned military, banks, insurance companies, and fortune 100 companies in general) believe that a *PACKAGE* is a UNIT OF CONSISTENTLY REPEATABLE, ENCAPSULATED *WORK*. How do you plan to reconcile those two views? Or are you going to outright try and FORCE people who have developed these technologies and have had them working for the past decade or more? You know, customers have one advantage over the IPS development team, they have existing technology and experience already in place and know from *EXPERIENCE* that the definition of the package as a unit of consistently repeatable work works, and works very well. On the other hand, we have the IPS team which is constantly saying IPS is the way to go, and we're not done yet, and we don't know what the final product will look like, but we're confident that our way is *better*. So, what of it? Now, even the abuse of SMF wouldn't be so terribly bad, SMF supported one-time SMF manifests, which it currently does not do (although it was planned), and the fact that adding one's own instances of a known service (smtp:abcd) is currently non-trivial and REQUIRES quite a but of svccfg(1M) scripting. If you must cause pain, how about developing some sort of method to automatically migrate pre- and postinstall and pre- and postremove scripts to one or more one-time SMF methods? And, one problem which I could not solve, if you think of packages as a unit of work, and we have one-time SMF methods emulating pre- and postinstall and pre- and postremove scripts, how does one ensure that a sysadmin doesn't accidentally enable an SMF method which is the equivalent of a pre- or postremove SVR4 package script? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Quick Question. pkginfo -q equivalent in IPS
No, there are no plans for that. If a package declares dependencies as required, then the package system must install them to be able to manage packages properly. To do so otherwise is madness from a dependency resolution standpoint. So how does one test different subsystems which are delivered as packages? How would I for instance test a package which other packages depends on, and i need to keep adding or removing that package constantly, because I'm perhaps debugging something. I'm sorry, but when I read statements like the ones above, I really can't help but get the impression that this IPS stuff really is nowhere near thought through. With that said, it is planned that publication tools are enhanced so that you can easily copy a package and strip its dependencies if you want to customise it and install your own version. How do you do testing on packages, today, right now, this instant? Are you forced to install all the dependencies of a package just to test that one package? That doesn't seem unreasonable to you, at all? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Quick Question. pkginfo -q equivalent in IPS
And sorry, but you're complaining about .64 seconds? Seriously? I can understand why that would be a problem: if there are large number of packages to query, those CPU times will add up. You have think in terms of scalability. In writing applications which make heavy use of databases, we have something called stress testing, where we artificially generate tables with 5, 6 hundred milion rows, and then do our queries and tuning, even though the application might never use than perhaps 100 rows. The logic is that if the code is optimized for loads that are 600 million times greater than the expected real life workload, and still perform *fast*, we should be able to be responsive and withstand real-world customer beating on the application and the database and not ditch our contract come time to renew because our application is slow garbage. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Which solaris do you use?
As I look at the details, I see, somebody sat there repeated their submission 50 times in 5 minutes. I saw that Solaris/SPARC had such an overwhelming majority, and I didn't believe it. People who run Solaris on SPARC nowdays are far and few between, partly because there really isn't any new SPARC workstation hardware to run on. I also knew that couldn't be right because I studied Sun's own number and the overwhelming majority of Solaris 10 downloads was for the i86pc platform, and not for sparc. To whoever inflated those numbers: perhaps you can use your energy to convince Sun Microsystems or Oracle to start producing cheaper-than-i86pc hardware using SPARC, then maybe there really will be more sparc platform users than i86pc ones. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
You're getting to see the process from the slaughterhouse through the kitchen, instead of just getting the steak delivered on a plate when it's fully cooked like you did before - it's going to be messy, but hopefully we'll end up with a better product in the end. And that's perfectly fine, great even, no problem with that at all! What makes me personally extremely angry and frustrated is the level of *aggresive* marketing and promotion of OpenSolaris as the be-all, end-all, the next big thing, THE Solaris.Next and use it today!, and then when one does actually attempt to use it and finds all these deficiencies, only THEN do the excuses start: yeah there are problems, but hey, it's OpenSolaris, so we still love him, right? yeah it's not perfect, but it's the way to go yeah it doesn't do that, that, AND no, it doesn't do that either, but it's really GREAT! So in the end it turns out that the only thing OpenSolaris does do is be a we're still working on that feature DESKTOP OS. So if it's not cooked, by the admission of the very people that work on it, why is it being PUSHED so AGGRESIVELY by the people at Sun? I can't even begin to pour in words my frustration and how angry that makes me, but believe me, it makes me very, very angry and frustrated. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
If you want to bundle packages together, We do not understand each other. In order to create a SVR4 package, a prototype(4) file must be created, which declares permissions and file attributes in a package, and specifies inclusion of metadata, such as depend(4), and pkginfo(4). In other words, a prototype(4) file declares what the package payload is. I believe that in IPS, this is called a bundle file or a package manifest perhaps? Which tool creates this declaration of package content? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
But there is something broken about abusing the package installation process to setup something as complex as a database in my view. You go ahead and tell that to all those banks which run world's trading exchange systems, and all those insurance companies, and the military. Tell them their super-stable, highly available systems with thousands of such packages are broken. I actually witnessed Sun coming in one such time and telling the customer all about how super-duper OpenSolaris is, and how IPS is the future, and a no scripting zone, until people in the room said wait, we have thousands of configuration packages, and have had them for the last 10 years! This IPS stuff will break all of that! And the Sun guy's jaw dropping on the floor... that OpenSolaris pitch did not go down well. What is the difference between delivering a binary executable, and a preconfigured /etc/inet/ntp.conf? There isn't any. A package is supposed to deliver encapsulated unit of work, not simply binary executables. If we were to follow your logic, delivering any configuration files, or adapting them to the system on-the-fly is broken, and that's absurd. Just because you can't imagine it, that doesn't mean it's broken, or that it doesn't exist. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
Banks should continue to use Solaris 10 *for now* for their database servers and mission critical systems - OpenSolaris releases, like Solaris Express releases before it, are previews of the next enterprise release of Solaris - they're works in progress, good enough for many tasks, but not ready for deployment to scenarios where you want to run the same OS for years without upgrading to new releases. There's a reason it doesn't say Solaris 11 on the CD labels yet. Agreed, and you're right. Perhaps you might answer me this: 1. SX:CE, the closest one has ever come to Solaris 11, is being killed 2. it has been stated on more than one occasion, that OpenSolaris the distribution is the way forward. But with OpenSolaris a) being radically different and b) not being in any shape or form ready for the enterprise, as stated here, what do you believe, or what is your personal vision of what will replace Solaris 10 in the enterprise space? With SX:CE, the ISVs like myself have at least had a chance to test our software and prepare for the future, and be ready for Solaris 11 (such as it was until now); now, with the decision to kill SX:CE, the very ground we stand on is being pulled from underneath us! Sure OpenSolaris might have SVR4 packaging tools, but it is no secret that those are meant for backward compatibility only - which means that sooner or later someone intends for the ISVs to migrate fully to IPS, or be stuck with something that will become akin to /usr/ucb. In my view, that is not a particularly warming or reassuring prospect, ultimately, all the units of work which we packaged up are obsolete, and the only way we can even begin to port to the new system is double effort and trying to execute the work using SMF as the back door. Now THAT is broken by design, works-as-designed. System engineers and developers shouldn't have to resort to using SMF as the back door to reach CMM level 2 and above. [BTW, like everything else you see on this mailing list, from everyone else involved, this is *me* speaking, one person, not the voice of the company. If you want an official Sun statement, contact the press office for a finely tuned press release in which all the content is scrutinized and sanitized.] Understood. And thank you for your thoughts. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
But the next release of Solaris will use the new packaging systems and installers, so SXCE is farther from Solaris 11 than OpenSolaris is. And that also was my point: because IPS is so radically different than SVR4 package format, whoever made these decisions just caused us double workload and doubled the cost. Because if we want to be ready for the future, we must now maintain two sets of packages for every component - one for the enterprise, which is what feeds us and pays the bills, one for being ready for the future. But that costs tremendous amounts of effort and money; it's very expensive. pkgadd(1M) could have been incrementally improved with the backgraph algorithm in AWK and the C programming language books which the make(1) tool also uses, why wasn't this done instead? pkgadd(1M) could have been incrementally improved, based on pkgtrans(1), to have knowledge of true package clusters instead of the loose package metacluster (like SUNWCall), why wasn't this done? pkgadd(1M)'s capability to install packages via http:// protocol could have been extended further, coupled with the dependency resolution algorithm, to automatically install any and all needed packages over the network, like yum install and pkg_get(1M) do; why wasn't this done? I understand you might not have the answers to these questions; but surely someone inside of Sun Microsystems knows! WHY? Of course, the answer could be if you really need it, you could do it yourself, and indeed, I can do it myself. But then, I also have to logically ask myself: if I have to do it myself, what exactly do I need Sun engineers for? For what? They are not giving me what I want or need, and I know how to do it myself, what do I need them for then? Seriously? Radically? It's a different packaging system and installer, and a few default preferences different - something like 99% of the binaries are bit-for-bit identical. A packaging subsystem can make or break the OS choice in lights out management environments, where one has to manage tens of thousands of systems completely non-interactively and automatically. No Flash(TM) capability (or 1:1 equivalent of it) is also a very grave and serious flaw in OpenSolaris. I don't believe I'm capable of stressing and putting in words just how critical the capability of having a compressed image of a system stripped of all system-specific information is. It's ultra critical for large environments. That's exactly what OpenSolaris gives you today - a chance to test your software and prepare for the future and be ready for Solaris 11. It's closer to that future than SX:CE is, and ending SX:CE simply stops you from wasting your time on dealing with the things that are known not to be part of the next Solaris enterprise release. At double the effort and the cost, because the packaging system is radically different. And very, very poorly documented! For instance, what is the equivalent of pkgmk(1) for IPS? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
From talking to both Solaris sysadmins and Linux users that like to change, it seems that the indiana way is not expected/wanted from either party. That's what gets me in this whole circus, something is being decided for us, and we're told it's good for us, but in the end the product tries to please everybody and fails to satisfy either side. The only people clapping at how great OpenSolaris is are end-users, which do not have the capacity to comprehend the issues. And that's unfair to everybody involved. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
you do not think the current state of the patching system in solaris is just broken at the moment? Never had a problem with it, because the management system I employ works completely differently. In my system, patches are never applied to production systems, but to the operating system build herself (I produce my own Flash(TM) builds based on Solaris 10). Once that build passes regression testing with the new patch, it is labeled as production release. This usually takes place at six month release cycles, although I do have automation in place to make it happen earlier, if the fix is critical. An upgrade, of possibly thousands of systems in parallel, if performed by a single click in the web browser of a custom software deployment server, and it'll bring the target nodes down, the network detects them and automatically reflashes them with the new OS build. There are no service interruptions at any point in this process, because the targets are nodes in clusters. I can't currently do these things with OpenSolaris; and it bothers me greatly. I feel your pain though, and i mostly agree with what you say. but i think IPS can be improved to a point where it makes my and your life easier. The biggest pain with IPS right now is very poor and lacking documentation, and inability to run pre and postinstall scripts, instead of forcing the ABUSE of SMF. And no tools to build packages. Compounded, it just exacerbates the pain. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
See man pkgsend.1 And which tool generates the bundle(4) file? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
There is significant end-user documentation, so I'll assume you're referring to publication documentation. And this time, you will be assuming correctly. That isn't true. There are many tools that are available with IPS to create and publish packages. And which tool generates the bundle(4) file? 11 Dec 2009 21:57 UX: NOTICE: last message repeated 17 times -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
Like I said above, my local understanding about David's comment is that he meant OpenSolaris is a Linux replacement /for the LAMPS niche/ . Once again, OpenSolaris is about creating a superior OS for targeted niches, of which LAMPS is one. To win in such niches, you do need to provide functionality equivalent or better than your competitors. OpenSolaris will never make it to the top of the food chain because it has severe architectural issues, starting with the software management subsystem, continuing with breaking compatibility with Solaris, and causing tremendous engineering and software development effort for third party ISVs, of which I am one. And: OpenSolaris will never be able to compete with Solaris 10 enhanced with Oracle, PHP and Apache. Not with all the fancy freeware, not with all the gizmos and GUIs, it won't stand a chance against Solaris 10. It's too unstable to be useful for any kind of system engineering on top of it. Unstable in terms of the software, unstable in terms of architecture. Severely lacking in enterprise features (more on that below). All that was really needed was Solaris 10 with tons of prepackaged and ready to go freeware, integrated into the OS and kept fresh, and more bug fixes, not a complete reengineering effort. That was a strategic mistake. To this end, the common GNU utils found in Linux are now a standard part of OpenSolaris, in /usr/gnu , which is now in the default path. This replaces the old way of prepending 'g' to the gnu tools, which used to be stored in /usr/sfw. The old SYSV utils haven't moved from /usr/bin , and aren't going to be moved or replaced. BASH is now the default shell for root, and I know this is a big thing for many people, as Bash is not a 100% Bourne Shell replacement. /sbin/sh is still there, as is the fully-compliant /bin/ksh. Yes yes, this is all known to me. And to have that changed to the way it was, it causes system engineering overhead for companies and ISVs. That costs money. So by making these decisions, someone cost me money. To whom and where can I send the bill, please? You're mis-informed, as I've stated above. That is EXTREMELY UNLIKELY, as I track changes in (Open)Solaris down to the file level. Almost daily. GNU tools are NOT being modified, David Comay 2008-05-21 22:57:00 UTC We're going to be going through these utilities, one by one, and working on determining which version we wish to use as a base and which changes are necessary then going forward. http://defect.opensolaris.org/bz/show_bug.cgi?id=576 There is indeed a failure here, and it's one of communication: Sun certainly needs to be clearer about exactly what OpenSolaris is targeting, and how it is going to get there. _I_ certainly could use better information. And, yes, I do wish it were easier for outside folks to contribute (and feel like it's worth-while to contribute) more code. Except that people which OpenSolaris is targeted at are extremely unlikely to contribute any code, because they simply do not have the necessary technical expertise - an expertise of a UNIX kernel engineer. Wrong crowd, and a gross miscalculation. Or perhaps, nobody even stopped and considered it, which is more likely. Those people aren't kernel or system engineers, they are me toos. How does it NOT feel like Solaris anymore? Because your default path is different? Because we've dumped the ancient (and frankly sucky) svr4 packaging system? ABSOLUTELY! Not only was SVR4 packaging ditched, instead of being INCREMENTALLY IMPROVED the Toyota way, the designers of IPS thought themselves extremely clever by not providing pre- and post install and remove mechanisms. As a result, SMF is now being overloaded with the equivalents of pre and postinstall and remove scripts, because people are basically forced to use SMF as a backdoor for automation and reaching CMM level 2 and above. Nice. Because of course, if Shawn Walker Co. can't imagine that someone would want to package preconfigured configuration files, or have Oracle configure herself on the fly during installation, it doesn't exist. Because more GNU (and other freeware) packages are now included as part of the default install, instead of on the Software Companion CD? Because the hideous piece of crap that was CDE is being dumped overboard 10 years late? I couldn't care less what GUI du jour is used or dumped, because a properly engineered system doesn't even need a GUI. When you have tens of thousands of systems in a lights out management environment, the desktop GUI concept is completely useless, and that is the case here with me. Solaris 10 needed more software, yes, integrated into the operating system, so that people like myself (and others) didn't have to spend sleepless nights integrating Postfix for instance. That alone cost us about $18,000 USD. We needed incremental improvement, more
Re: [osol-discuss] Some Why?-Questions
I suspect he's a holdover from the switch from SunOS to Solaris, way back in the early 90s. SunOS was a BSD-based system, and many old-timers really disliked the switch to the SVR4-based Solaris. My first Solaris was 2.5.1. So I started off on a System V Release 4.0 UNIX, and I feel extremely lucky that I did. Then my voyages took me to IRIX, which had also just completed the transition to System V Release 4. That was an awesome piece of technology to use and behold; a true multimedia UNIX. Then I ended up on HP-UX 10.20, and being that hp too went the System V route, I was right at home. A rock solid, high performance OS with an intelligent, advanced software management subsystem, SD-UX, high performance hardware (PA-RISC), and a really advanced volume manager, it couldn't be anything but love! I suspect AIX, even with all his idiosyncrocies, would have been OK too. It's too bad I didn't get a chance to work on him in-depth as I did on the other three. I regret that to this present day. All of that of course is ancient history. If he's wedded to the *BSD way of doing systems, well, then, he's likely using an apt-based Linux (Debian or Ubuntu) rather than an rpm-based one (SUSE or RedHat), and it's gonna be hard to get him to change his mindset. But at least olaris still has the SunOS userland utils in /usr/ucb Actually, I spend my days trying to make SuSE Linux Enterprise Server do the things Solaris can do with Flash(TM) and JumpStart(TM). And I'm making RPMs and doing system engineering all day long. Before that, I did the same on redhat Enterprise Linux. When you've come from sgi IRIX, and HP-UX, and Solaris, you get to experience just how miserable and deficient even enterprise GNU/Linux solution is. Stuff's just not cooked or thought through. And, now, I see OpenSolaris going that same route. sk him how he feels about HPUX. :-) I like HP-UX. I do development on it, and lots and lots of porting, compiling and packaging on it. What I dislike is that it is not gratis, and not easily available. And that it is obscure. But it's a good, solid, high performance, System V enterprise UNIX. UNIX! -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
How are they worthless? They all install fine, since compatibility was kept with the System V packaging system. I was told in no uncertain terms, by a Sun engineer I respect and trust, that IPS will be the way forward, come hell or high water, and that unless I migrate to IPS, all of our System V packages will be in backward compatibility, maintenance mode. So now we're stuck: double engineering effort - produce two sets of every package. Except one, SVR4 is well understood and documented, and other very poorly understood and documented. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
Sorry - just realized my mistake in replying to this mail too soon after having a different discussion and not shifting my brain fast enough - root's shell is bash, /bin/sh is ksh93. Errare humanum est - to err is human. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
There are few compatibility breaks that affect ISV's - what is breaking your software? What happens on OpenSolaris when one tries to install a System V package that runs a CREATE DATABASE inside of postinstall and SQL*Plus? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
The better question is why someone is doing something so broken in the first place. There is nothing broken about being able to consistently and repeatably create databases via packages. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is Oracle getting ready to kill OpenSolaris?
(Though unlike the other part of your suggestion, we're not going to maintain a separate install packaging system for Solaris, but will replace Solaris Express with the OpenSolaris installer packaging.) That's lovely; you (plural) will phase out a stable packaging subsystem in favor of a Python-cobbled together experiment that explicitly DOES NOT ALLOW SCRIPTING. I'd just like someone to tell me just how I'm supposed to remove my Oracle database with an IPS package. And if anyone writes SMF, then I'd like to know just how exactly will I run an SMF method to remove a database, when IPS doesn't allow scripting. In closing, I'm convinced that IPS in his current shape or form is one of the biggest technical mistakes in the history of SunOS. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SPARC Rock is dead,
Now when you talk about the mid-range to high-end market, such as the M-series it's a difficult ballpark. Unless you throw in someone like Unisys or Bull, you can't find an x86 system that'll have the amount of CPU's, Memory, or I/O; let alone RAS features. Maybe not, but like I keep hammering, RAS can be solved with: 1. IPMI (as crappy as it is, it's just good enough) 2. clusters. Got a fried CPU, motherboard, or power supply? Take the whole node down, without taking the service down, and pay a lot less money in the process! I used to work with really, really expensive supercomputers (sgi, Sun, hp), and it was really cool, so long as I wasn't the one footing the bills for them, and so long as sgi, Sun and hp kept lending or even giving us the hardware. But now that I'm the one footing the bills, it's a whole different ballgame. Now I realize just how ridiculously expensive that big iron hardware is. And now that I'm forced to compensate for not having big iron, I realized there are creative ways of having big iron performance without paying big iron prices. Sure it might take more (re)engineering in terms of software, but hey, I save tons of money on electricity bills alone, not to mention upfront savings on hardware! Like Jonathan Schwartz once wrote, there are always people willing to sacrifice their time effort instead of doling out cash. I'm one of those people. If I have the skill and experience, why not put it to good use to pay less? Even with my time, effort and materials, it's still a whole lot less money than doling out say, $75K for an entry level SPARC/SPARC64 system. In that space only IBM Power and HP Itanium systems can compete. Well, people are changing that game, with armies of cheap clusters. The junk is cheap and reliable enough, and if it does die, take the whole thing, throw it away, and put another one in. It's throw-away, expendable, cheap hardware. It's like going to a store and buying two or three drill bits for half the price of a quality drill bit, because you know that the first one is likely to break, the second one is likely to finish the job, and the third one is just, well, bonus, reserve. All you have to do is make sure your software is designed around running on a cluster. Yes that's hard, yes that's challenging, but that's what that degree in computer science was for! The other reality is that you can do some serious consolidation with the T-Series and the M-series. You don't need as many physical servers to replace your old Ultra Enterprise or Sun Fire servers. Ultimately, this is what's hurting Sun and even IBM. The difference is that IBM doesn't give away the software, virtualization, and management components away for free. Neither does Sun, for that matter. Zones is a runaway project that perfectly illustrates my point: there can be 8192 zones per server. Now, if you have tens of thousands of servers, how will you manage all those zones? xVM ops center? That's just an afterthought, and it lacks software, inventory, and change management. Stereotypical: Sun invents some cool new tech, but they only make it work for a single developer on a single system. Zones is a perfect example of that. Clustering zones? An afterthought, and how many years did it take Sun to even bring Sun cluster to a point where it's zones aware? Examples like this go on, and on, and on. No wonder small players like Jomasoft with their VDCF are reaping all the cream, while Sun scrambles to get bought by someone else. So consolidation with Sun T and Fujitsu M series isn't as simple or straightforward as it seems. Without the right tools for the job, you need an army of skilled Solaris system engineers (not even admins will do!) Good luck finding those in this day and age of cheap Linux and Windows sysadmins. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] basic how to for solaris express community?
For instance, the install didn't allow me to create both a root user and an admin user account like the opensolaris install does. I've been able to log in as root and create a user but how do i convert the system to the root role type system of opensolaris? You don't need it; all OpenSolaris distro is doing is imitating Apple OS X and Ubuntu with that. Also, how to i give my user account the ability to behave like it does in opensolaris (when i type pfexec bash i don't get a root terminal, i can log in with su but that is different) You don't need that either, but if you really want to fiddle with it, you'll have to study and master RBAC, and create an appropriate role for that. It's not worth the effort, but if you're curious enough, you can figure it out (with the help of http://docs.sun.com/) and set it up. I strongly recommend to forget the latest fashion fads and `su -` the good old fashioned way. Lastly, is it just me or do new users have an empty path profile? do you edit this in the .profile file in the home directory? It's one of the flaws of Solaris. Rather than using /etc/PATH and /etc/MANPATH like HP-UX does, all the shells have their individual configuration files in /etc, for system wide configuration; and then, there's also /etc/default/login and /etc/default/su as well. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Cloning / Backup of Solaris 10 Server
May I know what are the methods(either commandline or external software) in which I can dump out an image of the Suns Solaris 10 server I've installed? Alternatively, performing a full backup (including system configurations) of the server. See the manual page for flarcreate(1M). -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] basic how to for solaris express community?
The thing is trivial. If you can't master it, refrain from advising others. Buddy, I've got formal education and training in using RBAC. RBAC is *very* good at what it is meant to be used, large systems with different administrators doing different things. Don't compare it with sudo or su, for that matter. It's in a different league from that point of view. Nothing that is overly complex for what it needs to be can claim to be good. A matter of opinion again. No, it's not a matter of opinion, it's a matter of experience. HP-UX has had /etc/PATH and /etc/MANPATH for decades, it's the 21st century and Solaris still can't get it together or get it straight for that matter. Meanwhile, /etc/PATH and /etc/MANPATH system has been working wonderfully on HP-UX all these decades. As far as MANPATH is concerned, unset it on OpenSolaris. man works it out of PATH (I guess unless you want any special search rules, but for normal work that's best). The OP was asking about Solaris Express: Community Edition, which is most similar to Solaris 10, not the OpenSolaris distribution. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SPARC Rock is dead,
It's now a matter of time before programmers figure out how to really take advantage of the hardware, OS, and libraries. That's the part I really dread. I've spent the last six years in Europe, and what I've seen there was a disaster enough to make one's hair stand up on one's head. There are so few good people left, most of the programmers are completely incompetent, from incorrectly linked libraries, to using GCC, to package abominations; and the software, even coming from the United States, is not much better. It's like all the UNIX people vanished into thin air, and were succeeded by cheap Linux and Windows oh why must I support this Solaris thing people. In many ways, Sun is way ahead of the curve and unfortunately, the market wasn't ready. That's true. But that's not what really busted Sun. What busted Sun was pricing. Pricing and pricing alone. Times have changed, but Sun stayed stuck in the beginning of the '90s of the past century. They, even the engineers, stubbornly kept repeating reliability, availability, serviceability mantra - at exorbitant price premiums, except that the market had moved on to cheap i86pc Opteron and intel powered clusters, which can be up to 100x cheaper than what Sun was trying to sell. And that's why eventually, I became firmly convinced, that unless Larry makes SPARC systems dirt cheap, as cheap as Opterons and intels or even cheaper, I believe that SPARC days are numbered. Perhaps not right away, but if sparc hardware doesn't become as cheap or cheaper than i86pc hardware, it'll be the last nail in the coffin. Because the market has already voted with their Euros/dollars/francs. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SPARC Rock is dead,
I really wonder what the problems were with Rock though that made David Yen leave for Juniper and Marc Tremblay leave for Microsoft. 12% to 25% over UltraSPARC T2+ performance gains were cited by Sun's own sales reps. Some of the performance examples cited 2% - 7% improvement. I don't know about you, but in my opinion, that's miserable. Couple that with the fact that most customers' software is such garbage that it's not capable of running on more than one CPU, and therefore most customers aren't not able to take advantage of many slow performing hardware threads, and the disaster becomes pretty apparent. Sun had a good idea, but they either didn't want to invest enough funding, or didn't know how to make their existing UltraSPARC design into a powerful number cruncher, like IBM did with POWER. However, Fujitsu did manage to do that with SPARC, but their hardware is so exorbitantly expensive, that it makes store.sun.com look like selling peanuts in comparison. If that isn't a recipe for disaster, then I don't know what is. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris' future... should we be worried?
Hi... I am a concerned user of OpenSolaris who fears the distribution will be called off as soon as Oracle completes acquisition of Sun. Is this true? I would be more concerned about OpenSolaris Indiana becoming the next Solaris 11, than anything else. Everything else is small potatoes. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [desktop-discuss] SXCE 109 python 2.6 curses support bo
The python build scripts rename the modules to *_failed if they were built but could not be loaded for some reason. This is a known problem. Usually it happens because Python's build engine is very fragile, and does not link the .so libraries properly (i.e. no -R, and -R$ORIGIN/../lib is pure science fiction for those guys). I fought with this for about a month on HP-UX. Finally had to give up all optimizations and use their vanilla compile, and even then it didn't quite work, see below. In this case: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.11-i86pc-2.6/_curses.so: symbol wchgat: referenced symbol not found Correct, this is a known problem as well, and it has to do with the version of (n)curses used, if I remember correctly. Thanks for the report, I'll fix this. How will you fix this??? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] rge driver is broken
pci bus 0x0008 cardnum 0x00 function 0x00: vendor 0x10ec device 0x8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller This driver is problematic. It does not work correctly on Solaris 10, nor does it work correctly on Solaris Express, or actually any platform based off of the Nevada codebase. It seems that the basic framework for implementing functionality is in place, but HW checksumming does not work. In addition, it appears that there is more than one revision of this ChipSet, and the rge(7D) driver is incapable of dealing with that situation properly. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris 10 10/08 runs very slow when upgraded memory from 4GB to 8GB
This isn't the place to ask, solaris...@yahoogroups.com is more appropriate for Solaris 10 x86 questions, please follow up there. You know, after thinking about this some more, I'm no longer sure that that is correct. OpenSolaris code base stems from Solaris 10. Do you see where I'm going with this? And, we've traditionally always redirected Solaris questions away from this forum, because Sun wanted to make money selling support for the OS. But you know what? Other than SX:CE, there really isn't anything else to run than Solaris 10, that *runs right*; OpenSolaris the distribution is a horrible abomination that will never run correctly, because it is not pure Solaris or even OpenSolaris. So there isn't really anything else to run. And I'm sick tired of catering pandering to Sun's corporate agenda, so I actually think it's wrong to turn people with Solaris 10 away from opensolaris.org. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Best practices? user creation? sysadmins please ADVICE!
But, Ive heard that to be able to search directories, they must have set x bit, so directories: rwx r-x r-x and files: rw- r-- r-- that sucks. I must treat files different from directories. I can not do chmod -R 744 /tank You can either do what Casper wrote, or you can also do the following: find /tank -type d -print | xargs chmod a+rx find /tank -depth -type f -print | xargs chmod ug+r,o-rwx However, Casper's solution is slick elegant, as usual. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris vs HP-UX vs AIX
Is HP-UX 11i bundled with HP Virtual Server Environment It would be the other way around, but I don't remember seeing it on the DVDs; normally when one performs an HP-UX install, it will be years before another install is performed. From hp's web pages, it appears that VSE is a product which requires a paid license; there is a 90 day trial version available for download. and HP Serviceguard the same thing as what WPAR's are on AIX 6 and what Zones / N1 Grid Containers are on Solaris? What are the similarities and difference between them? I don't know squat about IBM's virtualization technology, but VSE is nothing like containers and zones, and very much like XEN, conceptually. Anyways, why don't you explore VSE, and make comparisons to Solaris zones containers for yourself: http://docs.hp.com/en/T2767-90180/ch01s07.html?btnNext=next%A0%BB -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris vs HP-UX vs AIX
And just because you run Oracle doesn't mean that you have to run Solaris, right? It doesn't, but it'd be foolish not to run Oracle on Solaris. Solaris is optimized for Oracle, and Oracle is optimized for Solaris. Oracle seems to be trying as hard as they can to cut all ties with Sun, even going so far Is there an official statement anywhere to this effect? I was elated to determine that Oracle has released 10.2.0.4 for 32-bit Solaris on the i86pc platform. I also know for a fact that MySQL runs faster on Linux than on Solaris because of the kind of screwed up way in which Linux allocates memory. I read an article about it in a Sun engineers blog, can't remember the URL off the top of my head though. MySQL is not a relational database management system, it's a shoddy SQL interface to a filesystem. MySQL features data corruption bugs which have been known since 2003, and they still aren't fixed; it is pointless to even mention MySQL just because the majority of database-incompetent people make it a fashion fad. Unfortunately, just because something is a fashion fad, does not automatically make it function correctly. Besides, to anyone even remotely considering the possibility or running MySQL, I can recommend PostgreSQL. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Reboots of nv111
Didn't have this before, so I wonder if it has to make with nv111? Around once per day, the mouse pointer freezes (be it in a terminal window or web browser), Kernel panic? then the hard drive LED is 100% active, Kernel writing crash dump? That's almost a 100% given, judging by the details he describes. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris vs HP-UX vs AIX
Has anybody around here ever used HP-UX or AIX or any other relevant non-BSD, non-Linux UNIX-style operating system before? I use HP-UX every day, especially since I have HP-UX servers at home and do heavy development and system engineering on HP-UX. If so, what do you think are the disadvantages and advantages of these other operating systems vis-a-vis Solaris? - HP-UX has POSIX binaries in /usr/(s)bin, something Solaris still does not have (POSIX XPG4 is in /usr/xpg4/bin, XPG6 is in /usr/xpg6/bin, not in PATH by default). - HP-UX is *hardcore* forward and backward compatible; moreso than Solaris, and that's a good thing! - the compilers are excellent, state of the art, and very similar in capabilities to Sun Studio! - HP-UX has /etc/PATH and /etc/MANPATH, the greatest thing since sliced bread... try to guess what those are for (I'd love to finally see that integrated in Solaris, I have the code ready and working) - the OS is high performance; really, really fast, and he's rock-solid-stable; this is probably his main strength and motivation for deploying HP-UX - the software management subsystem, SD-UX, is in most respects way more advanced that even the latest IPS (indeed, IPS looks like a toy in comparison to SD-UX, and so do pkgadd(1M) and friends): SD-UX supports bundles, products, subproducts - hierarchically ordered, limited regular expression version matching, match what target has. Some of the disadvantages: - SD-UX *does not* remove empty directories upon software removal (unbelievable, but true!) - SD-UX does not appear to have an equivalent of class action scripts like pkgadd(1M) and friends do - HP-UX has no way (at least not in 11.23 - 11i v2) to power the hardware off (or perhaps the hardware has no software poweroff) - runs only on hp proprietary hppa and ia64 platforms (in reality, 11i v3 runs only on ia64 nowadays, and a few select hppa models) - has practically no free open source software bundled with him (hp's internet bundle is really, really LAME - and old!) - every piece of software is installed in its own separate directory: /opt/tcsh, /opt/blabla, ... - not available to the public, you have to have bought the hardware to get the media, and even then, it might very well be locked down for use by only so many users - MirrorUX is an additional, licensed product, costing extra, as do the compilers, which in this day and age is intolerable I chuckle every time when some GNU/Linux wannabe here gripes about how Solaris is missing this, that, or the other; they should try working on HP-UX, *THEN* they would know, what a bare OS looks like!!! For example, I had to compile my own python(1), get my own Mercurial hg(1) working, my own ncurses(3C), my own screen(1) utility - even my own less(1)! (Yes, I know about the hp-ux archive and porting center, and I hate it, because they don't know what they are doing, stuffing everything into /usr/local, which is against the System V spec!) All things considered, and you'll often read me write this here, HP-UX is a System V UNIX; and being one, apart from the hardware dependent commands, HP-UX is very, very similar to Solaris; oldskool System V folks should feel right at home on HP-UX. All in all, excellent OS, it's really too bad hp is *intentionally* killing him by not doing what Sun has done for Solaris. I found this interesting link that compares HP-UX to Solaris and seems to argue heavily in favor of Solaris being easier to use: http://loudermilk.org/software/solaris-hpux.html That is an old, well known essay. I don't believe either is easier to use over the other; again, they're both System V UNIXes, so if you know Solaris, you know HP-UX, and vice-versa; those few platform dependent commands can be learned fairly quickly and painlessly in both operating systems. That is also one of the reasons why System V, apart from being strictly engineered to spec, is vastly superior to GNU: it's consistent and ubiquitous. down compared to Red Hat with it's: Starting this [ OK ] / [ FAILED ] messages. Now you know where GNU/Linux *lifted* it from: HP-UX! And the chkconfig(1M) was lifted from IRIX 6.5! Basically, anything that is cool in GNU/Linux was stolen from a System V UNIX, be it Solaris, IRIX, or HP-UX. I also didn't mention any of the other non-BSD Unices because I've been doing some research and SGI's IRIX The most advanced, way ahead of his time System V UNIX ever: IRIX. Even Apple computer's OS X still hasn't caught up to him in terms of user friendlyness and audio/video capabilities, and considering IRIX hasn't been developed since 2006, that says a lot; and the software management subsystem still has no match in the computer industry; it is still the most intelligent and most advanced, bar none. Remember- in the end... there can be only one! Yes - System V! -- This message posted from opensolaris.org ___
Re: [osol-discuss] Proper syntax to make syslog create a file
Wow... that seems a little extreme. So first I'd need to learn all about creating packages. Correct. If you continue delving into Solaris, you will need to learn this sooner or later, so better sooner than later. Why is all that necessary? So that you might reach at least CMM level 2: consistently repeatable. http://en.wikipedia.org/wiki/Capability_maturity_model You'll also learn a lot through the whole adventure: about processes (workflows), about process modeling, about WHAT NOT TO DO, and about what to do, and of course about syslogd(1M), packaging, and logrotate(1M). Even for an enthusiast, it will make you more productive in your tinkering. And it might very well be fun, too. Do you mean to e maintenance free...? Correct again. I see you catch on fast. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Osol based app that bcks up windows machines to zfs
Maybe Unix Admin didn't notice that I commented on `bacula' in my original post... I did indeed. I normally react immediately directly to paragraphs I read, because I find reading through the whole text is often disruptive to my thought flow. I caught the reference in your text in the second pass, but in my view, the question and the answer still stands. So can you tell me if you've had recent experience with it and can vouch for the usability of the windows clients (the part installed on windows machines)? No, apart from that Windows is supported. From what I used Bacula for (I compiled from scratch), it seemed to work as described on UNIX. This was also about two years ago. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proper syntax to make syslog create a file
Can anyone tell me what I need to do in /etc/syslog.conf To make the system logger create a file if it isn't present. I wanted a general debug file so put this in /etc/syslog.conf *.debug/var/adm/debug hen I boot up I get error about there being no /var/adm/debug present. If I touch /var/adm/debug, the error goes away on reboot. Where is this kind of thing controlled? Maybe /etc/logadm.conf? Or is it just required for admin to create the files by hand? The clean and proper way to do this is to create a package, which does the following things: 1. declares a payload file /var/log/debug, as ZERO BYTES in size 2. defines the /var/log/debug file as type v (for variable) in the package prototype file 3. automatically checks, and if necessary, makes an entry in /etc/syslog.conf for /var/log/debug in the postinstall file of the package 4. signals syslogd(1M) with SIGHUP that a configuration change has occured, also in the postinstall file. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Osol based app that bcks up windows machines to zfs
Setup: Opensolaris.11 buiid 110 I've wondered if there is an application available for OpenSolaris that is capable of backup (incrementally) windows machines across a network? Yes, there is. It is called Bacula (http://www.bacula.org/), and it is conceptually very similar to Legato NetWorker, the major difference being is that NetWorker is an enterprise commercial product, and Bacula is free and gratis. Bacula uses a PostgreSQL RDBMS as the backend for keeping track of backup operations and scheduling; the software supports streaming from multiple clients, and it supports Jukeboxes and tape libraries via mtx(1M). Windows clients are also supported by the software. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] disconnecting hdd from zfs mirror hangs whole
That's all you needed to supply. The CR was closed by renaud.ma...@sun.com, who noted in the evaluation that vold is gone, Tamarack replaced it, and that Tamarack *does* handle ZFS storage pools. The CR was then updated by artem.kachitch...@sun.com, who noted that Tamarack did do this, but that the methods it added are not invoked by USB hot plug, so that's still a problem. I appreciate the additional information, and I also appreciate the fact that you took some of your time to research this. As you might or might not be aware, not being a Sun Microsystems employee, I do not see those additional fields, so when a CR gets mutated, I have no way of knowing who manipulated it; if you hadn't researched it, I would have had no way to know what happened and who to contact. You probably shouldn't assume that developers are either (a) trying to thwart you deliberately I have no reason to assume that. or (b) actually paying attention to your individual needs. I'm sorry, but something as trivial as consistently mounting all kinds of removable media (which the OS supports) does not classify as my individual needs; further, I believe this to fall under basic operating system functionality. Do you agree? Software development is just not the same thing as paid support. If you need paid support, there are solutions for that, but arguments on opensolaris-discuss probably won't get there. Again, I'm asserting that this is basic operating system functionality; if you disagree with me, I ask you to please explain why you think that I should be paying support to have removable media mounted automatically. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun's Six Biggest Mistakes
http://www.forbes.com/2009/04/06/sun-microsystems-ente rprise-technology-enterprise-tech-sun.html I'm not a Sun Microsystems employee, but from my perspective as an outsider, and considering the end results, I would tend to agree with everything in that article. In fact, the article only reiterates what I have been writing about for years. Noone listened, which is not surprising. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun's Six Biggest Mistakes
Same here. Instead they complain about me because the (mis-)believe I'm trolling or flaming. They cannot see that I tried to help them. Like MANY OTHERS. I'd make one small change though: I wouldn't lay off any engineers. I'd fire or demote all of middle management. And enjoy every microsecond of it. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun's Six Biggest Mistakes
when a company is struggling, there are millions of analysts and experts who come up with zillions of reasons for not doing well. Very conveniently these reasons come up only after the fact. No, that's not true in this case; you can easily find my writings on the subject dating at least three and possibly five years ago. They're all over blogs, all over the 'Net. And as far as being an analyst after the fact, I'd gladly step up to the plate and become the next Sun Microsystems CEO; and I promise nothing but blood, sweat and tears to get the company out of the state it's in. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] uname -a ... 32bit vs 64bit
style type=text/css
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
/style
div id=jive-html-wrapper-div
div dir=ltrfont face=Tahoma color=#00
size=2When I run quot;uname -aquot; it
says:/font/div
div dir=ltrfont face=tahoma size=2SunOS
hostname 5.10 Generic_137138-09 i86pc i386
i86pc/font/div
div dir=ltrfont face=tahoma
size=2/fontnbsp;/div
div dir=ltrfont face=tahoma size=2In the
past, I've seen the system say quot;x86_64quot;
when you're 64bit.nbsp; And I've also seen it say
quot;32bitquot; when you're 32bit.nbsp; But now it
says nothing, so I'm left confused./font/div
Actually, that above, i386 i86pc i386 is the standard string as returned by
Solaris.
i86pc platform contains both i386 and amd64 ISAs, which is why it is
technically incorrect to refer to Solaris on the i86pc platform as Solaris
x86, because that would mean 32-bit Solaris only.
Further, you should not be concerned about whether your OS is 32- or 64-bit,
since Solaris runs BOTH at the same time, transparently.
If your hardware is 64-bit capable and you haven't explicitly forced booting of
a 32-bit kernel in GRUB, Solaris will automatically be in 64-bit mode, while
still being able to execute 32-bit applications transparently; in fact, most
binaries will still be 32-bit, even though the system would be running a 64-bit
kernel!
However, if you really want to know, all you have to run is:
isainfo -vk
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] disconnecting hdd from zfs mirror hangs whole
Why is it though that it appears many gnu tools have been adopted for Opensolaris? Is it just to try to make a transition for linux users a little less painful or something to do with licensing? Somehow someone at Sun figured that they wanted to woo all the Linux developers over to Solaris and to build up user base. The flaw in that logic is that hardcore Linux developers WILL NOT migrate to SunOS, and the users that would migrate can't tell one from the other anyway, because they aren't technical enough; those should have been brought up to speed on System V, not given a crutch, AND generate enormous amounts of system engineering bringing GNU userland on top of SunOS in the process; those system engineering efforts could have been better spent elsewhere (like finally getting USB and volume management to work correctly!) Most of those users aren't technical enough to use the command line tools anyway, as is plain visible from many of the posts and questions here. Hence a severe logic flaw. Another reason for bringing GNU into SunOS is that much of the free open source software has been migrated from Solaris to GNU/Linux in the mid- to late '90s,, and now REQUIRE tools like GNU make, GNU AWK, and the GNU C Compiler to build. One of the reasons for this state of affairs is that for the longest time, Sun Microsystems did not release their professional compilers for free; another reason is that SPARC hardware was too expensive, and support for the i86pc platform was flaky. It wasn't until the community of Solaris (not OpenSolaris!) users and sysadmins lobbied and stood up, that Sun management changed its mind; otherwise, in their folly, they would have dropped the i86pc port completely. Ironically, because Sun hardware was (and still is) so expensive, it made one guy so angry, that he started writing his own UNIX-like operating system for i386; the OS he started back then is now known as GNU/Linux. You might know this guy by the name of Linus Torvalds. Its probably getting far off topic for the thread but I wondered if you might list a few of the major deficiencies of gnu tools you are referring to. I already mentioned some (:-) GNU stands for GNU is not UNIX: tools implement other tools inside of them; the usage is inconsistent; no forward or backward compatibility guarantees (in fact, no guarantees in that respect of any kind!), no full POSIX compliance; deviation from accepted UNIX standards and practices, in the we know better than professional engineers that have been doing this for the last 40 years style. And the GNU tools are mostly inferior products in terms of performance: for example, GNU AWK is slower than System V AWK (this has been chewed into oblivion on the Usenet); or GCC generates slower code than any vendor's compilers (Sun Studio will trod GCC into the ground in hands of a person who knows what they are doing); or the GNU tar utility generating broken / incompatible tar archives (and implementing a compressor, something a Tape ARchiver is NOT supposed to do!), or GNU make breaking compatibility with regular System V make (GNU Makefiles cannot be processed by System V make as it stands right now). And let's not forget bash: a broken we know better replacement for Korn and Bourne shells. But here, then, is the real kicker: I with my knowledge of System V can burn and tear through GNU/Linux *anything* with ease; but someone weened off on the GNU diet, is hopelessly lost on a System V system. And with knowledge of Solaris, I can use *any* System V UNIX (HP-UX, IRIX for instance) without breaking a sweat, since they're System V UNIX based too. What angers me the most is that such people perceive System V as deficient, while in reality System V can do anything GNU can, and then some (clue in the ACL fiasco again), provided one knows what one is doing. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] disconnecting hdd from zfs mirror hangs whole
I have had different experiences than you in this respect. All I was trying to say is that they have excellent ideas, but the implementation has traditionally fallen short. Case in point is Java, write once run anywhere is a grand idea, but the complex language and lack of a compiler make the implementation a complete disaster; or ZFS root mirroring which -- when the mirror is detached or dies -- simply panics the system at next reboot. Or volume management, which to this day doesn't work correctly (one can't create a zpool on a removable device, then eject (zpool export) and plug that device somewhere else and have it instantly imported by vold(1M). And if you're interested, the RFE for this was closed as will not fix. So much for the most advanced operating system on the planet. While it is true that Solaris has revolutionized UNIX in some respects (ZFS, SMF), it is also true that it always somehow manages to fall short of truly being the most advanced operating system on the planet. Not to say that the competition is any better, it's a disaster, but logically, that's irrelevant, since the focus is on Solaris and Solaris alone. I can tell you one thing with certainty: it's a lucky thing for Solaris that sgi management was corrupt and incompetent and managed to kill the company, and IRIX with it: IRIX would have crushed Solaris in every respect, had he continued to be developed; if we compare IRIX64 6.5.x with his Solaris counterpart of the day, IRIX destroyed Solaris in just about every respect imaginable. Had the development continued, IRIX would have been continued to be light years away; if I wrote it once, I wrote it a million times: if IRIX lived, Solaris wouldn't stand a chance, if we compared the two feature-for-feature. Ironic, considering both are System V UNIXes. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] uname -a ... 32bit vs 64bit
Also: I personally don't understand why Sun made that design decision back in 1997/98 to treat a booted 32bit kernel and booted 64bit kernel as the same platform, and hence to identify it with the same uname() field values. In this case I prefer how linux handles it. Why? It makes perfect sense. When you're on Solaris, the system is *architected* such that you don't care whether you're on 32- or 64-bit (/usr/lib/64, isaexec(3C)), and it is *engineered* such that it will automatically use/boot the correct kernel. So why worry about it? Why care about it, if the system can figure it out for himself? I would think that all you should be concerned with as a developer is to deliver both 32- and 64-bit versions of your binaries in a single package, and let isaexec(3C) figure it out for you; and as a consumer, you shouldn't have to break your head about such things; that is one of the things which were architected and engineered correctly in my experience. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] disconnecting hdd from zfs mirror hangs whole
actually, this is two-sided coin. Sun Studio supports less architectures and less languages than gcc. I was writing about the compiler himself, not the front end 'cc'. Yes, what you write is true; but let's face it, any high-performance or system stuff will be written either in C or Fortran, what with Fortran still being king of HPC, and those are two languages that Sun Studio supports very well. You'd probably be surprised, but it just spawns gzip/bzip and doesn't compress anything by itself. I'm not surprised at all; in fact, that's the way to do it (or call zlib/bzlib). The only difference between spawning it manually+piping and spawning it automatically via -j/-z is ease of use. Ease of use at the price of portability: GNU is not a standard of any kind, so a lot of UNIX systems will not have GNU tar. tar cvpf - bla blabla | lzma|bzip2|gzip -9c archive.tar.lzma|bz2|gz will work everywhere, provided those utilities are present, and will generate a System V compliant tar archive, with correctly stored attributes (if USTAR is used), whereas not having GNU tar installed 'tar cvpz ...' will break. Portability, especially in shell scripts, is still more important than convenience, no ifs, buts, or maybes. Stating bash is replacement for ksh and sh you revealed quite strange perception of reality. bash is just a shell. There are lots of shells around, and not all of them are compatible, even ones trying to be. For example, zsh is not ksh-compatible. zsh goes above and beyond and out of his way to be as painless as possible to use for ksh and tcsh users, something bash, in utmost arrogance, does not do; even David Korn did not deviate from being compatible with Steve Bourne; there is a lesson to be learned from that, one which was obviously either not learned, or arrogantly disregarded by both the original author and the current maintainer of bash. And although the authors of zsh themselves admit that they are not POSIX compliant, which is a pity, I at least give them credit for not being arrogant in their implementation of zsh and admitting their own flaws. It commands respect, something the GNU community has no concept of, in my own view and experience. Also, there are csh and tcsh -- are they we know better replacements for ksh too? No; csh came about the same time as ksh, and was a research effort of Bill Joy; and tcsh is that concept taken further, on to become a superset of csh. Although I'm an avid tcsh fan and daily user, I am well aware of tcsh's flaws and weaknesses, which is why most of my production scripts are written to be simple Bourne shell programs; unlike the bash creators and the GNU club, I wouldn't dream of being that arrogant to assume that there is only one shell and only one operating system - GNU/Linux. That's almost the Microsoft view on the world. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] disconnecting hdd from zfs mirror hangs whole
That tinkering lead me to tryout a free OS being offered by Solaris. As I recall it cost something like $40 to try it out. The OS was free ut you paid for the processed CDs. I still remember when I finally got it to boot up that I thought it was really cool to see the Sun logo pop up on my home machine. Yep, I remember those days as well. It was 1997, and I had (finally!) managed to procure my first Sun system for running at home. The feeling was that of magic. The console seemed really retarded even then, compared to the console interface on linux. No mouse, no copy paste from terminal to vi or the like. I tinkered with that OS for several months before kind of giving up on it and trying to learn more about linux. But I didn't; coming from academia and seeing a single (albeit beefed up) Sun SPARCStation 20 serve AN ENTIRE COUNTRY, I knew this stuff was powerful. All I had to do was master it completely, and that same power would be mine. So I persisted and stubbornly ploughed on. I see today in build 110 that the console is still about the same. Absolutely retarded now, compared to what linux offers. All kinds of unexpected behaviour with backspace delete and such. Still no mouse or copy paste to an editor. Seemed to me that the console would have been vastly improved in some 14 yrs. Especially since it seems there are large numbers of Solaris eggheads that are command line oriented people. It was never a priority because Solaris is used in environments where the systems are connected to a terminal port concentrator (like the WTI CMS-16), and sysadmins can connect via them directly to any console of their choosing. But since this is mostly for ALOM (Advanced Lights Out Management) scenarios, 99% of the time we (the sysadmins) don't even need to connect to the console. So everyone was content to be able to remotely connect to the console when needed, and the rest of the time we work in 'screen' or xterms. Worked fine all these years. (WTI CMS-16 can be had off of ebay cheaply, because most are telco phased out equipment and this equipment is so obscure, that a $1,000 USD piece of HW goes for $50 USD because not even the guy selling it really knows what he has, or what it is.) Its just surprising somehow that the console has gone basically ignored. That's because most of Sun's paying customers never really needed the console to be as advanced, since this was compensated with console management switches noted above. CMSes happen to scale much better than Linux virtual consoles, since one could/can connect many systems to them at the same time, and the CMS exports all those consoles via his network port... When, unlike in 1995, lots of linux (gnu) tools are common place on the Osol OS now. Yes, and it's a pity, because GNU is vastly inferior to the native System V tools, not to mention inconsistent, not to mention that GNU tools don't work properly (latest scandal: no ZFS ACL support), not to mention that they go against the core UNIX philosophy of do one thing and do it well, by implementing tools inside of other tools (tar xvfz, grep -R)... GNU userland is just garbage, unfortunately most casual users aren't even aware just how shoddy and crappy GNU userland is. But compared to the two consumer grade NASs available for purchase, that I've tried, osol/zfs seems vastly superior in too many ways to ignore... even with the vast amount of troubles (AND help) I've encountered. ( well documented in my heavy use of these osol lists). Hopefully, relief will come with the next update of Solaris 10 (not Solaris Express, Solaris 10!), and if it does, ZFS will finally be usable in PRODUCTION. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] disconnecting hdd from zfs mirror hangs whole
I'm using what would pass as junk hardware to many here. Its older hardware and cheapo cards... but I've had to use PCI sata cards because OSOL does not recognize my onboard sata controller. Believe me when I write that I completely understand your frustration, simply because it is my frustration also. This has been a weakness of Sun's engineering for a very, very long time, as long as I've known Solaris (1994). Excellent engineers, excellent engineering practices and processes, but NEVER a product that works 100%, with all kinks worked out. Always phenomenal ideas, but never a 100% working product. About 75%, give or take, is what gets released. Is new functionality needed? Yes, of course. But for once, I'd like to have most of the bugs fixed and 100% working software, than 75% working software and tons of new functionality... because in the end, none of it works correctly when all put together. Last week I wrote that it remains to be seen whether Sun's new religion of release early, release often turns out to be the correct path. Now, several kernel panics (b109, b110) and countless hours of hacking later, I'm really beginning to believe release early, release often is an approach Google should be whacked on the head for at least 10 times a day, and whoever copies Google... well, fill in the rest yourself. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] MilaX now runs on the iPhone!
Nice April fool's hoax, however, you'll need to do a little better photoshopping next time. One can tell right away that the image is photoshopped. +1 on originality though. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] MilaX now runs on the iPhone!
And I would change i86pc i386 i86pc to ppc ppc ppc for next year (;-) -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Possible IBM aquisition of Sun
Granted, versus following reason why it's NOT tier 1: What can be done with such a box besides booting it and - display a nice screensaver - maybe show some content (streamed movie, blueray, whatever) What can be done? For starters, a PS3 can house a 3.5 drive interally, and has USB ports, which immediately makes it possible to do two things: - stick a 1.5TB drive in, and connect another identical drive over USB or EtherNet (iSCSI) - configure mirroring One could also connect a USB hub, and connect a whole bunch of drives and configure a zpool, for nice amount of external storage (TERABYTES!) This is assuming Solaris ran on the hardware, of course. Another variant, also assuming Solaris ran on the PS3 hardware, would be to build CLUSTERS of PS3s running for example Sun cluster. Cheap inexpensive clusters, high availability, active-active configurations, for fault tolerance. Yummy. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris-based CD/DVD Distributions as of March 26, 2009
yes: Tom Riddle and Brian (and Guy) are resuming work. That's really good news! But whatever they do: In any case it is not going to be a LiveCD/DVD distro very soon. So at least the subject is not entirely correct. Yes, that's what bothers me. If there is no downloadable, bootable image, how can a pile of prototype code be considered a distribution? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris-based CD/DVD Distributions as of March 26, 2009
OpenSolaris-based CD/DVD Distributions as of March 26, 2009: 12. Polaris (OpenSolaris on PowerPC project, b104+) There's a downloadable Polaris ISO image? Where? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] IBM and Auschwitz __/__ Re: Possible IBM aquisition of
Exactly. So we have an nwam that cannot support more than a single interface, we cannot (semi-officially) have more than one link to the same gateway (because that's rocket-science), we can't print A4 to an A4-sheet from Gnome (at least), quite a few machines hang at boot, we have corrupted boot archives at power failures, we still have unsupported interfaces (wired and wireless), there are some lacks at multimedia support, printing hangs some place in between, (and what not) Yes, because the whole thing has gone from being a traditional big bang development cycle to Google's release early, release often. Whether that is good or bad remains to be seen; only history will be able to tell. One thing is certain, the Solaris you are seeing is under very, very heavy development, and even in spite of Jeff Bonwick's now famous FCS all the time, sh*t happens. That's the way of the world, life, and the universe. But we have a handful of forks, that work neither (as expected). Correct, and that is BAD! However, again, historia est magistra vitae, and if history is any indicator, this is exactly what happened to Linux. So if that in turn implies that Solaris will someday be as important as Linux is today, then it's a good sign. Would it not have been the task of managers to focus on 'getting the core system right', before someone creates a desktop, storage, or whatever else, distribution? No, because what you are seeing is a massive development effort running in parallel; it's a miracle that the thing even works considering the complexity and the scale of development, and the only reason why it does is because of system engineering, something that's very rare to see nowdays (I write this from my own experience). Uwe, who can't contribute code, but has raised a lot of practical issues at using OpenSolaris as 'desktop production' machines. As long as a Unix sysadmin encounters problems thereby, it is more urgent to iron out those problems. Yes, and that is good so. Do you know why? I will tell you. When a Unix sysadmin raises an issue, it is because he has found a serious issue in the trenches. I am NOT writing about Uwe's lone desktop system here, I am writing about an issue which affects very large (think tens of thousands of systems, multiplied by tens of thousands of customers) environments. So it is thanks to the Unix sysadmin and the kernel engineers at Sun, that Uwe is able to do his online banking every day, get alerts on his stocks, book his flight tickes, pump the fuel into his vehicle, check his news feeds, send an SMS, make a phone call, and find fresh eggs milk in his local Famila, Aldi, Edeka, and so on. Without the issues identified by Unix sysadmins, many of the things that Uwe takes for granted would cease to function for unspecified amounts of time, bringing then environment to a collapse in short order. And oncemore, just to set things straight, the Unix sysadmin watches over all issues vigilantly, and has not only made sure that Uwe can lead his life with all the above described comforts, but also that Uwe's desktop will sooner or later work as expected, because that same Unix sysadmin has also opened bugs and RFEs for the issues that affect Uwe's (and many other millions of users') desktop. Just thought you'd like to know. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] IBM and Auschwitz __/__ Re: Possible IBM aquisition of
Funny enough, you tell the person why he is doing what he does. Maybe his reason is different, though? Maybe it is because he cares? Your enthusiasm never was in question. I was merely pointing out why it is good that problems noticed by UNIX admins are ironed out with a higher priority than lone desktop problems. It's actually not because they come from UNIX admins, but because those are usually serious production issues, affecting everybody, not just desktop users. That would include you too, whether you use Solaris or not, because the infrastructure that you do use relies on Solaris to function. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Which Samba packages to use and, what do Usr, Kernel, Root packages me
I notice that packages seem to come in three basic flavors: Usr, Root, and Kernel. Can someone explain what the precise differences are? I assume that Usr is a userland package, Root requires root privileges, and Kernel is a kernel module. But I want to confirm that. It's about architecture and system engineering, not about versions. You have a component, a metacluster, in this case it is Samba. The r is the root portion of this component, payload which goes into / (usually /etc/, which is in the / filesystem). Then there is the u portion of the component, which goes into the /usr filesystem. Finally there is the kr portion of the component, which usually delivers (kernel) drivers. And, in the case of Samba, there are several packages available and I'm not sure which one to pick: You shouldn't pick any of them; Solaris now has a CIFS kernel module, which makes Samba obsolete, at least for file serving. Read up on it on http://docs.sun.com/ -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] IBM and Auschwitz __/__ Re: Possible IBM aquisition of
Many thanks from all of us for Godwinning this pointless thread. It needed to be done. http://en.wikipedia.org/wiki/Godwin%27s_law From the link you posted: The rule does not make any statement about whether any particular reference or comparison to Adolf Hitler or the Nazis might be appropriate, but only asserts that one arising is increasingly probable. But in IBM's case, it seems very, very appropriate. IBM kills everything they touch, including their own operating system. It's what I wrote before, IBM will have no problem walking over corpses if it means killing the competition or increasing profits. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] IBM and Auschwitz __/__ Re: Possible IBM aquisition of
And now those employees talk about 'fork'. During their working hours at whatever the company is? I believe I was the first to write that I will fork OpenSolaris should I perceive the need to do so. I am not, and have never been an employee of Sun Microsystems, Inc. Also, you are assuming that I'm writing this during my work, which might or might not be correct, but is nevertheless an assumption. May I remind you that engineers don't work with assumptions, unless they have no other choice; we (myself included) work primarily with facts, empirical evidence, when it is available. If one wanted to combat any takeover, firstly the product has to improve (I leave out the long list of grouses on basic functionality, for the time being.). For your information, I've taken the latest-and-greatest revision of Ubuntu Linux for a spin, and am happy to experience that it is not all that better or more polished than Solaris, Ubuntu lacking basic functionality (like installing directly on XFS / from LiveCD, or the network manager behaving unreliably and inconsistenly, forcing me to configure networking from the CLI. I'm happy to report that Solaris is fixing important and critical issues faster than the competition (XFS / is a known issue since at least 8.04, so far Solaris has had the most critical and panic causing issues fixed.) Then, with the type of managers this company had to make with through the last decade, there is no future. Because there is no resolve, no vision, and mostly backtracking and reversals. There I cannot help but fully agree with you; if anything, Sun's management needs to be CLEANED OUT. With no mercy and no remorse. Jonathan seems to have done more damage than good. Sun can exist and survive, but needs a change of guard. Forget Jonathan, the guy is small potatoes. The people that really need fired is the whole middle management; and let the team leads finally be able to do their jobs! -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] IBM and Auschwitz __/__ Re: Possible IBM aquisition of
100% agreed. I think, if you put the number of posts and contributors in relationship to those with financial support from Sun, or an employer-employee relationship, empirical evidence might evolve that supports my lines. But this is not the most relevant thing. You are implying that if those employees were laid off, they would stop working on Solaris, and that Solaris development would therefore be severely impaired. Since we have no hard data which states how many Sun employees would keep working on Solaris on a completely voluntary basis, your implication is again an assumption at worst or speculation at best. What I actually would like to point out, though: Ubuntu seems, IMHO, better at getting the basics right: network, printing, installation (though the intermediate graphical installer, around nv70, was definitively superior. No idea, why it is gone now.) The installer is most likely gone because it warranted further development. Oh, yes: hardware support. Empirical data: just search the archive for plenty of ubiquitous machines, on which OpenSolaris HANGS the installer- or live-CD. But there the counterargument is the hardware compatibility list. Again, I'm not aware of any database containing hard data on systems which hang with the Ubuntu live media, which makes comparison hard, actually it makes it impossible. As long as reading - worse: writing - any other file system other than UFS or ZFS (plus a hackish vfat-support), there is nowhere to go. You could argue that having ZFS, alternative filesystems aren't necessary, and aren't a priority. You could also argue that there are so many FS choices on GNU/Linux because GNU/Linux doesn't have ZFS. As an example. As a casual observer, this project simply looks to me as if nobody actually knew where it was heading. While everyone fiddles on his/her own little things, to make them happen. Actually this project is composed of many different projects of their own, some of which are comparable to ONNV itself in size and complexity. If you look at the projects page, and look at the ONNV change logs, you will see what I mean. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] output from prtvtoc
You're stuck. There's no clean-cut way to do what you want; you can't copy the VTOC over, because of the geometry mismatch. The way to do what you want is with a combination of find(1) and cpio(1): Assuming that the 500GB disk is mounted on /mnt, ( find / -mount -local -depth -print | cpio -pvdmu /mnt 1 /tmp/cpio.log) 2 /tmp/cpio.err will copy the files over; lathe, rinse, and repeat for every other filesystem you might have. You'll also need to install the boot block on the 500GB disk, see installboot(1M) on sparc, respectively installgrub(1M) on the i86pc. In other words, this is such a messy operation which has to be performed with the utmost attention to detail, that it's *cheaper* to just back up the data you need, if you have any, and reinstall the operating system. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] output from prtvtoc
Additionally, you might want to experiment with `zfs send`, but as I've not used this feature yet, I can't say whether that'll work for this particular scenario. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to move the os to anther disk (no mirroring)
Can I use `dd' for that task or is that likely to have problems with zfs? Possible, yes. Also, you need to copy everything. Doesn't dd(1) do a bitwise copy, so how would that work? Yes. zpool pool replace olddevice newdevice Did anyone ever tell you that you're a genius? If it's a bootable pool, then there might be a problem; you can do it in two steps: zpool pool attach olddevice newdevice (make a a mirror) and later, after a reboot from the new mirror (and after installing grub) But what happens when you attempt to mirror a 60GB disk to a 500GB disk? How does that work? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] I am impressed with shutdown
To the 'genius' who pared down the shutdown process in snv_110, well done. The genius is Daniel Price, and you can read about the adventure to get there, at this URI: Speeding to a halt http://blogs.sun.com/dp/date/20090306 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to move the os to anther disk (no mirroring)
You get a 60GB mirror. I suspected as much, hence my question. Then, when you remove the 60G disk and your reboot or export/import the pool, then it will reevaluate the size of the vdev. It tried and it worked (and zpool history remembers how I did it) Cool. That is a really useful piece of information. I don't recall seeing it in the manual pages though. Is it documented anywhere? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Possible IBM aquisition of Sun
This is HORRIBLE. If IBM has any interest in taking over a smaller company with the same products, then only to destroy competition: Usually, yes. Chances are good that's the case here. Kill SPARC (T2 and Rock, not sure what they would do with Fujitsu's SPARC64), They can't do anything about Fujitsu, since it is its own company, producing its own hardware designs and its own processors; in other words, other than Solaris himself, Fujitsu would be largely unaffected. And all the mainframe-class systems Sun sells today are actually a Sun rebranded Fujitsu hardware running Fujitsu's, not Sun's processors. Other than T-series and the i86pc series, Sun doesn't really produce any SPARC based systems any more.[QUOTE]move customers to PowerPC[/QUOTE]It'd be nice if it really happened! I would not mind running Solaris on POWER6. Not at all, provided that the hardware is *DIRT CHEAP* and easily available, in rang with the run 'o' the mill PC-bucket. If anything, it would bring the PlayStation 3 port of Solaris closer to reality. Otherwise, it'd be a disaster for Solaris. I'm so sick and tired of expensive proprietary systems; I hate them, passionately! Kill NetBeans, force customers to Eclipse. Is that really relevant? From what I can tell, Eclipse is the defacto standard anyway. Kill OpenSolaris, force customers to migrate to LinUX. Can't kill something that's open source. If IBM tries to pull any stupid stuff, I'm forking the OpenSolaris code immediately, no ifs, buts, or maybes. I will have no mercy. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [desktop-discuss] SXCE 109 python 2.6 curses support bo
ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.11-i86pc-2.6/_curses.so: symbol wchgat: referenced symbol not found Thanks for the report, I'll fix this. Since I fought with this for about a month on HP-UX and managed to force the Python's build system to link the symbols in properly only after very heavy hacking, I'd be very much interested to know what the fix will look like. Whatever the fix is on (Open)Solaris, it will be exactly the same for HP-UX, because the cause of the problem is Python's braindead, full-of-wrong-assumptions build system (or rather, the designers of it). -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Possible IBM aquisition of Sun
Yes, of course. Luckily!! And I _know_, that most people on this list will jointly do this, together with you, or you together with them :)) Gladly! We talked about this before. But it doesn't make any sense to make a branch-off from Sun. I concur. Right now, it doesn't make sense to do that. But should things deteriorate, action will be taken. I'm downloading the current snapshot of the code for archival tonight. Sicher ist sicher. I actually believe in the community. There are at least several *former* Sun engineers that kept working on Solaris code even after they were laid off, and that tells one a lot about true enthusiasm of the OpenSolaris community, and is a testament to excellence of Solaris. This isn't about Sun any more. OpenSolaris *will* live on, come hell or high water. Under that new situation it would obviously be totally different. Agreed. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Possible IBM aquisition of Sun
Let`s hope that this will not happen...I personally doubt, that IBM will slay Solaris in favour of AIX, Solaris so far is much more architecture-independent than AIX. WARNING: speculation. This could go two ways, a) IBM helps the OpenSolaris effort further b) IBM moves in for the kill. IBM stands to profit both ways, but a) is not the obvious way. Solaris has been a thorn in IBM's behind for a very long time; IBM and AIX lost many a contract and sale opportunity to Sun and Solaris. If IBM pays USD $6.5 billion, IBM gets a shot at finally shooting their biggest OS competitor in the head. IBM wants to sell services around GNU/Linux, because IBM is against Microsoft and Linux goes against Microsoft. It is hard for me to see IBM investing considerable reasources to spearhead Solaris in that direction. Solaris on the other hand does not go against Microsoft, and, in quite an ingenious move, Sun has a 10 year contract which allows them to integrate features out of Windows into Solaris, ergo CIFS kernel support. So it is the exact opposite, Solaris has benefited greatly from *cooperation* between Microsoft and Sun, the exact opposite of what IBM has been doing up to this point. Finally, and here is the kicker -- Everything IBM touches is turned to gold, but loosing it`s inspiration and, well, unix-way :) Everything? How about a company, named IBM, that pretty much killed their own operating system, AIX, in favor of some hack-job effort called GNU/Linux? Best case scenario, IBM treat AIX as an abused stepchild that they inherited along the way, and are now somehow stuck with an OS they themselves don't believe in: closed, expensive, proprietary, runs only on CHRP PPC, no gratis compilers, no gratis cluster, and definitely NO CHEAP HARDWARE TO RUN AIX ON. They touch everything to Gold? Well, what I described above does not look like they'll be nice to Solaris. But we will have to wait and see how this chapter of computer history turns out. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Possible IBM aquisition of Sun
I don't know. Why not? Furthermore, there's already the Polaris project... ...Which hasn't gone anywhere after Genesi killed the ODW (open desktop workstation), the PS3 as the target wasn't accepted, and finally it was determined that the POWER hardware, the next logical target, was way too expensive. Which it is. Some work has been done on porting OpenSolaris to EFIKA, but as far as I know, that didn't get very far. Porting is a serious business, and the project is hurting from lack of human resources; don't expect to see any Polaris ISO images available for download any time soon. PS3 is the target which is abundant enough and makes the most sense to port to, after all, would wouldn't want to be able to run Sun cluster on a pile of PS3s, or use a PS3 workstation but be able to run a game after a long day of work, but there isn't enough PS3 HW know-how to go around for that. At least not for OpenSolaris, at least not right now. A shame, really. What a pity. I surely don't and wouldn't do so, I'm a BSD addict; however, during the last years I became much less political in this regard, so... use the perfect fitting tool. Sometimes this even may be GNU/Linux. I'll tell you one thing: if any of the BSDs had any clustering solution akin to Sun or Veritas cluster, And the Solaris became irrelevant, I'd start using BSD immediately, just so I didn't have to end up on GNU/Linux! -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Possible IBM aquisition of Sun
I don't see why one should see PS3 as tier 1 target; For a very simple reason: they are cheap and abundant, and can be had new, instead of being forced to scavenge off of ebay (and I should know, about 50% of my private server park is hardware scavanged boots to some kind of a prompt off of ebay). it'd be nice to have Cell supported, but that's no necessity. I'd say it's easier to get it ported to PS3 first, and then CHRP POWER second, if need be. Which I seriously doubt there would be. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Dell 2950 + MD 1000 + iSCSI and NFS
I would like to serve primarily iSCSI from this to a VMware cluster, and maybe some NFS, although that is not as important. Actually NFS would be a much more elegant and simple solution, if your clients are NFS capable, even for example for database workloads (did you know that Oracle has a built-in NFS client/accelerator of her own?) I think the best approach would be: Use both PERC/5E controllers. Good approach. Try to configure MPxIO, so you have load balancing and multipathing over both controllers. See http://docs.sun.com/ for details on how to configure MPxIO. Setup both MD1000 as JBOD and not use any of the horrible RAID capabilities Yes, this will give you the best ZFS performance. Connect all four ports from the PERC/5E's individually to the MD1000's Use software RAID (is this raidz?) in Opensolaris and create some RAID sets RAID-Z. Actually, in your case, it should be RAID-Z2. As to why, read below... The question then becomes - how many RAID sets - should I not span the individual ports from the PERCs to the MD1000's - I believe that port 0 on the MD1000 addresses drives 1-7, and port 1 addresses 8-15. Good question, and the following might help you: When to (and not to) use RAID-Z http://blogs.sun.com/roch/entry/when_to_and_not_to Anything else that I should be aware of? Yes; As I've written above, you probably should implement RAID-Z2, which is a variation of RAID-Z, but with double parity. You will of course lose one additional drive, but at 400GB a piece, can you really risk being without protection for that long? 400GB takes a while to sync. Ideally, if you can afford it, you should configure RAID-Z2 with a hot spare, so that you can lose a total of three drives before being out of service. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Building Boost 1.38.0 on Solaris 10 5/08 x86 with Studio 12
copy bjam exectuable into a directory in PATH (or build bjam seperately) $ cp ./tools/jam/src/bin.solaris/bjam PATH directory That's really not necessary. See here: http://www.forum.hr/showpost.php?p=18684168postcount=862 If you follow the above link step-by-step, you will end up with Boost C++ libraries compiled with Sun Studio 12 with generic optimizations. The default Boost config assumes -fast, if I remember correctly, which is a severe error. The steps as described by the original author patch the configuration for a generic platform, and only turn generic optimizations, which is what one would want in 99.9% of the cases. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] zfs related google summer of code ideas - your vote
10) Did I miss something.. Scoping the necessary work to turn ZFS into a cluster filesystem (phase 1), Further modifying ZFS in order to turn him into a distributed filesystem (phase 2). -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] dmesg?
Hi Is there a tool like linux dmesg for opensolaris? Yes, two in fact! one is tail -f /var/adm/messages and the other less -F /var/adm/messages dmesg also exists, but is unreliable: the buffer is limted, and after a while you will miss information. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Mke failing on opesolaris while installing mysql from source
The configure goes through fine but after configgure the make fails with the statement make failed for target - install recursive Did you try to build with GNU make? A lot of the freeware / open source code incorrectly assumes one is running on GNU/Linux and using the GNU userland. Also before you try with GNU make, I'd install GNU fileutils, which give you FreeBSD install(1M) and build with that. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /etc/release on Solaris Express
Perhaps using uname would be a better way to distinguish the releases? This is in machine-readable format, from what I understand... Yes, however: a) usable with switches only when one has one UNIX, and nothing else (100% platform consolidation), which is unlikely or b) in case of a heterogenous UNIX environment, only uname(1) alone, without any switches, can be used in a sane manner. The fundamental problem is that uname(1) switches and output, except for calling uname(1) by itself, are inconsistent among different flavors of UNIX, even System V UNIX. While the output is machine parsable, it is not guaranteed, and it is not the case, that a switch for uname(1) which exists on Solaris will exist on HP-UX, or FreeBSD, or ..., and even further, it's not at all the case, that those switches will deliver the same information. So something like this will work reliably: /export/install/`uname`/: /export/install/SunOS/ /export/install/HP-UX/ /export/install/IRIX/ but something like this has no chance of working in any consistent way: /export/install/`uname -p`/ /export/install/`uname -m`/ /export/install/`uname -r`/ /export/install/`uname -X`/ -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /etc/release on Solaris Express
That sounds like a bug to file against 'facter' ... though there are complications here. ...And then some, though they have little to do with 'facter' himself. Rather, 'facter' just happens to exhibit the underlying architectural and technical issues. The release is `uname -r`. Updates are *not* distinct releases in that sense, because they are all part of one patch train. In particular, it's possible to install some of the patches that are part of one Update without upgrading everything to the entire Update. What should the tool report in those cases? 10_u4.5? This, in my experience, has a lot to do with the technical issue of the underlying software management subsystem (System V packaging). An example of how this can be solved is to implement a software management subsystem which in and of itself is built around the concept of software subsystems and system overlays. For example, sgi inst(1M) is one such system. What Sun calls IDRs is what sgi would call patches SG_[0-9]+, however, there would maybe be one to four of those... per year. The real interesting question is, why? Is it becuase IRIX was so phenomenally stable, that sgi didn't need to issue any patches, or for some other reason? The answer is no, other than these Sun IDR equivalents, sgi never delivered patches; instead, they delivered entire system overlays, because inst(1M) understood them; it could pick up which software subsystems in the dist/ directory were newer, and automatically upgrade the old ones on the target system. It was almost as if working with images, overlays behaved in such a way. So one would go from 6.5 to 6.5.17, to 6.5.22, to 6.5.30 release, and one would always be at some known state. One could never have update 4.5, because even if one did, it would be irrelevant, since one could do inst keep * inst install upgrades inst go -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /etc/release on Solaris Express
What does release mean when describing a probably patched system??? Not much, other than the foundation one started with/from. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Equivalent of showrev command in opensolaris
To the best of my knowledge and belief, there are no patches for OpenSolaris; the only way to remedy or otherwise correct an OpenSolaris installation is to upgrade the system. This is a sideeffect of running a development stream of the Solaris operating system. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] my t41 with 512 mb ram dosen't use swap space
In the standart Installation, the installer Created a swap partition of 2gb. It certainly appears so: 219360k used, 2074692k available So at the time you posted this, the system was using ~214MB out of the ~1.98GB of total swap capacity. This implies (but does not guarantee), that if the system had 256MB more RAM, and assuming that the memory demand remains the same, your swap slice would not be, or would be very lightly used. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] my t41 with 512 mb ram dosen't use swap space
I started gnome and added the system monitor in my panel. I couldn't belief tat my ram is full and solaris doesn't use any swap space. I started many gui app's, the machine slows down but it doesn't use any swap why? Perhaps you have not sliced the disk such as to have a swap slice, or perhaps the swap slice was sliced to be too small. Please run the following command: /usr/sbin/swap -l This will show you whether you have a swap file, and if one exists, how big it is. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] FSS - What % do you need to give the global zone.
We have an e25k domain with x2 system boards (16 cores), we have x9 non-global zones, and we ant to use the Fair Share Scheduler (FSS) to manage the resources in the event every zone is competing for CPU resources. My question is, what % of shares should I give the global zone. Any suggestions ? We previously worked on systems with x4 CPU's we allocated 100 shares per CPU so 400 shares in total, as we gave the Global zone 100 shares that's 25%, but on the large e25k on that premises, it seems excessive to give the global zone 400 shares. This is really not a good idea. The reason why this is not a good idea is that the number of shares one can assign is arbitrary. What you are trying to do is take over the role of the kernel, and the Solaris kernel does an excellent job of spreading the load equally among zones. You should not attempt to artificially limit resources, unless you have a concrete problem that needs dealt with. As an example of a concrete problem, it would be a T5220 which has too little memory (64GB), and too many Oracle databases, so that the zones have a shared memory starvation problem. That's a concrete problem where defining containers *might* be a viable solution, however note that even in that particular case, it can still be solved actually configuring the SGA_TARGET appropriately. As for artificially limiting the CPU(s), I would definitely not recommend doing that, because you will actually be artifically decreasing the overall performance of the system. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software RAID in solaris 10?
ZFS is designed to do exactly what you want, they way you want it. No need to muck with SVM (Sun Volume Manager), unless you have a very specific need and scenario that needs addressed (which you do not seem to have). And guess what, ZFS is available on Solaris 10 starting with Solaris 10 06/06 (Solaris 10 u2). This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] bash line wrapping
If you're running /usr/openwin/bin/xterm, there is a special option to work around a line wrapping bug, with -rw -aw. Also, make sure your TERM is set correctly, and run: eval `/usr/openwin/bin/resize` on the command line. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Blastwave.org
But of course you've read the text provided with the hyperlink that states the dependencies eh? ;-) Of course. I am a very firm believer in reading the documentation. In fact, that's the very first thing I do. But truth be told, it is simply unprofessional to do what Steve Christensen has done with Sunfreeware, and whether it's free/gratis/whatever or not is no excuse in my eyes. At best, it's amateur work, and that's saying it very politely. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] I want to understand 'Boot Environment'!
This is not so much a question of a specific problem, than one of concepts and limitations. To make a long story short, you're trying to fit square pegs into round holes: you're trying to use the Live Upgrade technology to, in end effect, clone and move systems around. And that is not what the Live Upgrade technology is for. I already wrote that to do what you want, the way you want it, you need to start creating (compressed) .flar Flash(TM) archives, which will give you a near-complete clone of a given system. I write near complete, because some parts of network configuration, and the host name will be automatically stripped, on purpose. The rest is an image of the system as it was, including the data and configuration on it (minus what one explicitly specified to exclude, with -x). You can't just move disk and slices around - Solaris's /devices tree is specifically built for the hardware it runs on, including the drivers. To move disks/slices from one system to another, you'd have to have hardware that's identical. You also can't muck with the files (like copying /var/sadm/install/contents from one system to another) - the target system will be damaged, its referential integrity gone. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] I want to understand 'Boot Environment'!
We don't speak the same language, sorry. Doch! (:-) I am not asking what else I could do, or that it would not work. I am trying to understand why it would not work. To me, what is the purpose of a BE, if it will not boot? Wouldn't it be nice to have a BE to which one can simply boot when disaster occurs? No? No. That's what Flash(TM) and JumpStart(TM) technologies, combined, are for. The man-page says The following are some of the tasks you can perform with Live Upgrade software: oYou can make one or more copies of the currently running system. for, except of a possible upgrade. The word 'copy' is misleading, since it won't boot. I don't see how you get copy --- boot? A BootBlock is a special piece of binary code contained on a special place on the disk. This isn't Amiga and XCopy with nibble copying you know (;-) If you want bit-for-bit copies, you should use dd(1), although dd(1) will need to have an exact disk size / disk slice to restore, and is therefore not recommended. I got it know. Did you get the point, that it was fabulous if it did provide a bootable environment? The LiveUpgrade technology, irrespective of the BE terminology used, is meant to provide a copy of the OS in order to upgrade it. Now BE might be a misnomer, but consider this: if I give you a banana and tell you I call it a pineapple, does that make it a pineapple, or is it still a banana? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
