Re: [osol-discuss] [xwin-discuss] Building QT-4.3.3 with OpenGL enabled
On Jan 17, 2008 4:20 PM, Alan Coopersmith [EMAIL PROTECTED] wrote: russell aspinwall wrote: Maybe if the X library locations can be rationalised to /usr/X11/lib then it would not be necessary. We're working on it, and have accelerated it as part of the work we need to do for X in Indiana. Has the /usr/X11/include/mesa/GL directory fix already been applied to OpenSolaris? I don't know of any bug reports filed or fixes needed there. No Solaris OpenGL patches are needed to build QT 4.3.x. I have built QT 4.3.x without problems on S10U2 S10U4 and recent Nevada's. However, there is a bug in the QT OpenGL 4.3.2 and 4.3.3 library which causes memleaks. To see the bug in action, you can run the demos/gradients/gradients example, and watch the memory usage. AFAIK this has been recently fixed by TT. The workaround for now is to use QT 4.3.1 which does not have the memleak bug. --Stefan -- Stefan Teleman KDE e.V. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Error on compiling php on SOLARIS 10
On Tuesday 26 June 2007 03:06, yoyo wrote: Undefined symbol first referenced in file libiconv_close ext/iconv/.libs/iconv.o libiconv_open ext/iconv/.libs/iconv.o libiconvext/iconv/.libs/iconv.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status gmake: *** [sapi/cli/php] Error 1 I have set path=/opt/csw/bin:/usr/sfw/bin:/usr/sbin:/usr/bin:/usr/openwin/bin: /usr/dt/bin:/usr/ccs/bin and install package libiconv1.9.2 from BlastWave,but error still exist.i don't know what's wrong :( You aren't building the iconv.so PHP extension as a shared extension, it is statically linked into the PHP executable. So, you need to link the PHP executable against GNU libiconv which you downloaded from Blastwave (and maybe also libintl), by adding this to EXTRA_LIBS in PHP's Makefile: -liconv -lintl --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] QT/Jambi on Solaris 10/Sun Studio 11
QT/Jambi [http://trolltech.com/products/qt/jambi] on Solaris 10 built with Sun Studio 11 and QT 4.3.0: http://www.stefanteleman.org/qtjambi/jambisolaris.jpg And some patches: http://www.stefanteleman.org/qtjambi/ --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [ogb-discuss] Project Proposal - (what is/was Indiana)
Glynn Foster wrote: Hey, Here's the project proposal that should have been out a long while back (apologies, I'm happy to take the blame on this one). Before anyone gets too caught up in how little the proposal actually covers, I intend to follow up with my thoughts if and when the project alias gets created - I'd like that discussion to be far more focused than opensolaris-discuss has been. Glynn [ snippage to save space ] +1 from me. FWIW, i believe that this project should be allowed to proceed even though not all its aspects/scope/components have been formally defined. i believe that allowing an experiment is more valuable than disallowing it because of lack of due process, missing paperwork or filling in the wrong form. just my 0.02. --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun to make Solaris more Linux like
On Saturday 12 May 2007 17:48, Ceri Davies wrote: I assume the community reserves its right to reject Project Indiana? Ceri You do not speak for the community. You speak for yourself, and yourself *only*. You certainly do not speak for me, as I have never delegated you, or anyone else, that authority. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Sun to make Solaris more Linux like
On May 11, 2007 at 1:18 PM UNIX admin wrote: Dear Sir, if you need to use the `locate` command to find something, you have a MUCH bigger problem. Dude, This is, SO, like, AWESOME -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] was something else, now Packaging
On Friday 20 April 2007 11:19, Joerg Schilling wrote: In the Solaris STL lib, std::string.clear() and std::string.erase() do the same: delete on the allocated space. In the GCC STL lib, std::string.clear() only resets pointers and keeps the allocated memory while std::string.erase() deletes the allocated space. People wo develop with GCC rely on this fact and having two different STL libs could be a bit difficult. Could you please explain what you mean by People who develop with GCC rely on this fact and could you please also clarify which particular instance of std::basic_string::erase() you are referring to, since there are 3 of them, and each one of them does different things. There are several implementations of STL which work with GCC. Relying on any private implementation detail artifact of a particular STL implementation goes against the entire point of OO programming, C++ and STL, and it is not a C++ ABI compatibility problem. It is simply a lousy programming practice problem. Also, the Standard clearly states that std::basic_string::clear() behaves as if std::basic_string::erase(begin(), end()) would have been called [21.3.3.13]. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 10:21, Joerg Schilling wrote: But BTW: dirfd() would be just: #define dirfd(dp) (dp)-dd_fd This works really well when (dp) is NULL. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 12:29, Joerg Schilling wrote:
Stefan Teleman [EMAIL PROTECTED] wrote:
On Thursday 22 March 2007 10:21, Joerg Schilling wrote:
But BTW: dirfd() would be just:
#define dirfd(dp) (dp)-dd_fd
This works really well when (dp) is NULL.
???
Garbage in - garbage out.
Do not expect to get useful results in case that you
use useless input.
/* testnulldir.c */
#include stdio.h
#include sys/types.h
#include dirent.h
#define dirfd(dp)(dp)-dd_fd
static const char* dirname = /this/baby/does/not/exist;
int
main(int argc, char* argv[])
{
DIR* dir;
int fd;
fd = dirfd(opendir(dirname));
(void) fprintf(stderr, dirname fd = %ld\n, fd);
return 0;
}
[EMAIL PROTECTED]/tmp][03/22/2007 12:26:45][242] echo $CFLAGS
-Xc -erroff=%all -errshort=full -errfmt=error -errwarn=%none -xO3 -s -xjobs=2
-xregs=no%frameptr -dalign -xprefetch=auto
-xprefetch_auto_type=indirect_array_access -xprefetch_level=3 -xbuiltin=%all
-xcsi -xinline=%auto -xustr=ascii_utf16_ushort -z
combreloc -z redlocsym -z nodefaultlib -z now -z rescan -z
absexec -xipo=0 -xildoff -xldscope=symbolic -xrestrict=%all -xF=%none
-xalias_level=std -xsafe=mem -xthreadvar -lc -lpthread -lposix4 -lrt -mt
-D_REENTRANT -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_XPG4 -D_XPG4_2 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -D_XOPEN_SOURCE=600
-D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC -D_STRICT_STDC__
-D_STDC_C99 -DAPR_BUCKET_DEBUG=1 -DAPR_RING_DEBUG=1 -DAPR_POOL_DEBUG=0
-DSOLARIS -DSOLARIS10 -DSOLARIS2=10 -DUSE_SOLARIS -DNDEBUG -DNO_DEBUG -KPIC
-xtarget=pentium4 -xarch=sse2 -xchip=pentium4 -xcache=8/64/4:256/128/8 -xO3 -s
[EMAIL PROTECTED]/tmp][03/22/2007 12:26:47][243]
[EMAIL PROTECTED]/tmp][03/22/2007 12:26:47][243] $CC $CFLAGS
$LDFLAGS testnulldir.c -o testnulldir
testnulldir.c, line 14: error: undefined struct/union member: dd_fd
c99: acomp failed for testnulldir.c
[EMAIL PROTECTED]/tmp][03/22/2007 12:27:23][244]
we now change
#define dirfd(dp)(dp)-dd_fd
to
#define dirfd(dp)(dp)-d_fd
[EMAIL PROTECTED]/tmp][03/22/2007 12:28:10][246] $CC $CFLAGS
$LDFLAGS testnulldir.c -o testnulldir
[EMAIL PROTECTED]/tmp][03/22/2007 12:28:12][247] ./testnulldir
Segmentation fault (core dumped)
[EMAIL PROTECTED]/tmp][03/22/2007 12:28:17][248]
--Stefan
--
Stefan Teleman 'Nobody Expects the Spanish Inquisition'
KDE e.V.-Monty Python
[EMAIL PROTECTED]
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 15:03, [EMAIL PROTECTED] wrote: On Thursday 22 March 2007 10:21, Joerg Schilling wrote: But BTW: dirfd() would be just: #define dirfd(dp) (dp)-dd_fd This works really well when (dp) is NULL. Yes, is will SEGV; is that an issue? Yes. It can return -1 and set EBADF. This would require that it is a function, not a macro. getc(NULL) also blows up; what is your point? My point is that it should not SEGV on NULL pointer. It should return -1 and set EBADF. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 15:42, [EMAIL PROTECTED] wrote: getc(NULL) also blows up; what is your point? My point is that it should not SEGV on NULL pointer. It should return -1 and set EBADF. You are wrong; the standard disagrees with you. 7.19.7.5.3: The [getc] function returns the next characted from the input stream pointed to by [stream]. If the stream is at end-of-file, the end-of-file indicator for the stream is set and [getc] returns EOF. If a read error occurs, the error indicator for the stream is set and [getc] returns EOF. Where does the standard disagree ? --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Proposal to include dirfd(3C) into OpenSolaris
On Thursday 22 March 2007 18:23, Joerg Schilling wrote: The dirfd( ) function may fail if: [EINVAL] The dirp argument does not refer to a valid directory stream. May is not must ;-) It isn't can't or shouldtn't either. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Web Stack NG Project: Questions for the Community
Hi. The ARC Cases for the WebStack NG Project have been submitted for review (and hopefully approval), and i would like to ask our community's input regarding two important questions which have come up during our discussions: 1. Should the initial components released for this project include the 64-bit bits in the initial Integration ? 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. What are the community's views on this ? Thank you. --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
Shawn Walker wrote:
On 21/03/07, Rich Teer [EMAIL PROTECTED] wrote:
Overwriting the /usr/apache2 that comes on the Solaris media is a no-no,
in my opinion, and /usr/apache2.2 just pollutes the /usr namespace even
more than it is already. IMHO, the correct place for this is under /opt.
I have no strong feelings either way, but I would prefer /opt/apache2
over
/opt/apache2.2.
I strongly agree with this particular approach. This makes the
separation clear and easy.
Please keep in mind that, there are two additional locations for Apache, in
addition to the location of the actual binaries [/{usr,opt}/apache2]:
/etc/apache2
/var/apache2
These additional two locations *must* exist.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
[EMAIL PROTECTED]
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [sfwnv-discuss] Web Stack NG Project: Questions for the Community
[EMAIL PROTECTED] wrote: Stefan, 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. Just to clarify, the overwriting we're talking about is of the Apache 2.0.x binaries and libraries (or from a System V packaging perspective, the f files that the vendor - for example, Sun - delivers) and we're not talking about overwriting the configuration files (the so-called e files). Is that correct? Correct. Existing configuration files will *not* be overwritten. --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
John Plocher wrote: I should have been clearer - I like this overwrite proposal (as opposed to a the counter of having /usr/apache, /usr/apache2 and /usr/apache2.2), as long as the svc manifest names are the same as used by the current apache2 installation (svc:/network/http:apache) and not, for example, svc:/network/http:apache2.2. Yes, the svc manifest names will be preserved. --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
Alan DuBoff wrote: Stefan, Your suggestion above might be the best. The other thing is, what about having 2 seperate directories, keeping the old and adding the new, and using a symlink to point to the desired version. This was one of the other suggestions made on the ARC discuss list. My primary concern about keeping both 2.0.x and 2.2.4 around (albeit temporarily) is that it creates the possibility of a huge disaster: application X links againsr /uar/apache2 application Y links against /usr/apache2.2 application Z links against X and Y If this were ever to happen, it would be discovered quite quickly (i'm willing to bet that any apache module linked in such a dysfunctional fashion will crash very quickly). The question then becomes: in the interest of preserving Sun customers' existing installations, easing the transision pain, and giving enough leeway for module porting and regression testing, is the possibility described above an acceptable risk ? --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal: Next Generation Web Stack
On Tuesday 20 March 2007 02:07, Alan DuBoff wrote: On Monday 19 March 2007 07:37 pm, Stefan Teleman wrote: http://www.php-security.org/ This is scary...I think I'll go get a cold shower...;-) I have to wonder, much of the online forum software is written in PHP, and as such seems to be vulnerable. How do people deal with sites that are based on that? Numerous sites are written in PHP. Many of them run the suhosin security extension, but many others don't. Those who don't are doing so at their own peril. php-security writes the suhosin PHP security extension, which is very useful (imho it would be insanely risky to run any PHP site open to the Internet without suhosin enabled). The constant problem php-security is facing is that they update their security extension depending on the latest vulnerabilities they have uncovered. So it ends up being a game of a catch-up: PHP releases a new version, php-security has to update the suhosin extension to this latest version. I mean, you have to patch this stuff constantly, so no matter what is delivered will be changing shortly it would seem. Essentially, yes. It looks like there will always be two parallel patch tracks: security patches for the currently released PHP, and security patches for the next-to-be-released PHP version. All this is compounded by the fact that PHP releases aren't necessarily compatible with each other. Truely the only way to deal with that is to be tracking the nightly code from PHP, or is there another way? The fundamental problems stems from the fact that a PHP vulnerability can exist either in the PHP code, or in the PHP application. Uncovering vulnerabilities in the PHP code can be very tricky: vulnerabilities might only occur on infrequent code paths, or in infrequent combinations of code paths + PHP extensions being used. Vulnerabilities in the PHP application depend exclusively on how the application is written. I'm thinking that the nightly code would be even more dangerous. It's also a moving target. It seems to me that the efficient approach is to track official PHP releases. The official (numbered) PHP releases are the only ones which might have a release of suhosin. What i believe we should do: we should audit the PHP codebase with Coverity (http://www.coverity.com/). From looking at the htp://scan.coverity.com/ page, it doesn't look like PHP is currently being audited by Coverity. The only information i could find about a PHP Coverity audit was here: http://www.internetnews.com/dev-news/article.php/3589361 Perl had a defect density of only 0.186. In comparison Python had a defect density of 0.372 and PHP was actually above both the baseline and LAMP averages at 0.474. [defect density == number of code defects per 1000 lines of code] I believe we should also Purify PHP. The problem is that Purify probably won't work on Nevada, but we could build PHP on a release of S10 they support, and it will still catch buffer overflows, ABR/ABW, UMR, stack corruption, double deletion, etc. We could then publish the results of the Coverity audit and of the Purify output, and we could forward them to php-security.org, along with patches. This would give the PHP community an objective base for requesting bug and security fixes. Seems we'll need to update this regularly as a community. Not pointing the finger at you specific Stefan, it's an issue that needs to be worked out within the community. The most important aspect, for me, is to identify these vulnerabilities and to have bugs and security fixes accepted upstream by the PHP Group. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal: Next Generation Web Stack
On 3/20/07, Alan DuBoff [EMAIL PROTECTED] wrote: When you say, So I think we'll be upgrading and patching(once 11 comes out) the web stack on a regular basis., so you mean the community will need to keep upgrading the package(s)? I'm not sure who we'll refers to. In this particular case we referes to yours truly. I was using the Royal We. :-) Yes, maintaining security patches for PHP is an extremely high maintenance job. --Stefan -- Stefan Teleman KDE e.V. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On 3/19/07, Ian Murdock [EMAIL PROTECTED] wrote: Hi all, It's being announced today that I'm joining Sun as chief operating platforms officer, which basically means I'll be in charge of Sun's operating system strategy, spanning Solaris and Linux. I just posted the announcement on my blog (http://ianmurdock.com/2007/03/19/joining-sun/), and it'll likely be making the rounds soon. Just wanted to make sure you heard the news directly from me and to introduce myself. Cool. Very cool. --Stefan -- Stefan Teleman KDE e.V. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal: Next Generation Web Stack
On Monday 19 March 2007 13:52, Octave Orgeron wrote: Hi, I think this is a great idea and will help developers and shops that depend on these tools. Of course the key issue I see is supportability. A lot of developers like to see the latest and greatest versions of these tools. However, that must be tempered with the requirement of stability and security. http://www.php-security.org/ --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Project Proposal: Next Generation Web Stack
Project Proposal: Next Generation Web Stack Summary We would like to create an OpenSolaris project to assume and enhance the community and work originally created in Sun's CoolStack project as part of the CoolTools project. This project will assume all of the CoolStack components, including Apache HTTP Server, MySQL Database Server, Perl, PHP, Ruby, Rails, Squid and others. The existing CoolStack forums will be retired and replaced with discussions at OpenSolaris.org. Goals The aim of this project is to address the OpenSolaris community needs for a set of Next Generation Web Tier Technologies. The initial seeding of this project will be based on the work already put into CoolStack, but it is not intended to be tied to the set of technologies currently in CoolStack. The project will provide the following: - A forum for discussion on which next generation web tier components should be part of various Solaris distributions - A codebase from which various packaged software can be derived for various OpenSolaris distributions, including build scripts and best practices for building this software with OpenSolaris - A forum for discussion on what kind of integration and features users would like to see integration between OpenSolaris and these external Open Source projects Overview of CoolStack In 2006, Sun introduced CoolStack - a Solaris-optimized, full-featured open-source based Web Tier stack which includes all of the traditional components of an AMP stack. This project proposes to take the best of the technologies and practices delivered by CoolStack and fully integrate them into OpenSolaris, optimized to utilize the features within OpenSolaris such as DTrace and the Solaris Management Facility. Many details can be found on CoolStack and the associated forums at http://cooltools.sunsource.net/coolstack/. However, we would like to summarize the history and goals to clarify how they relate to this project proposal. CoolStack had been originally conceived to provide a set of out-of-the-box optimized binaries for a common set of software components on the UltraSPARC T1 based systems. By performing this packaging for the community, the OpenSPARC project and Sun's Performance Technologies group had a goal to make it easy for users to quickly add packages to their existing systems to quickly obtain optimized performance and reducing time to service. Over time, there was sufficient demand for an equivalent set of packages on x64, so a similar set of optimized packages and build scripts were put together for the i386 and amd64 architectures as appropriate. CoolStack derives its name from the CoolTools project it is associated with. Because the community has already gained familiarity with the CoolStack name, there is no plan to change the name, despite the fact it's moving away from the CoolThreads processor and CoolTools project. Q: Why should this project exist here instead of upstream source code bases? In attempting to keep the various components under this project in step with the latest and/or most popular releases from the component projects, core code modifications will be contributed to the upstream projects wherever possible. However, it is expected that some contributed items, such as build scripts, a community forum, SMF manifests and the like, are more appropriate for an OpenSolaris project than the codebase of the component project. It is also anticipated that this project may have specific discussions about packaging as it relates to various OpenSolaris distributions and a need for there to be a forum to discuss how OpenSolaris technologies such as DTrace and SMF integrate with these component projects. Accordingly, this project will serve as the source for the OpenSolaris.org discussions and community decisions. From experience with the CoolStack project forums already, we know there may be some overlap with questions on issues/bugs and how things are intended to work that may be more appropriate for the project from which the component was derived, but the members of the OpenSolaris CoolStack project will encourage working with the component projects wherever possible. This project is intended to add to the communities surrounding those projects, not fragment them. - 1. Public interfaces as defined in the ARC release taxonomy at http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal -- Honeycomb Information and dev tools
On Wednesday 07 February 2007 12:04, Darren J Moffat wrote: what it if it a non code project ? Not all projects should be required to be code based. Granted, but i'm assuming that 6 months from inception, a project should show some signs of activity of some sort. :-) --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun Microsystems Solaris on HP
On Thursday 08 February 2007 00:01, Paul Maher wrote: I'm a newbie. We have several sun systems we purchased our sun reseller, MCA http://www.mcac.com. We are now migrating some of our applications on to HP servers. Would they support solaris 10? http://www.hp.com/wwsolutions/solaris/index-all.html --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
On 2/6/07, Alan Coopersmith [EMAIL PROTECTED] wrote: Sorry - I've never used Opera and don't know what it does. One thing it *doesn't* do is to bloat Xorg to 684MB in 24 hours. --Stefan -- Stefan Teleman KDE e.V. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal -- Honeycomb Information and dev tools
On Tuesday 06 February 2007 15:58, James Carlson wrote: At least at this point, I'd be disinclined to reject a project unless it either looks like the output from /dev/urandom or like this: http://www.ietf.org/internet-drafts/draft-terrell-math-quant-ternar y-logic-of-binary-sys-04.txt Maybe we could enforce some kind of automatic self-destruct timer from the date of project inception. For example, if a project doesn't check in any code within 6 months of inception, it self-destructs. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: What does OpenSolaris Success look like to you?
On 2/4/07, Bryan Cantrill [EMAIL PROTECTED] wrote: Let me lay out a scenario that I just elucidated on Stephen O'Grady's blog (http://redmonk.com/sogrady/): let's say that several years down the track, a major competitor to Sun in the server space decides that, much to their regret, OpenSolaris is an option that they must not just provide, but also extend and develop. But the competitor doesn't want to outsource its OS development to Sun -- they just want to hijack OpenSolaris. A GPLv3 dual-license allows for a devious plan: they could take the source, strip the CDDL, and announce that their GPLv3-only OpenSolaris was open to all comers. This can be done right now, without any involvement with a GPL dual license, solely under CDDL. This hypothetical competitor can take the current OpenSolaris, under CDDL, set up an open development environment somewhere, and purposely and explicitly disallow anyone who is now, or has ever been associated with, Sun Microsystems, from participating in this new venture, under any circumstances. This new venture can make API and ABI incompatible changes to existing source, they can add new source (and features) based on these incompatible changes, thereby making it, if not impossible, impractical to even try to merge these changes back into OpenSolaris. This newly added source might implement features which would be desirable in OpenSolaris. However, because of the nefarious intent of this hypothetical competitor, these features cannot be brought back into OpenSolaris, because it would require ABI and API breakage. At this point there are two incompatible versions of OpenSolaris, which can never be reconciled. This new WeBrokeABIWithOpenSolarisSoNeenerNeenerNeener operating system might even become very successful, and might even steal momentum from OpenSolaris. And this was done exclusively under CDDL. What does this have to do with the GPL ? For the record: Yes, i am a card carrying member of the Free Software Foundation. --Stefan -- Stefan Teleman KDE e.V. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: libc_i18n.a rewrite.
On Friday 02 February 2007 01:07, John Sonnenschein wrote: Currently, there is no possible way to build an opensolaris distribution without including the closed-source libc_i18n.a. What this means is that a traditional distribution is entirely out of the question. This is entirely unacceptable for a project which wishes to call itself Open Source. I propose that a project be started seeking to re-implement all necessary functions locked up behind that binary. I've done a rudimentary count of the work required, and from what I can tell there's a small number ( 100 - 200 ) utility functions ( wcwidth() for example) that need a rewrite. I would prefer if this project be attached to the name of closed-reimplementation or something similar, due to the fact that the primary focus at first will be to remove libc_i18n.a, and that must be integrated without delay, but ultimately I'd like for closed bins to disappear completely. +1. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] GPLv3?
On Tuesday 30 January 2007 19:44, Stephen Harpster wrote: I think that we (we being all of you) should be asking ourselves what we think about GPLv3. What would it mean to the community if we dual-licensed? It's now a possibility that we could attach an assembly exception to the GPLv3 which would let us mix GPL and CDDL code. This could open up a world of possibilities. But what are the downsides? What does the community, you, think of the way GPLv3 is taking shape? These are important issues and I urge everyone with an opinion to voice it sooner rather than later. +1 from me to dual license under GPLv3, with, or without, the CDDL assembly exception. the only material downside that i can think of is not to dual-license. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Recommended g++ reading pdf: A Common Vendor ABI for C++
On Friday 19 January 2007 08:36, Joerg Schilling wrote: [EMAIL PROTECTED] wrote: http://www.research.att.com/~bs/slashdot_interview.html Quote from that article: There is no C ABI either, but on most (all?) Unix platforms there is a dominant compiler ... which is just flat-out wrong. +1, you just have been a few seconds faster, I wanted to write the same ;-) This is what i think he means: This: __t11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntityPCt11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntity is a randomly chosen symbol from libqt-mt.so.3.1.1 as delivered on the Companion CD, and built with (a version of) g++ on SPARC. If i try to demangle this symbol with SunProCC's dem, on the same box (not that the box should matter): [EMAIL PROTECTED]/opt/sfw/lib][01/19/2007 9:18:05][75] dem __t11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntityPCt11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntity __t11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntityPCt11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntity == __t11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntityPCt11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntity [EMAIL PROTECTED]/opt/sfw/lib][01/19/2007 9:19:24][76] In other words, SunProCC's demangler has no clue what this is, it cannot demangle it. Attempting to link this library with SunProCC will result in an 'undefined symbol' error, and your program will not link. If i try to demangle the same exact symbol with c++filt, on a different box, i get: [EMAIL PROTECTED]/19/2007 9:20:50][106] c++filt __t11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntityPCt11QMapPrivate2Z7QStringZQ223QXmlSimpleReaderPrivate12ExternEntity QMapPrivateQString, QXmlSimpleReaderPrivate::ExternEntity::QMapPrivate(QMapPrivateQString, QXmlSimpleReaderPrivate::ExternEntity const *) [EMAIL PROTECTED]/19/2007 9:25:35][107] It demangles. The opposite is equally true: This: __1cLQdDTextLayoutLcurrentItem6M_nJQdDTextItem__ is a randomly chosen symbol from libqt-mt.so.3.3.7, built with SunStudio 11. dem says: [EMAIL PROTECTED]/opt/qt-3.3.7-32/lib][01/19/2007 9:26:01][85] dem __1cLQdDTextLayoutLcurrentItem6M_nJQdDTextItem__ __1cLQdDTextLayoutLcurrentItem6M_nJQdDTextItem__ == QTextItem QTextLayout::currentItem() [EMAIL PROTECTED]/opt/qt-3.3.7-32/lib][01/19/2007 9:26:03][86] c++filt says: [EMAIL PROTECTED]/19/2007 9:29:46][108] c++filt __1cLQdDTextLayoutLcurrentItem6M_nJQdDTextItem__ __1cLQdDTextLayoutLcurrentItem6M_nJQdDTextItem__ [EMAIL PROTECTED]/19/2007 9:31:05][109] --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Refined OpenSolaris KDE proposal / Re: Proposal to create an OpenSola
On Thursday 18 January 2007 10:26, Joerg Schilling wrote: Or be compatible with both, like the solaris core? (and let the distros choose which ABI they prefer) If they really use C++ library interfaces it may be impossible. BTW: how do you like to separate CC and g++ created libraries in /usr/lib/? SunProCC's and g++'s C++ ABI's are incompatible. This is noone's fault really, the C++ ABI has never been formalized. The only ways to make them compatible would be: - SunProCC switches to g++'s ABI - g++ changes to SunProCC's ABI My guess is that neither of the above will happen. SunProCC's C++ ABI has been compatible ever since Workshop 5.0. It would seem logical to me that anything which ends up in /usr (or a subdirectory thereof) would observe the SunProCC ABI. So the answer to this question is: you don't need to separate them, because you can't mix them in the first place. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to create an OpenSolaris KDE project
On Thursday 18 January 2007 19:02, Martin Bochnig wrote: Martin Bochnig wrote: (MB) Stefan Teleman wrote: (ST) STAt most, you can say that the intersection between KDE e.V. and STOpenSolaris is not the Null Set, since it contains at least one known STelement. :-) ST ST--Stefan MBHowever, it depends on how the original unequations are interpreted MB(they did not come with any further definitions/assumptions). MB MB :-) Stefan, you cannot simply switch back and forth in regard to what you actually _mean(t)_ by a very incomplete/isolated specific enum of unequations. What you write at the top is certainly true for two plain sets, if evaluated without any context (and that's of course state school level - set theory). But if you (indirectly) continue to suggest, I had made a painful miscalculation, then the following two assumptions must be true: Martin, I have *no clue* what you are talking about. Can we let this subthread die now ? Thank you. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Refined OpenSolaris KDE proposal / Re: [osol-discuss] Proposal to create an OpenSolaris KDE project
On Wednesday 17 January 2007 05:49, Roland Mainz wrote: John Sonnenschein wrote: Following the official proposal guidelines, I'd like to take this opportunity to propose that we collaborate with the KDE e.V. and kde-core-devel in order to integrate KDE as an OpenSolaris project Ok, lets refine this proposal: [ ... snippage to save space ... ] The only aspect i am not sure will work is the no Konqueror part: No Konqueror == No File Manager. I don't think that's feasible, or useful. About KDE3 vs. KDE4: there is a KDE 3.5.x series which has many improvements over KDE 3.4.x. That IMHO would be worth having in OpenSolaris (plus the starting point for the KDE 3.5.x work can be KDE 3.4.x, while KDE4 is completely new). Otherwise, no objections here. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] GPLv3
On Tuesday 16 January 2007 12:24, W. Wayne Liauh wrote: http://www.eweek.com/article2/0,1895,2084284,00.asp?kc=EWEWEMNL0115 07EP28A ( Sun to License OpenSolaris Under GPLv3) +1. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] GPLv3
On Tuesday 16 January 2007 14:48, Joerg Schilling wrote: Blindly trying to follow Linux is not the right way to deal with the challenge. Mr. Torvalds has, thus far, expressed an unfavorable view of GPLv3. While i have zero interest in getting involved in another Pointless License War(TM), i am questioning the Blindly trying to follow Linux statement, given Mr. Torvalds' publicly expressed views on GPLv3. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to create an OpenSolaris KDE project
On Tuesday 16 January 2007 19:56, John Sonnenschein wrote: Following the official proposal guidelines, I'd like to take this opportunity to propose that we collaborate with the KDE e.V. and kde-core-devel in order to integrate KDE as an OpenSolaris project +1. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to create an OpenSolaris KDE project
On Tuesday 16 January 2007 21:08, Javier O. Augusto wrote: Following the official proposal guidelines, I'd like to take this opportunity to propose that we collaborate with the KDE e.V. and kde-core-devel in order to integrate KDE as an OpenSolaris project http://solaris.kde.org/ Am I missing something??? Yes. This [ http://solaris.kde.org/ ] is the URL for the KDE Solaris site at KDE, under the kde.org domain, sponsored, paid for and maintained by The KDE Foundation [KDE e.V.]. It is completely independent from Sun, or OpenSolaris. This Project Proposal is about creating a KDE Project at OpenSolaris, pursuant to the OpenSolaris Project Proposal Guidelines. These Project Guidelines are completely independent from the KDE e.V., or from KDE Solaris. OpenSolaris != KDE e.V. KDE e.V. != OpenSolaris OpenSolaris Project != OpenSolaris Community --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to create an OpenSolaris KDE project
On Tuesday 16 January 2007 22:09, Martin Bochnig wrote: OpenSolaris != KDE e.V. KDE e.V. != OpenSolaris Strictly speaking this cannot be true, as there exists at least one element 'n' element 'N', that is part of both organizations at once: YOU At most, you can say that the intersection between KDE e.V. and OpenSolaris is not the Null Set, since it contains at least one known element. :-) --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V.-Monty Python [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to create an OpenSolaris KDE project
On Tuesday 16 January 2007 23:39, John Plocher wrote:
Am I missing something???
Yes.
This [ http://solaris.kde.org/ ]
is the URL for the KDE Solaris site at KDE, under the kde.org
domain, sponsored, paid for and maintained by The KDE Foundation
[KDE e.V.]. It is completely independent from Sun, or
OpenSolaris.
Rephrasing Martin's question:
What is there that an OpenSolaris Project {would, could}
do that the solaris.kde.org effort {wouldn't, couldn't,
isn't} already doing?
If the answer is along the lines of nothing much, just more of the
same, but done by different people in a different place, then I'd
vote -1, because I don't see a compelling reason for OpenSolaris
(the community) to replicate each and every other project out
there.
The answer to this question is not nothing much, just more of the
same, but done by different people in a different place.
There is currently no place where Things that align well with the
kernel and/or the core utilities, that demand or require tight
integration can happen for KDE Solaris, except for Solaris specific
patches floating around ftp sites as unified contextual diffs. If the
goal of OpenSolaris is indeed to be a place where Things that align
well with the kernel and/or the core utilities, that demand or
require tight integration can happen, and where the developer
community can gather and work together on project which ultimately
benefit OpenSolaris, then that is the purpose of KDE as an
OpenSolaris Project. After all, this is a proposal for KDE on
OpenSolaris, not KDE on OpenVMS.
I am quite a bit surprised at the comparison between KDE and
OpenOffice, or Java, mostly because it is very unclear to me what
exactly is being compared here. I think it would be useful to
determine whether a comparison between KDE and OpenOffice, or Java,
could ever be made in the first place.
--Stefan
--
Stefan Teleman 'Nobody Expects the Spanish Inquisition'
KDE e.V.-Monty Python
[EMAIL PROTECTED]
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal to create an OpenSolaris KDE project
On Wednesday 17 January 2007 01:03, John Plocher wrote: Stefan Teleman wrote: There is currently no place where Things that align well with the kernel and/or the core utilities, that demand or require tight integration can happen for KDE Solaris, Consider me to be ignorant; you won't be too far off ;-) The proposal says collaborate with the KDE e.V. and kde-core-devel in order to integrate KDE as an OpenSolaris project, yet the solaris.kde.org web page gives the impression that that is *its* charter; furthermore, there already is an OpenSolaris Desktop KDE community with what looks to be the same charter yet again. So my question is what will this new project do that is different from those other two? Why do we need three communities/projects to do this? solaris.kde.org is a web site hosted by KDE e.V. and dedicated to KDE on Solaris. As a side note, Solaris is the *only* commercial OS to have its own web site hosted at KDE. Its existence predates the existence of OpenSolaris. KDE e.V. also pays for hosting patches and packages for KDE Solaris, for the maintenance of the boxes which host these packages and patches, as well as for the bandwith for downloading these patches and packages. As everyone may or may not be aware of, KDE is, and has always been licensed under LGPL/GPLv2 (with a limited number of exceptions in some translation units). KDE's primary development OS is, and has been since its inception, GNU/Linux. KDE is predominant in the EU. It originated in Germany, and it is closely aligned with Trolltech. The source code downloadable from ftp.kde.org is, as you say, a baseline, even for GNU/Linux distributions. Distro-specific patches exist for SUSE and for RedHat (those are the ones i know of, there may be more). Given that GNU/Linux is the reference implementation of KDE, it is virtually impossible, with the minute number of KDE developers currently involved with KDE Solaris, to provide portable patches, when these become necessary because of incompatibilities between Linux, FreeBSD and Solaris, or between compilers, or simply because better implementations exist. Common, and correct solutions *do* exist. However, there simply is no time to write, and test such OS-transparent artifacts, which would work equally well, and equally transparently, on GNU/Linux, FreeBSD and Solaris, with GCC and SunStudio. As such, KDE Solaris patches are, and have been relegated to just that: KDE Solaris Patches floating around on ftp servers. What this Project will achieve: [0]. Provide a unified location for the source code of KDE Solaris. [1]. Given [0], provide a reference implementation of KDE Solaris, similar to the OpenSUSE or Fedora Projects. This reference implementation would be the result of collaborative development work under the OpenSolaris KDE Project. [2]. Given [1], create a foundation for commercial distributions of KDE Solaris. There are currently in existence 3 commercial distributions of KDE (that i know of): - Xandros [ http://www.xandros.com/ ] - Linspire [ http://www.linspire.com/ ] - Tomahawk Computers [ http://www.tomahawkcomputers.com ] This would open the possibility for mixed GNU/Linux and OpenSolaris-based KDE installations. Currently, this is simply not possible, and not even considered. [3]. Also given [1], create a baseline foundation for currently existing OpenSolaris-based distributions (Belenix and Nexenta). So far, patches for KDE Solaris have been distributed to Belenix and Nexenta via email. [4]. Prevent the automatic dismissal of OpenSolaris as a Desktop OE based on the sole reason that it does not support or include KDE (it has happened, and it's been documented in some needlessly bad press). [5]. Provide those customers who have asked for KDE with what they have asked for: KDE. [6]. Provide an OpenSolaris equivalent to what is currently considered the best (whatever that means) GNU/Linux Distro (SUSE Enterprise Desktop 10, which provides both GNOME and KDE as a choice). [7]. Provide a unified way of bringing into OpenSolaris those external dependencies which are common between KDE and GNOME, and which should be included in OpenSolaris. In spite of several discussions on this subject, on this very email list, we are in the same spot where we were two years ago. [8]. Provide guidance to the developer community outside of OpenSolaris, if not directly, then by example. If we are to build a community of developers from outside Sun, and if we are to pique their interest in OpenSolaris, then a lot of good will and interest can be obtained just by showing community spirit. Licenses aren't that interesting. Source code is. [9]. Alleviate the perception that Sun dislikes C++. This language is here to stay. KDE is one of the largest C++ software projects in existence. [10]. Provide a GUI building toolkit (QT) tested and patched for the latest Studio compilers. AFAIK, Trolltech
Re: [osol-discuss] Re: No google code hosting for CDDL/OpenSolaris based projects
On 8/15/06, Joerg Schilling [EMAIL PROTECTED] wrote: Frank Hofmann [EMAIL PROTECTED] wrote: The people think: Hmm, The GPL was written long ago. All this free SW is there and will be free forever. Will it be ? If you're getting into license fasicm, you end up with projects like this: http://www.smcc.demon.nl/webcam/ And this is even a case that would be allowed by the GPL. The driver situation under Linux hasn't improved in the last few years anymore, and that's due to GPL extremists. Wrt. to that, some of the Linux developers are fighting a holy war, actively ignoring the needs of the users... One reason to not call the software they produce free. The factual information presented in the two posts (partially quoted above) is untrue. First of all, Philips Webcam driver development continues to date. The latest version(s) of the Linux pwc drivers (supporting kernels 2.4.x and 2.6.x) can be downloaded from: http://www.saillard.org/linux/pwc/ This version the pwc driver appears to have been released in January 2006 (based on the timestamp of the translation units). I am currently using pwc-10.0.11 on all my SUSE boxes, with a Philips SPC 900NC webcam. I had to hack the driver source to make it work with this webcam (which is not supported by the original implementation). it works just fine. Information about configuring these drivers is available from: http://www.seismo.ethz.ch/linux/webcam.html SuSE Linux 9.3 and 10.0 (the ones i can speak of from experience) provide a pwc kernel driver in their default installation. SuSE Linux also provides the following documentation page containing detailed information on compiling Linux kernel drivers, here: http://www.novell.com/coolsolutions/feature/16340.html One of the examples used on SuSE's kernel driver page is the pwc driver. The information about the Linux pwc driver can be easily found by Google'ing for 'SuSE 10 Philips webcam'. The first link which pops up is On 8/15/06, Joerg Schilling [EMAIL PROTECTED] wrote: Frank Hofmann [EMAIL PROTECTED] wrote: The people think: Hmm, The GPL was written long ago. All this free SW is there and will be free forever. Will it be ? If you're getting into license fasicm, you end up with projects like this: http://www.smcc.demon.nl/webcam/ And this is even a case that would be allowed by the GPL. The driver situation under Linux hasn't improved in the last few years anymore, and that's due to GPL extremists. Wrt. to that, some of the Linux developers are fighting a holy war, actively ignoring the needs of the users... One reason to not call the software they produce free. The factual information presented in the two posts (partially quoted above) is untrue. First of all, Philips Webcam driver development continues to date. The latest version(s) of the Linux pwc drivers (supporting kernels 2.4.x and 2.6.x) can be downloaded from: http://www.saillard.org/linux/pwc/ This version the pwc driver appears to have been released in January 2006 (based on the timestamp of the translation units). There are more recent versions of this driver, which are currently under development. I am currently using pwc-10.0.11 on all my SuSE boxes, with a Philips SPC 900NC webcam. I had to hack the driver source to make it work with this webcam (which is not supported by the original implementation). SuSE Linux 9.3 and 10.0 (the version i can speak about from personal knowledge) provide a pwc driver in their default installation, for both IA32 and AMD64 architectures. Information about configuring these drivers (and much more) is available from: http://www.seismo.ethz.ch/linux/webcam.html I found the information about the Linux pwc driver by searching for 'SuSE 10 Philips webcam' in Google. Finding this information is not an obscure and tedious task. I do not understand the purpose of these endless GPL-vs-CDDL flamewars. Even less so when factually incorrect information is being presented as an advocacy tool. My understanding of participation in an open community is predicated on the assumption of civil discourse. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
On 7/27/06, Rich Teer [EMAIL PROTECTED] wrote: On Thu, 27 Jul 2006, Martin Schaffstall wrote: I suggest to make /bin/ksh ksh93 from the beginning that you don't have to deal with any backwards compatibility fuzz later I advocate against that; individual distros are free to do what want, of course, but making gratuitous incompatible changes just because sounds like the sort of thing our penguin loving friends over at kernel.org would go for. Having the PPC port being unnecessarily different to SPARC and x86 will lead to more fragmentation than we want, I would think. How is gratuitous incompatibility defined in this particular case ? The possibility that someone who will try the PowerPC Solaris port in the future might be unhappy because this future port will default to ksh93 instead of /bin/ksh, creating the possibility that Korn Shell scripts written in 1990 might break in 2008 ? Solaris 10 SPARC is currently incompatible with Solaris x86/x64: Xsun on SPARC vs. Xorg on x86/x64. I haven't heard of too many complaints because of this compatibility breakage (source code written, compiled and linked on Solaris 10 Xorg x86/x64 will not compile and link on Solaris 10 Xsun SPARC because Solaris 10 Xsun SPARC is a very different beast than Solaris 10 Xorg x86/x64). I haven't heard of too many people willingly running Xsun on x86/x64 for compatibility's sake either -- compatibility in this particular case means running glxgears at 42 FPS. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
On 7/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm not sure what you mean with source code written, compiled and linked ... Xorg). The X client runtime is exactly the same on both; the server is different but by and large implements the same feature set (with the exception of DPS on SPARC and XDAMAGE on x86) Or perhaps you are thinking about OpenGL which is still a bit problematic? i am specifically referring to: Xrender XVideo XvMC XRandR Xcomposite none of these extensions are available on Xsun SPARC. source code which makes use of any of these extensions, which compiles, links and runs on Xorg x86/x64 does not compile or link (never mind run) on Xsun SPARC, because the header files are missing. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
On 7/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: All of them should compile and run (against Xorg servers) on SPARC. There is nothing i would love more than to be able to run Xorg with all these extensions working on SPARC and my XVR-1000 card, so i can watch DVD's at more than 1280x1024 fullscreen and use the Xv/XvMC drivers instead of the CPU pig also known as Xshm on Xsun SPARC. Can i do this on Solaris 10 U2 06/06 SPARC ? ;-) Yep. Note that these are not gratuitous incompatibilities but rather a historical bagage which we will want to get rid of over time: - No Xorg drivers for SPARC hardware - fbconfig before Xrandr existed - No interest on the SPARC side to support the latest Xorg extensions This is yet another example of why branch, close source and modify is such a bad development model. You (and your customers) pay through the nose later. exaclty. so then back to my original question: why start off the Power PC Solaris port with an already obsolete (and not open source) Korn Shell ? i have no personal emotional attachment to the Korn Shell, i use the T-Shell. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
[ offlist ] On 7/27/06, Rich Teer [EMAIL PROTECTED] wrote: Mmmm. Perhaps I was overly assertive, although I stick to the principle. 'Course, the ensuing discussion about ksh88 not being able to be open sourced doesn't help the debate. you weren't being overly assertive. this backwards compatibility for backwards compatibility's sake is no longer a selling point. Linux has proven that backwards compatibility for its own sake is largely irrelevant (my personal unhappiness about this incompatibility, grounded in purely philosophical rather than practical considerations notwithstanding). today's cuckoo is not backwards compatible with the t-rex. the t-rex tried to remain backwards compatible with itself. it did not work out quite as the t-rex might have intended. the backwards incompatibility of the cuckoo did not make it better. it only succeeded at making the t-rex worse. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Formal Proposal : Port OpenSolaris to PowerPC
On 7/27/06, James Carlson [EMAIL PROTECTED] wrote: The good news, I think, is that Linux is still readily available for those who aren't so interested in compatibility. Nobody else really needs to ape that model. and Linux is also being readily deployed. 12,000+ workstations at ODF Niedersachsen (until very recently running Solaris x86, now running SuSE) will attest to that. so will those 5000+ boxes at EuroNext/LIFFE. i'm not sure whom they are ape-ing. one would presume that such decisions are primarily based on market economics and rational choice, and only secondarily on the collective set of irrational instincts we might be sharing with our primate acestors. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Proposal to create the “Community In Project”
On 6/19/06, James Dickens [EMAIL PROTECTED] wrote: On 6/19/06, Stephen Harpster [EMAIL PROTECTED] wrote: What you're proposing is the Companion CD. Check out the a href=http://www.opensolaris.org/os/project/companion/;Companion Project/a. You can add the stuff you want there where it will automatically show up in Solaris Express. This project is about including scripts and content that new users use every day. One likely canidate for inclusion in this project is blastwave's pkg-get and its use is directly conflicts with the companion CD project, it may not be perfect but the people have spoken, there are currently over 3 million package downloads a month and growing. I'm sure there are other things that this project will work to get intrograted that conflict with the companion CD project as well or may not be perfect enough to meet the companion CD projects requirements, but still used by many people. I am a bit confused about the necessity of creating a new OpenSolaris project which states from the outset that it will be in conflict with an existing OpenSolaris project. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google Earth
On 6/12/06, Glynn Foster [EMAIL PROTECTED] wrote: [1] Seems GTK+ is used for the installer, and QT is used for the application. You have to wonder who inspired that decision ;) Someone who may have thought that a sucky installer is probably less important than a sucky application. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] skype for opensolaris
On 6/12/06, Dennis Clarke [EMAIL PROTECTED] wrote: Hi All, Skype is officially supported on windows, linux Mac. Did anyone run Skype on Solaris sparc or x86? If not, Is anyone working on porting skype on opensolaris? gag ... something I have been watching closely : see http://www.skype.com/help/faq/technical.html Q: Is the source code for Skype available? Can I have a copy? A: No. Skype is proprietary and closed-source software. Q: Which protocols does Skype use? A: Skype uses a proprietary protocol which we have developed. We looked at many available protocols when designing Skype and none were good enough for us. We hope you agree! if Sun can open source Solaris then whats the issue with these people ? They don't want to open source it and they don't use SIP. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun lost one of it's biggest and oldest x86 customer
On 5/31/06, Joerg Schilling [EMAIL PROTECTED] wrote: Glenn Weinberg [EMAIL PROTECTED] wrote: If I'm reading the articles correctly, when they made the decision two years ago the information was, unfortunately, valid. They did make the final decision last year. The process did start in autumn 2000 when the Linux Verband Deutschland did aproach the OFD Niedersachsen and did tell them that Sun will shut down Solaris x86 support. The final convincing work did start in autumn 2004. This is wy I did aproach Sun marketing at that time when I was in Menlo Park. From the information I have, the final decision must have been made recently. Noone from OFD Niedersachsen has contacted KDE Solaris to at least ask a generic question about whether or not KDE is supported on Solaris X86. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On 5/29/06, Erast Benson [EMAIL PROTECTED] wrote: But I'm asking how to make Sun C compiler do what I want? The compiler is doing what you want, within the limits of it being explicitly allowed to ignore what you want. :-) --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Software for Solaris (was Re: Adobe Acrobat for Solaris x86)
On 5/29/06, Erast Benson [EMAIL PROTECTED] wrote: On Mon, 2006-05-29 at 12:51 -0400, Stefan Teleman wrote: On 5/29/06, Erast Benson [EMAIL PROTECTED] wrote: But I'm asking how to make Sun C compiler do what I want? The compiler is doing what you want, within the limits of it being explicitly allowed to ignore what you want. :-) OK. Than how to disable it? :-) I'm seeing that one could specify explicit names of functions to always inline. How to make it a default policy for all my inlined functions? ISO/IEC 9899:1999:6.7.4 says: [ ... ] 5. A function declared with an *inline* function specifier is an _inline function_. The function specifier may appear more than once; the behavior is the same as if it appeared only once. Making a function an inline function suggests that calls to the function be as fast as possible[118]. The extent to which such suggestions are effective is implementation-defined[119]. 6. Any function with internal linkage can be an inline function. For a function with external linkage, the following restrictions apply: If a function is declared with an *inline* function specifier, then it shall also be defined in the same translation unit. If all of the function file scope declarations for a function in a translation unit include the *inline* function specifier without *extern*, then the definition in that translation unit is an _inline definition_. An inline definition does not provide an external definition for the function, and does not forbid an external definition in another translation unit. [ ... ] It is unspecified whether a call to the function uses the inline definition or the external definition[120]. [118] By using, for example, an altermative to the usual function call mechanism, such as inline substitution. Inline substitution is not textual substitution, nor does it create a new function. [...] [119] For example, an implementation might never perform inline substitution, or might only perform inline substitutions to calls in the scope of an *inline* declaration. [120] Since an inline definition is distinct from the corresponding external definition and from any other corresponding inline definitions in other translation units, all corresponding objects with static storage duration are also distinct in each of the definition. You can try: - set the optimization level to -xO4 or higher - pass -xinline=%auto However: A function is not inlined if any of the following apply (no warning is issued): o Optimization is less than -xO3 o The routine cannot be found o Inlining the routine does not look profitable or safe to iropt o The source for the routine is not in the file being compiled (however, see -xcrossfile). --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Sequencers/music editors on Opensolaris
On 5/20/06, UNIX admin [EMAIL PROTECTED] wrote: There is no Solaris driver for Jack anyway. Yet. ;-) Apparently so. Not apparently so, definitely so. And Jack is really not crappy at all. The design is actually quite clean and elegant. it is based on operating system specific loadable modules. That's an oximoron: how can the design be clean if it is based on operating system specific loadable modules? Given the implementation problem at hand, which Jack Audio attempts to solve, which is: implementation of an operating-system independent real-time audio server, and associated API library, which publishes a common, public interface, and hides the operating system- and hardware-dependent implementation details. The use of dynamically loadable modules, which hide the operating system- and hardware-dependent functionality, but publish to the common, publicly available API, achieve just that. For example, if you are running Jack Audio on FreeBSD, the modules for OSS or ALSA are not needed, and will not be loaded. Your hypothetical software, which makes use of Jack Audio's public API, will only know about Jack Audio's public API. You don't care what operating system it's running on, or whether your user wants to use OSS, ALSA or Solaris /dev/audio backends. You allow the user of your software to choose which audio back-end to use. You don't need to worry about which dynamic module to load. Your software subscribes to the Jack API, and Jack Audio takes care of the rest. This translates into your software having cleaner, and more maintainable code. In OO-land, this is called encapsulation and polymorphism. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Sequencers/music editors on Opensolaris
On 5/15/06, Serge [EMAIL PROTECTED] wrote: Hi Stefan, I'm happy to read from you in this forum. Hi. :-) As i explained a few monthes ago in your kde-solaris forum, old versions from the new Rosegarden have really full worked with old versions of aRTs, i mean only two or three years ago. it used to work, but not anymore. :-( I tried this at the summer 2005 with actuals versions of both softs : it worked also, the sound is good (Sun audio0), only aRTs won't receive the release signal from each note, and it will impossible to useful compose music. I think that this issue isn't without solution, but ... Rosegarden ? aRTs ? Where is the problem exactly ? i think the problem is in both Rosegarden and aRts. it was about two years ago that everyone realized that aRts was a dead end, since no aRts development was happening any longer, so support of aRts essentially stopped or became a second thought. aRts still works in KDE for generic sound effects, but even amaroK prefers either Xine or GStreamer. Serious, i think that it could be good that any day someone will learn about that : we Solaris-men could have at first time a very good sequencer/music editor available... Probabily most people, witch actually like i needs to go back to crappy Linux software for compose music, will be happy to make this on their preferred Solaris... i'm working on a native Solaris driver for Jack. which will remove the need for aRts, and Rosegarden has builtin support for Jack audio. stay tuned. :-) --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Sequencers/music editors on Opensolaris
On 5/14/06, UNIX admin [EMAIL PROTECTED] wrote: From here on, it gets even worse. JACK won't compile on Solaris, gives out some stupid error: Undefined first referenced symbol in file sched_get_priority_max engine.o More of crappy Linux software. Why can't they do some QA on their stuff? There is no Solaris driver for Jack anyway. Yet. ;-) And Jack is really not crappy at all. The design is actually quite clean and elegant. it is based on operating system specific loadable modules. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] kdiff3 for KDE 3.4.3
Hi. Forwarded-From: http://lists.kde.org/?l=kde-solarism=114583439110822w=2 This patch installs kdiff3 for KDE 3.4.3. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KDE 3.4.3 (AmaroK) patch [KDE20060420-01]
Hi. Forwarded-From: http://lists.kde.org/?l=kde-solarism=114564061403078w=2 This is a thread concurrency/deadlock fix for AmaroK 1.3.5. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
On 4/13/06, Dennis Clarke [EMAIL PROTECTED] wrote: Dennis Clarke wrote: Dennis Clarke wrote: There must be a way in which we can work together. Compromises made and fences dropped. I am always trying to be a peace maker despite all my noise and passion. So that's a +1 from you in favor of Keith's proposal to set up a project I blatantly disagree with the creation of yet another separate project that completely replaces services and processes that already exist and snip So you are still in support of Keith's proposal which opens discussion between the long existing Sun Companion Software project (which predates Discussion is fine .. lets discuss how to make the Solaris Community project at Blastwave even better. Should you wish to join the Solaris Community project at Blastwave then you are welcome to do so. Dennis: You have been asked point blank, several times in this thread, if you and the Blastwave project are willing to join and support the Companion CD project as proposed by Keith. So far you have not given a straight answer. In order to help clarify your position on whether or not you, and Blastwave, are willing to support the Companion CD Project, i am providing here a simple, multiple choice questionnaire, for your convenience. Please select only one answer to the following question: Are you willing to support the Companion CD Project as proposed by Keith Wesolowski: 0. Yes [ ] 1. No [ ] Thank you. Stefan Teleman -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [Fwd: Proposal to start new project on Streaming Server]
On 3/8/06, Gerard Fernando [EMAIL PROTECTED] wrote: Proposal to start new project on Streaming Server -- I'd like to propose starting a new OpenSolaris project on the Streaming Server. The Sun StorEdge Media Central Streaming Server (http://www.sun.com/products-n-solutions/hardware/docs/pdf/806-4868-10.pdf ) will form the basis for the Streaming Server project. I would be very interested in working on this project.--Stefan-- Stefan Teleman[EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] two new patches for KDE 3.4.3
Forwarded-From: http://lists.kde.org/?l=kde-solarism=114083627122915w=2 KDE20060223-01 KDE20060223-02 KDE20060223-01 upgrades TagLib to version 1.4. This patch fixes several thread concurrency problems in TagLib 1.3.1. KDE20060223-01 is required for KDE20060223-02. KDE20060223-02 fixes thread concurrency problems in amaroK 1.3.5. These two patches are available for both IA32AMD32 and UltraSPARC-II. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE 3.4.3 patch
On 2/15/06, Alan DuBoff [EMAIL PROTECTED] wrote: On Tuesday 14 February 2006 07:14 pm, Stefan Teleman wrote: Forwarded-From: http://lists.kde.org/?l=kde-solarism=113997299912587w=2 This patch adds Xine playback support for Microsoft Windows *.avi and *.wmv files. That's great! Playing windows media files on Solaris? pinch me! BenR said he had that going a while ago, but I've never bugged him enough to get it. This is a nice addition! Thanks a bunch Stefan! Thank you -- you're welcome. :-) Now, if i could just fix once and for all those pesky little bugs in KDE ... --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] libsmedia.so
On 2/15/06, Darren J Moffat [EMAIL PROTECTED] wrote: If you tell us exactly what you need to interface directly with libsmedia for it would help, ie what kind of service or application are you building on top of it. For example all the libdvd*.so's now use libsmedia.so for the USCSI interface, although it's undocumented. i also have to port HAL for KDE4, and the media modules for as well (which include the CD/DVD burners, players, USB/FireWire devices, etc). it would be very nice if we could use libsmedia as a documented interface for SCSI/USCSI, instead of raw ioctl(2)'s. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] libsmedia.so
Hi. i am not sure this is the right forum for this question, but since this forum is a catch-all, maybe i could start here and then move to the appropriate one. and the question is: would it be possible to make libsmedia.so a public interface ? it is a very useful library, and it is currently marked private. it is true that it's not very difficult to guess the functions and their usage from the header files. but i thought, since many of us already do this, why not do it openly ? --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KDE 3.4.3 patch
Forwarded-From: http://lists.kde.org/?l=kde-solarism=113997299912587w=2 This patch adds Xine playback support for Microsoft Windows *.avi and *.wmv files. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KDE 3.4.3 binary patch [CD/DVD authoring tools patch]
Forwarded-From: http://lists.kde.org/?l=kde-solarism=113928171511102w=2 --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] 2 new patches for KDE 3.4.3
http://lists.kde.org/?l=kde-solarism=113877382526587w=2 --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] First Draft of GPLv3
Disclaimer: This Post Is Not An Open Invitation For Yet Another GPL Flamewar. If you feel the irresistible urge to engage in such activity, please go to Slashdot. Thank you. The first draft of GPL v3 has been made public at: http://gplv3.fsf.org/draft On my first reading, it would appear that the linking with non-GPL code restrictions from GPL v2 have been removed. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE 3.4.3 Source Code at Sunfreeware
On 1/16/06, Erast Benson [EMAIL PROTECTED] wrote: On Sun, 2006-01-15 at 01:21 -0500, Stefan Teleman wrote: The entire source code tree for the KDE 3.4.3 port is now available for download from Sunfreeware and its mirrors: http://www.sunfreeware.com/kde.html Many Thanks to Steve Christensen for taking the time to set this up and for making the full source code available. Final source code patches for K3B will follow very soon. Great achievement! Thanks a lot! thank you. :-) Any easy ways to extract diffs out of sources? For just the diff's -- you can get them from one of the KDE mirrors: http://ftp.sayclub.com/pub/X/KDE/stable/3.4.3/SOLARIS/SUNSTUDIO10/SOURCE.PATCHES/ http://www-ftp.lip6.fr/pub/X11/kde/stable/3.4.3/SOLARIS/SUNSTUDIO10/SOURCE.PATCHES/ http://ftp.tiscali.nl/kde/stable/3.4.3/SOLARIS/SUNSTUDIO10/SOURCE.PATCHES/ Do you have CVS or SVN repository where we can extract log? Unfortunately i don't have a CVS or SVN repository for this ... :-( I'd like to apply your changes to Nexenta KDE. Sure -- thank you. Please let me know if you run into any problems -- just email me directly. :-) There will be some more patches for K3B very soon. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KDE 3.4.3 Security Patch
Forwarded-From: http://lists.kde.org/?l=kde-solarism=113746309510548w=2 -- Forwarded message -- Hi. I have uploaded KDE binary patch KDE20060116-01, for both IA32/AMD32 and UltraSPARC-II. This patch addresses the multiple integer overflow problems identified by the KDE Security Advisory 20051207-1, and subsequent updates at: http://www.kde.org/info/security/advisory-20051207-2.txt I strongly recommend applying this patch at your earliest convenience. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KDE 3.4.3 Source Code at Sunfreeware
The entire source code tree for the KDE 3.4.3 port is now available for download from Sunfreeware and its mirrors: http://www.sunfreeware.com/kde.html Many Thanks to Steve Christensen for taking the time to set this up and for making the full source code available. Final source code patches for K3B will follow very soon. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KDE 3.4.3 for Solaris 10 binary patches
Hi. Forwarded-From: http://lists.kde.org/?l=kde-solarism=113675916809028w=2 KDE20060107-01 : fixes KWeatherService bug which did not update the KWeather kicker applet icon on weather changes/updates. KDE20060107-02 : fixes K3B CD/DVD capabilities detection bugs and adds support for Sun cdrw. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Companion CD [ was: KDE, GNOME, etc. ]
I would be very careful using any optimization that sets the -fns on Sun Studio, as I've seen significant differences in results when enabling this. For that matter, -ffast-math has a similar effect with gcc. No such optimization is involved, because no such flags are passed. This is pure speculation on your part, since you don't know what compiler flags i use. I question how much any of this would affect KDE though, since enhancements to both Sun Studio and GCC optimization have had to do additions for the new incarnations of simd instructions and should really only affect floating point performance, so far as I am aware. Forget KDE. i posted yesterday the results of fibonacci, which does not, and cannot, involve, any floating point operations. (i *hope* we're not going to argue this one). There are other reasons for me stating that no floating point optimizations are being performed. Both KDE and GNOME being mostly GUI's, most of their time is spent doing integer-based operations. Which is the main reason for choosing fibonacci as an example, as opposed to some other silly test program involving floating point. As an aside, floating point is not the only place where good compilers can achieve optimizations. And in this particular case, floating point optimization is completely irrelevant. Now. Are we going to accept that Sun Studio generates better and faster code, as previously shown, or are we going to continue speculating on what could happen if what just happened did not happen, and instead, what i would have liked to happen, happened. --Stefan This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Companion CD [ was: KDE, GNOME, etc. ]
On 1/3/06, David Schanen [EMAIL PROTECTED] wrote: I would imagine that Sun Studio may generate better code for some intense computational tasks, and I never claimed it doesn't. I would also imagine that KDE's components do not do any computationally intensive tasks. i imagine, i would imagine, i bet and i feel is not computer science. having spent daily time since November of 2002 working on KDE Solaris (back when KDE had given up on KDE with GCC because performance on SPARC was lousy, and KDE no longer had Solaris builds), i have come to certain conclusions in regards to GCC vs. Sun Studio performance (or Forte as it was known back then). insofar as i am concerned, KDE Solaris with GCC is not going to happen. every Tom, Dick and Harry can type './configure' followed by 'gmake' and build KDE on their own. my participation in this collective exercise is neither required, nor necessary. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Companion CD [ was: KDE, GNOME, etc. ]
On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So can we change this now to Studio? One thing is C++ ABIs (and the complete lack of stability at the g++ side of the fence) but also the problem with gcc compiled shared libraries in general: they often do not work easily when you don't use gcc ( symbol __eprintf: referenced symbol not found ). But code compiled with gcc intermingles with Sun Studio compiled libraries just fine. Casper Sun Studio: Yes!! GCC: don't you guys want a snappy, fast, KDE ? :-( In C++, GCC and SunStudio do not get along at all. And sometimes not in C either. Happy New Year. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Companion CD [ was: KDE, GNOME, etc. ]
On 1/2/06, Erast Benson [EMAIL PROTECTED] wrote: gcc-4.x branch has reworked optmizer for C++ and generates quite fast objects. yup. By any chance, do you have comparision links between Studio and gcc-4.x ? Latest issue of Linux Magazine discusses gcc-4.x vs gcc-3.x. the results of the comparison are not spectacular, or much different than gcc 3.x. i don't have links, but i have a test program, with results. because of the restrictions prohibiting the posting of benchmark results unless explicitly authorized by Sun, i can only post the output of this program here. if someone from Sun says it's ok to post the whole thing, i will gladly do so. Disclaimer: This Is Not A Benchmark. This is a silly test program. 1. SPARC: [EMAIL PROTECTED]/programming/fibonacci.SPARC][01/02/2006 14:31:38][81] /usr/bin/time -p fibonacci.SunStudio10 -i 50 -f 36 fibonacci.SunStudio10: calculated 50 fibonacci(36) in 20.96 seconds real 20.99 user 20.97 sys 0.01 [EMAIL PROTECTED]/programming/fibonacci.SPARC][01/02/2006 14:32:11][82] /usr/bin/time -p fibonacci.SunStudio11 -i 50 -f 36 fibonacci.SunStudio11: calculated 50 fibonacci(36) in 20.80 seconds real 20.82 user 20.81 sys 0.00 [EMAIL PROTECTED]/programming/fibonacci.SPARC][01/02/2006 14:32:43][83] /usr/bin/time -p fibonacci.gcc342 -i 50 -f 36 fibonacci.gcc342: calculated 50 fibonacci(36) in 52.68 seconds real 52.71 user 52.68 sys 0.00 [EMAIL PROTECTED]/programming/fibonacci.SPARC][01/02/2006 14:33:46][84] 2. X86: [EMAIL PROTECTED]/src/steleman/fibonacci][01/02/2006 14:38:56][358] /usr/bin/time -p fibonacci.SunStudio10 -i 50 -f 36 fibonacci.SunStudio10: calculated 50 fibonacci(36) in 9.45 seconds real 9.46 user 9.45 sys 0.00 [EMAIL PROTECTED]/src/steleman/fibonacci][01/02/2006 14:40:06][359] /usr/bin/time -p fibonacci.SunStudio11 -i 50 -f 36 fibonacci.SunStudio11: calculated 50 fibonacci(36) in 9.32 seconds real 9.32 user 9.32 sys 0.00 [EMAIL PROTECTED]/src/steleman/fibonacci][01/02/2006 14:40:25][360] /usr/bin/time -p fibonacci.gcc342 -i 50 -f 36 fibonacci.gcc342: calculated 50 fibonacci(36) in 10.12 seconds real 10.12 user 10.12 sys 0.00 [EMAIL PROTECTED]/src/steleman/fibonacci][01/02/2006 14:40:46][361] Now, if gcc 4.x has gone from 52.68 seconds to 20.96 seconds on SPARC, i would sure like to know. In C++, GCC and SunStudio do not get along at all. And sometimes not in C either. You mean binary incompatability? Example please? 1. Try compling QT with GCC (either version above 3.x.x) and then try compiling and linking KDE against that build of QT, with SunStudio, and let us know how the linking goes. :-) 2. Try building libmad, libxine or liba52dec (which are written in C) with SunStudio, and let us know the results. 3. Hint: The C++ Standard (ISO/IEC 14882:2003) does not contain a single instance of the following regular expressions: - mangling - virtual table --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Companion CD [ was: KDE, GNOME, etc. ]
On 1/2/06, Erast Benson [EMAIL PROTECTED] wrote: and what makes you think C++ is going to be any better ? traditionally, C++ is always worse than C. comparison, comparison wise ... :-) gcc-3.4 and gcc-4.x C delta != C++ delta ok, so because there are no published benchmarks of SunStudio 10 C++ vs. GCC4 C++, let's just assume GCC4 is faster, with no data to back up that assumption. past performance notwithstanding. of cause not... still, when you have a chance, could you please pass linking error here to discuss/verify? i have not spent time doing this test since 2002. there is sufficient and more recent information to this effect on the kde-solaris list (people trying to build KDE with SunStudio against GCC built QT by mistake), with predictable results. sure, some software uses gcc-izms, so that's a known fact. How is this related to gcc vs. studio performance problem? if we agree that Sun Studio has better performance, it would make sense to build everything with Sun Studio, as opposed to taking the Big Compiler Mish-Mash approach. IMHO. if you disagree, we could throw in the Centerline and EDG compilers in the mix, let's see what comes out. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Companion CD [ was: KDE, GNOME, etc. ]
On 1/2/06, Damjan Perenic [EMAIL PROTECTED] wrote: When I run oopack and stepanov last time (admittedly, quite some time ago) though both compilers, I got results the other way around on both, x86 and SPARC. As I remember, the difference in C was not big at all. Sun Studio was a bit faster on SPARC and a bit slower on x86. But it was C++ where the difference was big in favour on gcc. Here are some C/C++ benchmarks, like oopack and stepanov, which have same routines written in C and C++ language. http://annwm.lbl.gov/bench/ http://www.ratol.fi/~sfarin/cpp-bench/ Things have probably changed since then as there were major compiler releases since then. Maybe it would be a good time to rerun it with Sun Studio 11 (-fast) and equivalent on gcc 4.0 (-O3 -ffast-math -funroll-loops -mcpu=ultrasparc3 -m64 -mvis -ftree-vectorize). And after all, they are still just benchmarks. Results could be the other way around with different benchmarks as seen in your case. -fast is not the fastest option on either SPARC or X86. he who uses -fast shall be disappointed. :-) it actually generates significantly _slower_ code than other options (which require more work because they need to be written out). --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE 3.4.3 @ Sunfreeware
On 12/28/05, ken mays [EMAIL PROTECTED] wrote: Congrads Stefan and Steve C. !!! Any ETA for the KDE work to be ported to the Companion CD?!? i don't know precisely _yet_, because there are at least two rather complex steps to be taken for KDE to make it on the Companion CD: 1. figuring out which of the *many* KDE requirement libraries go on the Companion CD as part of the core distribution, and which go as part of the KDE requirements dependencies only. 2 (a). building these libraries with the correct Companion CD RPATH and location 2 (b). building KDE with the correct Companion CD RPATH 3. testing thoroughly 2(a) and 2(b). As soon as we figure these out, we can have a more precise timeline. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE Translucency
On 12/28/05, Paul Gress [EMAIL PROTECTED] wrote: 4) Installed the kompmgr that came with kwin. Problem. Searched the whole installation for this file, not there. kompmgr cannot be built (yet) on S10 because the S10 Xorg 6.8.2 does not yet support XComposite, and kcompmgr requires XComposite. i have built XComposite on my own (from the Xorg sources), but it is extremely unstable and i decided against releasing it, since it would have been of very little use anyway. the situation is identical on SPARC. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE Translucency
On 12/28/05, Paul Gress [EMAIL PROTECTED] wrote: The XComposite is an Xorg library. Shouldn't this be Sun's responsibility to add. Are they going to have it in Xorg 6.9? i really don't know. maybe AlanC could shed some light on this when he gets back from vacation. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KDE 3.4.3 @ Sunfreeware
Many Thank You's to Steve Christensen for making KDE 3.4.3 available at Sun Freeware and its mirrors: http://www.sunfreeware.com/ --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] K3B upgraded to 0.12.10
Hi. i upgraded K3B to version 0.12.10 (IA32 and SPARC): http://lists.kde.org/?l=kde-solarism=113547539525248w=2 --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Companion CD [ was: KDE, GNOME, etc. ]
On 12/21/05, Eric Boutilier [EMAIL PROTECTED] wrote: Back to KDE. Per the OpenSolaris roadmap[1], the same thing will eventually happen with KDE via the Companion CD. Which is to say, Sun's port source code and development environment for the Nevada KDE packages will be launched on opensolaris.org sometime in Q1 '06. Hi. Sorry for replying at random -- first, thank you for the very kind words. A bit of news: i have been working with Steve Christensen , and i am very happy to let everyone know that KDE will be available on the Companion CD. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: KDE, GNOME, etc.
I can easily sit here and ask where else can I find Scribus or FlightGear (not to get too far off topic) other than Blastwave?!? Scribus for Solaris has been available at KDE since early 2004 and KDE 3.3.1 --Stefan This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/22/05, ken mays [EMAIL PROTECTED] wrote: Stefan seems to have delivered the answer that KDE was being updated on the Companion CD with Steve C.'s help and we have people willing to 'officially' support KDE on Solaris - with Sun's enginering assistance i think with regard of support of the Companion CD, we can say that it is not a Sun supported product, but it is Community supported, if you run into trouble or have any questions, please post a message to insert mailing list here and the community will help on a best effort basis. very many open source software packages have functioned with this model for a very long time. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/20/05, Glynn Foster [EMAIL PROTECTED] wrote: Having BOTH means giving users (actual and potential) a choice. It's really about resources issues. The desktop team within Sun is already swamped enough without having to look and fix issues with KDE as well. But yeah, I completely agree with you - having the ability for customers to install KDE off the companion CD or off some online package repository would be *ABSOLUTELY FANTASTIC*. is Sun willing to at least give access to a SVN repository so the KDE Solaris port source code and the associated required libraries source code (which, by the way, are three times the size of what used to be the Companion CD) have a material presence at OpenSolaris, where people can actually collaborate and do work ? if that is not possible, then the current situation will not change, and will not improve. KDE can be downloaded right now off the 'Net, in its various shapes, forms and incarnations. having a real, collaborative engineering effort at OpenSolaris does not formally imply product support from Sun. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/21/05, Ian Collins [EMAIL PROTECTED] wrote: Would it be possible to base your KDE build on Blastwave libraries? No. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/21/05, Ian Collins [EMAIL PROTECTED] wrote: Would it be possible to base your KDE build on Blastwave libraries? As the most actively maintained set for Solaris, I can see them moving towards becoming de facto standards. Blastave is *not* the de fact standard for anything on Solaris. At least not insofar as solaris.kde.org is concerned. There is currently no de facto, or de jure, standard for open source packages on Solaris. There are *several* distributions of GNU/OpenSource packages for Solaris, each one of them with their advangages and their disadvantages. To ascertain a priori on this forum that somehow Blastwave is a primus inter pares amongst GNU/OpenSource Solaris distributions is a matter of personal opinion, and not everyone is required, or expected to share it. I do not share in this opinion, and i have objective reasons for not sharing this opinion. I can explain these reasons upon request. If this were to happen, I think you KDE would become more popular. KDE is doing quite well on its own merits, with, or without Blastwave. Stefan Teleman -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/21/05, Ian Collins [EMAIL PROTECTED] wrote: Why the hostility, when I only asked a polite question? I find this incessant Blastwave promotion patently unfair. How come none of the Blastwave promoters ever mentions the work done by Steve Christensen with Sunfreeware, or the work done by The Written Word ? And i am quite certain they are others i forget right now. There was a time, not so long ago, when Sunfreeware was the *only* where GNU/OpenSource software for Solaris was available for download. Sunfreeware *still* maintains and publishes packages for Solaris, on both X86 and SPARC. So does The Written Word. The reason i am involved with KDE and OpenSolaris is because i believe that individuals are entitled to certain freedom rights insofar as software is concerned, and because i believe that freedom, openness, honesty and fair play foster creativity and innovation. Openness, honesty and fair play carry a responsibility on the part of those involved in free software: one must be willing to take a back seat in this show, because the show is not about particular distributions, or individuals, but about freedom, innovation and creativity. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/21/05, Ian Collins [EMAIL PROTECTED] wrote: This would be a start in cleaning what appears to an outsider to be the messy situation of conflicting version of the same application. Then you wouldn't have to spend your time keeping the KDE dependencies up to date. Freedom can also be freedom for the drudgery of maintaining thins you require, rather than those you want to build and grow. I know, I've been there. There is nothing i would like more than for all of us involved in this to finally agree on a set of standards, and follow them. That means *all* of us. I have asked this very exact question 6 months ago, on this forum. What was the response ? Does anyone remember ? If my recollections are correct, of all the parties of whom the question was asked, only two answered. one of them was OpenSolaris (a.k.a. Glen), the other one was solaris.kde.org. (a.k.a. yours truly). Blastwave chose to stay silent. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/21/05, Ian Collins [EMAIL PROTECTED] wrote: Stefan Teleman wrote: On 12/21/05, Ian Collins [EMAIL PROTECTED] wrote: Yes I remember that well and as you say, nothing has happened in the interim. So, how can we move forward? Any common system must include Sun Solaris packages as well, to avoid the silly situation John raised. Defining a means of identifying packages isn't hard, an agreed file format and location should be all that is required. This can be a simple text or XML file with the name, version and location of each package. It could be appended to by a package post-install script and scanned by a pre-install script to check the system for required dependencies. Have I over simplified the problem and solution? If not, let's take this forward. a bit, i think. i think GNU/OpenSource packages fall into three broad top-level categories: 0. software which never updates (example: gettextlib, which is considered done) 1. software for which updates are possible, but do not occur often (example: gdbm) 2. software which updates frequently (example: gstreamer) these three categories can each be further divided into three: 10. core (example: GNU fileutils) 11. application-specific dependency (example ffmpeg, which by itself is not very useful, but is required by Xine and many others) 12. toplevel application, which depends on 10 and 11 (example: Xine) and then there is the broad category of large-scale distributions, like GNOME and KDE, which have dependencies on all the types of software mentioned above, but which are also self-contained frameworks, with their own set of internal dependencies. i actually gave this some thought over the past few months. here's what i came up with, and this is just a suggestion. if it were up to me, i would build a relational database which describes: 0. each individual package, which has foreign key relationships to all the categories it belongs to 1. relationships between packages listed in 0, expressed as lookup tables based on unique numeric id's the advantages of doing this are: - managed inventory - well defined package categories - well defined package dependencies - a large scale package download (for example GNOME) becomes a join, and can be expressed as a checkbox on a GUI installer. figuring out what packages to install happens automagically behind the scenes, with the join, the user only clicks on Install GNOME. - RPATH (which is an expression of dependencies) is also a join - no unnecessary downloads (they won't be part of the join) in terms of the actuall installation tool, i personally like very much Sun's WebStart install, which is used by the Companion CD. it's written in Java, it's GUI driven, therefore it's easy to use for installs, and it's also easy for uninstalls. if i were to implement this, i would do it in PostgreSQL on the backend and WebStart as the frontend. the user will only have to download a small Java application which is the installer driver, and presents them with a list of package choices. users can choose to only install a small package (for example gdbm) with one click, or they can choose to install the entire KDE with one click, or only install the fundamental modules of KDE plus just two additional modules with one click for the KDE foundation modules and two for each of the additionals. of course, the Java installer should also support command-line installs as well (for example: java-installer --nogui --list-packages followed by java-installer --nogui --install JDS --version 3.2.2). this also has the advantage of providing GPL compliance out of the box. the user can click a radio button labeled install source for anything they choose to install (for the GUI), and for the command line it's just an additional option: --install-source just my 0.02. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/19/05, Joerg Schilling [EMAIL PROTECTED] wrote: How many catholics will avoid to use the pill just because the pope recommends not to use it? i don't use the pill and i am catholic. is that bad ? --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] KDE, GNOME, etc.
On 12/20/05, ken mays [EMAIL PROTECTED] wrote: The benefit of BOTH GNOME and KDE is in the modern open source applications developed for those desktop environments. Really, having both GNOME and KDE available is a better choice in the long run as it opens up more open source software to the consumer no matter which major UNIX desktop environment they chose in the end. in my mind, this is about choice. we all want Solaris/OpenSolaris to be the Desktop of choice (yes, some may say that i am being unrealistic here, but i have my reasons for really believing this is possible). i remember the times when having a Sun Workstation on your desk was Da Bomb. this is *not* about My Desktop Is Better Than Your Desktop. if it's too difficult to support both GNOME and KDE within Sun, why can't the Desktop Project be split ? GNOME/JDS within Sun and KDE outside Sun. Having BOTH means giving users (actual and potential) a choice. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: OpenSolairis a choice for the government desktop? // Re: [osol-discuss] KDE, GNOME, etc.
On 12/19/05, Brian Nitz [EMAIL PROTECTED] wrote: I'm sure there are other areas where GNOME has an advantage over KDE. For example PDF rendering. I hope Opensolaris distributions based on KDE, Looking glass and other open source desktops become available but if everyone played by the rules and followed proper procurement directives, GNOME would have a decent chance of winning government desktops. Are you actually trying to publicly suggest that GNOME/JDS has not succeeded because of unfair competitive practices by KDE e.V. Stefan Teleman -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] KDE 3.4.3 IA32/AMD32 and UltraSPARC-II Released
KDE 3.4.3 (Sun Studio 10 build) has been released. Announcement is here: http://lists.kde.org/?l=kde-solarism=113497402431141w=2 Screenshots are here: http://www.flickr.com/photos/skipjackdes/sets/1603147/ Stefan Teleman -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On 11/21/05, Alan DuBoff [EMAIL PROTECTED] wrote: On Monday 21 November 2005 06:37 am, Patrick Mauritz wrote: On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: This is currently a problem with all of the distributions on Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, etc...all build their own userland. GNU/OpenSolaris does the same in it's own way. this is why I built my own Right. But ultimately if we want to really work together, it would be nice if we had a common set of libraries that everyone could use, and so that we shouldn't have so many sets of libs floating around our directories. The fact that you build your own only exemplifies that point, IMO. i agree 100% with Alan on this. with one notable exception, i have seen very little in terms of working together, although it's been several months since the idea was brought up. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Anyone succeded in porting xine to Nevada?
On 11/13/05, Alfredo Peña [EMAIL PROTECTED] wrote: I'm trying to run xine-ui in Nevada b25 (Solaris Express build 25) without success. Here is what I have right now: - xinelib should be compiled with gcc and linked with gld, Solaris native ld doesn't work (lots of relocation problems) - there are several glibc functions used by xinelib and xine-ui that doesn't have an implementation in Solaris libc and the xine configuration step doesn't check for. These are strsep, strndup and getline. I replaced them with implementations I found in the web. - gxine cannot be built with the gnome version shipped, as it requires gnome 2.10, so I tried xine-ui xine-ui dumps core after initialising the xshm extension, this is the stack trace: #0 0xce3ff4f8 in resolve_object () from /usr/lib/libX11.so.4 #1 0xce3ff854 in _XsunOsDynamicLoad () from /usr/lib/libX11.so.4 #2 0xce3a2763 in _XOpenLC () from /usr/lib/libX11.so.4 #3 0xce3b5cf7 in _XlcCurrentLC () from /usr/lib/libX11.so.4 #4 0xce3ed917 in _XkbGetCharset () from /usr/lib/libX11.so.4 #5 0xce3eb879 in _XkbLoadDpy () from /usr/lib/libX11.so.4 #6 0xce3b77b8 in XKeysymToKeycode () from /usr/lib/libX11.so.4 #7 0x080c2d7f in xitk_init () Can anybody give me a tip on what is wrong? Thanks, Alf xine builds and runs fine on S10 FCS with SunStudio 10 and /usr/ccs/bin/ld and very aggressive optimizations, on both UltraSPARC and X86. on SPARC it runs with no problems at all, no dropped frames, with the xshm extension. on X86 it runs equally well with the xv extension and Xorg. both SPARC and X86 run with no problems in fullscreen mode (definition of no problems: watching a 2hr 15min DVD movie with no problems to report). screenshots of running xine with libxine-1.1.0 and xine-ui 0.99.4: http://www.flickr.com/photos/skipjackdes/ strsep and strndup are provided by libxine and can be found in libxineutil.a. getline is part of GNU libgettext. ./configure checks for these functions and flags their presence or absence in libxine's config.h. the SEGV above is caused by calls to libintl_bindtextdomain(). --Stefan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Sparc ? x86 Comparison
On 10/10/05, Alan DuBoff [EMAIL PROTECTED] wrote: Stefan, I wouldn't say that's completely true, there are actually some folks that design data centers around spec numbers. Most of the folks I know do not do that, but I do hear there are folks that do that. I 'spose this needs to be taken into consideration, since there are some folks that do that. It would be interesting to understand why those folks that do design data centers based on spec numbers do that. Agreed. For certain types of software, spec numbers are important. If the software in question will spend most of its time doing what the benchmark did. i don't know how realistic that is. So, let's just say that Linux is faster is some operations (which it most certainly is, even though it's slower in others). Let's say that you need to select an OS. Do you select it on the results that point to a faster system on Linux for a specific task? Nope (if i am making a rational decision based on observable evidence and facts). i deal with (soft) real-time software every single day of my day job. this does not only include (near) real-time complex math, it also includes (near) real-time network data tranfers (to the extent real-time is possible). i keep saying near because none of this is implemented in firmware for some specific processors, it's all software. For these types of systems, spec numbers become second in consideration. First and foremost are reliability and predictability plus cost of development plus cost of maintenance (too many buzzwords already). The operating system in question must have a 100% reliable threads implementation, a 100% reliable filesystem implementation, documented uptimes measured in hundreds of days, a flat response time curve under increasing load, 100% binary compatibility when applying upgrades or patches, clearly observable performance analysis tools, and a state of the art set of development tools. these are the foremost considerations. whether or not it came in second on one spec and first on another spec, that will be noted, but is secondary, and ultimately becomes the developer's (my) job: make it as fast as possible, and make it perform to requirements. spending some extra $$$ on four additional CPU's is significantly less expensive than losing several USD $MM because of a crash in the middle of the day. I'd like to take a step back and concede that Linux is faster at some operations. I know Sun's performance group is working to tighten up that very gap in those areas. What does this all mean? sure it is faster on some operations, according to the benchmark. but the benchmark is just one aspect, in my experience. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No CDE in OpenSolaris
On 9/11/05, Shawn Walker [EMAIL PROTECTED] wrote: Wasted time? As long as *commercial* native KDE applications have to pay the Trolltech Tax GNOME is the only viable alternative for many commercial endeavors. KDE does not publish or write any commercial software of any kind. Period. There are *no* fees to be paid for downloading, building or using KDE. The version of QT used in KDE is the GPL version of QT. As such, there are no fees or licenses to be paid for using the version of QT used in KDE. Please stop posting erroneous information. Thank you. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No CDE in OpenSolaris
On 9/12/05, Shawn Walker [EMAIL PROTECTED] wrote: On 9/11/05, Stefan Teleman [EMAIL PROTECTED] wrote: Please stop posting erroneous information. It is not erroneus information. Yes, it is. For all practical purposes, since the very base toolkit of KDE is Qt, and you must license Qt from Trolltech for any major commercial applications (be serious, who releases major desktop commercial applications like Photoshop as GPL?) you have to pay what I and many others call the Trolltech Tax by licensing Qt so you don't have to GPL your software. GNOME does not require this. GNOME is not GPL V2? http://www.gnome.org/about/ GNOME is Free Software and part of the GNU project, dedicated to giving users and developers the ultimate level of control over their desktops, their software, and their data. Find out more about the GNU project and Free Software at gnu.org. For small businesses that write commercial software and don't want to GPL it, you are *forced* to license Qt if you want to make a native KDE application. Hence terming it a tax. This is simply not true. KDE is released under GPL V2, just as GNOME. The QT version used by KDE is released under GPL V2, just as GNOME. I don't believe i need to rehash the terms and conditions of the GPL. Please stop posting erroneous information. Thank you. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
