I like this quote from a Maccentral article:...Jobs delivered the morning keynote to Intel's annual sales conference in Las Vegas.
Maybe there's hope for OS X on Intel after all. Goodbye Classic, Goodbye Altivec, Hello to some driver rewrites, but what a great leap in price/performance!
I can't think of a better model to begin this transition with than the XServe.
Complexity: I've implemented SIP, H.323, et al., and SIP is just as complex as H.323.
Not true. I've developed two commercial SIP stacks, each about one man year. While I haven't developed an H.323 stack, I've worked with both the OpenH323 and RadVision H.323 stacks, and SIP is much, much simpler.
To wit, RFC 3261 is the largest RFC ever produced and even larger than the H.323 Recommendation.
I don't have a copy of the H.323 Recommendation because I'm not willing to buy it. However, the ITU's H.323 download page shows that the H.323 spec is 2,112,158 bytes in pdf format, while the latest SIP spec is 1,231,871 bytes. This non-conclusive evidence suggests that the
H.323 spec is in fact twice as large as the SIP spec.
Add on all of the supporting RFCs and I-Ds, and you have a real mess. Folks even talk about the mess on the SIP reflectors.
H.323 has numerous annexes as well. Most SIP developers speak highly of the protocol, and while there are problems, I certainly wouldn't call it "a mess".
Interoperability: SIP is not more interoperable than H.323. Geez, I think their up to 13 or 14 interop events so far, and I've heard from those in attendance that SIP interoperability is getting harder and harder to achieve.
I have not seen these kinds of interoperability issues at the interops. I have seen many stacks fail the various torture tests, but this does not preclude interoperability. The only reason H.323 is just now achieving interoperability is because of the consolidation of the video conferencing industry into a single dominate vendor: Polycom.
Patents: There are no patents that I am aware of regarding H.323. There are, however, patent claims against some codecs used by H.323, e.g., G.723.1 and G.729, but those same codecs are also used by SIP.
One difference: H.323 requires support of patened codecs, building in a revenue source for those controlling the standard. SIP has no such codec requirements, although I agree that in practice those same codecs are used by many SIP clients.
Moreover, there are several patent claims against SIP (http://www.aful.org/wws/arc/patents/2003-01/msg00 082.html).
This is certainly a potential liability, and it is indeed "aful". Interestingly, those filing patents against IETF standards tend to be frozen out of the standards process, which hopefully acts as a deterant.
Microsoft: I agree that they will hurt SIP more than help. Note that Messenger is merely SIP-based.
Hey, we agree about Microsoft! Yes, Messenger is currently SIP-based (in a bastardized way), but as I said, MS is soon moving to more fully embrace SIP. It will be interesting to see what happens...
No, expressing video parameters is easy with SIP. SIP messages carry SDP payloads describing audio and video setup parameters. SDP payloads are also used by other protocols, like RTSP to set up streaming ssessions.
If you've ever watched a live QuickTime stream, your video was set up with SDP/RTSP. Setting up a SIP session is identical, except that the both sides supply set up SDP.
Perhaps you're thinking about SIP's lack of codec negotiations. This was fixed quite a while ago with the OPTION message, yet some anti SIP papers persist with this view.
You're right about H.323 interop. It's the primary barrier to using SIP for video conferencing clients.
H.323 should be dead, because the complexity, interoperability issues, and patent licensing fees keep small players out.
However, the consolidation of the video conferencing industry into a single major player (Polycom) means that Polycom sets the defacto standard. Why should Polycom help small players out by adopting SIP, when they've already invested the required time and money to support H.323?
SIP is popular among smaller internet telephony vendors, and of course Microsoft supports a bastardized version of SIP. Look for more SIP support from Microsoft in the near future.
MS support gives SIP credibility, but it's a double-edged sword: what kind of Window-isms will MS inject into their new SIP implementation...?
In late 1997 (early '98?), Apple released a developer version of Rhapsody, which was the internal name for OS X. Both PPC and Intel versions were released. It was pitched as the future of macintosh, so it was most certainly a promise.
Apple also promised a Yellow Box (Cocoa) runtime for the 32 bit Win platforms, but that never saw the light of day.
There is no techniocal reason why OS X can't run on TabletPC hardware --except Classic, of course. Imagine: Cocoa, Carbon, Darwin, not to mention QuickTime all runing on a TabletPC with Intel Inside.
This is not only cool, it's a step towards a new-and-improved hardware-independent Apple.
The only danger I see is that if it's released for TabletPC, it will be bootlegged and running on a standard wintel box in no time.
During the current OS X transition, Apple needs the G4 architecture to support legacy software. Not just in Classic. Many users still boot OS 9.
Once OS X is fully adopted, Apple could release hardware based on another architecture with no Classic support. App vendors would need to recompile Carbon/Cocoa apps into "fat" binaries.
But who knows...if Intel continues to push Pentium performance, maybe a G4 emulator could smooth the transition, like the 68K emulator that shipped with the first PPC macs.
I linked to an open source CDSA project on Freshmeat, which you're too lazy to look at. That, or you're simply spreading FUD. To save you the effort of clicking, the CDSA 2 project supports the following operating systems according to Freshmeat:.
Operating System:: Microsoft, Microsoft:: Windows, Microsoft:: Windows:: Windows 95/98/2000, Microsoft:: Windows:: Windows NT/2000, OS Independent, POSIX, POSIX:: AIX, POSIX:: HP-UX, POSIX:: Linux, Unix
Here's a theory I've long held regarding the excessive number of buffer overrun security holes in MS software:
The lack of an snprintf method in the DevStudio standard C lib causes MS developers to use the unbounded sprintf instead, potentially resulting in buffer overruns.
It's not an.sdp file, it's a QuickTime movie file embedded in a pretty web page that takes seconds to create using homepage.mac.com. The movie contains an SDP reference to my streaming server, but otherwise behaves like any other QuickTime movie embedded in a web page --except it's playing live audio/video from my very own broadcaster.
1) download and install Streaming Server and Broadcaster 2) start Streaming Server 3) start Broadcaster and point it at Streaming Server 4) start Movie Player and enter the URL of your Streaming Server 5) if video doesn't stream, plug in camera and repeat step 4 6) save movie to iDisk, in the Movies directory 7) log into homepage.mac.com 8) create account 9) create new movie page, select background, and select saved movie from iDisk 10) there is no step 10.
We're using AccuRev for Linux and Windows development. The features are great - multiple stream hierarchies, giving each developer control over what and when he promotes or gets. Integrated bug tracking is nice.
Unfortunately, the company is small, and the tools show it. Bugs abound. The java front end is quirky, but at least it runs on an X server or on windows (although is is too slow to tunnel through ssh).
Because disk spae is cheap, files are stored uncompressed and undiffed in a directory hierachy, which is a comforting thought --in case the whole system has a meltdown.
I hope the company is successful, because AccuRev has a lot of potential, IMHO.
Slashdot Mirror
I like this quote from a Maccentral article: ...Jobs delivered the morning keynote to Intel's annual sales conference in Las Vegas.
Maybe there's hope for OS X on Intel after all. Goodbye Classic, Goodbye Altivec, Hello to some driver rewrites, but what a great leap in price/performance!
I can't think of a better model to begin this transition with than the XServe.
Complexity: I've implemented SIP, H.323, et al., and SIP is just as complex as H.323.
0 082.html).
Not true. I've developed two commercial SIP stacks, each about one man year. While I haven't developed an H.323 stack, I've worked with both the OpenH323 and RadVision H.323 stacks, and SIP is much, much simpler.
To wit, RFC 3261 is the largest RFC ever produced and even larger than the H.323 Recommendation.
I don't have a copy of the H.323 Recommendation because I'm not willing to buy it. However, the ITU's H.323 download page shows that the H.323 spec is 2,112,158 bytes in pdf format, while the latest SIP spec is 1,231,871 bytes. This non-conclusive evidence suggests that the H.323 spec is in fact twice as large as the SIP spec.
Add on all of the supporting RFCs and I-Ds, and you have a real mess. Folks even talk about the mess on the SIP reflectors.
H.323 has numerous annexes as well. Most SIP developers speak highly of the protocol, and while there are problems, I certainly wouldn't call it "a mess".
Interoperability: SIP is not more interoperable than H.323. Geez, I think their up to 13 or 14 interop events so far, and I've heard from those in attendance that SIP interoperability is getting harder and harder to achieve.
I have not seen these kinds of interoperability issues at the interops. I have seen many stacks fail the various torture tests, but this does not preclude interoperability. The only reason H.323 is just now achieving interoperability is because of the consolidation of the video conferencing industry into a single dominate vendor: Polycom.
Patents: There are no patents that I am aware of regarding H.323. There are, however, patent claims against some codecs used by H.323, e.g., G.723.1 and G.729, but those same codecs are also used by SIP.
One difference: H.323 requires support of patened codecs, building in a revenue source for those controlling the standard. SIP has no such codec requirements, although I agree that in practice those same codecs are used by many SIP clients.
Moreover, there are several patent claims against SIP (http://www.aful.org/wws/arc/patents/2003-01/msg0
This is certainly a potential liability, and it is indeed "aful". Interestingly, those filing patents against IETF standards tend to be frozen out of the standards process, which hopefully acts as a deterant.
Microsoft: I agree that they will hurt SIP more than help. Note that Messenger is merely SIP-based.
Hey, we agree about Microsoft! Yes, Messenger is currently SIP-based (in a bastardized way), but as I said, MS is soon moving to more fully embrace SIP. It will be interesting to see what happens...
No, expressing video parameters is easy with SIP. SIP messages carry SDP payloads describing audio and video setup parameters. SDP payloads are also used by other protocols, like RTSP to set up streaming ssessions.
If you've ever watched a live QuickTime stream, your video was set up with SDP/RTSP. Setting up a SIP session is identical, except that the both sides supply set up SDP.
Perhaps you're thinking about SIP's lack of codec negotiations. This was fixed quite a while ago with the OPTION message, yet some anti SIP papers persist with this view.
You're right about H.323 interop. It's the primary barrier to using SIP for video conferencing clients.
H.323 should be dead, because the complexity, interoperability issues, and patent licensing fees keep small players out.
However, the consolidation of the video conferencing industry into a single major player (Polycom) means that Polycom sets the defacto standard. Why should Polycom help small players out by adopting SIP, when they've already invested the required time and money to support H.323?
SIP is popular among smaller internet telephony vendors, and of course Microsoft supports a bastardized version of SIP. Look for more SIP support from Microsoft in the near future.
MS support gives SIP credibility, but it's a double-edged sword: what kind of Window-isms will MS inject into their new SIP implementation...?
...promise OS X for x86, that is.
In late 1997 (early '98?), Apple released a developer version of Rhapsody, which was the internal name for OS X. Both PPC and Intel versions were released. It was pitched as the future of macintosh, so it was most certainly a promise.
Apple also promised a Yellow Box (Cocoa) runtime for the 32 bit Win platforms, but that never saw the light of day.
There is no techniocal reason why OS X can't run on TabletPC hardware --except Classic, of course. Imagine: Cocoa, Carbon, Darwin, not to mention QuickTime all runing on a TabletPC with Intel Inside.
This is not only cool, it's a step towards a new-and-improved hardware-independent Apple.
The only danger I see is that if it's released for TabletPC, it will be bootlegged and running on a standard wintel box in no time.
So what!
During the current OS X transition, Apple needs the G4 architecture to support legacy software. Not just in Classic. Many users still boot OS 9.
Once OS X is fully adopted, Apple could release hardware based on another architecture with no Classic support. App vendors would need to recompile Carbon/Cocoa apps into "fat" binaries.
But who knows...if Intel continues to push Pentium performance, maybe a G4 emulator could smooth the transition, like the 68K emulator that shipped with the first PPC macs.
Why not? A simplified API. Better certificate management (which is a pain). Theoretically portable API.
Can you be more specific why OpenSSL is better?
thanks.
I linked to an open source CDSA project on Freshmeat, which you're too lazy to look at. That, or you're simply spreading FUD. To save you the effort of clicking, the CDSA 2 project supports the following operating systems according to Freshmeat:.
:: Microsoft, Microsoft :: Windows, Microsoft :: Windows :: Windows 95/98/2000, Microsoft :: Windows :: Windows NT/2000, OS Independent, POSIX, POSIX :: AIX, POSIX :: HP-UX, POSIX :: Linux, Unix
Operating System
Here's a theory I've long held regarding the excessive number of buffer overrun security holes in MS software:
The lack of an snprintf method in the DevStudio standard C lib causes MS developers to use the unbounded sprintf instead, potentially resulting in buffer overruns.
What do you think?
It's not an .sdp file, it's a QuickTime movie file embedded in a pretty web page that takes seconds to create using homepage.mac.com. The movie contains an SDP reference to my streaming server, but otherwise behaves like any other QuickTime movie embedded in a web page --except it's playing live audio/video from my very own broadcaster.
1) download and install Streaming Server and Broadcaster
2) start Streaming Server
3) start Broadcaster and point it at Streaming Server
4) start Movie Player and enter the URL of your Streaming Server
5) if video doesn't stream, plug in camera and repeat step 4
6) save movie to iDisk, in the Movies directory
7) log into homepage.mac.com
8) create account
9) create new movie page, select background, and select saved movie from iDisk
10) there is no step 10.
We're using AccuRev for Linux and Windows development. The features are great - multiple stream hierarchies, giving each developer control over what and when he promotes or gets. Integrated bug tracking is nice. Unfortunately, the company is small, and the tools show it. Bugs abound. The java front end is quirky, but at least it runs on an X server or on windows (although is is too slow to tunnel through ssh).
Because disk spae is cheap, files are stored uncompressed and undiffed in a directory hierachy, which is a comforting thought --in case the whole system has a meltdown.
I hope the company is successful, because AccuRev has a lot of potential, IMHO.