There's quite a few ways to get rid of Wi-Fi geeks:
Firstly, open the curtains, turn on the lights, and turn the aircon up above 20 degrees C. Do this every hour on the hour and the shop will clear to cries of "Nooooo, the Day Star!"
Alternatively, confuse them by putting herbal sleep powder in the coffee and cola. They'll feel more drowsy, so buy more cola and coffee. Problem solved. Every few purchases, give them one infused with Penguin Mints (for added caffeine)
Firstly, most VoIP architectures currently look to SIP proxies for segmentation between the operator's network and the user agent or equipment. A SIP proxy is basically just an application-layer gateway. This type of software is being incorporated in to many of the forthcoming customer premises equipment. Therefore, if your application layer gateway is at the edge of your network, proxying incoming and outgoing SIP requests, what does having end-to-end IPv6 buy you?
Secondly, despite evidence of a shortage of IPv4 addresses, there is some confusion over what this really means. There is a shortage of AVAILABLE IPv4 addresses. This is distinctly different from having a shortage of UNALLOCATED IPv4 addresses. Basically, many telcos, ISPs and large institutions are sitting on some very large blocks of address space. This address space was handed out readily in the 1990s because demand (i.e the dotcom boom) wasn't anticipated. Due to certain organisations receiving such large allocations, there was little or no control over how this resource was allocated to their networks. The result of this is highly wasteful allocation, some still using classful addressing (so summarising subnets on classful boundaries such as 255.255.255.0 or 255.255.0.0,/24 or/16). A similar problem exists where organisations have gradually learned about HOW to allocated public address space. In some cases, large portions of significant allocated blocks are wasted on infrastructure, customer link connections and some other, unnecessarily wasteful applications.
Many of these places could actually go back over their allocated address ranges and re-claim huge chunks. All it requires is a motivation to do so and the time and resource to plan and execute it. At the moment, the motivation is rarely there and organisations would generally prioiritise such activity at the bottom of a long list of things to do.
The problem arises when they are required to demonstrate to their regional registrar that they have sensibly used their current allocations in order to obtain new blocks of unassigned space. Generally, this is when you will hear the cries of "Oh no, the Internet is running low on available IPv4 space! Panic!".
Finally, your worm theory is just wrong. Yes, it decreases the probability of hitting an exploitable host, but it increases the depth to which the worm can scan. What I mean by this is that the worm will be able to scan in to people's private networks if NAT and firewalling are not used. If rules are not explicitly put in place to protect your home IPv6 LAN, then worms will be able to scan all hosts from the outside.
How many people put up a NAT/PAT box or a firewall, and then think they're perfectly safe from the outside? Most networks conform to the Twinkie theory -- crunchie on the outside and soft and squidgy in the middle. Chances are that an IPv6 home lan would be totally unprotected once on the inside. If this inside is exposed to the Internet then the chances of remote exploitation increase dramatically in my opinion.
Yes, NAT can break some application protocols such as H.323 (among others), and does require a NAT/PAT device, ideally with some sort of packet filtering of stateful firewalling ability, but it does provide some basic security.
With end to end publically addressable space being used, the ability to portscan for exploits not only extends from ISP access network to ISP access network, but also in to what should be private LANs. LANs in your home and your place of work.
If people continue to want security in an IPv6 world, then firewalling will still be required at the edge of such private networks. The private nets won't have private addressing any more, so rules will be required to filter access to/from those assigned v6 addresses.
So if you've still got your firewall at the edge of your private network, why not continue to NAT at the same time? If that's the case, why bother with v6 at all unless there are significant application or service drivers?
It just sounds like another "project" that will be adopted by a computer science student, and duly abandoned after (s)he finishes final year and begins paid employment.
If you really want to contribute, get involved in the calendar (iCal) working group in the IETF, as mentioned elsewhere in this thread. At least then, when you stop having enough time to contribute, your effort and work won't be lost or just gather dust before becoming another abandoned project.
And this is precisely the reason why people should (myself included) support groups like 2600 (http://www.2600.com/ with their excellent Off The Hook show. Yes, you can download it, but shows like this (by hackers for hackers) deserve financial support more than the latest over-marketed, over-hyped, *wood "blockbuster".
The same applies to video games too. Why buy the latest generic release from EA, when you can buy some innovative, lovingly crafted, software from guys like Introversion (http://www.introversion.co.uk./
Support the niches and eventually, it will change the mainstream.
I used to use a Psion series 3 (http://www.psion.com/) as a portable PDA/word processor. In fact, when I was at university, I wrote entire chapters of my projects on it while in a coffee bar or any area away from the network. It was portable, had a usable keyboard once you got used to it, and had some great applications. PC connectivity was over serial and I just dumped all my edits in plain text and imported them later to whatever app I was using on the desktop system.
One good thing was that I was using LaTeX at the time, and just marked up the text appropriately. Therefore, when it was dumped to my Linux desktop, I could just build the LaTeX and it was ready formatted.
The Series 5 was a good step forwards from the 3, with more power, better screen, stylus input etc. There's some info on it over at Geek.com: http://www.geek.com/hwswrev/pda/psionser5.htm.
If you can pick one up off Ebay, there's a great user community still there. Cheap now, too.
I run an Epia 5000 system in a basic case with a large-ish HDD and an external USB2.0 HDD. This system acts as a fileserver for my LAN and a backup system so that I can dump stuff to the external HDD.
It was a cheap system to put together and really just works (with Debian GNU/Linux on there).
I would make the same decision if I was doing it again. Firstly, you can use 3.5" HDD internally, so you get some performance and size benefits. The Mini is just 2.5" and has slot internal drives. The external option is there in both systems.
If nothing else, I don't see the point in buying a Mini with a license for probably the best desktop operating system out there and then using it as a headless station running Linux. Unless you can sell the OS X license and software to recoup some of the cost that is.
As for installing Linux on a Mini to use on the desktop, that's just crazy talk.
But in order for Azureus to form this 'one single giant P2P network', there must be some first point of contact. In the case of Azureus, is this achieved with some hard-coded nodes that the Azureus developers maintain? If so, we're no further along than with the more traditional, managed, P2P overlay nets.
Removing the need for an initial point of contact from an individual torrent is a good thing. Making it a search function in to an overlay P2P network is just moving the problem elsewhere though.
Saying this, I can't see a solution because it's chicken + egg.
Maybe my understanding of how this works is wrong, but perhaps it makes a torrent more vulnerable, at least with regard to new joins.
With a trackerless torrent, it appears as though the original seed needs to be encoded in to the.torrent file. If this is the case then anyone joining the torrent will need to contact the seed in order to begin obtaining hashes of swarm members.
Now, it may be almost impossible to DoS the "tracker" of the torrent, given that it's distributed, but it's certainly not impossible to DoS the Seed of the torrent. The Seed is probably more vulnerable than a traditional tracker, given that it's probably running from someone's DSL connection. All the eggs are also in one basket, with the first point of contact and the file's Seed being one and the same.
So, DoS the Seed of the torrent and you prevent any new joins to the swarm and also hinder/stop distribution from the Seed if there are no other Seeds in the swarm.
I had problems connecting to my Samba server running on Debian when I first installed 10.4.
It appears as though 10.4 requires the password exchange to be encrypted, so in the smb.conf file:
; encrypt passwords = false
(note the semi colon).
I used to run plaintext passwords with 10.3 for some reason. I think it was because 10.3 didn't like encrypted password exchange with Samba, but I may be mistaken (poor memory).
"I go to a convenience store and take one of the free samples of diet coke that are being given away in a marketing promotion. I like the coke so much that I go back the next day and buy some. I also tell many of my friends that this new diet coke is good, so they best go get some."
Almost as scary as an "invisible" keystroke logger or spotlight hijacker is the possibility of your Dashboard becoming a battleground for full-screen adverts from auto-installed ad-widgets. Close the widget and it auto-starts a secondary one in its place. Rinse and repeat.
I first started using OS X in the early days of 10.2 (yes, a relative latecomer). This was when my wife bought an iBook (after some *ahem* guidance... read encouragement) for studies she was undertaking. When she wasn't working on it, I got to play and set to work integrating it with our home network.
The pain I had getting SMB to perform acceptably under 10.2 nearly put me off OS X. Basically, the way that 10.2 handled mounting network filesystems really sucked. It was unreliable and often left the system hanging with a spinning beachball (the Mac equivalent of an egg timer). Often, powering off was the only solution.
This was fortunately fixed later on in the 10.2 lifecycle with some networking updates. Things got much better from then on.
When I got my own iBook several months later, it arrived with 10.3. This release seemed to have a reasonably good SMB implementation, but the performance was truly sucky. File transfer speeds between the iBooks and my Linux-based Samba server were low, but at least mounting was reliable.
As 10.3 progressed, this problem went away and performance/reliability are currently both very good. It means I can use SMB between my Linux server and both iBook and Windows XP clients. All works just fine.
I am, however, considering a move to WebDAV for file sharing on the network. WebDAV is a nicely lightweight protocol and has the benefit of being an open standard. Most good implementations are open source too. There are also client libraries for most decent scripting/programming languages. The added benefit is that you can integrate the WebDAV server in to OS X to perform iSync backups of your system and do calendar sharing etc. All nice, geeky, stuff.
The only major problem I can see at the moment is that the way the WebDAV server interacts with the underlying filesystem is a bit complex, given that my server runs under Apache. The model it appears to assume is that the server will have a dedicated directory or area for WebDAV files, and not simply share out a user's home directory or a backup drive.
From what I have read, it does seem to affect some users and not others. There is an extensive thread on it over at Apple's discussion forum. For what it's worth, I'm using Dovecot for my IMAP server.
Since Apple broke IMAPS support in the 10.3.9 release, it would have been nice to see a fix in this patch.
Basically, the problem is that if you use Mail.app to access a remote IMAPS server, you may experience problems synchronising your mailbox. My symptoms are that the synchronisation starts but even though the subject lines appear in the list, the connection does not seem to download the message body and close down successfully. It can take several minutes/hours for it to complete, if at all.
In the interim, I'm using Thunderbird on OS X, which is OK given that I use IMAP anyway, but it's far from ideal.
There are two sides to any new console launch and the purchasing decision.
Firstly, and the one that probably influences the vast majority of less professional reviews (such as this one in my opinion), is the WOW factor. This is that burning desire to own the latest, greatest, most powerful, coolest, piece of gaming kit. The excitement and anticipation of getting hold of that highly powerful and sleek piece of hardware is a very very strong pull.
However, now we need to look at the other side. Once the novelty of having this rather expensive toy has started to wear off, it really comes down to what software is available to run on it. It's quite rare that any new console has very high quality titles available at launch that will still be classed as "classics" in 12 months' time. Generally, they're a bit rushed in order to meet launch deadlines and based on limited experience with development equipment and console hardware.
So you may have this nice, new, slick, piece of harware, but at the end of the day, it's all about the games. I can guarantee (because I've been there myself several times) that once the novelty of having the hardware has worn off, unless the games are there to actually engage you and keep you playing, it's a bad purchase.
The best thing to do, in my opinion, is to look at the launch schedules for both consoles. Look at which titles, coming out over the next six months, you actually want to play. If there's a good handful of titles for a given console, then it's probably worth buying. Otherwise, I can guarantee that it'll end up sitting there gathering dust, or get traded in for the next big thing.
I've also done this recently. I did consider paying for a.Mac account, but the only value I'd get out of it (being a technical person who runs his own SMTP/IMAP/HTTP etc. services elsewhere), would be the calendar publishing and backup services. I didn't think these were worth the money, especially given the space restrictions in iBackup on.Mac. Saying this, iBackup is a very nice tool and can do backups to local network shares, CD/DVD etc. so it's not just for use with.Mac.
So I looked at putting together my own alternatives for the.Mac services I thought I would use. First on the list was the calendar sharing. It was easier than I thought to set up mod_dav for Apache. iCal then just published seamlessly to my WebDav service. I also get the added benefit of being able to use the WebDav service to do online backups, which OSX uses without blinking.
I did try to use my WebDav service with Windows XP, but there is a known problem with XP regarding its use of "online folders", i.e. WebDav services. The problem seen with Apache is that XP sends Domain/Username & Password authentication, whereas Apache's mod_dav only wants Username & Password. There is a patch to "fix" this, but personally I drew the line at patching my service to make it work with a broken implementation.
In terms of an iBackup replacement, I've been looking at a few packages. RSyncX seems quite good and popular, as does Impression. However, seeing as though OSX is so nicely Unix-based, I may well use something like Flexbackup or my own scripts based on backup/restore (the BSD tools) or rsync.
I would be the first to say that the core Mozilla engine has come on in leaps and bounds over the past few years. Yes, the project has had ups and downs, but has eventually delivered a fantastic browser engine.
However, as an end user, I don't have the time|inclination to sift through several variants of a browser (some of which seem identical to a non-clued-up end user).
How about a single distribution package that just does a modular installation (or even use a custom network installer that just downloads the necessary components). The components for installation, including whatever GUI shell you would like, plug-in support etc, could all be selected from a simple checkbox GUI. The installer app could then just go an grab the components (or even the appropriate fork distribution as a first attempt) from the Mozilla site.
This way, we just get Mozilla, not have to decide which of several variants are appropriate.
Slashdot Mirror
There's quite a few ways to get rid of Wi-Fi geeks:
Firstly, open the curtains, turn on the lights, and turn the aircon up above 20 degrees C. Do this every hour on the hour and the shop will clear to cries of "Nooooo, the Day Star!"
Alternatively, confuse them by putting herbal sleep powder in the coffee and cola. They'll feel more drowsy, so buy more cola and coffee. Problem solved. Every few purchases, give them one infused with Penguin Mints (for added caffeine)
I have to disagree.
/24 or /16). A similar problem exists where organisations have gradually learned about HOW to allocated public address space. In some cases, large portions of significant allocated blocks are wasted on infrastructure, customer link connections and some other, unnecessarily wasteful applications.
Firstly, most VoIP architectures currently look to SIP proxies for segmentation between the operator's network and the user agent or equipment. A SIP proxy is basically just an application-layer gateway. This type of software is being incorporated in to many of the forthcoming customer premises equipment. Therefore, if your application layer gateway is at the edge of your network, proxying incoming and outgoing SIP requests, what does having end-to-end IPv6 buy you?
Secondly, despite evidence of a shortage of IPv4 addresses, there is some confusion over what this really means. There is a shortage of AVAILABLE IPv4 addresses. This is distinctly different from having a shortage of UNALLOCATED IPv4 addresses. Basically, many telcos, ISPs and large institutions are sitting on some very large blocks of address space. This address space was handed out readily in the 1990s because demand (i.e the dotcom boom) wasn't anticipated.
Due to certain organisations receiving such large allocations, there was little or no control over how this resource was allocated to their networks. The result of this is highly wasteful allocation, some still using classful addressing (so summarising subnets on classful boundaries such as 255.255.255.0 or 255.255.0.0,
Many of these places could actually go back over their allocated address ranges and re-claim huge chunks. All it requires is a motivation to do so and the time and resource to plan and execute it. At the moment, the motivation is rarely there and organisations would generally prioiritise such activity at the bottom of a long list of things to do.
The problem arises when they are required to demonstrate to their regional registrar that they have sensibly used their current allocations in order to obtain new blocks of unassigned space. Generally, this is when you will hear the cries of "Oh no, the Internet is running low on available IPv4 space! Panic!".
Finally, your worm theory is just wrong. Yes, it decreases the probability of hitting an exploitable host, but it increases the depth to which the worm can scan. What I mean by this is that the worm will be able to scan in to people's private networks if NAT and firewalling are not used. If rules are not explicitly put in place to protect your home IPv6 LAN, then worms will be able to scan all hosts from the outside.
How many people put up a NAT/PAT box or a firewall, and then think they're perfectly safe from the outside? Most networks conform to the Twinkie theory -- crunchie on the outside and soft and squidgy in the middle. Chances are that an IPv6 home lan would be totally unprotected once on the inside. If this inside is exposed to the Internet then the chances of remote exploitation increase dramatically in my opinion.
This is a very good point.
Yes, NAT can break some application protocols such as H.323 (among others), and does require a NAT/PAT device, ideally with some sort of packet filtering of stateful firewalling ability, but it does provide some basic security.
With end to end publically addressable space being used, the ability to portscan for exploits not only extends from ISP access network to ISP access network, but also in to what should be private LANs. LANs in your home and your place of work.
If people continue to want security in an IPv6 world, then firewalling will still be required at the edge of such private networks. The private nets won't have private addressing any more, so rules will be required to filter access to/from those assigned v6 addresses.
So if you've still got your firewall at the edge of your private network, why not continue to NAT at the same time? If that's the case, why bother with v6 at all unless there are significant application or service drivers?
It just sounds like another "project" that will be adopted by a computer science student, and duly abandoned after (s)he finishes final year and begins paid employment.
If you really want to contribute, get involved in the calendar (iCal) working group in the IETF, as mentioned elsewhere in this thread. At least then, when you stop having enough time to contribute, your effort and work won't be lost or just gather dust before becoming another abandoned project.
And this is precisely the reason why people should (myself included) support groups like 2600 (http://www.2600.com/ with their excellent Off The Hook show. Yes, you can download it, but shows like this (by hackers for hackers) deserve financial support more than the latest over-marketed, over-hyped, *wood "blockbuster".
The same applies to video games too. Why buy the latest generic release from EA, when you can buy some innovative, lovingly crafted, software from guys like Introversion (http://www.introversion.co.uk./
Support the niches and eventually, it will change the mainstream.
I used to use a Psion series 3 (http://www.psion.com/) as a portable PDA/word processor. In fact, when I was at university, I wrote entire chapters of my projects on it while in a coffee bar or any area away from the network. It was portable, had a usable keyboard once you got used to it, and had some great applications. PC connectivity was over serial and I just dumped all my edits in plain text and imported them later to whatever app I was using on the desktop system.
One good thing was that I was using LaTeX at the time, and just marked up the text appropriately. Therefore, when it was dumped to my Linux desktop, I could just build the LaTeX and it was ready formatted.
The Series 5 was a good step forwards from the 3, with more power, better screen, stylus input etc. There's some info on it over at Geek.com: http://www.geek.com/hwswrev/pda/psionser5.htm.
If you can pick one up off Ebay, there's a great user community still there. Cheap now, too.
I run an Epia 5000 system in a basic case with a large-ish HDD and an external USB2.0 HDD. This system acts as a fileserver for my LAN and a backup system so that I can dump stuff to the external HDD.
It was a cheap system to put together and really just works (with Debian GNU/Linux on there).
I would make the same decision if I was doing it again. Firstly, you can use 3.5" HDD internally, so you get some performance and size benefits. The Mini is just 2.5" and has slot internal drives. The external option is there in both systems.
If nothing else, I don't see the point in buying a Mini with a license for probably the best desktop operating system out there and then using it as a headless station running Linux. Unless you can sell the OS X license and software to recoup some of the cost that is.
As for installing Linux on a Mini to use on the desktop, that's just crazy talk.
But in order for Azureus to form this 'one single giant P2P network', there must be some first point of contact. In the case of Azureus, is this achieved with some hard-coded nodes that the Azureus developers maintain? If so, we're no further along than with the more traditional, managed, P2P overlay nets.
Removing the need for an initial point of contact from an individual torrent is a good thing. Making it a search function in to an overlay P2P network is just moving the problem elsewhere though.
Saying this, I can't see a solution because it's chicken + egg.
Maybe my understanding of how this works is wrong, but perhaps it makes a torrent more vulnerable, at least with regard to new joins.
.torrent file. If this is the case then anyone joining the torrent will need to contact the seed in order to begin obtaining hashes of swarm members.
With a trackerless torrent, it appears as though the original seed needs to be encoded in to the
Now, it may be almost impossible to DoS the "tracker" of the torrent, given that it's distributed, but it's certainly not impossible to DoS the Seed of the torrent. The Seed is probably more vulnerable than a traditional tracker, given that it's probably running from someone's DSL connection. All the eggs are also in one basket, with the first point of contact and the file's Seed being one and the same.
So, DoS the Seed of the torrent and you prevent any new joins to the swarm and also hinder/stop distribution from the Seed if there are no other Seeds in the swarm.
Or am I wrong?
So the initial seed of a torrent is still named in the .torrent file? (be it hashed or obfuscated)
I had problems connecting to my Samba server running on Debian when I first installed 10.4.
It appears as though 10.4 requires the password exchange to be encrypted, so in the smb.conf file:
; encrypt passwords = false
(note the semi colon).
I used to run plaintext passwords with 10.3 for some reason. I think it was because 10.3 didn't like encrypted password exchange with Samba, but I may be mistaken (poor memory).
After Theo's latest public outburst on the IETF's TCP Maintenance list (http://www1.ietf.org/mail-archive/web/tcpm/curren t/msg01233.html), there are a few things that could be addressed at the Hackathon.
Ssshhh already. Us geeks won't be able to use the "but I have no time for exercise in my busy work schedule" any more.
I wonder what a website (and associated server/network tin) looks like when it's Slashdotted at the speed of light?
Now think about:
"I go to a convenience store and take one of the free samples of diet coke that are being given away in a marketing promotion. I like the coke so much that I go back the next day and buy some. I also tell many of my friends that this new diet coke is good, so they best go get some."
Ring any bells?
Almost as scary as an "invisible" keystroke logger or spotlight hijacker is the possibility of your Dashboard becoming a battleground for full-screen adverts from auto-installed ad-widgets. Close the widget and it auto-starts a secondary one in its place. Rinse and repeat.
Glad I've stuck with 10.3 for now.
I first started using OS X in the early days of 10.2 (yes, a relative latecomer). This was when my wife bought an iBook (after some *ahem* guidance... read encouragement) for studies she was undertaking. When she wasn't working on it, I got to play and set to work integrating it with our home network.
The pain I had getting SMB to perform acceptably under 10.2 nearly put me off OS X. Basically, the way that 10.2 handled mounting network filesystems really sucked. It was unreliable and often left the system hanging with a spinning beachball (the Mac equivalent of an egg timer). Often, powering off was the only solution.
This was fortunately fixed later on in the 10.2 lifecycle with some networking updates. Things got much better from then on.
When I got my own iBook several months later, it arrived with 10.3. This release seemed to have a reasonably good SMB implementation, but the performance was truly sucky. File transfer speeds between the iBooks and my Linux-based Samba server were low, but at least mounting was reliable.
As 10.3 progressed, this problem went away and performance/reliability are currently both very good. It means I can use SMB between my Linux server and both iBook and Windows XP clients. All works just fine.
I am, however, considering a move to WebDAV for file sharing on the network. WebDAV is a nicely lightweight protocol and has the benefit of being an open standard. Most good implementations are open source too. There are also client libraries for most decent scripting/programming languages. The added benefit is that you can integrate the WebDAV server in to OS X to perform iSync backups of your system and do calendar sharing etc. All nice, geeky, stuff.
The only major problem I can see at the moment is that the way the WebDAV server interacts with the underlying filesystem is a bit complex, given that my server runs under Apache. The model it appears to assume is that the server will have a dedicated directory or area for WebDAV files, and not simply share out a user's home directory or a backup drive.
I do need to go and RTFM, however.
From what I have read, it does seem to affect some users and not others. There is an extensive thread on it over at Apple's discussion forum. For what it's worth, I'm using Dovecot for my IMAP server.
Since Apple broke IMAPS support in the 10.3.9 release, it would have been nice to see a fix in this patch.
Basically, the problem is that if you use Mail.app to access a remote IMAPS server, you may experience problems synchronising your mailbox. My symptoms are that the synchronisation starts but even though the subject lines appear in the list, the connection does not seem to download the message body and close down successfully. It can take several minutes/hours for it to complete, if at all.
In the interim, I'm using Thunderbird on OS X, which is OK given that I use IMAP anyway, but it's far from ideal.
Come on Apple, fix Mail.app!
and provide local maps for local people?
But that's why there's a new Gameboy in development right now. The DS is not a Gameboy replacement.
Firstly, and the one that probably influences the vast majority of less professional reviews (such as this one in my opinion), is the WOW factor. This is that burning desire to own the latest, greatest, most powerful, coolest, piece of gaming kit. The excitement and anticipation of getting hold of that highly powerful and sleek piece of hardware is a very very strong pull.
However, now we need to look at the other side. Once the novelty of having this rather expensive toy has started to wear off, it really comes down to what software is available to run on it. It's quite rare that any new console has very high quality titles available at launch that will still be classed as "classics" in 12 months' time. Generally, they're a bit rushed in order to meet launch deadlines and based on limited experience with development equipment and console hardware.
So you may have this nice, new, slick, piece of harware, but at the end of the day, it's all about the games. I can guarantee (because I've been there myself several times) that once the novelty of having the hardware has worn off, unless the games are there to actually engage you and keep you playing, it's a bad purchase.
The best thing to do, in my opinion, is to look at the launch schedules for both consoles. Look at which titles, coming out over the next six months, you actually want to play. If there's a good handful of titles for a given console, then it's probably worth buying. Otherwise, I can guarantee that it'll end up sitting there gathering dust, or get traded in for the next big thing.
We're getting off-topic here, but does anyone have recommendations for backup tools in this case?
A good explanation related to the parent post can be found at: this URL.
I've also done this recently. I did consider paying for a .Mac account, but the only value I'd get out of it (being a technical person who runs his own SMTP/IMAP/HTTP etc. services elsewhere), would be the calendar publishing and backup services. I didn't think these were worth the money, especially given the space restrictions in iBackup on .Mac. Saying this, iBackup is a very nice tool and can do backups to local network shares, CD/DVD etc. so it's not just for use with .Mac.
So I looked at putting together my own alternatives for the .Mac services I thought I would use. First on the list was the calendar sharing. It was easier than I thought to set up mod_dav for Apache. iCal then just published seamlessly to my WebDav service. I also get the added benefit of being able to use the WebDav service to do online backups, which OSX uses without blinking.
I did try to use my WebDav service with Windows XP, but there is a known problem with XP regarding its use of "online folders", i.e. WebDav services. The problem seen with Apache is that XP sends Domain/Username & Password authentication, whereas Apache's mod_dav only wants Username & Password. There is a patch to "fix" this, but personally I drew the line at patching my service to make it work with a broken implementation.
In terms of an iBackup replacement, I've been looking at a few packages. RSyncX seems quite good and popular, as does Impression. However, seeing as though OSX is so nicely Unix-based, I may well use something like Flexbackup or my own scripts based on backup/restore (the BSD tools) or rsync.
I would be the first to say that the core Mozilla engine has come on in leaps and bounds over the past few years. Yes, the project has had ups and downs, but has eventually delivered a fantastic browser engine. However, as an end user, I don't have the time|inclination to sift through several variants of a browser (some of which seem identical to a non-clued-up end user). How about a single distribution package that just does a modular installation (or even use a custom network installer that just downloads the necessary components). The components for installation, including whatever GUI shell you would like, plug-in support etc, could all be selected from a simple checkbox GUI. The installer app could then just go an grab the components (or even the appropriate fork distribution as a first attempt) from the Mozilla site. This way, we just get Mozilla, not have to decide which of several variants are appropriate.