Do I like Yahoo? Not really. But I don't really like Google or MS either. The less of these online service providers there are, the worse it will be for consumers. I hope Yahoo continues to exist in some form or another just so there are more players in the marketplace. That means more choice, more competition and a better experience for users.
I've been with Hutch3 (in Australia) for a number of years now, and I do feel a degree of brand loyalty for a few reasons:
No service issues
Reasonable choice of handsets
Good pricing
Fast data
Intelligible contracts with no "hidden catches"
They have never changed my pricing plan, even though the plan isn't available to new customers any more
If customers don't feel loyal to their carrier, it means the carrier is doing nothing to inspire loyalty, and should re-think what they're doing. Low customer loyalty leads to high churn (customers switching away to another carrier).
Well, Jabber (as used by Google Talk) is distributed. You can log on with to any Jabber server you have an account with, and you should be able to talk to users on any other Jabber server. Google just happen to have a lot of people with accounts on their Jabber server.
Total garbage - has no error result codes! Always assumes all writes have no failures, so unplugging a firewire drive or a USB drive or eSata drive guaranteed to either kernel panic or otherwise crash the OS.
ZFS is designed to perform writes asynchronously. If the write should be able to complete, it returns success and then goes off to do it. It's a different way of thinking about a filesystem. You need to do a "zpool export" or something before you can unplug a detachable disk to avoid the panic when you unplug it. That's not a bug. It's by design.
The Finder itself is lied to.
No it isn't. You're just misunderstanding the semantics of ZFS.
This is such an amateurish implementation, I am shocked that the source was even offered.
No it isn't. It's just not a filesystem that's suitable for the masses. Average users cannot understand or manage an advanced storage pool system like ZFS. They're better off with filesystems that make sense to them, like HFS+, ext2 or NTFS.
Shame on Apple for funding this quality of work.
Shame on all the geeks for telling everyone that ZFS will solve all their problems. ZFS is great under certain circumstances. It does what it does very well, but it isn't a filesystem for the masses.
I will admit, a few years ago, DURING BOOT, linux had a similar design bug and all IDE writes during boot had no error codes returned. But this is different. This is 2008.
Just plain not reporting errors is a bug. ZFS asynchronous write semantics is intentional, although counter-intuitive, behaviour.
I know it's a joke, but you really are onto something. Back in the day, you would punch out your program on cards and send it off to the computing facility to run in the overnight batch. You'd think a lot more about getting the program right first time. If there was a bug, the best possible result was that you would submit the corrected program for the next overnight batch, and you would lose a day; but since computer time was severely limited, you might not be allowed a slot in the next batch, and you'd lose even more days waiting until you were allowed another slot.
These days, people are far too eager to jump into the debugger, or to just try running something to see if it works. This culture leads to a lot of obscure, since the program isn't designed to be correct, and examined critically in an attempt to say with reasonable confidence that it really is correct but is simply run by the developer. The whole "works for me" syndrome.
I know it's pointless arguing, but root isn't necessary to do damage. You can send plenty of spam when logged on with any user account. Spyware only needs user privileges to spy on a user. A user probably cares just as much, or even more, about their e-mail, documents, photos, etc. being damaged as they do about system files being damaged - it's easy to reinstall an OS, while photos may be irreplaceable.
Besides which, my point was that the formats are no more or less secure than their Windows equivalents, and it's just the environment that they run in that is arguably more secure.
Well it's true of the formats -.EXE is no more or less secure than an ELF binary,.COM is no more or less secure than a.out format,.CHM is no more or less secure than a tarball,.DLL is no more or less secure than ELF.so,.VBS is no more or less secure than a Perl script. The issue is whether the environment they run in is secure or not. You could argue that the execution environment that an ELF binary runs in under Solaris is more secure than the environment that a.EXE runs in under Windows, but a malicious program could still scavenge personal data send it to the "bad guys" over HTTP (which is open in most people's firewalls). Perl is definitely a lot more secure than the VBScript runtime, but that won't stop a malicious script from deleting or overwriting a user's files.
I disagree. I think the reason there are fewer pieces of malware floating around for Linux is because of the kind of roles Linux machines typically serve in. Most Linux machines are servers or enterprise workstations. In the case of a server, there will be a system administrator who is responsible for configuring the server, locking it down, and keeping it up. Chances are, they'll notice malware pretty quickly, and do something about it. Enterprise workstations aren't an attractive target, either: they're usually either a shared machine that's locked down hard, and under the eye of a sysadmin, or they're the pet of a tech-savvy user who wants his box in top condition so s/he can get stuff done.
Malware is all about money these days, whether it's herding bots so you can sell spamming services, or getting paid to DDoS someone's competitor, sniffing credit card numbers to buy stuff, or sniffing personal details for identity theft. Remember that your attack isn't 100% reliable, so you want as many potential targets as possible, and you want to attack weak targets so as to get the highest possible success rate. All so you can make as much money as possible, of course.
And what's the best target? Home Windows PCs, of course. No vigilant sysadmin monitoring the system; average Joe user doesn't grasp the concept of locking his box down, let alone have the m4d skillz to do it; Joe doesn't install patches regularly because he sees the downloads and restarts as nothing more than an annoyance; Joe doesn't really understand his computer, so he doesn't know how to look for the telltale signs of malware; Joe doesn't understand that he has to keep his virus scanner's definitions up to date, and turned off the annoying prompts; Joe doesn't understand a firewall, so he just clicks "Allow" to get rid of the warning message; the list goes on forever...
Now that MacOSX is becoming more popular, we're seeing a bit of malware for it, too. Example, that thing that claimed to be a video codec, but was really a DNS redirector. Now this one is a very good example of how malware authors target uninformed users: in the standard OSX installer program, there is an option to show the files that will be installed; if you or I (as/. geeks) looked at the files that this "codec" was installing, we would see that it couldn't be a real codec at all, and we could cancel the install; but an uninformed user won't know to look at file listings, and won't know what looks right, and what doesn't. It wasn't a failing of the OS: it was a valid installer package that prompted for authorisation to run; it was all about users who don't know how to administer a system.
Until Linux is popular in the hands of inexperienced, non-tech-savvy home users (as opposed to enterprise), it won't be an attractive target for malware authors, and we won't see its security put to the test. When it does become popular, I expect we will see Linux malware, and I expect it will be like OSX malware, in that it relies on failings of the user, rather than the system itself.
For the record, I use OSX and Solaris at home, and develop for whatever I'm paid to develop for at work (which was, until recently, Windows, Linux, Solaris and OSX - looks like it will be just Solaris soon).
Considering how few viruses run on Linux, it's not as big a deal for Linux users. However, Linux machines that deliver content to Windows users (mail servers, usenet servers, bulletin boards, etc.) are a useful application for Linux virus scanners that detect viruses for other platforms. And the big names do function in this role: Kaspersky and AVG both have products for doing just this. And there's the free ClamAV as well, of course. The Linux versions of the big name products are probably no more or less effective than the Windows versions.
That's absolute rubbish. Japanese cars are more reliable than anything coming out of the US. It's far more common to see a twenty year old Toyota than a Ford from the same year. American cars are built to look impressive, but that's about as far as it goes. The build quality is atrocious, and they aren't efficient or practical, either.
It's basically a multi-core barrel processor - it switches threads on every cycle (similar to the old Cray and CDC gear). This gives it time to fetch data while other threads are being serviced to reduce the likelihood of cache misses. This makes it ideal for highly parallel workloads, like web application servers and multi-user database servers. But the workload needs to be highly parallel for it to perform: a quad core Niagara needs at least sixteen threads to be fully utilised. It has weak floating point, too, since web application and database workloads don't usually depend heavily on this. It's pretty much useless for a typical desktop or workstation workload.
Permanently locking a handset to a single provider is anti-competitive. Suppose I sign up on a contract with and get a handset from Provider A, but half way through my contract, I realise that Provider B has a far better deal for me. Now if the handset is able to be unlocked, I can pay out my contract with Provider A and switch to Provider B without having to pay for a new handset. However, if the handset can't be unlocked, there is a significant disincentive to switching providers: not only would I have to pay out my contract, but I would also have to pay for a new handset.
Now unlocking doesn't cause problems for most of the handset manufacturers, because they just sell the handset and that's the end of it. But Apple has negotiated a ridiculous arrangement where they get some of the monthly call/data/service revenue from the providers. If you could easily unlock the iPhone and move to a different provider (or even a different plan with the same provider), Apple would lose this revenue stream. That's why they're so opposed to unlocking. (Note that while I understand the reasons for preventing unlocking, I still think it's anti-competitive and the iPhone should be unlockable.)
I don't know how they get away with the current practice, though. The EU passed laws that were supposed to crack down on anti-competitive business practices in the telecommunications sector. I understood them to mean that providers had to allow customers to buy out of contracts for no more cost than the remaining minimum payments, and were required to unlock the customers' handsets when a contract was terminated (either by expiring or by the customer buying out). Apparently the laws are toothless.
Any new OS is going to be slower than the previous one - this is easily tested by dual booting and checking for yourself - this means that unless there is a compelling reason to upgrade, WHY would anyone want to slow themselves down?
That's not true at all. Every version of Mac OS X has been faster when compared on the same hardware (yes, minimum system requirements have increased, but that's another issue). I would imagine Linux gets faster as it gets more highly optimised, too. Microsoft has just been stupid by adding all these layers of "protection" that turn the OS into molasses.
It's not like there aren't problems with Intel's CPUs - just take a look at the problems with the MMU in the Core 2 - but no-one is suggesting Intel is doomed. It would just be better if AMD had admitted this when they first knew about the issue rather than sending out review units that are known to have serious issues.
If it's a patch for the Linux kernel, which is distributed under the GPL, I don't think they can enforce an NDA. The patch may be used to create a derived work of a GPL'd product, so the derived work must also be GPL'd: so you can distribute it, as long as you include its source. This will be available for all Linux variants soon.
You consider our billing system stupid, I consider it stupid to ask *ME* to pay extra for what device someone else is using.
And should the receiver pay for a long distance call? If you don't want to pay, don't make the call. I don't want to pay for receiving unwanted calls from telemarketers. I don't want to pay to receive text messages used for verifying online transactions. I like being able to pay for a call to a pre-paid mobile service with a balance of zero. If I want to call a person and be able to reach them even if they aren't at home/work, I should have to pay for that. If I don't want to pay more, I can call them on a landline, and put up with the fact that they may not be there.
Can you keep the same landline number in different geographic regions? Didn't think so. How is that any worse than having a different number for landline or mobile? We can keep the same number when we change companies or move a landline within a local area. We can keep our mobile numbers wherever we go, on whichever company we want. The US system gives the carriers an excuse to keep the stupid receiver pays system in place.
In most countries you can tell whether a call is to a mobile or not from the number, and you can decide whether you want to pay to call a mobile. For example in Australia, mobile numbers start with 04, and in China mobile numbers start with 13. If a non-mobile number is forwarded to a mobile number, the owner of the forwarded number pays the mobile call rate (as opposed to the caller or the receiver).
Just about any phone will get you better call quality than a Sony Ericsson. They're atrocious! The best call quality you can get is from the NECs, but they have poor battery life. I'd be shocked if the iPhone didn't sound better than a Sony Ericsson.
I'm guessing you wanted me to laugh, but in a highly parallel system, going through the code line by line is often the most effective way of finding a problem. When you catch the bug on a running system, you can see the state it's got itself into. But to figure out how it could have got there, you need to read and analyse the code. People are often far too eager to jump into the debugger when critically analysing the code is often a better solution.
It obviously doesn't work in situations like this where the bug is in the runtime and not the application.
Slashdot Mirror
Do I like Yahoo? Not really. But I don't really like Google or MS either. The less of these online service providers there are, the worse it will be for consumers. I hope Yahoo continues to exist in some form or another just so there are more players in the marketplace. That means more choice, more competition and a better experience for users.
I've been with Hutch3 (in Australia) for a number of years now, and I do feel a degree of brand loyalty for a few reasons:
If customers don't feel loyal to their carrier, it means the carrier is doing nothing to inspire loyalty, and should re-think what they're doing. Low customer loyalty leads to high churn (customers switching away to another carrier).
Real geeks have XKCD, Dilbert and BOFH to amuse them among other things.
Well, Jabber (as used by Google Talk) is distributed. You can log on with to any Jabber server you have an account with, and you should be able to talk to users on any other Jabber server. Google just happen to have a lot of people with accounts on their Jabber server.
The difference is that while metrosexuals try hard to be gay, homosexuals succeed.
ZFS is designed to perform writes asynchronously. If the write should be able to complete, it returns success and then goes off to do it. It's a different way of thinking about a filesystem. You need to do a "zpool export" or something before you can unplug a detachable disk to avoid the panic when you unplug it. That's not a bug. It's by design.
No it isn't. You're just misunderstanding the semantics of ZFS.
No it isn't. It's just not a filesystem that's suitable for the masses. Average users cannot understand or manage an advanced storage pool system like ZFS. They're better off with filesystems that make sense to them, like HFS+, ext2 or NTFS.
Shame on all the geeks for telling everyone that ZFS will solve all their problems. ZFS is great under certain circumstances. It does what it does very well, but it isn't a filesystem for the masses.
Just plain not reporting errors is a bug. ZFS asynchronous write semantics is intentional, although counter-intuitive, behaviour.
If it's worldwide, why is it called the GayNigger Association of America?
I know it's a joke, but you really are onto something. Back in the day, you would punch out your program on cards and send it off to the computing facility to run in the overnight batch. You'd think a lot more about getting the program right first time. If there was a bug, the best possible result was that you would submit the corrected program for the next overnight batch, and you would lose a day; but since computer time was severely limited, you might not be allowed a slot in the next batch, and you'd lose even more days waiting until you were allowed another slot.
These days, people are far too eager to jump into the debugger, or to just try running something to see if it works. This culture leads to a lot of obscure, since the program isn't designed to be correct, and examined critically in an attempt to say with reasonable confidence that it really is correct but is simply run by the developer. The whole "works for me" syndrome.
What about the GNAA? Are they in their own cone of nonsense or do they coexist with Slashdot in its cone?
You can make calls on your Sybian? Where can I get this new model (for my wife, of course). Oh, you mean a Symbian phone. Oh well...
I know it's pointless arguing, but root isn't necessary to do damage. You can send plenty of spam when logged on with any user account. Spyware only needs user privileges to spy on a user. A user probably cares just as much, or even more, about their e-mail, documents, photos, etc. being damaged as they do about system files being damaged - it's easy to reinstall an OS, while photos may be irreplaceable.
Besides which, my point was that the formats are no more or less secure than their Windows equivalents, and it's just the environment that they run in that is arguably more secure.
Well it's true of the formats - .EXE is no more or less secure than an ELF binary, .COM is no more or less secure than a.out format, .CHM is no more or less secure than a tarball, .DLL is no more or less secure than ELF .so, .VBS is no more or less secure than a Perl script. The issue is whether the environment they run in is secure or not. You could argue that the execution environment that an ELF binary runs in under Solaris is more secure than the environment that a .EXE runs in under Windows, but a malicious program could still scavenge personal data send it to the "bad guys" over HTTP (which is open in most people's firewalls). Perl is definitely a lot more secure than the VBScript runtime, but that won't stop a malicious script from deleting or overwriting a user's files.
I disagree. I think the reason there are fewer pieces of malware floating around for Linux is because of the kind of roles Linux machines typically serve in. Most Linux machines are servers or enterprise workstations. In the case of a server, there will be a system administrator who is responsible for configuring the server, locking it down, and keeping it up. Chances are, they'll notice malware pretty quickly, and do something about it. Enterprise workstations aren't an attractive target, either: they're usually either a shared machine that's locked down hard, and under the eye of a sysadmin, or they're the pet of a tech-savvy user who wants his box in top condition so s/he can get stuff done.
/. geeks) looked at the files that this "codec" was installing, we would see that it couldn't be a real codec at all, and we could cancel the install; but an uninformed user won't know to look at file listings, and won't know what looks right, and what doesn't. It wasn't a failing of the OS: it was a valid installer package that prompted for authorisation to run; it was all about users who don't know how to administer a system.
Malware is all about money these days, whether it's herding bots so you can sell spamming services, or getting paid to DDoS someone's competitor, sniffing credit card numbers to buy stuff, or sniffing personal details for identity theft. Remember that your attack isn't 100% reliable, so you want as many potential targets as possible, and you want to attack weak targets so as to get the highest possible success rate. All so you can make as much money as possible, of course.
And what's the best target? Home Windows PCs, of course. No vigilant sysadmin monitoring the system; average Joe user doesn't grasp the concept of locking his box down, let alone have the m4d skillz to do it; Joe doesn't install patches regularly because he sees the downloads and restarts as nothing more than an annoyance; Joe doesn't really understand his computer, so he doesn't know how to look for the telltale signs of malware; Joe doesn't understand that he has to keep his virus scanner's definitions up to date, and turned off the annoying prompts; Joe doesn't understand a firewall, so he just clicks "Allow" to get rid of the warning message; the list goes on forever...
Now that MacOSX is becoming more popular, we're seeing a bit of malware for it, too. Example, that thing that claimed to be a video codec, but was really a DNS redirector. Now this one is a very good example of how malware authors target uninformed users: in the standard OSX installer program, there is an option to show the files that will be installed; if you or I (as
Until Linux is popular in the hands of inexperienced, non-tech-savvy home users (as opposed to enterprise), it won't be an attractive target for malware authors, and we won't see its security put to the test. When it does become popular, I expect we will see Linux malware, and I expect it will be like OSX malware, in that it relies on failings of the user, rather than the system itself.
For the record, I use OSX and Solaris at home, and develop for whatever I'm paid to develop for at work (which was, until recently, Windows, Linux, Solaris and OSX - looks like it will be just Solaris soon).
Considering how few viruses run on Linux, it's not as big a deal for Linux users. However, Linux machines that deliver content to Windows users (mail servers, usenet servers, bulletin boards, etc.) are a useful application for Linux virus scanners that detect viruses for other platforms. And the big names do function in this role: Kaspersky and AVG both have products for doing just this. And there's the free ClamAV as well, of course. The Linux versions of the big name products are probably no more or less effective than the Windows versions.
That's absolute rubbish. Japanese cars are more reliable than anything coming out of the US. It's far more common to see a twenty year old Toyota than a Ford from the same year. American cars are built to look impressive, but that's about as far as it goes. The build quality is atrocious, and they aren't efficient or practical, either.
It's basically a multi-core barrel processor - it switches threads on every cycle (similar to the old Cray and CDC gear). This gives it time to fetch data while other threads are being serviced to reduce the likelihood of cache misses. This makes it ideal for highly parallel workloads, like web application servers and multi-user database servers. But the workload needs to be highly parallel for it to perform: a quad core Niagara needs at least sixteen threads to be fully utilised. It has weak floating point, too, since web application and database workloads don't usually depend heavily on this. It's pretty much useless for a typical desktop or workstation workload.
Permanently locking a handset to a single provider is anti-competitive. Suppose I sign up on a contract with and get a handset from Provider A, but half way through my contract, I realise that Provider B has a far better deal for me. Now if the handset is able to be unlocked, I can pay out my contract with Provider A and switch to Provider B without having to pay for a new handset. However, if the handset can't be unlocked, there is a significant disincentive to switching providers: not only would I have to pay out my contract, but I would also have to pay for a new handset.
Now unlocking doesn't cause problems for most of the handset manufacturers, because they just sell the handset and that's the end of it. But Apple has negotiated a ridiculous arrangement where they get some of the monthly call/data/service revenue from the providers. If you could easily unlock the iPhone and move to a different provider (or even a different plan with the same provider), Apple would lose this revenue stream. That's why they're so opposed to unlocking. (Note that while I understand the reasons for preventing unlocking, I still think it's anti-competitive and the iPhone should be unlockable.)
I don't know how they get away with the current practice, though. The EU passed laws that were supposed to crack down on anti-competitive business practices in the telecommunications sector. I understood them to mean that providers had to allow customers to buy out of contracts for no more cost than the remaining minimum payments, and were required to unlock the customers' handsets when a contract was terminated (either by expiring or by the customer buying out). Apparently the laws are toothless.
That's not true at all. Every version of Mac OS X has been faster when compared on the same hardware (yes, minimum system requirements have increased, but that's another issue). I would imagine Linux gets faster as it gets more highly optimised, too. Microsoft has just been stupid by adding all these layers of "protection" that turn the OS into molasses.
It's not like there aren't problems with Intel's CPUs - just take a look at the problems with the MMU in the Core 2 - but no-one is suggesting Intel is doomed. It would just be better if AMD had admitted this when they first knew about the issue rather than sending out review units that are known to have serious issues.
If it's a patch for the Linux kernel, which is distributed under the GPL, I don't think they can enforce an NDA. The patch may be used to create a derived work of a GPL'd product, so the derived work must also be GPL'd: so you can distribute it, as long as you include its source. This will be available for all Linux variants soon.
And should the receiver pay for a long distance call? If you don't want to pay, don't make the call. I don't want to pay for receiving unwanted calls from telemarketers. I don't want to pay to receive text messages used for verifying online transactions. I like being able to pay for a call to a pre-paid mobile service with a balance of zero. If I want to call a person and be able to reach them even if they aren't at home/work, I should have to pay for that. If I don't want to pay more, I can call them on a landline, and put up with the fact that they may not be there.
Can you keep the same landline number in different geographic regions? Didn't think so. How is that any worse than having a different number for landline or mobile? We can keep the same number when we change companies or move a landline within a local area. We can keep our mobile numbers wherever we go, on whichever company we want. The US system gives the carriers an excuse to keep the stupid receiver pays system in place.
In most countries you can tell whether a call is to a mobile or not from the number, and you can decide whether you want to pay to call a mobile. For example in Australia, mobile numbers start with 04, and in China mobile numbers start with 13. If a non-mobile number is forwarded to a mobile number, the owner of the forwarded number pays the mobile call rate (as opposed to the caller or the receiver).
Just about any phone will get you better call quality than a Sony Ericsson. They're atrocious! The best call quality you can get is from the NECs, but they have poor battery life. I'd be shocked if the iPhone didn't sound better than a Sony Ericsson.
I'm guessing you wanted me to laugh, but in a highly parallel system, going through the code line by line is often the most effective way of finding a problem. When you catch the bug on a running system, you can see the state it's got itself into. But to figure out how it could have got there, you need to read and analyse the code. People are often far too eager to jump into the debugger when critically analysing the code is often a better solution.
It obviously doesn't work in situations like this where the bug is in the runtime and not the application.