OS X might already be licensed. SCO isn't trying to stop companies from using UNIX, they're just trying to get people not paying them licensing fees to start. A good chunk of that $120 you pay in OS X upgrades may already be going to SCOs coffers.
(note: yes, that is speculation - i don't claim to know what contracts apple is under.)
And, of course, you can very well write a compositing manager to do this. That's the beauty of this extension set and architecture - the X server doesn't tell you how to render things. It just provides the means to let you do it. You could even swap composition managers on the fly, I'd imagine, or just tweak settings there-of, or whatever. Just like you can do with a window manager.
OpenGL isn't a 2D rendering system. And, just to point it out, the compositing manager is completely free to use OpenGL to do said compositing.
You are confusing the high level management and protocol with the low-level rendering driver/architecture. Quartz Extreme may use OpenGL for rendering, but the apps don't use OpenGL calls to do it - they use Aqua/Quartz calls, which uses OpenGL in its lower layers for final rendering/composition.
I don't think this is the issue anymore - the extensions used for this translucency don't require any driver changes, as RENDER (or any other rendering method/extension) can be used.
Here's to hoping XFree86 gets these extensions. Having an X server that doesn't work that well for the hardware most people are using is going to limit how many people can use these new extensions...;-)
The only really good use I can think of at all for Kylix is reusing old code, not written with modern development tools in mind. But Kylix didn't work for that, since Windows Delphi and Kylix were apparantly incompatible.
Who in all the world would want an application development suite that thus had absolutely no use, especially given its price?
if GTK or Qt, both well designed toolkits, run slowly, chances are, it's *not them*. X has lots of problems forcing both of those toolkits to do a lot more work than they should need to in order to provide functionality to the user. if you bitch about apps being the problem, and to just remove the apps... what is the point of using my computer at all then?
your previous post also goes on with some more nonsense facts, like how WindowMaker being C makes it noticably faster - I hate to tell you this, but just about all of GNOME is written in C, too.;-)
im not saying GTK/Qt/GNOME/KDE don't have problems (GTK still doesn't handle events as efficiently as it could, forcing more round trips and redraws then necessary), but they are far from the only problem.
not even your WindowMaker can do some of the things OS X and Longhorn can(will) do, simply because basic 2D acceleration with a complete lack of things like transparency isn't enough. to say XFree86 is perfectly fine and speedy is like saying your tty is perfectly fine and speedy - technically true, but completely irrelevant of what *most* people actually use their computers for.
I noticed the spots several times in Underworld, and it was actually pretty annoying. I didn't realize what they were tho, I thought perhaps they were some version of the dots movies always had when reels were aligned. Guess now I know.
On the upside, I guess I shouldn't worry too much about them, that movie isn't worth paying for a DVD version.;-)
[in case anyone's wondering, *no*, that doesn't mean I'll pirate it - just that i'll not watch it again]
ADV: This is so unbelievable! ~~~234
on
Building Better Spam
·
· Score: 3, Funny
You haven't sent me the $19.95 the e-mail requested, of course! Send me the money, and I promise I'll deliver the possiblity of perhaps maybe getting all your desires.*
(*note: "all your desires" is defined as "an e-mailed receipt** showing you paid $19.95 for penis enlargement.)
(**note: by "e-mailed receipt", we mean e-mailed to all your friends, relatives, and co-workers.)
Ya, I'll admit XSLT is a pretty hard language to work with in the readability department. Especially if you look at my XSLT scripts in AweMUD, which were my first large XSLT scripts. ~,^
It probably wouldn't be bad at all to just use a DOM-based parser in Perl or Python or something and use that to generate the output.
I upgrade my hardware a lot with nothing more complex than a floppy disk, if that. Additionally, security holes/bugs can often be fixed without breaking the interface. I'm not sure the fact that DRM is in hardware is such the black/white case you make it out to be.
Code generation is definitely something programmers of large/complex projects should look into. There's a lot of different forms of it, and I'd be surprised if people haven't used on form or another already.
My personal favorite trick at the moment is describing interfaces in XML, and getting multi-language bindings and docs out of it with a few XSLT scripts. Techniques like that makes script language bindings easy as pie (as do other systems like Swig).
Have you any idea how much lots of lawyers cost? I don't think many Open Source companies could possibly afford such a lawsuit. Weighing the loss of profits from customers scared by SCO (all, what, 1.34 of them?) versus the cost of a lawsuit, it may just make more sense for them to wait for SCO to kill themselves off, or for IBM to smash them.
From the article: "And the recording industry has struggled with this with Napster. I'm impressed that these people were able to come up with free file-sharing. How somebody was able to figure out how to do that, I'll never understand."
Right; so he clearly doesn't understand technology much at all, if file sharing is so mystical and magical, and the idea of fricken connecting to another machine and downloading something is so amazing.
While understanding technology has little to do with understanding "this text/code is a direct copy and that's illegal", it does make one wonder how competent these lawyers are for such a technological case.
What does apache, an http server, have to do with their ftp server being cracked?
But no, Apache isn't 100% secure. There is no such 100% server, except one unplugged from the net, encased in titanium, and buried beneath the Pacific seabed.
If all the technology used to drive the internet is down, so would be I imagine the powerlines; so in these destroyed or desolate areas with no cell towers or working cabling, the ham radios would work well enough, no?
Re:Don't think so....
on
Qt On DirectFB
·
· Score: 4, Informative
DirectFB has a multi-application core, and also a specialized X server that runs on it. You can run GNOME on it already, adding Qt/KDE to the mix only _increases_ the number of apps that can be run on it natively.
And so far as the "features" of X... the only feature X has that DirectFB doesn't is network independence, which very few users need, and those who do can use VNC or the DirectFB X server.
For starts, having access to the source doesn't guarantee anything, since your compiler itself may be hacked. (There are a couple papers on this iirc, Google is your friend.)
Second, there is the simple case of ease. It is a serious pain in the ass to check each and every program installed on a modern desktop OS. It is so much easier to just click on an app in Red Carpet, wait for it (and dependencies) to download and install, and then get on with doing real work. I don't have the time nor the inclination to spend hours and hours scouring source.
If was running a server used to control nuclear reactors, sure, I'd want a little more security. Sitting at my desk doing web development or playing Quake, who the hell cares?
I just wish people would remember all the _good_ parts of trusted computing. So far as the TCPA goes, DRM isn't even a part of it. It's just a standard hardware interface for encryption and key storage. Whether that's used to sign OS's, implement DRM, or simply secure Apache, is up to the OS. Yes, it _can_ be used for all that. But hell, a BIOS _now_ can be set to only boot an OS with a certain fingerprint - how the technology is used is independent from the technology itself. TCPA is a (possibly) good thing. Palladium/DRM, that's the real evil (from the consumer and OSS viewpoints, anyways).
Eh? This is the reverse if anything - benchmarking labs are free to make any modifications they want to the compiler beforehand. I'm not saying they do, just making it clear that a compiler being open source doesn't protect you against anything.
Slashdot Mirror
OS X might already be licensed. SCO isn't trying to stop companies from using UNIX, they're just trying to get people not paying them licensing fees to start. A good chunk of that $120 you pay in OS X upgrades may already be going to SCOs coffers.
(note: yes, that is speculation - i don't claim to know what contracts apple is under.)
And, of course, you can very well write a compositing manager to do this. That's the beauty of this extension set and architecture - the X server doesn't tell you how to render things. It just provides the means to let you do it. You could even swap composition managers on the fly, I'd imagine, or just tweak settings there-of, or whatever. Just like you can do with a window manager.
OpenGL isn't a 2D rendering system. And, just to point it out, the compositing manager is completely free to use OpenGL to do said compositing.
You are confusing the high level management and protocol with the low-level rendering driver/architecture. Quartz Extreme may use OpenGL for rendering, but the apps don't use OpenGL calls to do it - they use Aqua/Quartz calls, which uses OpenGL in its lower layers for final rendering/composition.
I don't think this is the issue anymore - the extensions used for this translucency don't require any driver changes, as RENDER (or any other rendering method/extension) can be used.
;-)
Here's to hoping XFree86 gets these extensions. Having an X server that doesn't work that well for the hardware most people are using is going to limit how many people can use these new extensions...
The only really good use I can think of at all for Kylix is reusing old code, not written with modern development tools in mind. But Kylix didn't work for that, since Windows Delphi and Kylix were apparantly incompatible.
Who in all the world would want an application development suite that thus had absolutely no use, especially given its price?
Damn, the compiler's spitting chunks on this code. Starting to make my head spin...
They should've saved that title for the Linux/BSD port. Those seem a lot rarer than Windows ports of GUI apps from Apple. ;-)
sure, and my pure-text console screems on a p66.
;-)
if GTK or Qt, both well designed toolkits, run slowly, chances are, it's *not them*. X has lots of problems forcing both of those toolkits to do a lot more work than they should need to in order to provide functionality to the user. if you bitch about apps being the problem, and to just remove the apps... what is the point of using my computer at all then?
your previous post also goes on with some more nonsense facts, like how WindowMaker being C makes it noticably faster - I hate to tell you this, but just about all of GNOME is written in C, too.
im not saying GTK/Qt/GNOME/KDE don't have problems (GTK still doesn't handle events as efficiently as it could, forcing more round trips and redraws then necessary), but they are far from the only problem.
not even your WindowMaker can do some of the things OS X and Longhorn can(will) do, simply because basic 2D acceleration with a complete lack of things like transparency isn't enough. to say XFree86 is perfectly fine and speedy is like saying your tty is perfectly fine and speedy - technically true, but completely irrelevant of what *most* people actually use their computers for.
If you do notice these spots, demand your money back from the theater; you have the right if the movie you paid for is "defective."
Enough people demand their money back, they'll stop.
I noticed the spots several times in Underworld, and it was actually pretty annoying. I didn't realize what they were tho, I thought perhaps they were some version of the dots movies always had when reels were aligned. Guess now I know.
;-)
On the upside, I guess I shouldn't worry too much about them, that movie isn't worth paying for a DVD version.
[in case anyone's wondering, *no*, that doesn't mean I'll pirate it - just that i'll not watch it again]
You haven't sent me the $19.95 the e-mail requested, of course! Send me the money, and I promise I'll deliver the possiblity of perhaps maybe getting all your desires.*
(*note: "all your desires" is defined as "an e-mailed receipt** showing you paid $19.95 for penis enlargement.)
(**note: by "e-mailed receipt", we mean e-mailed to all your friends, relatives, and co-workers.)
Ya, I'll admit XSLT is a pretty hard language to work with in the readability department. Especially if you look at my XSLT scripts in AweMUD, which were my first large XSLT scripts. ~,^
It probably wouldn't be bad at all to just use a DOM-based parser in Perl or Python or something and use that to generate the output.
I upgrade my hardware a lot with nothing more complex than a floppy disk, if that. Additionally, security holes/bugs can often be fixed without breaking the interface. I'm not sure the fact that DRM is in hardware is such the black/white case you make it out to be.
Code generation is definitely something programmers of large/complex projects should look into. There's a lot of different forms of it, and I'd be surprised if people haven't used on form or another already.
My personal favorite trick at the moment is describing interfaces in XML, and getting multi-language bindings and docs out of it with a few XSLT scripts. Techniques like that makes script language bindings easy as pie (as do other systems like Swig).
Have you any idea how much lots of lawyers cost? I don't think many Open Source companies could possibly afford such a lawsuit. Weighing the loss of profits from customers scared by SCO (all, what, 1.34 of them?) versus the cost of a lawsuit, it may just make more sense for them to wait for SCO to kill themselves off, or for IBM to smash them.
From the article: "And the recording industry has struggled with this with Napster. I'm impressed that these people were able to come up with free file-sharing. How somebody was able to figure out how to do that, I'll never understand."
Right; so he clearly doesn't understand technology much at all, if file sharing is so mystical and magical, and the idea of fricken connecting to another machine and downloading something is so amazing.
While understanding technology has little to do with understanding "this text/code is a direct copy and that's illegal", it does make one wonder how competent these lawyers are for such a technological case.
What does apache, an http server, have to do with their ftp server being cracked?
But no, Apache isn't 100% secure. There is no such 100% server, except one unplugged from the net, encased in titanium, and buried beneath the Pacific seabed.
If all the technology used to drive the internet is down, so would be I imagine the powerlines; so in these destroyed or desolate areas with no cell towers or working cabling, the ham radios would work well enough, no?
DirectFB has a multi-application core, and also a specialized X server that runs on it. You can run GNOME on it already, adding Qt/KDE to the mix only _increases_ the number of apps that can be run on it natively.
And so far as the "features" of X... the only feature X has that DirectFB doesn't is network independence, which very few users need, and those who do can use VNC or the DirectFB X server.
Except that the new screens are pretty much ripoffs of Microsoft Entourage on the Mac. ;-)
Quite a few. Mandrake being one of the major ones.
For starts, having access to the source doesn't guarantee anything, since your compiler itself may be hacked. (There are a couple papers on this iirc, Google is your friend.)
Second, there is the simple case of ease. It is a serious pain in the ass to check each and every program installed on a modern desktop OS. It is so much easier to just click on an app in Red Carpet, wait for it (and dependencies) to download and install, and then get on with doing real work. I don't have the time nor the inclination to spend hours and hours scouring source.
If was running a server used to control nuclear reactors, sure, I'd want a little more security. Sitting at my desk doing web development or playing Quake, who the hell cares?
You mean IPSEC'ing your wireless connections? Something actually on my TODO list today. ^,^
I just wish people would remember all the _good_ parts of trusted computing. So far as the TCPA goes, DRM isn't even a part of it. It's just a standard hardware interface for encryption and key storage. Whether that's used to sign OS's, implement DRM, or simply secure Apache, is up to the OS. Yes, it _can_ be used for all that. But hell, a BIOS _now_ can be set to only boot an OS with a certain fingerprint - how the technology is used is independent from the technology itself. TCPA is a (possibly) good thing. Palladium/DRM, that's the real evil (from the consumer and OSS viewpoints, anyways).
Eh? This is the reverse if anything - benchmarking labs are free to make any modifications they want to the compiler beforehand. I'm not saying they do, just making it clear that a compiler being open source doesn't protect you against anything.