Strangely enough most of the OS X converts I know are experienced sysadmins / developers with years of experience on *nix.
Indeed. When I first switched started using a Mac casually, it was still largely "the artists platform". These days, I know more programmers and systems administrators sporting PowerBooks than I do graphic designers.
I've been using Linux for longer than most, and I still completely agree with you. This is why I now use OS X on my desktop.
All I have to say is "duck"... few/. readers can actually handle the truth, especially when the truth flies in the face of the reality-distortion-field surrounding the "Linux on the Desktop is Finally Ready" movement.
That is really what this comes down to.. if you're going to try to make something asynchronous reliable, you're going to need an ACK/NACK/missing ACK solution.. basicly all the same pitfalls of TCP over unreliable IP.
Indeed, and most modern MQ servers implement this.
You might as well just spawn a thread to deliver the message to a host:port TCP address tuple and skip all the queuing.
Why, when I can just set the MQ stack to deal with all of this for me? Of course, you're correct... but I have better things to do then write the ack/nack/missing ack logic.
The message queuing they're talking about is code centric asynchronous message sending in either publish/subscribe or peer-to-peer systems. It's for when one library of code (say, manufacturing control) needs to relay an XML message (or Java object serialization, or whatever) to another library of code (say, procurement) to tell it to execute additional logic. Human beings, save for debugging purposes, never actually read the messages and indeed, many times the messages aren't even really human readable.
So, no, not really like SMTP. Though SMTP is, I guess, a loose metaphor for how MQ servers work. That said, Exchange has nothing to do with it. The SMTP/POP3/IMAP model is just a little too much overhead for most message queue applications.
Of course, the real problem with your statement is that asynchronous messaging doesn't in fact preclude reliability, and indeed, the word asynchronous/synchronous and reliability are more or less completely different topics and wholly unrelated.
Most MQ servers persist undeliverable messages until such time as the destination peer (or the whole of the registered subscriber list) is available and ack's receipt of the message in question. All "asynchronous" means is that library A can send a message and continue on without ever caring about -when- the message is delivered.
Using the manufacturing/procurement example again, you can see why it would be stupid for manufacturing to walk their ordering message over to procurement, then wait around for the mail clerk to show up, take the message, and acknowledge it's been received. This would be a "synchronous" message transmission. Surely, it's easier to just leave it in an "inbox" for the clerk to pick up later (send the message asynchronously).
As for reinventing the wheel, I largely agree. Most large scale applications are being rolled out in J2EE or.NET, both of which offer message queuing (J2EE having tons from many different vendors - we use OpenJMS a lot in our shop).
The only thing I can see as being beneficial is a new MQ implemented with interaction entirely in XML-RPC, etc... as this would allow J2EE/.NET/PHP/whatever apps to use it regardless of platform.
Then tell me: why is linux more and more used by all sorts of hardware manufacturers?
There's actually a pretty good discussion about this on one of the MSDN blogs. The real answer that all the hardware manufacturers are giving: cost and reliability. They're pretty clear... it's not so much about "an equal playing ground" as it is about lowering the per-unit cost of their product and ensuring it works reliably once it's delivered (thus lowering support costs). Bottom line, Windows XP Embedded is expensive and flakey. Once again, I'm not seeing the "freedoms" issue being key here... existent, but hardly key. It's all about costs.
your assumption failes, and even if it did not, is one only entitled an opinion when he depends on the outcome of that opinion?
No, but those directly effected by an issue should always be entitled to more of a "vote" then those looking from on the sidelines. That said, I have no doubt your income depends on writing software... lots of peoples do. But being paid to write a program by a university (or a company) and writing one on your own dime are very different things. By your own admission, you have the luxury of the "reality barrier" between actually turning a profit on your work and what ends up in your bank account. This comes hand-in-hand with salaried or contracted work; vastly different from a "it fails you and don't get paid" situation.
And even if I were to write a decent piece of software in the hope people would pay me for it afterwards: ever heard of Bram Cohen? He is the author of BitTorrent (MIT license, free download). He accepts PayPal donations. He and his family live off these donations. Proof enough?
Far from it. A few poster boys here and there don't prove anything except that one in a million guys are able to buck the trend and make money. Good for Bram Cohen. The other 999,999 guys behind him are still having to depend on commercial software industry to buy their dinner.
One simularity in visionaries is that in their time they are called insane by the ones who do not understand them or fail to see the logical flow of things. The world has already been 100% open source, until software writers closed their source to limit their end-users' freedom (to change to another hardware provider for instance). The world will be open source again, as soon as end-users demand it.
You're missing a major key point here. You can DEMAND an open source copy of Adobe Photoshop all you want... but Adobe isn't going to release one because they know one thing; 99% of the people out there don't feel that their freedoms are infringed by not having the source code to their software.
What you and the rest of the OSS/FSF zombies should really clue in to is the fact that you are a massive minority.... nobody cares as much as you care... and the majority don't care at all. You can say this is because they have't been "educated", but the reality is that even the ones who have heard your message still can't understand why it's an issue.
Don't confuse the sucess of Linux (for example) with the sucess of your (err, RMS's via you) vision. Corporations love Linux because it's cost effective, not because they feel their freedoms are protected by it.
The again, why am I bothering? You're obviously not someone who's ever had to actually live off their ability to write software, so everything you're saying is just regurgitated propaganda anyways. Come talk to me when you have actually -tried- to make money selling your shiny new open source project.
The average OSS zealot, alas, has never actually had to buy their meals using money earned from writing and selling a software product.
It's all fine and dandy to say "all software should be free and include source code" and make some altruistic arguments about why... and in a perfect world, I would agree completely.
Here in reality on the other hand, I don't have the luxury of being paid by academia to wax intellectual about things. The corporation that takes my ideas and packages them, brands them, and puts them on the market makes the money, and I make nothing.
As many others have said, Solaris 10 is definately 64-bit capable on Opteron, with a full AMD64 kernel and AMD64 drivers. We have 3 B72 systems (Solaris beta from 10/04) running on dual opteron, all with 8GB of memory and all with 64-bit MySQL processes consuming well in excess of 4GB of memory...
Needless to say, definately 64-bit. This was true in the last express release and is true in the FCS.
As for Janus and ZFS... apparently Janus will be in the next release of Express. I'm much interested in ZFS... though obviously most/. readers will care less about it and Janus is the more important thing....
As a digression, I can't imagine why.... most/. readers are all about open source/free software and 99.9% of the free software builds on Solaris natively. Only thing I can see Janus being good for are the commercial apps, of course.
Solaris supports 64-bit on Opteron in exactly the same way it supports 64-bit on SPARC... 64-bit kernel with 64-bit drivers suporting either both 32-bit and 64-bit ABI's for applications and libraries.
Libraries appear in the same/usr/lib and/usr/lib/64 folders as they do on SPARC, so of course, you need to build 32 AND 64 bit libraries if you want all applications to link against them.
bash-2.05b$ file/opt/csw/mysql/bin/mysql/opt/csw/mysql/bin/mysql: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available
Regardless of what a nasty old troll tries to tell you, Solaris on Opteron has been fully 64-bit since B72 (11/04).
The release version even includes (in/usr/sfw) GCC 3.4.3 with the sol10 amd64 patches, so you get a 64-bit capable compiler out of the box.
Actually, Sun hardware generally supports a lot more memory, Sun just lists on the ceritifed hardware lists what was available at the time they shipped the systems as new.
Our E4000, for example, is "limited" to 14 CPU's and 14GB of memory according to the documentation. Of course, this didn't stop me from installing 24GB of memory in one and having it work reliably.
Although I haven't bothered to look, am sure that there are at least 512MB SIMM (aka, 8GB) for the E450. We actually have a 420R here, so I could look... but I'm lazy.:P
Jesus, you talk about the man like he's... well, Jesus.
No, I wouldn't wire to my brain to a piece of closed source software. Of course, this has little do with the point. That said, I wouldn't wire my head to a piece of open source software either. The last thing I want my brain co-processor to do is start spitting out "woof woof" every time I try to un-think something, but I digress.
It's very much the "free software is better for them" attitude that pisses me off about RMS/the whole movement; as if there is some karmic superiority i'll enjoy from running Linux. Get over yourselves.
At the end of the day, if you feel the closed/open source nature of your software really makes an impact on your personal "freedoms", you have way too much attachment to your software.
Of course, It would be just as much an oppression of my "freedom" to not allow me to create and sell a closed source software product as it would be for you to not get it for free, but try not to think about that little paradox too much....
Anyways, it's 3:00am and I'm installing Solaris 10 on my Ultra2. No, I don't have the source code. No, I don't feel oppressed because of it.
You're right. Why shouldn't it be mandatory that if I write a great piece of software that I be required to simply -hand- you the means to undermine my ability to earn a living on it? I'm not claiming that I should have a perpetual lock on the ideas I create, but I certainly should be allowed the incentive to develop knowing that if I spend years on a new technology, -you- won't be able to join me in the market a month later because you stood on my shoulders.
Copy me if you want, but do the work. Commerical, closed-source software=good. Software patents=bad.
Nobody complains that musicians don't distribute their CD's complete with the original multitrack masters.... this is no different. On the same point, nobody dares question their right to earn a living from their work. (Well, some people do... but these people have often never created a thing in their lives and therefore, I don't really care what they think about the rights of a creator over their creation).
Code is like music (or any art), and I have every right to distribute my art as I see fit. If you don't want it because I won't give you the code, then don't take it... but don't cry about it. In the spirit of open source, write your own... then you'll have the code... but fsck you if you think you can tell me what I'm going to do with my work.
On the other side of the coin, why SHOULD it be mandatory for users to have these rights? Perhaps before asking questions of me you should really reason out an acceptable answer to that. Something for the sake of same is always pointless.
Don't get me wrong... I firmly support open source, contribute to open source projects, and have been writing and using open source software as long as I can remember... but there will always be the need for the "black box" projects... I do the work, you want the results, you pay for them. Unlike RMS, I can't laze about in academia all day sermonizing on the virtues of OSS... I have bills to pay.
You're right... things evolve. Things change... but you're insane to really think that a 100% OSS world is where it's evolving to.
Why? Does not everybody have a right to study and modify the software they run?
Not if it was written by someone else who allows you to use it with the explicit condition that you cannot study the source or modify it. Is it ideal that you can acquire these rights? Of course, but it shouldn't be mandatory.
Do you want to be told you cannot 'think' certain thoughts, because they have been patented?
Using Z to prove A never makes any sense. I know it's convienient to make this connection to argue that "all software should be free", but it's simply not the same thing.
There is no compromise possible; a user should have certain rights to the code he is running.
And if you demand this right, then acquire code to which you have the those rights... but don't acquire binaries you don't have the rights to and then turn around and complain about not having the code. That would be stupid. There will always be free code, no doubt, and if you choose to use it, do so.
The irony is that the open source movement argues "choice" at every turn... unless of course that choice is to not use open source software. "choice" is absolute, like the freedom to think what one wants, regardless of how you want to limit it by suggesting that such freedoms don't exist unless an OSI compliant license is attached to them.
You had me with the "my software is free, just share your code with me too" line.
You had me with the "complete UNIX toolset, we just need a kernel" idea.
You lost me with the "now all code should be free without exceptions" bit.
After that, I stopped caring what you thought about the APSL and the BSD license, and still don't care what you think about the CDDL.
A brilliant engineer you are, but please stop playing the pundit on all technology issues that run counter to your ideas. Clearly, the GPL isn't for everyone... try to remember that.
Carbon and Cocoa are both implemented on top of CoreFoundations. That said, you can make calls to CF from both API's and indeed, many Cocoa objects are "zero toll bridged" to their CF counterparts.
A good example of this is the all-useful "NSString". It doesn't really exist. In your object graph, it shows as CFString since an NSString is just the Cocoa representation of the underlying CoreFoundations string type.
While it is true that most of the user-interface glitz you get from cocoa you largely get for free, the same glitz can easily be built into an existing carbon application if a developer chooses to do so.
Sheets are a good example... they are typically "cocoa", yet appear in Microsoft Office and BBEdit (both quite Carbon apps).
Which would be ironic, considering the unacknowledged (beyond that - i'd say closer to rigidly suppressed) intellectual contributions Solaris/SunOS has made to Linux.
I suppose the satisfaction of knowing that my theory that all people are fundamentally lazy, preferring to trick others into doing their own work for them rather then spending the time themselves, is indeed correct.
What really pisses -me- off is that whenever someone asks a question that could be just solved a by doing a Google search, a few people quite rightly tell that person to go use Google. Then, inevitably, there is always some self-righteous prick who chimes in with his "Just re-post the content you found on Google because I too am much too lazy to go use Google but am hiding it by coming off like a self-righteous prick" routine.
Although most/. readers probably won't care, dual core CPU's are already on the market in the form of the UltraSPARC IV CPU from Sun Microsystems. Sun also happen to be sporting the most ambitious multi-core project going in the form of Niagara, which although initially an 8-core system has apparently been seen running Solaris 9 with 32 independent CPU cores.
In addition to this, the POWER 5 CPU is also available with multiple cores, fully supporting Linux.
This is really of most use for the data center right now, but as more applications wrap their heads around paralelizing themselves, multi-core CPU's on the desktop will become more popular.
That said, developers really have no excuses for not having blazing fast "dual-core aware" apps... a multi-processor system purchased today provides about as much performance as a dual core system... so it's not like a wild new technology where application developers have to wait for SDK's or test hardware. Multiple cores, HyperThreading CPU's or multiple physical processors are all just additional CPU's from the operating systems perspective, and are developed for using the same tried and true thread libraries (pthreads, etc).
Multi-thread those apps people! There are so many instances, especially when writing GUI apps, where an extra thread or two thrown in the right direction can really improve the user experience.
Of course, a big problem is just how developers learn to program. Everyone learns their "Hello World!", then goes from there... but this is all very linear in approach. Finding good programmers who can think of an application in terms of what many parallel threads should (or shouldn't) be doing isn't easy... but I digress.
These days, we are splitting the difference between rolling our own and buying. We used to be a pretty heavy Sun/SPARC shop (SPARC iron still claims the majority in our data center), but with Solaris 10 for AMD64 coming out, we're buying a lot of Opteron boxes and just running Solaris 9 on the them in the meantime (or Solaris 10 for some experimental stuff).
Tyan, of course, have been making excellent motherboards for years. These are simply the motherboard and a case, integrated together. Just add disks, procesors and memory.
Slashdot Mirror
Strangely enough most of the OS X converts I know are experienced sysadmins / developers with years of experience on *nix.
Indeed. When I first switched started using a Mac casually, it was still largely "the artists platform". These days, I know more programmers and systems administrators sporting PowerBooks than I do graphic designers.
I've been using Linux for longer than most, and I still completely agree with you. This is why I now use OS X on my desktop.
/. readers can actually handle the truth, especially when the truth flies in the face of the reality-distortion-field surrounding the "Linux on the Desktop is Finally Ready" movement.
All I have to say is "duck"... few
That is really what this comes down to.. if you're going to try to make something asynchronous reliable, you're going to need an ACK/NACK/missing ACK solution.. basicly all the same pitfalls of TCP over unreliable IP.
Indeed, and most modern MQ servers implement this.
You might as well just spawn a thread to deliver the message to a host:port TCP address tuple and skip all the queuing.
Why, when I can just set the MQ stack to deal with all of this for me? Of course, you're correct... but I have better things to do then write the ack/nack/missing ack logic.
The message queuing they're talking about is code centric asynchronous message sending in either publish/subscribe or peer-to-peer systems. It's for when one library of code (say, manufacturing control) needs to relay an XML message (or Java object serialization, or whatever) to another library of code (say, procurement) to tell it to execute additional logic. Human beings, save for debugging purposes, never actually read the messages and indeed, many times the messages aren't even really human readable.
.NET, both of which offer message queuing (J2EE having tons from many different vendors - we use OpenJMS a lot in our shop).
... as this would allow J2EE/.NET/PHP/whatever apps to use it regardless of platform.
So, no, not really like SMTP. Though SMTP is, I guess, a loose metaphor for how MQ servers work. That said, Exchange has nothing to do with it. The SMTP/POP3/IMAP model is just a little too much overhead for most message queue applications.
Of course, the real problem with your statement is that asynchronous messaging doesn't in fact preclude reliability, and indeed, the word asynchronous/synchronous and reliability are more or less completely different topics and wholly unrelated.
Most MQ servers persist undeliverable messages until such time as the destination peer (or the whole of the registered subscriber list) is available and ack's receipt of the message in question. All "asynchronous" means is that library A can send a message and continue on without ever caring about -when- the message is delivered.
Using the manufacturing/procurement example again, you can see why it would be stupid for manufacturing to walk their ordering message over to procurement, then wait around for the mail clerk to show up, take the message, and acknowledge it's been received. This would be a "synchronous" message transmission. Surely, it's easier to just leave it in an "inbox" for the clerk to pick up later (send the message asynchronously).
As for reinventing the wheel, I largely agree. Most large scale applications are being rolled out in J2EE or
The only thing I can see as being beneficial is a new MQ implemented with interaction entirely in XML-RPC, etc
or was McNealy just blathering to anyone who'd listen...
Probably not. Are you?
Then tell me: why is linux more and more used by all sorts of hardware manufacturers?
There's actually a pretty good discussion about this on one of the MSDN blogs. The real answer that all the hardware manufacturers are giving: cost and reliability. They're pretty clear... it's not so much about "an equal playing ground" as it is about lowering the per-unit cost of their product and ensuring it works reliably once it's delivered (thus lowering support costs). Bottom line, Windows XP Embedded is expensive and flakey. Once again, I'm not seeing the "freedoms" issue being key here... existent, but hardly key. It's all about costs.
your assumption failes, and even if it did not, is one only entitled an opinion when he depends on the outcome of that opinion?
No, but those directly effected by an issue should always be entitled to more of a "vote" then those looking from on the sidelines. That said, I have no doubt your income depends on writing software... lots of peoples do. But being paid to write a program by a university (or a company) and writing one on your own dime are very different things. By your own admission, you have the luxury of the "reality barrier" between actually turning a profit on your work and what ends up in your bank account. This comes hand-in-hand with salaried or contracted work; vastly different from a "it fails you and don't get paid" situation.
And even if I were to write a decent piece of software in the hope people would pay me for it afterwards: ever heard of Bram Cohen? He is the author of BitTorrent (MIT license, free download). He accepts PayPal donations. He and his family live off these donations. Proof enough?
Far from it. A few poster boys here and there don't prove anything except that one in a million guys are able to buck the trend and make money. Good for Bram Cohen. The other 999,999 guys behind him are still having to depend on commercial software industry to buy their dinner.
One simularity in visionaries is that in their time they are called insane by the ones who do not understand them or fail to see the logical flow of things. The world has already been 100% open source, until software writers closed their source to limit their end-users' freedom (to change to another hardware provider for instance). The world will be open source again, as soon as end-users demand it.
You're missing a major key point here. You can DEMAND an open source copy of Adobe Photoshop all you want... but Adobe isn't going to release one because they know one thing; 99% of the people out there don't feel that their freedoms are infringed by not having the source code to their software.
What you and the rest of the OSS/FSF zombies should really clue in to is the fact that you are a massive minority.... nobody cares as much as you care... and the majority don't care at all. You can say this is because they have't been "educated", but the reality is that even the ones who have heard your message still can't understand why it's an issue.
Don't confuse the sucess of Linux (for example) with the sucess of your (err, RMS's via you) vision. Corporations love Linux because it's cost effective, not because they feel their freedoms are protected by it.
The again, why am I bothering? You're obviously not someone who's ever had to actually live off their ability to write software, so everything you're saying is just regurgitated propaganda anyways. Come talk to me when you have actually -tried- to make money selling your shiny new open source project.
That said, I doubt I'll hear from you again...
Exactly.
The average OSS zealot, alas, has never actually had to buy their meals using money earned from writing and selling a software product.
It's all fine and dandy to say "all software should be free and include source code" and make some altruistic arguments about why... and in a perfect world, I would agree completely.
Here in reality on the other hand, I don't have the luxury of being paid by academia to wax intellectual about things. The corporation that takes my ideas and packages them, brands them, and puts them on the market makes the money, and I make nothing.
Thanks, but no thanks.
As many others have said, Solaris 10 is definately 64-bit capable on Opteron, with a full AMD64 kernel and AMD64 drivers. We have 3 B72 systems (Solaris beta from 10/04) running on dual opteron, all with 8GB of memory and all with 64-bit MySQL processes consuming well in excess of 4GB of memory...
/. readers will care less about it and Janus is the more important thing....
/. readers are all about open source/free software and 99.9% of the free software builds on Solaris natively. Only thing I can see Janus being good for are the commercial apps, of course.
Needless to say, definately 64-bit. This was true in the last express release and is true in the FCS.
As for Janus and ZFS... apparently Janus will be in the next release of Express. I'm much interested in ZFS... though obviously most
As a digression, I can't imagine why.... most
Solaris supports 64-bit on Opteron in exactly the same way it supports 64-bit on SPARC... 64-bit kernel with 64-bit drivers suporting either both 32-bit and 64-bit ABI's for applications and libraries. Libraries appear in the same /usr/lib and /usr/lib/64 folders as they do on SPARC, so of course, you need to build 32 AND 64 bit libraries if you want all applications to link against them.
bash-2.05b$ uname -a
/opt/csw/mysql/bin/mysql /opt/csw/mysql/bin/mysql: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available
/usr/sfw) GCC 3.4.3 with the sol10 amd64 patches, so you get a 64-bit capable compiler out of the box.
SunOS prime 5.10 s10_72 i86pc i386 i86pc
bash-2.05b$ isainfo -kv
64-bit amd64 kernel modules
bash-2.05b$ file
Regardless of what a nasty old troll tries to tell you, Solaris on Opteron has been fully 64-bit since B72 (11/04).
The release version even includes (in
Actually, Sun hardware generally supports a lot more memory, Sun just lists on the ceritifed hardware lists what was available at the time they shipped the systems as new. Our E4000, for example, is "limited" to 14 CPU's and 14GB of memory according to the documentation. Of course, this didn't stop me from installing 24GB of memory in one and having it work reliably. Although I haven't bothered to look, am sure that there are at least 512MB SIMM (aka, 8GB) for the E450. We actually have a 420R here, so I could look... but I'm lazy. :P
Jesus, you talk about the man like he's... well, Jesus.
No, I wouldn't wire to my brain to a piece of closed source software. Of course, this has little do with the point. That said, I wouldn't wire my head to a piece of open source software either. The last thing I want my brain co-processor to do is start spitting out "woof woof" every time I try to un-think something, but I digress.
It's very much the "free software is better for them" attitude that pisses me off about RMS/the whole movement; as if there is some karmic superiority i'll enjoy from running Linux. Get over yourselves.
At the end of the day, if you feel the closed/open source nature of your software really makes an impact on your personal "freedoms", you have way too much attachment to your software.
Of course, It would be just as much an oppression of my "freedom" to not allow me to create and sell a closed source software product as it would be for you to not get it for free, but try not to think about that little paradox too much....
Anyways, it's 3:00am and I'm installing Solaris 10 on my Ultra2. No, I don't have the source code. No, I don't feel oppressed because of it.
You're right. Why shouldn't it be mandatory that if I write a great piece of software that I be required to simply -hand- you the means to undermine my ability to earn a living on it? I'm not claiming that I should have a perpetual lock on the ideas I create, but I certainly should be allowed the incentive to develop knowing that if I spend years on a new technology, -you- won't be able to join me in the market a month later because you stood on my shoulders.
Copy me if you want, but do the work. Commerical, closed-source software=good. Software patents=bad.
Nobody complains that musicians don't distribute their CD's complete with the original multitrack masters.... this is no different. On the same point, nobody dares question their right to earn a living from their work. (Well, some people do... but these people have often never created a thing in their lives and therefore, I don't really care what they think about the rights of a creator over their creation).
Code is like music (or any art), and I have every right to distribute my art as I see fit. If you don't want it because I won't give you the code, then don't take it... but don't cry about it. In the spirit of open source, write your own... then you'll have the code... but fsck you if you think you can tell me what I'm going to do with my work.
On the other side of the coin, why SHOULD it be mandatory for users to have these rights? Perhaps before asking questions of me you should really reason out an acceptable answer to that. Something for the sake of same is always pointless.
Don't get me wrong... I firmly support open source, contribute to open source projects, and have been writing and using open source software as long as I can remember... but there will always be the need for the "black box" projects... I do the work, you want the results, you pay for them. Unlike RMS, I can't laze about in academia all day sermonizing on the virtues of OSS... I have bills to pay.
You're right... things evolve. Things change... but you're insane to really think that a 100% OSS world is where it's evolving to.
Ya know, as I clicked the submit button I thought... wait a second, someone is going to get as far as the word "wacky" and mod me down.
*sigh*
What can ya do?
Why? Does not everybody have a right to study and modify the software they run?
Not if it was written by someone else who allows you to use it with the explicit condition that you cannot study the source or modify it. Is it ideal that you can acquire these rights? Of course, but it shouldn't be mandatory.
Do you want to be told you cannot 'think' certain thoughts, because they have been patented?
Using Z to prove A never makes any sense. I know it's convienient to make this connection to argue that "all software should be free", but it's simply not the same thing.
There is no compromise possible; a user should have certain rights to the code he is running.
And if you demand this right, then acquire code to which you have the those rights... but don't acquire binaries you don't have the rights to and then turn around and complain about not having the code. That would be stupid. There will always be free code, no doubt, and if you choose to use it, do so.The irony is that the open source movement argues "choice" at every turn... unless of course that choice is to not use open source software. "choice" is absolute, like the freedom to think what one wants, regardless of how you want to limit it by suggesting that such freedoms don't exist unless an OSI compliant license is attached to them.
Oh wacky, wacky Richard.
You had me with the "my software is free, just share your code with me too" line.
You had me with the "complete UNIX toolset, we just need a kernel" idea.
You lost me with the "now all code should be free without exceptions" bit.
After that, I stopped caring what you thought about the APSL and the BSD license, and still don't care what you think about the CDDL.
A brilliant engineer you are, but please stop playing the pundit on all technology issues that run counter to your ideas. Clearly, the GPL isn't for everyone... try to remember that.
Not forgetting Safari, Apple Mail, and System Preferences, the latter of which I find the most important of all sometimes.
This is because it is....
Carbon and Cocoa are both implemented on top of CoreFoundations. That said, you can make calls to CF from both API's and indeed, many Cocoa objects are "zero toll bridged" to their CF counterparts.
A good example of this is the all-useful "NSString". It doesn't really exist. In your object graph, it shows as CFString since an NSString is just the Cocoa representation of the underlying CoreFoundations string type.
While it is true that most of the user-interface glitz you get from cocoa you largely get for free, the same glitz can easily be built into an existing carbon application if a developer chooses to do so.
Sheets are a good example... they are typically "cocoa", yet appear in Microsoft Office and BBEdit (both quite Carbon apps).
Which would be ironic, considering the unacknowledged (beyond that - i'd say closer to rigidly suppressed) intellectual contributions Solaris/SunOS has made to Linux.
From now on, you can be the captain of the run-on-sentence department.
I suppose the satisfaction of knowing that my theory that all people are fundamentally lazy, preferring to trick others into doing their own work for them rather then spending the time themselves, is indeed correct.
What really pisses -me- off is that whenever someone asks a question that could be just solved a by doing a Google search, a few people quite rightly tell that person to go use Google. Then, inevitably, there is always some self-righteous prick who chimes in with his "Just re-post the content you found on Google because I too am much too lazy to go use Google but am hiding it by coming off like a self-righteous prick" routine.
Although most /. readers probably won't care, dual core CPU's are already on the market in the form of the UltraSPARC IV CPU from Sun Microsystems. Sun also happen to be sporting the most ambitious multi-core project going in the form of Niagara, which although initially an 8-core system has apparently been seen running Solaris 9 with 32 independent CPU cores.
In addition to this, the POWER 5 CPU is also available with multiple cores, fully supporting Linux.
Also of note is that the Opteron dual-core CPU's from AMD are apparently going to be pin-compatible with the current Opteron processors (by current,I mean, the latest socket 939 (I think) systems, not the original Opteron 2xx or whatever).
This is really of most use for the data center right now, but as more applications wrap their heads around paralelizing themselves, multi-core CPU's on the desktop will become more popular.
That said, developers really have no excuses for not having blazing fast "dual-core aware" apps... a multi-processor system purchased today provides about as much performance as a dual core system... so it's not like a wild new technology where application developers have to wait for SDK's or test hardware. Multiple cores, HyperThreading CPU's or multiple physical processors are all just additional CPU's from the operating systems perspective, and are developed for using the same tried and true thread libraries (pthreads, etc).
Multi-thread those apps people! There are so many instances, especially when writing GUI apps, where an extra thread or two thrown in the right direction can really improve the user experience.
Of course, a big problem is just how developers learn to program. Everyone learns their "Hello World!", then goes from there... but this is all very linear in approach. Finding good programmers who can think of an application in terms of what many parallel threads should (or shouldn't) be doing isn't easy... but I digress.
I am not your butler.
These days, we are splitting the difference between rolling our own and buying. We used to be a pretty heavy Sun/SPARC shop (SPARC iron still claims the majority in our data center), but with Solaris 10 for AMD64 coming out, we're buying a lot of Opteron boxes and just running Solaris 9 on the them in the meantime (or Solaris 10 for some experimental stuff).
That said, check out:
Tyan Transport Barebones Systems
Tyan, of course, have been making excellent motherboards for years. These are simply the motherboard and a case, integrated together. Just add disks, procesors and memory.
They've been working great for us.