In terms of the smartest thing, I'm dubious. Assume for a moment that Nokia's software platform is a dead-end (Nokia's leadership certainly has). The best strategy would not be an exclusivity agreement that locks them out of the Android game (the largest slice of the pie ignoring Nokia and Apple). You say Nokia would be 'just a lemming' by going Android and that WP7 differentiates them, but the same vendors doing Android are largely also doing WP7. Nokia in no way is differentiating at the software platform no matter how you slice it, and in that situation ignoring the largest slice of the pie is a recipe for failure or at least an upper bound on your potential for success.
No video-out (at least no talk of it). If they wanted to do business, the ability to do video-out to project might have been a nice bonus, not to mention set-top application.
Pre 3's resolution is lower than the Atrix and iPhone 4. RAM lower than the Atrix.
There may be a chance that between the reduced ram and screen size/resolution, they can out-battery the Atrix, which may be the reason for going light on those specs relative to the cutting edge.
No LTE or WiMax radio capability mentioned. This is a very strange omission.
WebOS on a regular 'computer' seems disinteresting. I'm a fan of WebOS as an excellent compromise for multitasking management given a small form factor, but I'd much rather have traditional window management on my desktop/laptop.
On the good news, they *finally* got an auto-focus camera (that was one hardware feature that was needed to do all sorts of things along the lines of barcode recognition). The screen resolution is a nice bump and is at least in the ball-park of Atrix and iPhone 4. The 1.4 GHz snapdragon seems pretty good. The 'tap to share' seemed a decent enough story on owning the 'family' of products, but I still can't be bothered to care about any tablet.
More seriously, I would be surprised if most people that claim to be 'Anonymous' have the know-how to accurately cover their tracks as they do things. For example, in this last wave, I think a number of people were trivially linked as originators of traffic generated by the LOIC tool. We aren't talking about an uber-sophisticated secret organization with super powers, we are talking about a group of moderately skilled technical people that are naive in their confidence in their anonymity and/or a misunderstanding of how the legal system works induced by various crime/court drama television shows.
They did conduct some arrests ('ton' is a very subjective term in this context). The police can and does act without 'hard' proof while an investigation is conducted to either uncover hard proof, a confession, testimony, whatever or give up.
I would say that anyone trying to accurately report the state and actions of SCO can't help but to *seem* paranoid. You have to keep in mind how incredibly insane SCO people have repeatedly been. They charged at *IBM* with no case at all. They played all sorts of games with investors and regulatory agencies to cheat their way out of trouble and keeping as much money as possible. This 'Unxis' being nothing more than some sort of shell game to further misdirect things is not far fetched at all. It's not really paranoia if they really are out to get you.
A transition period will always have issues, there simply is no way around it. The point of NAT64 is indeed for people doing browsing from their house. Sure, the target loses some granularity in tracking if using IP (though I wonder if geo-ip might still work if the NAT64 gateways tend to be close to the end-user), but every 'answer' for the problem messes with that anyway (if not NAT64, carrier grade NAT would happen and you are back to square one).
If you have significant datacenter presence, it's probably unavoidable to refesh networking equipment and software to cleanly support IPv6. As mentioned before, you can defer this by staying v4 until your budget allows at the expense of talking to some hosts via NAT64. Of course, if IPv6 takes off in NAT64 mode, the NAT issues will probably confuse your attack/fraud detecion too.
djb's point is that everyone has to be dual stack, you haven't gotten anywhere meaningful, If your provider can give you both, great. If IPv4 is exhausted, then there better be a way to get by without an IPv4 address at all.
Besides if your provider has to juggle both IPv6 and IPv4, they have nothing to gain in terms of operational cost reduction by offering dual stack. They still have all the logistical problems of managing IPv4 space while at the same time doing v6. With NAT64, the carrier could just do IPv6 and potentially save some cash. The only downside is your endpoint is unaccessible from v4-only hosts, meaning it will be fine for most residential use short term, but servers will have to at least do IPv4, so dual stack makes a lot of sense there.
Agreed in principle, however NAT64 enables *precisely* what djb complains about. An IPv6 only host can now meaningfully participate in an internet filled with v4-only servers.
The former is a tad old and mostly fixed by NAT64.
On second:
they created a totally new problem by avoiding arp. the
benefit of their layer-2 discovery mechanism has been
absolutely zero; the best unit of measure for the cost of
that decision is "decades".
ICMPv6 neighbor solicitation at *worst* case 'degrades' to ARP-type behavior. In very well behaved layer 2 networks (almost none, admittedly) it greatly reduces load at large scale of system. I don't see why avoiding ARP costs 'decades'.
they created an entirely new and huge problem (destroying
SIOCGIFCONF backwards compat hurt IPV6 deployment in operating
systems on a massive scale) by not making their sockaddr be
a power of 2 in size.
I still haven't heard anyone explain why that is so catastrophically bad. It may be, but in practice, I haven't seen how this afflicts me.
Now I will complain that they changed some fundamentals around DHCP (DHCP at all being a near afterthought as they magically thought route advertisement, stateless addressing, and mDNS would be the cure for *EVERYTHING*). However, most of it is probably going to fall into place as soon as more practical deployments start (currently, most v6 trials that end in failure cause people to just walk away from now instead of trying to push fixes.
My WRT54G doesn't have IPv6 baked in unless I go to a third-party firmware that has it (I plan on doing that, but still no IPv6 in sight for Time Warner customers so I don't know what they'll do when the time comes). Note third-party firmware, not something that mom and pop would generally apply. A whole *LOT* of people have devices like that as their gateway. Besides, a firmware update is not exactly automatic.
Now try telling your mom how to differentiate between the 2 IPv6 addresses she'll have on her PC (link-local and the routable one), when before she just handled that 192.168.1.xxx one and everything worked.
Most 'mom's that can't tell fe80:: from anything else don't even know what an IPv4 address is at all. *If* there is more than one computer on the network, they access via NETBIOS name service today.
And when my ISP decides to give me a new prefix, the IPv6 devices on my network also have their IPs changed
I would wager it will be a lot less likely for an ISP to change your prefix than it is for them to change your IP today. Within your house, you have invariant link-local addresses baked in (and you won't want to remember any addresses, but thanks to mDNS you don't have to anyway).
Or I assign them a THIRD IPv6 address (FC00::/64 is the private range) so I can always refer to my router as FC00::1, my NAS appliance as FC00::0101, etc?
Using FC00::/7 like that is against the rules. You would instead end up with something like fdd2:773a:45a2::/48. I know this feeds into your 'IPv6 is hard' argument, but I wanted to make sure that ULA addresses are understood as having a mechanism to try for uniqueness so that private networks don't conflict when tunnelled together. You really really should just use the easy to remember name your device will have, but if you feel compelled to memorize an IP, then just remember you need to connect to fe80::94ab:e1ff:fea7:808a instead of 2001::f00.
Management headaches - you shouldn't need to be a network engineer just so you can share your internet with everyone else in your family.
All the management 'magic' is there. In fact, it is *less* likely that 'mom' will have to log in and change private addressing settings with v6 (today if your ISP happens to do carrier grade NAT using 192.168.0.0/16, then that linksys needs advanced config, not the case with prefix delegation or even auto-generated ULA addresses). For in-house name resolution, mDNS is pretty well baked into everything. For external... well you'll probably still have to use a dynamic dns service just like today for your needs since your ISP probably won't be giving you a subdomain to play in, but that's no worse than today.
For 99% of applications, I don't see the difference between v6 and v4 at the API layer as being particularly large.
Now if you are doing your own mask calculations and such, yes you have a mild amount of work (mostly mitigated by arbitrary precision math libraries for low-performance applications) to cope with the fact that it doesn't fit into a 32 bit int. I don't understand the beef about sockaddr_in6 not being a power of 2 or aligned.
If you feel a lot of performance is lost by going to non-int addresses, I think it's fairly obvious that massive NAT based solutions would impact performance more.
Another problem with your vision is it presumes all users want to be mindless consumers. I like hosting my services. I like being able to ssh into my box without having to sign up for some inefficiently implemented hosted proxy for that sort of thing.
Basically that is the 'cloud-enhanced' hosting model. Pretty much the same as hosting before cloud was a buzzword, but with a certain expectation of no people interacting with people to do something (and therefore low latency to get what you need done without knowing the details).
The same principals can apply to how an organization deploys internal resources. Instead of opening a ticket that an admin has to read and immediately react to (often times that latency representing an outage), you implement a strategy where self-service is viable *most* of the time. The admins do what is needed behind the scenes without having to pay *too* close attention to the specifics of the users and what they are doing and similarly, the end-user requests and sees their resource stay up or reboot without calling an admin to say that RAID controller X kicked the bucket or that DIMM 7 had an uncorrectable ECC error, or that a power supply shot itself in the head. This lets a large, internal IT organization act pretty much just like a cloud provider in terms of cost. When you rent capacity from Amazon, *you* have to foot Amazon's operational cost plus margin. When you only need a fraction of a server (individuals, or small/medium business with modest compute needs), this makes a whole lot of sense. If you can keep hundreds of servers fully utilized constantly, Amazon's pricing structure will be far more than insourcing the needs (*iff* done correctly, which is a big iff).
A lottery would notice someone winning every time with high frequency. They would at *best* change the game to correct the exposure, at worst figure some way to prosecute him for something or another.
1. your can allow privacy on your network (eg. different IP address for each request, so sites can't track *you* reliably, etc.)
That's just silly. At the IP layer, they lose no granularity over today (they can tell basically what house it came from from the leading 64 bits and either interpret the last bits as finer grained data or discard as noise. All this is moot as sites track *you* reliably via use of higher-layer features like authenticated sessions and/or HTTP cookies that persist regardless of originating IP.
2. no need to run DHCP - each computer can make a unique address automatically
True, but of little practical consequence for most of the world. Most of the world lived in the default private network their linksys box gave them and the DHCP was effectively equally magic as route advertising with auto-config in v6. Note I did say most of the world, some cases required end-user tweaking that won't know, but a small minority.
3. no more NAT necessity - SIP, Skype, BT, IRC, server - all work as they are suppose to work.
Nope, that ship has sailed. Sure, NAT won't be there to mess things up but firewalls will continue to break P2P by default and things like Skype and BT will continue to need 'superpeers' that will be somewhat rare still (though more prevalent than IPv4, but only slightly). If the late 90s hadn't seen so many DoS attacks using immature IP stacks and insecure services left wide open by overly trusting OS vendors (MS largely, but other vendors not blameless), maybe firewall wouldn't be considered a must-have. Now even with solid IP stacks and generally more secure defaults, poor security practices and paranoia will not magically make firewalls disappear. One of my first thoughts was that broken P2P models would be resolved as NAT goes away, but the firewalls will generally stay. I have the power to increase my reach, so it isn't bad for me, but for automagic, zero-config routers, yeah those will still be locking people up just as if they were behind a NAT gateway.
So first, Dell saying that is both a no-brainer (he's talking about a *competitor*, of *course* he's going to talk badly), and secondly in 97 Apple was fairly boned by all accounts and few would believe that it would recover. That was the year where everyone only began to learn that Apple+Jobs could succeed as one, but didn't fare so well individually (apple and next both tanked pretty hard).
The statement about the iPod being like the Walkman may or may not be accurate. Walkman enjoyed a *very* long position at the top, so the timeframe doesn't fall out quite just yet. It isn't likely to be accurate because of networking effects (iTunes store) and interacting with a music library being a larger area for differentiation than 'play, stop, rewind, fast forward, eject'. The suggestion of either Apple or Walkman representing a non-sustainable model did make no sense, there is nothing fundamentally less sustainable about either of those two compared to anything in technology.
Again, with netgear, they have absolutely nothing to gain from Apple's success, so they too will take every opportunity to highlight exposures. On the one hand, trashing Apple as being too subject to the whims of Jobs, on the other hand, if Jobs leaves the company could very well revisit their 90s experience.
At a glance, they have no commercial entity trying to spam it all over the news for one. For another, they too require some commercial add-on to be 100% outlook compatible. Lastly, they make no effort to use buzzowrds like 'SaaS' or 'cloud', which I suppose ties into the first point.
It might also suck, I have no idea, I don't do groupware stuff anymore so I have no reason to try it out.
The thing about Exchange competitors is unfortunately playing nice with Microsoft's monopoly which means outlook is *everywhere*. Microsoft never makes efforts to support open standards, therefore Outlook will never work well with something like citadel (sure, imap is there, but doing anything more than that requires, surprise, a commercial add-on).
The problem for groupware is not that Exchange is so fundamentally awesome beyond hope of competing on a level playing field, it's that it rides on the success of MS office.
I think your point is accurate on some open source projects on their own, but a lot of projects work quite well. The same applies to commercial products, sometimes they are solid, sometimes they are hard to use/counterintuitive, and when you have a bug, you don't even have the 'masocist' option of fix it yourself. I have had commercial vendors want to charge me a $200 incident support fee to let me send them a stack trace from their poroduct crashing without an error message. Similarly with support, we had a commercial vendor who could *not* figure out our problem with their product and some of our client systems. After 3 days of back and fourth with the vendor and figuring out nothing, I searched the mailing list of an open source competitor and they had the exact same problem and resolution, which we could translate to the commercial application and fixed in an hour what they had spent days trying to sort out.
There is great variance amongst open source and commercial software implementers. Some are consistent, some are not. Some produce quality product, others do not. Open source is not inherently worse than commercial offerings. Chasing 100% Exchange compatibility seems to draw the most questionable of the lot (both commercial and open source, with the latter usually ending up a token gesture to pull you into a 'real' commercial alternative in that space).
Slashdot Mirror
He did say 'looking', not 'quitting'.
In terms of the smartest thing, I'm dubious. Assume for a moment that Nokia's software platform is a dead-end (Nokia's leadership certainly has). The best strategy would not be an exclusivity agreement that locks them out of the Android game (the largest slice of the pie ignoring Nokia and Apple). You say Nokia would be 'just a lemming' by going Android and that WP7 differentiates them, but the same vendors doing Android are largely also doing WP7. Nokia in no way is differentiating at the software platform no matter how you slice it, and in that situation ignoring the largest slice of the pie is a recipe for failure or at least an upper bound on your potential for success.
No video-out (at least no talk of it). If they wanted to do business, the ability to do video-out to project might have been a nice bonus, not to mention set-top application.
Pre 3's resolution is lower than the Atrix and iPhone 4. RAM lower than the Atrix.
There may be a chance that between the reduced ram and screen size/resolution, they can out-battery the Atrix, which may be the reason for going light on those specs relative to the cutting edge.
No LTE or WiMax radio capability mentioned. This is a very strange omission.
WebOS on a regular 'computer' seems disinteresting. I'm a fan of WebOS as an excellent compromise for multitasking management given a small form factor, but I'd much rather have traditional window management on my desktop/laptop.
On the good news, they *finally* got an auto-focus camera (that was one hardware feature that was needed to do all sorts of things along the lines of barcode recognition). The screen resolution is a nice bump and is at least in the ball-park of Atrix and iPhone 4. The 1.4 GHz snapdragon seems pretty good. The 'tap to share' seemed a decent enough story on owning the 'family' of products, but I still can't be bothered to care about any tablet.
Tomato does not, but TomatoUSB does do IPv6.
I think I see their plan..
They buy up *all* the websites, then take them off the 'web' and make them accessible only through their 'AOL keyword'.
Oh, well in that case since Anonymous consists of antisocial computer users, that shouldn't require many arrests at all to meet the criteria.
I am Spartacus, I mean Anonymous!
More seriously, I would be surprised if most people that claim to be 'Anonymous' have the know-how to accurately cover their tracks as they do things. For example, in this last wave, I think a number of people were trivially linked as originators of traffic generated by the LOIC tool. We aren't talking about an uber-sophisticated secret organization with super powers, we are talking about a group of moderately skilled technical people that are naive in their confidence in their anonymity and/or a misunderstanding of how the legal system works induced by various crime/court drama television shows.
They did conduct some arrests ('ton' is a very subjective term in this context). The police can and does act without 'hard' proof while an investigation is conducted to either uncover hard proof, a confession, testimony, whatever or give up.
As Cooks Source knows well, *anything* on the internet is public domain and therefore open season.
I love my eReader and have no interest in a tablet, but a non-touchscreen, slow refresh device would not be particularly useful in this context.
I would say that anyone trying to accurately report the state and actions of SCO can't help but to *seem* paranoid. You have to keep in mind how incredibly insane SCO people have repeatedly been. They charged at *IBM* with no case at all. They played all sorts of games with investors and regulatory agencies to cheat their way out of trouble and keeping as much money as possible. This 'Unxis' being nothing more than some sort of shell game to further misdirect things is not far fetched at all. It's not really paranoia if they really are out to get you.
A transition period will always have issues, there simply is no way around it. The point of NAT64 is indeed for people doing browsing from their house. Sure, the target loses some granularity in tracking if using IP (though I wonder if geo-ip might still work if the NAT64 gateways tend to be close to the end-user), but every 'answer' for the problem messes with that anyway (if not NAT64, carrier grade NAT would happen and you are back to square one).
If you have significant datacenter presence, it's probably unavoidable to refesh networking equipment and software to cleanly support IPv6. As mentioned before, you can defer this by staying v4 until your budget allows at the expense of talking to some hosts via NAT64. Of course, if IPv6 takes off in NAT64 mode, the NAT issues will probably confuse your attack/fraud detecion too.
djb's point is that everyone has to be dual stack, you haven't gotten anywhere meaningful, If your provider can give you both, great. If IPv4 is exhausted, then there better be a way to get by without an IPv4 address at all.
Besides if your provider has to juggle both IPv6 and IPv4, they have nothing to gain in terms of operational cost reduction by offering dual stack. They still have all the logistical problems of managing IPv4 space while at the same time doing v6. With NAT64, the carrier could just do IPv6 and potentially save some cash. The only downside is your endpoint is unaccessible from v4-only hosts, meaning it will be fine for most residential use short term, but servers will have to at least do IPv4, so dual stack makes a lot of sense there.
Agreed in principle, however NAT64 enables *precisely* what djb complains about. An IPv6 only host can now meaningfully participate in an internet filled with v4-only servers.
The former is a tad old and mostly fixed by NAT64.
On second:
they created a totally new problem by avoiding arp. the
benefit of their layer-2 discovery mechanism has been
absolutely zero; the best unit of measure for the cost of
that decision is "decades".
ICMPv6 neighbor solicitation at *worst* case 'degrades' to ARP-type behavior. In very well behaved layer 2 networks (almost none, admittedly) it greatly reduces load at large scale of system. I don't see why avoiding ARP costs 'decades'.
they created an entirely new and huge problem (destroying
SIOCGIFCONF backwards compat hurt IPV6 deployment in operating
systems on a massive scale) by not making their sockaddr be
a power of 2 in size.
I still haven't heard anyone explain why that is so catastrophically bad. It may be, but in practice, I haven't seen how this afflicts me.
Now I will complain that they changed some fundamentals around DHCP (DHCP at all being a near afterthought as they magically thought route advertisement, stateless addressing, and mDNS would be the cure for *EVERYTHING*). However, most of it is probably going to fall into place as soon as more practical deployments start (currently, most v6 trials that end in failure cause people to just walk away from now instead of trying to push fixes.
My WRT54G doesn't have IPv6 baked in unless I go to a third-party firmware that has it (I plan on doing that, but still no IPv6 in sight for Time Warner customers so I don't know what they'll do when the time comes). Note third-party firmware, not something that mom and pop would generally apply. A whole *LOT* of people have devices like that as their gateway. Besides, a firmware update is not exactly automatic.
Now try telling your mom how to differentiate between the 2 IPv6 addresses she'll have on her PC (link-local and the routable one), when before she just handled that 192.168.1.xxx one and everything worked.
Most 'mom's that can't tell fe80:: from anything else don't even know what an IPv4 address is at all. *If* there is more than one computer on the network, they access via NETBIOS name service today.
And when my ISP decides to give me a new prefix, the IPv6 devices on my network also have their IPs changed
I would wager it will be a lot less likely for an ISP to change your prefix than it is for them to change your IP today. Within your house, you have invariant link-local addresses baked in (and you won't want to remember any addresses, but thanks to mDNS you don't have to anyway).
Or I assign them a THIRD IPv6 address (FC00::/64 is the private range) so I can always refer to my router as FC00::1, my NAS appliance as FC00::0101, etc?
Using FC00::/7 like that is against the rules. You would instead end up with something like fdd2:773a:45a2::/48. I know this feeds into your 'IPv6 is hard' argument, but I wanted to make sure that ULA addresses are understood as having a mechanism to try for uniqueness so that private networks don't conflict when tunnelled together. You really really should just use the easy to remember name your device will have, but if you feel compelled to memorize an IP, then just remember you need to connect to fe80::94ab:e1ff:fea7:808a instead of 2001::f00.
Management headaches - you shouldn't need to be a network engineer just so you can share your internet with everyone else in your family.
All the management 'magic' is there. In fact, it is *less* likely that 'mom' will have to log in and change private addressing settings with v6 (today if your ISP happens to do carrier grade NAT using 192.168.0.0/16, then that linksys needs advanced config, not the case with prefix delegation or even auto-generated ULA addresses). For in-house name resolution, mDNS is pretty well baked into everything. For external... well you'll probably still have to use a dynamic dns service just like today for your needs since your ISP probably won't be giving you a subdomain to play in, but that's no worse than today.
For 99% of applications, I don't see the difference between v6 and v4 at the API layer as being particularly large.
Now if you are doing your own mask calculations and such, yes you have a mild amount of work (mostly mitigated by arbitrary precision math libraries for low-performance applications) to cope with the fact that it doesn't fit into a 32 bit int. I don't understand the beef about sockaddr_in6 not being a power of 2 or aligned.
If you feel a lot of performance is lost by going to non-int addresses, I think it's fairly obvious that massive NAT based solutions would impact performance more.
Another problem with your vision is it presumes all users want to be mindless consumers. I like hosting my services. I like being able to ssh into my box without having to sign up for some inefficiently implemented hosted proxy for that sort of thing.
Basically that is the 'cloud-enhanced' hosting model. Pretty much the same as hosting before cloud was a buzzword, but with a certain expectation of no people interacting with people to do something (and therefore low latency to get what you need done without knowing the details).
The same principals can apply to how an organization deploys internal resources. Instead of opening a ticket that an admin has to read and immediately react to (often times that latency representing an outage), you implement a strategy where self-service is viable *most* of the time. The admins do what is needed behind the scenes without having to pay *too* close attention to the specifics of the users and what they are doing and similarly, the end-user requests and sees their resource stay up or reboot without calling an admin to say that RAID controller X kicked the bucket or that DIMM 7 had an uncorrectable ECC error, or that a power supply shot itself in the head. This lets a large, internal IT organization act pretty much just like a cloud provider in terms of cost. When you rent capacity from Amazon, *you* have to foot Amazon's operational cost plus margin. When you only need a fraction of a server (individuals, or small/medium business with modest compute needs), this makes a whole lot of sense. If you can keep hundreds of servers fully utilized constantly, Amazon's pricing structure will be far more than insourcing the needs (*iff* done correctly, which is a big iff).
Not a good long term strategy.
A lottery would notice someone winning every time with high frequency. They would at *best* change the game to correct the exposure, at worst figure some way to prosecute him for something or another.
1. your can allow privacy on your network (eg. different IP address for each request, so sites can't track *you* reliably, etc.)
That's just silly. At the IP layer, they lose no granularity over today (they can tell basically what house it came from from the leading 64 bits and either interpret the last bits as finer grained data or discard as noise. All this is moot as sites track *you* reliably via use of higher-layer features like authenticated sessions and/or HTTP cookies that persist regardless of originating IP.
2. no need to run DHCP - each computer can make a unique address automatically
True, but of little practical consequence for most of the world. Most of the world lived in the default private network their linksys box gave them and the DHCP was effectively equally magic as route advertising with auto-config in v6. Note I did say most of the world, some cases required end-user tweaking that won't know, but a small minority.
3. no more NAT necessity - SIP, Skype, BT, IRC, server - all work as they are suppose to work.
Nope, that ship has sailed. Sure, NAT won't be there to mess things up but firewalls will continue to break P2P by default and things like Skype and BT will continue to need 'superpeers' that will be somewhat rare still (though more prevalent than IPv4, but only slightly). If the late 90s hadn't seen so many DoS attacks using immature IP stacks and insecure services left wide open by overly trusting OS vendors (MS largely, but other vendors not blameless), maybe firewall wouldn't be considered a must-have. Now even with solid IP stacks and generally more secure defaults, poor security practices and paranoia will not magically make firewalls disappear. One of my first thoughts was that broken P2P models would be resolved as NAT goes away, but the firewalls will generally stay. I have the power to increase my reach, so it isn't bad for me, but for automagic, zero-config routers, yeah those will still be locking people up just as if they were behind a NAT gateway.
It is really silly. They should have at least given each user 4,722,366,482,869,645,213,696 addresses, 18 quintillion is being way too stingy.
Only half joking, I kind of wanted at least some headroom to segment my home network if I chose. Even a /62 would have been nice.
So first, Dell saying that is both a no-brainer (he's talking about a *competitor*, of *course* he's going to talk badly), and secondly in 97 Apple was fairly boned by all accounts and few would believe that it would recover. That was the year where everyone only began to learn that Apple+Jobs could succeed as one, but didn't fare so well individually (apple and next both tanked pretty hard).
The statement about the iPod being like the Walkman may or may not be accurate. Walkman enjoyed a *very* long position at the top, so the timeframe doesn't fall out quite just yet. It isn't likely to be accurate because of networking effects (iTunes store) and interacting with a music library being a larger area for differentiation than 'play, stop, rewind, fast forward, eject'. The suggestion of either Apple or Walkman representing a non-sustainable model did make no sense, there is nothing fundamentally less sustainable about either of those two compared to anything in technology.
Again, with netgear, they have absolutely nothing to gain from Apple's success, so they too will take every opportunity to highlight exposures. On the one hand, trashing Apple as being too subject to the whims of Jobs, on the other hand, if Jobs leaves the company could very well revisit their 90s experience.
At a glance, they have no commercial entity trying to spam it all over the news for one. For another, they too require some commercial add-on to be 100% outlook compatible. Lastly, they make no effort to use buzzowrds like 'SaaS' or 'cloud', which I suppose ties into the first point.
It might also suck, I have no idea, I don't do groupware stuff anymore so I have no reason to try it out.
The thing about Exchange competitors is unfortunately playing nice with Microsoft's monopoly which means outlook is *everywhere*. Microsoft never makes efforts to support open standards, therefore Outlook will never work well with something like citadel (sure, imap is there, but doing anything more than that requires, surprise, a commercial add-on).
The problem for groupware is not that Exchange is so fundamentally awesome beyond hope of competing on a level playing field, it's that it rides on the success of MS office.
I think your point is accurate on some open source projects on their own, but a lot of projects work quite well. The same applies to commercial products, sometimes they are solid, sometimes they are hard to use/counterintuitive, and when you have a bug, you don't even have the 'masocist' option of fix it yourself. I have had commercial vendors want to charge me a $200 incident support fee to let me send them a stack trace from their poroduct crashing without an error message. Similarly with support, we had a commercial vendor who could *not* figure out our problem with their product and some of our client systems. After 3 days of back and fourth with the vendor and figuring out nothing, I searched the mailing list of an open source competitor and they had the exact same problem and resolution, which we could translate to the commercial application and fixed in an hour what they had spent days trying to sort out.
There is great variance amongst open source and commercial software implementers. Some are consistent, some are not. Some produce quality product, others do not. Open source is not inherently worse than commercial offerings. Chasing 100% Exchange compatibility seems to draw the most questionable of the lot (both commercial and open source, with the latter usually ending up a token gesture to pull you into a 'real' commercial alternative in that space).