If I was selling hardware, and someone reverse-engineered it to provide support to an alternate platform, I'd be very happy indeed (as I'm not an anon^H^H^H^Hpig in shit, I can't comment on the comparison). If I would normally sell N units, and having someone else write software that changes that to N+M, why wouldn't I be happy?
And it turns out that some folks have actually spoken to folks in authority at XM, and they're quite happy indeed to find that they've created a device that has inspired a community of hackers to make it better.
2. Mute and Power buttons should be near the volume control.
3. Volume should be labeled.
Um, there is no volume control. I think you're looking at the song rating slider.
4. Now playing box should be more distinguishable.
Not sure I understand what you're saying here. But let's take this conversation over to the bug and/or feature request section of the project rather than continue here.
I've learned quite a bit from MacXM. If I had to do it again, I'm not so sure I'd use Java. Not that I wouldn't rather use it, it's just that if you're writing Cocoa using Java, you're a second class citizen. There are a number of things that are made a lot more difficult that shouldn't be.
Where is the Java version of runSelectorOnMainThread? That is, in a case where in a Swing app you'd have said SwingUtilities.invokeLater(), what are you expected to do in Java/Cocoa? I had to roll my own NSTimer event to poll a queue for invokes. Ick!
If you have a C main(), as is the case with the default Java/Cocoa template in ProjectBuilder, why can't you use the Info.plist properties to adjust things like the JNI library path? Alternatively, where is the Java version of NSApplicationMain()? Without a solution, you can't use System.loadLibrary();. There is an alternative Cocoa way to load them, but it winds up not being portable, which is an issue if you're talking about a potentially reusable model class. It also precludes you from selecting which version of the JVM gets used.
Why isn't there some nice facility to allow for a Java equivalent to Categories? I suppose subclassing is the only way. I wound up writing a proxy category for NSApplication in Re^H^HObjective-C to enable AppleScript handling. It's a bit ugly.
When you subclass a Cocoa UI object, you need to implement all of its constrictors, including the protected ones (the implementations just call the base constructor with the same arguments) used by the NIB loader. Naturally, those are undocumented. Fun!
The Java URL class can't handle arbitrary URL protocols without some shimming. Why, then, isn't there an overload to NSWorkspace.openURL() that takes a string? This is an issue because openURL() handles more types of protocols than the URL connection factories in Java do.
Why didn't they include javax.comm? That would have been a helpful fix for #2, at least for me.
There are others I can't think of right offhand. Don't get me wrong - I love Java, and I really love the combination of Java and Interface Builder. There are just a few issues that you run into when doing Java/Cocoa. I hope they get resolved soonoer rather than later.
You bring up a good point. I believe there is a standard for calendar and contact MIME attachments. If you had an IMAP server, you could duplicate the MS functionality of Exchange "contact" folders by having a folder full of (null) emails with such attachments. On the mac, you could lightly integrate iCal with Mail to achieve this. Same thing with the Address book. Those 3 apps together would be not only the Mac Entourage/Outlook killer, they'd be the Exchange killer too! Now that would be insanely great.
Apple could take a lesson from the Omni Group and its browser OmniWeb, which had a preference that could make the browser say to sites that it was IE/Windows, IE/Mac, or other browser to fake it out and allow access.
If you turn on the Debug menu, one of its options is a list of alternate User Agents. Thanks to MacOS X Hints for a refresher (defaults write com.apple.Safari IncludeDebugMenu 1).
Today's SlashDotFunQuiz is to predict the order in which, impact when, and years until these other Mac products get the axe: Media Player, MSN Messenger, Office, Outlook, and Virtual PC.
Before we start... Isn't it Entourage instead of Outlook? And there's a MS Media Player for Mac? First I've heard. I'd be a lot happier, of course, if they'd just port the codecs over the QuickTime.
Anyway... I don't really know the order in which they'll be axed, but I do believe the impact will be minimal unless they axed them all Monday morning. Why? Because all of them either have perfectly good replacements now or they will have easily within a year.
IPv6 addresses are printed in groups of 16 bits in hex, separated by colons. 3ffe:1200:301b:1:a00:20ff:fec0:ffee, for example. Notice that the '1' is really '0001' - leading 0s within a group can be left out. There are more little tricks, but you can go look at the various IPv6 RFCs if you're really curious.
For my money, we're already heading in the right direction with the switch to digital broadcasting, since that change involves moving all of the TV broadcasters up to UHF. The big VHF give-back is, IMHO, the important part. There are 12 channels of VHF TV. At 6 MHz each, that's 72 MHz of space, or more than a quarter of the available VHF spectrum. VHF is prime real estate that could be much better used than for a fixed-point broadcasting service (most TV receivers don't move).
The larger point, however, is that networks of terrestrial broadcast stations are already obsolete. Back before widespread adoption of cable, it was the only option. But now, having NBC programming come out of a few hundred transmitters scattered across the US is wasteful, given that just about everyone gets TV programming from a satellite (directly or indirectly from their cable company). NBC, CBS, ABC, Fox and PBS should each have a single channel on that satellite, just like Comedy Central, and the local broadcasters should use their bandwidth to serve local needs. It's just common sense.
In the begining, Microsoft set up a division to fiddle with a Unix port. The division was eventually called SCO, and their product was Xenix. Microsoft then spun SCO off.
I'm sure it's not anything like the same SCO anymore, but I still find the irony delicious that just when Microsoft wants to spread FUD about Linux, SCO is the outfit that's actually doing it.
The migration path, in general, is to use DNS proxies and NATPT to make the transition appear to IPv6 users to be instantaneous.
I did this a while ago at my house. My network actually had no IPv4 on it at all for a few weeks. I stopped because a couple of applications didn't support IPv6 and because the KAME NATPT I grafted into my FreeBSD source tree broke. I did it sort of as a proof of concept, and it succeeded sufficiently for me to propose that IPv6-only ISPs could easily use the technique.
You first set up a DNS proxy. totd (Trick or Treat Daemon) is a good one. Its job is to turn requests for AAAA records into requests for AAAA or A records, and to translate A record replies into AAAA records with a special prefix tacked on to the high bits. This will make it look as though the whole IPv4 Internet is hidden inside of a special/96 prefix.
Coincidently, you route that/96 prefix into a NATPT. IPv6 packets go in, IPv4 packets come out and are sent to the IPv4 Internet as if they had gone through a NAT.
Having done this, all of the ISPs customers would see a complete IPv6-only Inernet, but they could still interact with legacy (IPv4) sites as if they were IPv6. As more and more ISPs convert over, the IPv4 network will simply shrink slowly until it's gone, but in the meantime remain as accessable as it currently is.
With such a transition plan in place, the more people who move to IPv6, the emptier the IPv4 Internet experience becomes (however, folks trapped with IPv4 only providers could use techniques like 6to4 to escape the legacy network), which in turn becomes the driving force for transition.
So, Enough stories are turning up... When is/. going to support IPv6?
Well, more to the point, the market is broken by the US health care system because the folks who get the benefits generally are not the folks paying the bill. Health insurance, generally funded either by the state or by employers pays the bills, but the patients get the benefits. The normal feedback loop of the market does not close properly.
I tried H&R blocks software and found no real difference.
My understanding (perhaps it's merely a rumor I'm repeating) is that H&R Block was going to use the same Cactus crap to protect their software starting in 2003 (that is, for the 2003 tax year which is actually going to be in 2004), but the minute they saw the flap starting over Intuit's use of it they very quickly backpeddled and put on a nice public face (while secretly saying, "there but for the grace of God go we").
So I guess H&R Block is the lesser evil, but I don't believe they're entirely innocent here.
I thought we had already had this whole cycle (copy protection, customer backlash, an escalating battle of attrition on both sides, and finally the realization that it does more harm than good) played out in the '80s.
Software companies that offer real value for money have little need to resort to copy protection. It's the ones that don't that always wind up resorting to nonsense like copy protection. But, of course, the copy protection lowers the value of their product even more, which simply makes the decision to jump to a competitor even easier. Even Microsoft is starting to see this.
Mod me down if you must, but I have to get this on the record.
I've been using His Steveness as a label for Jobs for a very long time, and now I'm sure I'll be blasted as a copycat every time I do from now on. But that's ok. I'm not bitter. Much.:-)
The fix for this is to specify IPv6 literal addresses inside [], which is the solution for IPv6 literals in URLs. For example, the IPv6 equivalent to 127.0.0.1:0 is [::1]:0.
But doesn't using encapsulated IPv6 inside IPv4 packets create an ugly overhead in packet sizes?
Of course. But there's no choice, since it's impractical to create an alternate IPv6-only Internet immediately.
Slightly off-topic, but not quite: IPv6 headers alone are not quite as bloated as it might seem. Though they contain 4 times as much address data (since each address is 4 times larger), they are only double the size of IPv4 headers. They're also much easier for intermediate routers to process because there is no IP header checksum. A lot of the fields of the IPv4 header have been removed and turned into optional extension headers (the Protocol byte has been renamed Next Header and is the start of a daisy chain of optional headers culminating in the TCP/UDP/ICMP/whatever header).
So for now, IPv6 moves through the IPv4 internet through encapsulation. This winds up wasting 20 bytes per packet. The bigger problem of IPv6 is that people who use tunneled connections often wind up with pessimal routing because the underlying IPv4 topography is not always reflected in the IPv6 routing table. Obviously when the migration is complete that won't be the case, but for now it's the best we can do, and the payoff is that it gives everyone experience with the new stuff.
With an IP-Masqueraded network everyone can have an entire class A to themselves.
How then does the machine at 10.0.0.1 in Santa Clara directly interact with the machine at 10.0.0.1 in Talahasee?
NAT is like AOL: You don't get the Internet, you get the InterWeb. The whole raison detre of the Internet is machines being able to communicate and interoperate. NAT makes that largely impossible, and sort of recasts the Internet into two groups: Those with real addresses and those without. If you don't like the idea of the big Net Media conglomerates taking control of content, then you should be all about early addoption of IPv6.
Do not confuse NAT with Firewalls. Firewalls are good. They give the administrator control over the interactions between your machines and the rest of the world. NAT is bad because it, generally speaking, makes classes of interactions painfully difficult (if they're possible at all).
I don't know for certain that they haven't watermarked the music (and I don't particularly care because I don't intend to put them up for p2p ripped or not), but I would suggest that it is unlikely. Unless they simply want to track the appearance of iTunes store tracks generally on p2p, they would need to individually watermark each song. That means they'd need to either watermark and encode the song during download (which seems unlikely given the time and server CPU that would require), or they'd need to watermark the audio during playback. Again, the latter is possible, but it seems unlikely that a watermark that would not be audible would survive all of MP3, AAC, or Ogg encoding. And when someone manages to separate the AAC stream from its encumbering DRM (without decoding and re-encoding it), that would be Game Over.
Software for macs, in general, has a much lower rate of piracy than software for PCs. I personally suspect this is the case because a bigger fraction of Apple's customers are grown-ups rather than 'l33t h4x0r5. I suspect that has a lot to do with how His Steveness got the Big 5 to go along with this. I actually suspect that ITMS tracks won't find their way to p2p in droves, as some of the naysayers say will happen.
It would be pointless to put the AAC file up on Kazaa because no one else can play it.
You could use iMovie to export an AIFF of the audio, then re-encode it to DRM-less AAC or MP3 if you like, and then upload it to Kazaa, but that would be indistinguishable from someone who bought the CD, ripped a track, and then did the same thing.
It's up to the API or OS to decide the tie-breaker if a host lookup gives back both an IPv4 and IPv6 address. The high order bit, of course, is to get AAAA-only hosts to work just as well as A-only hosts.
As for the software side, lots of software works with IPv6 today. Just to pick web browsers as an example... IE (on XP) and mozilla (depends on the platform) both support it. Alas, Safari, Camino and OmniWeb do not. The only way I've found to see The Dancing Kame on a mac has been to set up my own little primitive Java proxy (that's right, the latest JRE for OS X is IPv6-aware! Yay!).
What you're looking for is sort of the opposite of BIA - Bump in the API. With BIA, you can trick IPv4-only applications into supporting IPv6 by using LD_PRELOAD (or a platform equivalent) to replace GetHostBy___() with one that caches the results of GetAddrInfo() and returns 0.0.0.0/24 addresses. Then when a socket() or connect() call is made with a 0.0.0.0/24 address, the socket is actually created and connected with the cached information.
If you set up an IPv6-only network, you can use a DNS proxy and a NAT-PT to interoperate with IPv4-only hosts. The DNS proxy turns requests for AAAA records that fail into requests for A records, and translates the replies into AAAA records within a special/96 prefix. That prefix is routed into the NAT-PT, which is just like a NAT, except that it also does protocol translation. IPv6-only ISPs can set up their own network-wide NAT-PT and DNS proxy systems so that their customers can experience a more or less "pure" IPv6 internet. I wouldn't be at all surprised if AOL decides to take this route at some point (they probably wouldn't tell anyone).
Slashdot Mirror
If I was selling hardware, and someone reverse-engineered it to provide support to an alternate platform, I'd be very happy indeed (as I'm not an anon^H^H^H^Hpig in shit, I can't comment on the comparison). If I would normally sell N units, and having someone else write software that changes that to N+M, why wouldn't I be happy?
And it turns out that some folks have actually spoken to folks in authority at XM, and they're quite happy indeed to find that they've created a device that has inspired a community of hackers to make it better.
3. Volume should be labeled.
Um, there is no volume control. I think you're looking at the song rating slider.
4. Now playing box should be more distinguishable.
Not sure I understand what you're saying here. But let's take this conversation over to the bug and/or feature request section of the project rather than continue here.
There are others I can't think of right offhand. Don't get me wrong - I love Java, and I really love the combination of Java and Interface Builder. There are just a few issues that you run into when doing Java/Cocoa. I hope they get resolved soonoer rather than later.
The trouble is that most tech support outfits are wise to the "ask for a supervisor" gambit. Guess what: now they're all "supervisors." Feh.
The "Automatic" choice is to have it identify itself as Safari. Not quite the AI engine you thought it was.
You bring up a good point. I believe there is a standard for calendar and contact MIME attachments. If you had an IMAP server, you could duplicate the MS functionality of Exchange "contact" folders by having a folder full of (null) emails with such attachments. On the mac, you could lightly integrate iCal with Mail to achieve this. Same thing with the Address book. Those 3 apps together would be not only the Mac Entourage/Outlook killer, they'd be the Exchange killer too! Now that would be insanely great.
If you turn on the Debug menu, one of its options is a list of alternate User Agents. Thanks to MacOS X Hints for a refresher (defaults write com.apple.Safari IncludeDebugMenu 1).
Before we start... Isn't it Entourage instead of Outlook? And there's a MS Media Player for Mac? First I've heard. I'd be a lot happier, of course, if they'd just port the codecs over the QuickTime.
Anyway... I don't really know the order in which they'll be axed, but I do believe the impact will be minimal unless they axed them all Monday morning. Why? Because all of them either have perfectly good replacements now or they will have easily within a year.
IPv6 addresses are printed in groups of 16 bits in hex, separated by colons. 3ffe:1200:301b:1:a00:20ff:fec0:ffee, for example. Notice that the '1' is really '0001' - leading 0s within a group can be left out. There are more little tricks, but you can go look at the various IPv6 RFCs if you're really curious.
For my money, we're already heading in the right direction with the switch to digital broadcasting, since that change involves moving all of the TV broadcasters up to UHF. The big VHF give-back is, IMHO, the important part. There are 12 channels of VHF TV. At 6 MHz each, that's 72 MHz of space, or more than a quarter of the available VHF spectrum. VHF is prime real estate that could be much better used than for a fixed-point broadcasting service (most TV receivers don't move).
The larger point, however, is that networks of terrestrial broadcast stations are already obsolete. Back before widespread adoption of cable, it was the only option. But now, having NBC programming come out of a few hundred transmitters scattered across the US is wasteful, given that just about everyone gets TV programming from a satellite (directly or indirectly from their cable company). NBC, CBS, ABC, Fox and PBS should each have a single channel on that satellite, just like Comedy Central, and the local broadcasters should use their bandwidth to serve local needs. It's just common sense.
I'm sure it's not anything like the same SCO anymore, but I still find the irony delicious that just when Microsoft wants to spread FUD about Linux, SCO is the outfit that's actually doing it.
That would not be possible, unless those on the IPv4 network use something like 6to4 to obtain connectivity with the IPv6 network.
I did this a while ago at my house. My network actually had no IPv4 on it at all for a few weeks. I stopped because a couple of applications didn't support IPv6 and because the KAME NATPT I grafted into my FreeBSD source tree broke. I did it sort of as a proof of concept, and it succeeded sufficiently for me to propose that IPv6-only ISPs could easily use the technique.
You first set up a DNS proxy. totd (Trick or Treat Daemon) is a good one. Its job is to turn requests for AAAA records into requests for AAAA or A records, and to translate A record replies into AAAA records with a special prefix tacked on to the high bits. This will make it look as though the whole IPv4 Internet is hidden inside of a special /96 prefix.
Coincidently, you route that /96 prefix into a NATPT. IPv6 packets go in, IPv4 packets come out and are sent to the IPv4 Internet as if they had gone through a NAT.
Having done this, all of the ISPs customers would see a complete IPv6-only Inernet, but they could still interact with legacy (IPv4) sites as if they were IPv6. As more and more ISPs convert over, the IPv4 network will simply shrink slowly until it's gone, but in the meantime remain as accessable as it currently is.
With such a transition plan in place, the more people who move to IPv6, the emptier the IPv4 Internet experience becomes (however, folks trapped with IPv4 only providers could use techniques like 6to4 to escape the legacy network), which in turn becomes the driving force for transition.
So, Enough stories are turning up... When is /. going to support IPv6?
Or just \d (if you're using psql).
Well, more to the point, the market is broken by the US health care system because the folks who get the benefits generally are not the folks paying the bill. Health insurance, generally funded either by the state or by employers pays the bills, but the patients get the benefits. The normal feedback loop of the market does not close properly.
My understanding (perhaps it's merely a rumor I'm repeating) is that H&R Block was going to use the same Cactus crap to protect their software starting in 2003 (that is, for the 2003 tax year which is actually going to be in 2004), but the minute they saw the flap starting over Intuit's use of it they very quickly backpeddled and put on a nice public face (while secretly saying, "there but for the grace of God go we").
So I guess H&R Block is the lesser evil, but I don't believe they're entirely innocent here.
Software companies that offer real value for money have little need to resort to copy protection. It's the ones that don't that always wind up resorting to nonsense like copy protection. But, of course, the copy protection lowers the value of their product even more, which simply makes the decision to jump to a competitor even easier. Even Microsoft is starting to see this.
I've been using His Steveness as a label for Jobs for a very long time, and now I'm sure I'll be blasted as a copycat every time I do from now on. But that's ok. I'm not bitter. Much. :-)
The fix for this is to specify IPv6 literal addresses inside [], which is the solution for IPv6 literals in URLs. For example, the IPv6 equivalent to 127.0.0.1:0 is [::1]:0.
Of course. But there's no choice, since it's impractical to create an alternate IPv6-only Internet immediately.
Slightly off-topic, but not quite: IPv6 headers alone are not quite as bloated as it might seem. Though they contain 4 times as much address data (since each address is 4 times larger), they are only double the size of IPv4 headers. They're also much easier for intermediate routers to process because there is no IP header checksum. A lot of the fields of the IPv4 header have been removed and turned into optional extension headers (the Protocol byte has been renamed Next Header and is the start of a daisy chain of optional headers culminating in the TCP/UDP/ICMP/whatever header).
So for now, IPv6 moves through the IPv4 internet through encapsulation. This winds up wasting 20 bytes per packet. The bigger problem of IPv6 is that people who use tunneled connections often wind up with pessimal routing because the underlying IPv4 topography is not always reflected in the IPv6 routing table. Obviously when the migration is complete that won't be the case, but for now it's the best we can do, and the payoff is that it gives everyone experience with the new stuff.
How then does the machine at 10.0.0.1 in Santa Clara directly interact with the machine at 10.0.0.1 in Talahasee?
NAT is like AOL: You don't get the Internet, you get the InterWeb. The whole raison detre of the Internet is machines being able to communicate and interoperate. NAT makes that largely impossible, and sort of recasts the Internet into two groups: Those with real addresses and those without. If you don't like the idea of the big Net Media conglomerates taking control of content, then you should be all about early addoption of IPv6.
Do not confuse NAT with Firewalls. Firewalls are good. They give the administrator control over the interactions between your machines and the rest of the world. NAT is bad because it, generally speaking, makes classes of interactions painfully difficult (if they're possible at all).
Software for macs, in general, has a much lower rate of piracy than software for PCs. I personally suspect this is the case because a bigger fraction of Apple's customers are grown-ups rather than 'l33t h4x0r5. I suspect that has a lot to do with how His Steveness got the Big 5 to go along with this. I actually suspect that ITMS tracks won't find their way to p2p in droves, as some of the naysayers say will happen.
As for the software side, lots of software works with IPv6 today. Just to pick web browsers as an example... IE (on XP) and mozilla (depends on the platform) both support it. Alas, Safari, Camino and OmniWeb do not. The only way I've found to see The Dancing Kame on a mac has been to set up my own little primitive Java proxy (that's right, the latest JRE for OS X is IPv6-aware! Yay!).
If you set up an IPv6-only network, you can use a DNS proxy and a NAT-PT to interoperate with IPv4-only hosts. The DNS proxy turns requests for AAAA records that fail into requests for A records, and translates the replies into AAAA records within a special /96 prefix. That prefix is routed into the NAT-PT, which is just like a NAT, except that it also does protocol translation. IPv6-only ISPs can set up their own network-wide NAT-PT and DNS proxy systems so that their customers can experience a more or less "pure" IPv6 internet. I wouldn't be at all surprised if AOL decides to take this route at some point (they probably wouldn't tell anyone).