On Friday, September 6, 2002, at 12:57 PM GMT, Adrian Umpleby wrote:
but what about the THREADING aspect of it?On Monday, September 2, 2002 at 4:48:12 AM PST, Lenny Bruce wrote:It only contains the XDarwin application (the X server itself) - there'sThe threaded XFree86 4.2.0.1-1 has been released on Fink. OroborOSX-v0.8b2 contains a private XDarwin within its package.
much more to XDarwin (i.e. XFree86 for OSX) than just XDarwin.app...
How does this new XFree86 impact OroborOSX-v0.8b2 use of a private XDarwin?Just run OroborOSX as normal and all should be well.
The threaded version of XDarwin is still really considered to be experimental,
and there are several possible (though rare) problems with it...
Yes, you can install the new XDarwin - OroborOSX will continue to use its ownShould we use the new XDarwin? Can the new XDarwin be modified?
version of the XDarwin application (i.e. the actual X server), though all the
other parts (the dynamic libs, and the various X11 apps like xterm/xeyes/etc.)
will be the newer ones from 4.2.0.1.
forget OroborOSX for a second... what does it do to XFree86
if you run the non-threaded XDarwin on the threaded libraries
it's a situation they never expect the user to encounter
because one can only install one version or the other
and you wouldn't normally have an extra XDarwin application sitting around
you've included your own XDarwin inside the OroborOSX application package
and I assume it's from the non-threaded version of XFree86
my original question was about
what happens if we update XFree86 to a new version
when there's no matching version of OroborOSX
(because of the differing versions of XDarwin)
but now I'm asking
what happens if we use the threaded version of XFree86
when the XDarwin used by OroborOSX is from the non-threaded version
that's a similar question because it leads to my original point:
the reason I asked this questionThere once was an interleaving script included with OroborOSX to modify XDarwinThe interleaving script is now redundant - it only operated on the external
but now OroborOSX includes its own XDarwin instead... and now what do we do?
version of the XDarwin app. Interleaving is now toggled on-the-fly from within
OroborOSX itself (providing you are using the modified XDarwin.app).
was for this problem about XDarwin versions.
in any case it would be a wonderful thing
if OroborOSX was not tied to a specific XDarwin
for the two reasons I discovered: versions and threading
my question about the interleaving script
was really a question about building our own OroborOSX
to match the version of XFree86 we are using
I'm not nit-picking or attacking you... I'm a great fan.
I believe the combo of OroborOSX, Fink, and FinkCommander added to XFree86
will enable/encourage the majority of Mac OS X users to use open-source UNIX software
where they would otherwise be frightened away from the experience
The people I want to attack are TENON... what they're doing is CRIMINAL.
The more interesting (and difficult) changes are going to come when the direct-drawing and accelerated 3d version of the XDarwin X server is released. That's going to require some quite major changes to the code of the modified XDarwin to keep some of the OroborOSX features intact (such as translucency and dimming).I believe we're being cheated by a transparent payware conspiracy.
We're the only platform where HW OpenGL for XFree86 is payware.
It must be political.
Somehow Tenon is preventing XonX from releasing XFree86 with Hardware OpenGL support. (I wonder about Powerlan eXodus too.) There's no reason for XonX to deny it to us other than greed and complicity with Tenon. Apple GIVES us the shared libraries and headers necessary to link to Hardware OpenGL in /System/Library/Frameworks/OpenGL.framework for free. Tenon is getting away with being able to SELL the open-source completely-free XFree86 with a teeny tiny modification while forbidding XonX from doing it. That's Microsoft-level antitrust racketeering!!! The Fink team was able to patch ESD into CoreAudio very easily using Apple headers and libs in the CoreAudio framework - linking Hardware OpenGL has to be the same method and a lot easier. XonX simply WON'T give it to us.
The sickest part of this is that Tenon is not really profiting from it. Most people are choosing the free Fink version rather than suffer Tenon's old (20020222) version of XFree86 4.2. OroborOSX does exactly what Tenon's front-end does and does it much better. They're charging $199 for their exclusive payware link between the completely-free open-source XFree86 and the completely-free open-source Hardware OpenGL libraries -- while blocking the XonX team from linking them -- even though Apple provides us with the so-called "missing pieces" for free. I've read incredible misleading excuses from the XonX team where they bitch about the difficulty access hardware directly -- that's a giant lie because OpenGL provides singular universal access to specific hardware -- Apple did all the difficult work for us and did it for free! The more you think about it, the more it sounds like Microsoft's criminal activity... Tenon just isn't smart enough to profit from the extreme damage they're doing to us.
There must be something we can do to stop Tenon's racketeering!!!
Should we go to the US Federal Trade Commission?
Why should we be the only platform that has to pay for free things?
(Don't bitch about Mac OS X being a commercial product built on free materials. Apple makes Darwin available for free, they're only charging us for Aqua and Cocoa. You can run XFree86 on top of Darwin for free.)
lenny bruce
[EMAIL PROTECTED]
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Fink-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-users
