One thing that might help is getting more FreeBSD 5 stuff into the kernel -- if you look at the release notes, there appear to be fewer locks in the kernel, although I don't know if Darwin uses those locks in the first place.
Another good trend for peripheral support for Mac OS and Linux is that USB and FireWire have the "device family" concept, so generic drivers can be written and work with lots of hardware.
There will still be a need for product-specific drivers, and sometimes devices will not properly implement the generic interfaces they say they do, but this situation makes the playing field a lot more level.
It's not control over the hardware, it's about having a more flexible compositing model than other window systems, and then making its implementation fast (Quartz Extreme). Apple decided to push compositing down a few levels so that any graphics application, including the window server, could take advantage of it, but the only hardware consideriation is optimizng compositing with OpenGL if the hardware supports it.
I was just speculating about this with a friend who works at Rational last night. I could even see IBM acquiring Borland, which might (ironically enough) have fewer anti-trust problems than Microsoft acquiring Borland.
Things can change very quickly. When I started at Lotus in 1990, there was a "Welcome Novell" banner in the lobby, since the two companies were all set to merge. So much for THAT.
Although Carbon is definitely tied to pre-10.0 Mac way of doing things, the QuickTime API is a large subset of Carbon. In fact, some have surmised that the QuickTime port to the old NeXTStep base and the Carbon port were probably part of the same development stream.
Bob Moses worked in the civil rights movement in the 60s and he's teaching algebra now, as reported in this Mother Jones article.
Moses believes that mastering algebra, preferably by the eighth grade, is the modern-day equivalent of the right to vote because it represents a dividing line between having -- or not having -- a chance in life. ''In the 1960s, we opened up political access,'' he says. ''The most important social problem affecting people of color today is economic access, and this depends crucially on math and science literacy, because the American economy is now based on knowledge and technology, not labor.''
Mac OS X actually comes out looking pretty good in the Salon article, because it's easy to write front-ends to Unix-based tools, and, even better, there is a "Services" hook that allows at least a generic, simple, if not completely seamless, way to integrate a facility with existing programs.
And I had also checked out Mac OS X GPG solutions a few weeks ago too. We use PGP at work and I was looking for both a migration solution (can I use my PGP keys in GPG ?) and an interoperability solution.
I am not exactly "holding off" on buying DVDs, but I am renting before I buy. It's mostly to save money and space; I doubt we'll be getting an HD-capable monitor within five years.
What I want do is to just daisy-chain every component together without having to look at labels on the back panels. FireWire would be good for that.
Somebody had the brilliant idea of making a digital audio coax connection use RCA plugs. Listen to what happens when you plug your DVD's output into one of your receivers analog inputs...
If this thing had FireWire and Mac OS support, I'd be on it in a sec. I would suspect that Mac OS would at least be able to use this in a generic mode.
For now I'll probably get the much cheap Griffin iMic, which also does 24-bit audio (which OS X supports).
I've seen a lot of "real" musicians use PowerBooks live, although I'm not sure if they are using the onboard audio with analog out (if it's a G3) or a USB/FireWire thingy. On the other hand, Apple actually pays attention to their analog subsystems so they might be good enough for your needs.
I agree. If Microsoft releases the specs and licenses for free or a nominal fee, it's OK. This article doesn't say what would happen. Normally the other big boys wouldn't accept this sort of thing unless it was opened.
But as others have pointed out, there are already a lot of DVD players out there and most of them aren't upgradeable. I really don't see new-format DVD driving hardware sales -- the higher quality is nice, but what it is really selling DVD right now is the convenience: no more rewinding, and less hardware to think about, since it replaces the CD player and VCR (for lot of a people the VCR is really just a VCP). I can see myself getting a new DVD player in two years or so in order to play DVD-Audio discs and MP3s, but since I don't plan on getting a new TV for at least another six years, better quality or higher resolution is irrelevant.
Maybe Microsoft's efforts will become part of the DVD-HD standard instead. If HD quality takes less space than using MP* standards, DVD makers might actually take the bait, but then again there are a lot political issues that have to be worked out.
As usual, PC hardware makers are too timid. Why couldn't the Treo use FireWire and just market a bundled with a PC or PCI FireWire card ? Other makers of FireWire peripherals (such as Maxtor) already do this.
The similarity is no accident. Apple sued Microsoft for stealing codec code; I beleive it was settled out of court, and might have been one of the terms of Microsoft's $150m investment in Apple.
Windows 3.1 had a simple multimedia API but it was pretty simple, and didn't do video without obscure, specialized hardware, unless controlling laserdisc players is your idea of video on a PC.
The Gamecube ads on TV are needlessly weird. Is the point to show the games or to show a production company can wedge odd, uncomfortable collections of things inside cubes in random places ? Yawn.
There are some applications like XFree86 on OS X which put CLI implementations inside the bundle, but that's a pretty odd case, and besides, it's more of a Darwin application than an OS X application (although that is changing it it becomes more integrated with Aqua).
What I'd really like to see migrate to other Unices is the framework concept and version discipline for shared libraries. But the problem with that is maintainers of various Open Source DSOs like libz, libtiff, libpng, and so on would have to start tracking binary API compatiblity vs. mere source compatibility, which isn't trivial.
Alternatively, maybe there should be a Darwin project that collects the most popular libraries and gives them meaningful version information, so that dependent projects can take advantage of it. It would mean changing link statements in upstream projects but it is work that would avoid a needless proliferation of DSO versions, and could be eventually applied to other Unices if they ever come their senses. (OK,;->)
or maybe it's not a problem, as others have discussed -- a lot of people like having lots of things in a path directory instead of a very long path. At my employer we use a system that puts packages in different directories, and it's very nice (it searches a database and takes versions and platforms into account), but occasionally other tools complain about the very long paths that result. I also ended up writing a little Perl script that searchs for patterns in the contents of PATH-like variables in order to get a better grip on exactly where things in my environment are coming from.
You must put things on the PATH for command-line purposes, although a desktop environment or package shouldn't require this. I don't use X-like environments for GUI tasks so I am unfamiliar with the approaches that they take to this problem. The related problem is that dynamic libraries also need to be searched as well, so sometimes even GUI packages need to modify the environment.
The nice thing about a big PATH is that less things have to know about exactly where things are for GUI explorer-type applications. For example, on the Mac or Windows, something needs to associate.jpg files with a program, and you must know exactly where that program is. Whereas, if it's on a PATH, all you need to know is the name. With symbolic links and other Unix trickery, it's easier to move around such application. But the problem with Unix trickerey is that it's too complicated to follow for most people.
The problem with the Taliban's "head for the hills" strategy (if indeed it is a strategy) is that they have no support from the population and they will be not supplied anybody from inside or outside the country. The big difference between now and the Soviet occupation is that the CIA and Pakistan were happy to supply the mujahedin with what they needed. Where are the Taliban's supplies going to come from ?
We need a K-Meleon equivalent for Mac OS X. From what I've read it's Possible and merely a Small Matter of Code.
My one complaint with K-Meleon is that the preference interface is lacking; probably because the code hasn't been written yet. This is going to be the one problem with alternate UIs for Gecko; the UI resources and code for Mozilla can't be used in such projects. Well, at least directly. Perhaps the Mozilla UI users could be imported by a tool that translates them to a plaform-specific format. It doesn't even have to do a perfect job, it just has to do a good enough job so that a developer can tweak the final results to look native on the target platform.
Slashdot Mirror
True, but you can buy a cable with FireWire plug on one end and a dock plug on the other.
One thing that might help is getting more FreeBSD 5 stuff into the kernel -- if you look at the release notes, there appear to be fewer locks in the kernel, although I don't know if Darwin uses those locks in the first place.
Another good trend for peripheral support for Mac OS and Linux is that USB and FireWire have the "device family" concept, so generic drivers can be written and work with lots of hardware.
There will still be a need for product-specific drivers, and sometimes devices will not properly implement the generic interfaces they say they do, but this situation makes the playing field a lot more level.
It's not control over the hardware, it's about having a more flexible compositing model than other window systems, and then making its implementation fast (Quartz Extreme). Apple decided to push compositing down a few levels so that any graphics application, including the window server, could take advantage of it, but the only hardware consideriation is optimizng compositing with OpenGL if the hardware supports it.
I was just speculating about this with a friend who works at Rational last night. I could even see IBM acquiring Borland, which might (ironically enough) have fewer anti-trust problems than Microsoft acquiring Borland.
Things can change very quickly. When I started at Lotus in 1990, there was a "Welcome Novell" banner in the lobby, since the two companies were all set to merge. So much for THAT.
Although Carbon is definitely tied to pre-10.0 Mac way of doing things, the QuickTime API is a large subset of Carbon. In fact, some have surmised that the QuickTime port to the old NeXTStep base and the Carbon port were probably part of the same development stream.
Mac OS X actually comes out looking pretty good in the Salon article, because it's easy to write front-ends to Unix-based tools, and, even better, there is a "Services" hook that allows at least a generic, simple, if not completely seamless, way to integrate a facility with existing programs.
And I had also checked out Mac OS X GPG solutions a few weeks ago too. We use PGP at work and I was looking for both a migration solution (can I use my PGP keys in GPG ?) and an interoperability solution.
I am not exactly "holding off" on buying DVDs, but I am renting before I buy. It's mostly to save money and space; I doubt we'll be getting an HD-capable monitor within five years.
Besides "open" from the shell, if you drag any Finder item to a terminal window, it inserts the text of its pathname.
Also, maybe the reason why everything is not viewed as a file under Mac OS X is because not everthing is a file in reality.
For Mac OS, MP3 Rage can do similar things, like rename files according to tags or gleaning tags from the pattern of the file name.
Why do so many MP3 files not have tags ?
What I want do is to just daisy-chain every component together without having to look at labels on the back panels. FireWire would be good for that.
Somebody had the brilliant idea of making a digital audio coax connection use RCA plugs. Listen to what happens when you plug your DVD's output into one of your receivers analog inputs...
If this thing had FireWire and Mac OS support, I'd be on it in a sec. I would suspect that Mac OS would at least be able to use this in a generic mode.
For now I'll probably get the much cheap Griffin iMic, which also does 24-bit audio (which OS X supports).
I've seen a lot of "real" musicians use PowerBooks live, although I'm not sure if they are using the onboard audio with analog out (if it's a G3) or a USB/FireWire thingy. On the other hand, Apple actually pays attention to their analog subsystems so they might be good enough for your needs.
You could get a new iMac which has iDVD and the requisite hardware needed to burn discs that will play on nearly all consumer DVD players.
The easiest platform on which to configure X is... Mac OS X ! Just unpack XFree86 and run. The framebuffer drive tells X the rest.
I agree. If Microsoft releases the specs and licenses for free or a nominal fee, it's OK. This article doesn't say what would happen. Normally the other big boys wouldn't accept this sort of thing unless it was opened.
But as others have pointed out, there are already a lot of DVD players out there and most of them aren't upgradeable. I really don't see new-format DVD driving hardware sales -- the higher quality is nice, but what it is really selling DVD right now is the convenience: no more rewinding, and less hardware to think about, since it replaces the CD player and VCR (for lot of a people the VCR is really just a VCP). I can see myself getting a new DVD player in two years or so in order to play DVD-Audio discs and MP3s, but since I don't plan on getting a new TV for at least another six years, better quality or higher resolution is irrelevant.
Maybe Microsoft's efforts will become part of the DVD-HD standard instead. If HD quality takes less space than using MP* standards, DVD makers might actually take the bait, but then again there are a lot political issues that have to be worked out.
As usual, PC hardware makers are too timid. Why couldn't the Treo use FireWire and just market a bundled with a PC or PCI FireWire card ? Other makers of FireWire peripherals (such as Maxtor) already do this.
The similarity is no accident. Apple sued Microsoft for stealing codec code; I beleive it was settled out of court, and might have been one of the terms of Microsoft's $150m investment in Apple.
Err, that's just a simple audio player.
Windows 3.1 had a simple multimedia API but it was pretty simple, and didn't do video without obscure, specialized hardware, unless controlling laserdisc players is your idea of video on a PC.
The Gamecube ads on TV are needlessly weird. Is the point to show the games or to show a production company can wedge odd, uncomfortable collections of things inside cubes in random places ? Yawn.
There are some applications like XFree86 on OS X which put CLI implementations inside the bundle, but that's a pretty odd case, and besides, it's more of a Darwin application than an OS X application (although that is changing it it becomes more integrated with Aqua).
;->)
What I'd really like to see migrate to other Unices is the framework concept and version discipline for shared libraries. But the problem with that is maintainers of various Open Source DSOs like libz, libtiff, libpng, and so on would have to start tracking binary API compatiblity vs. mere source compatibility, which isn't trivial.
Alternatively, maybe there should be a Darwin project that collects the most popular libraries and gives them meaningful version information, so that dependent projects can take advantage of it. It would mean changing link statements in upstream projects but it is work that would avoid a needless proliferation of DSO versions, and could be eventually applied to other Unices if they ever come their senses. (OK,
or maybe it's not a problem, as others have discussed -- a lot of people like having lots of things in a path directory instead of a very long path. At my employer we use a system that puts packages in different directories, and it's very nice (it searches a database and takes versions and platforms into account), but occasionally other tools complain about the very long paths that result. I also ended up writing a little Perl script that searchs for patterns in the contents of PATH-like variables in order to get a better grip on exactly where things in my environment are coming from.
.jpg files with a program, and you must know exactly where that program is. Whereas, if it's on a PATH, all you need to know is the name. With symbolic links and other Unix trickery, it's easier to move around such application. But the problem with Unix trickerey is that it's too complicated to follow for most people.
You must put things on the PATH for command-line purposes, although a desktop environment or package shouldn't require this. I don't use X-like environments for GUI tasks so I am unfamiliar with the approaches that they take to this problem. The related problem is that dynamic libraries also need to be searched as well, so sometimes even GUI packages need to modify the environment.
The nice thing about a big PATH is that less things have to know about exactly where things are for GUI explorer-type applications. For example, on the Mac or Windows, something needs to associate
The problem with the Taliban's "head for the hills" strategy (if indeed it is a strategy) is that they have no support from the population and they will be not supplied anybody from inside or outside the country. The big difference between now and the Soviet occupation is that the CIA and Pakistan were happy to supply the mujahedin with what they needed. Where are the Taliban's supplies going to come from ?
We need a K-Meleon equivalent for Mac OS X. From what I've read it's Possible and merely a Small Matter of Code.
My one complaint with K-Meleon is that the preference interface is lacking; probably because the code hasn't been written yet. This is going to be the one problem with alternate UIs for Gecko; the UI resources and code for Mozilla can't be used in such projects. Well, at least directly. Perhaps the Mozilla UI users could be imported by a tool that translates them to a plaform-specific format. It doesn't even have to do a perfect job, it just has to do a good enough job so that a developer can tweak the final results to look native on the target platform.