"Stop looking over your shoulder and invent something!"
That's just it: Microsoft has never invented anything. Everything Microsoft ever sold (with the possible exception of that first BASIC interpreter) they either bought or stole (sometimes both) from somwhere else. Microsoft can't innovate because they've never known how.
Apple's switch campaign used ordinary folks. Microsoft's practically requires MCSEs.
It's only fair, of course. That's pretty much how the two operating systems stack up as well.:-)
Re:10.2.4 broke the Linksys WPC54G AirPort2.kext h
on
Mac OS X 10.2.4 Is Out
·
· Score: 4, Informative
Well, that didn't take long.
The procedure to get your WPC54G to work with Apple's AirPort2 driver is a little more advanced now (it involves patching the driver), but it once again works.
10.2.4 broke the Linksys WPC54G AirPort2.kext hack
on
Mac OS X 10.2.4 Is Out
·
· Score: 3, Informative
10.2.4 comes with AppleAirPort2.kext version 3.0.3. This version appears to perform an extra check designed to thwart those of us who have managed to get the 3.0.1 version of the driver to talk to Linksys WPC54G and WMP54G cards.
If you have used this (admittedly unsupported) hack to get 802.11g for older hardware, you might want to move the 3.0.1 kext out of the way and put it back. At least until this extra check is found and neutralized.
We're both in violent agreement, but you misunderstood the argument slightly. I was drawing an equivalence between IPv4 addresses and IPv6/48 site allocations. The equivalence is arguable if you compare the extra large per-site allocations in IPv6 to the use of NAT with IPv4 to achieve similar ends.
except that the public hierarchy is SIXTEEN TIMES larger than that
It's actually 16 bits larger, or 65,536 times larger.
But I can't let it go at that, because that's also a bit wrong.
The top 3 bits of IPv6 addresses are a format prefix. It cuts the address space into 8 pieces. The top and bottom ones are used for things like multicast, link local and IPv4 mapped addresses. One of them is the place where allocations are happening today - the Agregatable Global Unicast space. So if we lop off the top 3 bits from the 16, we get that the current allocation space is 12 bits, or 4096 times larger than the IPv4 space.
And we've got another 5 of those waiting in the wings if we need them.
That's true, but as more 6to4 users come online, I suspect more of them will appear. And thanks to RFC 3068, 6to4 users don't actually have to do anything in response.
Oh, and if anyone reading this is in a position to do so, setting up a 6to4 relay router and advertising the RFC 3068 route is probably one of the best ways to help the cause of IPv6 migration.
Unfortunately, there are not enough 6to4 endpoints around the internet...
huh?
6to4 users can interact perfectly well with non-6to4 IPv6 addresses. They just need to set a default route to a 6to4 relay router. And RFC 3068 makes that universally trivial.
I don't believe there's any need for concern with the way IPv6 addresses are being dished out.
Look at it this way:
IPv4 addresses were indeed first allocated badly. It can be said that it's unfair that apple.com and.jp both wound up with a class A (unfair to Japan, in this comparison). These legacy allocations are most of the reason we're in a mess with IPv4. In fact, it's the complexity of the non-default routing table at the heart of the Internet that is driving the transition more than the lack of address space.
Now. Let's pretend that we could snap our fingers and give every "site" on the Internet a *single* IPv4 address. That means that apple.com gets a single IPv4 address and every cable modem user gets a single IPv4 address. All of the class As and class Cs get freed up. All of a sudden there are a lot more addresses available.
That's the case with IPv6, except that the public hierarchy is SIXTEEN TIMES larger than that. Sites in IPv6 are supposed to get a single/48 prefix. A/48 is going to be sufficient for the largest of organizations. They can have 65,536 subnets, each with a potential 2^64 nodes. IPv4, in theory, was supposed to be subnettable. The problem is that if you want to cut a class C into 8 pieces, each of those pieces is only going to be able to have 32 hosts. It's this tight binding between the number of subnets and the number of possible hosts in the subnet that has resulted in the proliferation of switches and flat networks. That's not really how it is supposed to be.
IPv6 is designed to last us 50 years or so. Personally, I think it will last a lot longer than that.
They could do it a lot easier than that... All they really have to do is implement 6to4, use the RFC 3068 default route, and implement NAT-PT and a DNS proxy layer. If you have a box that does that, then IPv6-only clients would be able to experience the IPv4 internet seamlessly, but still gain all the advantages of being native IPv6.
Just a bit of amplification for those not familiar with wireless systems.
Ethernet is CSMA/CD - Carrier Sense, Multiple Access with Collision Detection. Carrier Sense simply means you can hear anyone else on channel when they talk. Multiple Access means that anyone can talk any time they want. Collision Detection means that if two people happen to talk at the same time, they can actually detect that they have done so, back off and try again. Ethernet can do CSMA/CD because, to oversimplify, it can listen at the same time as it transmits, therefore it can hear the collisions.
CSMA/CA systems, by contrast, are the same as far as the CSMA part goes, but CA stands for Collision Avoidance. This is really just spin. It means that the station's cannot listen at the same time as they transmit. This is typical for peer-to-peer wireless systems. It's like CB radio. When you push the push-to-talk button, the receiver stops receiving. You need this to happen, because the transmitter is relatively powerful and the receiver is relatively sensitive. Even if the receiver would not be damaged by having the transmitter key up right next to it, the transmitter would easily drown out the signal from any other on-channel transmitter.
"But wait," I hear you cry, "What about cell phones? They can transmit and receive at the same time." This is true. But in this case, the transmitter and receiver are not on the same frequency, but instead on frequencies very far apart. This allows the receiver to have a band-reject filter tuned for the transmitter's output. In fact, the closer in frequency a full-duplex (receive and transmit simultaneously on independent channels) receiver and transmitter are, the more elaborate the filtering must be. Extreme examples can be had by looking at a typical Amateur Radio 3 kHz FM voice in-band VHF repeater. The frequency separation between receiver and transmitter on the 2 meter band is typically 600 kHz. To achieve sufficient isolation, you actually need to use tuned cavities. They're rather large and ticklish to get dialed in. But although the repeater can use the cavities to achieve full-duplex, the user radios are still half-duplex (transmit and receive on independent channels, but not at the same time). Which means that the only way you know that you and your fellow repeater user keyed up at the same time is when the other repeater users tell you that they didn't hear you.
Full- or half-duplex is only an attractive solution in cases where either it's not a peer-to-peer system or where it's a point-to-point system. So it's a lot like 10baseT, where you can either wire two peers directly together or you can connect multiple stations to a repeater (aka a hub or a switch). 802.11b radios are simplex (they transmit and receive on the same channel). This means that you're not going to be able to do collision detection. And that means that either throughput will suffer much more heavily than CSMA/CD systems when demand rises, or you need to have a much more asymetric model, probably with the server station polling the clients, or you need some sort of variation on token rings or some other dining-philosopher-like solution.
One thing they could have done would be to make 802.11b infrastructure mode a half-duplex mode. On the plus side, this means that the downlink from the base station would be collision free since user stations (at least those on the same network) would not be expected. On the minus side, this means, of course, that all of the base stations would take two channels.
One thing I read recently (perhaps here?) about softwareupdate was that Apple was going to release an SDK for softwareupdate so that third parties could use it as a mechanism to keep users up-to-date.
UFS1 can already handle files > 2GB. One of the big benefits of moving to UFS2 is that it is one of the requirements for moving to 64 bit time_t values, which will slay the y2037 bug.
Congratulations to all of the folks who worked hard to make this happen. I stayed up way to late last night upgrading my desktop machine and ran into only a few trivialitiess that were straightforward to fix.
I suppose it could be psychosomatic, but it actually seems faster to me than 4.7-RELEASE.:-)
I have a couple of public web server type sites that I plan on leaving at 4.x for now, but I'm quite pleased with the present state of the 5.x branch.
Me thinks you are confusing port 25 *ingress* and port 25 *egress*.
You can have an open port 25 listener if you like (so long as it's not set up to do inappropriate 3rd party relay). But forcing *your* server to talk to the ISP's mail server for *sending outgoing* mail is what we're talking about. So long as the ISP's mail server actually does properly relay the mail for you and doesn't do anything else out of spec, there's nothing (much) wrong with them forcing you to use it.
There is the privacy issue (suddenly your mail winds up on a 3rd party system for however long it takes that machine to spool it, then send it on its way), but my expectation of privacy for unencrypted e-mail is already fairly low.
I used to run a tiny ISP. What I did was *redirect* traffic outbound to port 25 to a local mail server. The mail would still be delivered, and that server was (obviously) set up to allow 3rd party relay from the correct set of addresses. I had a small customer base, but I never once had any complaints about this policy. The users could forge the From: header all they wanted, but the outgoing mail would always have a proper Received: header, at least.
As long as the mail server doesn't do anything more agregious to the mail than add a Received: header, I find it unlikely that any legitimate complaints could be made about this practice. It's certainly a much more gentle answer than simply blocking port 25 egress completely. At least this way it's more or less invisible to the end-user.
Wow. Rendezvous sounds like a really convenient way to do this sort of thing. I've recently delved into the universe of Java-Cocoa. Does anyone know if Rendezvous is conveniently available to a Java-Cocoa app?
My friends and I have a private joke. My friend is a Microslut, and I am BSDish (and now MacOS Xish). The joke recalls the Star Trek TOS episode "For the world is hollow and I have touched the sky." I refer to his MS Implant that brings him pain whenever he considers using Linux or Open Office or the like.
VirtualDub.[...]There isn't a comparable commercial app on any operating system.
I would say that Quicktime Pro is comperable to VirtualDub, with the obvious proviso that you wind up making Quicktime videos instead of AVIs. I'll pass on commenting on which is better and simply mention that QTP is available on both Macs and Winduhs with the same feature set. It isn't free (either definition) like VirtualDub, however.
Firstly, there is no reason why Microsoft couldn't sell their own version of Linux for the server, and charge the same as they charge for their current Windows server software. I am quite sure that it would sell well, and could reduce the numbers of people migrating to Red Hat, for example.
Let's look at this scenario in detail.
Let's say that Microsoft ports Exchange to Linux and sells a Linux distro with this Exchange server bundled. History repeats itself, as doing so violates the Sherman act the exact same way that bundling IE in with Windows did. How? Exchange is an instrument of monopolistic leverage. Using LinExchange to sell MSLinux is the same as using Windows to "sell" IE. Red Hat gets to play the part of Netscape. Microsoft could negate the damage by decoupling LinExchange from MSLinux, but given their success in the past at brushing aside pesky anti-trust actions, can anyone really think they would?
Such a port has been the subject of speculation for some time, so much so that Microsoft has actually denied it, thus giving the notion even more credibility.
Doesn't that sound like the scene from "Life of Brian" where someone in the crowd says that only the true Messiah denies himself?
Comparing new prices with used is like comparing, well, apples and oranges. Besides, even if those eBay machines were new-old-stock, they'd still probably be short of this device in terms of RAM and disk.
Slashdot Mirror
"Stop looking over your shoulder and invent something!"
That's just it: Microsoft has never invented anything. Everything Microsoft ever sold (with the possible exception of that first BASIC interpreter) they either bought or stole (sometimes both) from somwhere else. Microsoft can't innovate because they've never known how.
Apple's switch campaign used ordinary folks. Microsoft's practically requires MCSEs.
:-)
It's only fair, of course. That's pretty much how the two operating systems stack up as well.
Well, that didn't take long.
The procedure to get your WPC54G to work with Apple's AirPort2 driver is a little more advanced now (it involves patching the driver), but it once again works.
here is where you can get the details.
10.2.4 comes with AppleAirPort2.kext version 3.0.3. This version appears to perform an extra check designed to thwart those of us who have managed to get the 3.0.1 version of the driver to talk to Linksys WPC54G and WMP54G cards.
If you have used this (admittedly unsupported) hack to get 802.11g for older hardware, you might want to move the 3.0.1 kext out of the way and put it back. At least until this extra check is found and neutralized.
The nominees include Pinochio, Star Wars II and Pluto Nash, among other (very deserving) candidates.
We're both in violent agreement, but you misunderstood the argument slightly. I was drawing an equivalence between IPv4 addresses and IPv6 /48 site allocations. The equivalence is arguable if you compare the extra large per-site allocations in IPv6 to the use of NAT with IPv4 to achieve similar ends.
It's actually 16 bits larger, or 65,536 times larger.
But I can't let it go at that, because that's also a bit wrong.
The top 3 bits of IPv6 addresses are a format prefix. It cuts the address space into 8 pieces. The top and bottom ones are used for things like multicast, link local and IPv4 mapped addresses. One of them is the place where allocations are happening today - the Agregatable Global Unicast space. So if we lop off the top 3 bits from the 16, we get that the current allocation space is 12 bits, or 4096 times larger than the IPv4 space.
And we've got another 5 of those waiting in the wings if we need them.
That's true, but as more 6to4 users come online, I suspect more of them will appear. And thanks to RFC 3068, 6to4 users don't actually have to do anything in response.
Oh, and if anyone reading this is in a position to do so, setting up a 6to4 relay router and advertising the RFC 3068 route is probably one of the best ways to help the cause of IPv6 migration.
huh?
6to4 users can interact perfectly well with non-6to4 IPv6 addresses. They just need to set a default route to a 6to4 relay router. And RFC 3068 makes that universally trivial.
I don't believe there's any need for concern with the way IPv6 addresses are being dished out.
.jp both wound up with a class A (unfair to Japan, in this comparison). These legacy allocations are most of the reason we're in a mess with IPv4. In fact, it's the complexity of the non-default routing table at the heart of the Internet that is driving the transition more than the lack of address space.
/48 prefix. A /48 is going to be sufficient for the largest of organizations. They can have 65,536 subnets, each with a potential 2^64 nodes. IPv4, in theory, was supposed to be subnettable. The problem is that if you want to cut a class C into 8 pieces, each of those pieces is only going to be able to have 32 hosts. It's this tight binding between the number of subnets and the number of possible hosts in the subnet that has resulted in the proliferation of switches and flat networks. That's not really how it is supposed to be.
Look at it this way:
IPv4 addresses were indeed first allocated badly. It can be said that it's unfair that apple.com and
Now. Let's pretend that we could snap our fingers and give every "site" on the Internet a *single* IPv4 address. That means that apple.com gets a single IPv4 address and every cable modem user gets a single IPv4 address. All of the class As and class Cs get freed up. All of a sudden there are a lot more addresses available.
That's the case with IPv6, except that the public hierarchy is SIXTEEN TIMES larger than that. Sites in IPv6 are supposed to get a single
IPv6 is designed to last us 50 years or so. Personally, I think it will last a lot longer than that.
They could do it a lot easier than that... All they really have to do is implement 6to4, use the RFC 3068 default route, and implement NAT-PT and a DNS proxy layer. If you have a box that does that, then IPv6-only clients would be able to experience the IPv4 internet seamlessly, but still gain all the advantages of being native IPv6.
NAT is an abomination that must die.
Ethernet is CSMA/CD - Carrier Sense, Multiple Access with Collision Detection. Carrier Sense simply means you can hear anyone else on channel when they talk. Multiple Access means that anyone can talk any time they want. Collision Detection means that if two people happen to talk at the same time, they can actually detect that they have done so, back off and try again. Ethernet can do CSMA/CD because, to oversimplify, it can listen at the same time as it transmits, therefore it can hear the collisions.
CSMA/CA systems, by contrast, are the same as far as the CSMA part goes, but CA stands for Collision Avoidance. This is really just spin. It means that the station's cannot listen at the same time as they transmit. This is typical for peer-to-peer wireless systems. It's like CB radio. When you push the push-to-talk button, the receiver stops receiving. You need this to happen, because the transmitter is relatively powerful and the receiver is relatively sensitive. Even if the receiver would not be damaged by having the transmitter key up right next to it, the transmitter would easily drown out the signal from any other on-channel transmitter.
"But wait," I hear you cry, "What about cell phones? They can transmit and receive at the same time." This is true. But in this case, the transmitter and receiver are not on the same frequency, but instead on frequencies very far apart. This allows the receiver to have a band-reject filter tuned for the transmitter's output. In fact, the closer in frequency a full-duplex (receive and transmit simultaneously on independent channels) receiver and transmitter are, the more elaborate the filtering must be. Extreme examples can be had by looking at a typical Amateur Radio 3 kHz FM voice in-band VHF repeater. The frequency separation between receiver and transmitter on the 2 meter band is typically 600 kHz. To achieve sufficient isolation, you actually need to use tuned cavities. They're rather large and ticklish to get dialed in. But although the repeater can use the cavities to achieve full-duplex, the user radios are still half-duplex (transmit and receive on independent channels, but not at the same time). Which means that the only way you know that you and your fellow repeater user keyed up at the same time is when the other repeater users tell you that they didn't hear you.
Full- or half-duplex is only an attractive solution in cases where either it's not a peer-to-peer system or where it's a point-to-point system. So it's a lot like 10baseT, where you can either wire two peers directly together or you can connect multiple stations to a repeater (aka a hub or a switch). 802.11b radios are simplex (they transmit and receive on the same channel). This means that you're not going to be able to do collision detection. And that means that either throughput will suffer much more heavily than CSMA/CD systems when demand rises, or you need to have a much more asymetric model, probably with the server station polling the clients, or you need some sort of variation on token rings or some other dining-philosopher-like solution.
One thing they could have done would be to make 802.11b infrastructure mode a half-duplex mode. On the plus side, this means that the downlink from the base station would be collision free since user stations (at least those on the same network) would not be expected. On the minus side, this means, of course, that all of the base stations would take two channels.
One thing I read recently (perhaps here?) about softwareupdate was that Apple was going to release an SDK for softwareupdate so that third parties could use it as a mechanism to keep users up-to-date.
I think that is fantastic.
UFS1 can already handle files > 2GB. One of the big benefits of moving to UFS2 is that it is one of the requirements for moving to 64 bit time_t values, which will slay the y2037 bug.
:-)
34 years and counting...
Congratulations to all of the folks who worked hard to make this happen. I stayed up way to late last night upgrading my desktop machine and ran into only a few trivialitiess that were straightforward to fix.
:-)
I suppose it could be psychosomatic, but it actually seems faster to me than 4.7-RELEASE.
I have a couple of public web server type sites that I plan on leaving at 4.x for now, but I'm quite pleased with the present state of the 5.x branch.
Me thinks you are confusing port 25 *ingress* and port 25 *egress*.
You can have an open port 25 listener if you like (so long as it's not set up to do inappropriate 3rd party relay). But forcing *your* server to talk to the ISP's mail server for *sending outgoing* mail is what we're talking about. So long as the ISP's mail server actually does properly relay the mail for you and doesn't do anything else out of spec, there's nothing (much) wrong with them forcing you to use it.
There is the privacy issue (suddenly your mail winds up on a 3rd party system for however long it takes that machine to spool it, then send it on its way), but my expectation of privacy for unencrypted e-mail is already fairly low.
I used to run a tiny ISP. What I did was *redirect* traffic outbound to port 25 to a local mail server. The mail would still be delivered, and that server was (obviously) set up to allow 3rd party relay from the correct set of addresses. I had a small customer base, but I never once had any complaints about this policy. The users could forge the From: header all they wanted, but the outgoing mail would always have a proper Received: header, at least.
As long as the mail server doesn't do anything more agregious to the mail than add a Received: header, I find it unlikely that any legitimate complaints could be made about this practice. It's certainly a much more gentle answer than simply blocking port 25 egress completely. At least this way it's more or less invisible to the end-user.
Wow. Rendezvous sounds like a really convenient way to do this sort of thing. I've recently delved into the universe of Java-Cocoa. Does anyone know if Rendezvous is conveniently available to a Java-Cocoa app?
I figured out how to add self-signed and alternate CA root certs to Safari. See how here.
My friends and I have a private joke. My friend is a Microslut, and I am BSDish (and now MacOS Xish). The joke recalls the Star Trek TOS episode "For the world is hollow and I have touched the sky." I refer to his MS Implant that brings him pain whenever he considers using Linux or Open Office or the like.
Ein Volk, Ein Reich, Ein Führer.
Yes, it's an old one, but it bears repeating.
I would say that Quicktime Pro is comperable to VirtualDub, with the obvious proviso that you wind up making Quicktime videos instead of AVIs. I'll pass on commenting on which is better and simply mention that QTP is available on both Macs and Winduhs with the same feature set. It isn't free (either definition) like VirtualDub, however.
Let's look at this scenario in detail.
Let's say that Microsoft ports Exchange to Linux and sells a Linux distro with this Exchange server bundled. History repeats itself, as doing so violates the Sherman act the exact same way that bundling IE in with Windows did. How? Exchange is an instrument of monopolistic leverage. Using LinExchange to sell MSLinux is the same as using Windows to "sell" IE. Red Hat gets to play the part of Netscape. Microsoft could negate the damage by decoupling LinExchange from MSLinux, but given their success in the past at brushing aside pesky anti-trust actions, can anyone really think they would?
Doesn't that sound like the scene from "Life of Brian" where someone in the crowd says that only the true Messiah denies himself?
Comparing new prices with used is like comparing, well, apples and oranges. Besides, even if those eBay machines were new-old-stock, they'd still probably be short of this device in terms of RAM and disk.