Students not taking A-Level mathematics (or "maths", over here in the UK) is nothing new, typically it was the preserve of those who had a natural aptitude for it, rather than based on the requirements of a degree they might want to study.
This isn't ideal, obviously, but it's been this way (in England & Wales: the Scottish and Northern Irish education systems are quite different, and I don't know how popular Higher Maths is in Scotland) for at least 15 years, probably longer.
And yet none of those remotely-vulnerable services are enabled by default. Indeed, of the three, two of them wouldn't get switched on by the vast majority of Mac users.
Which is somewhat different to, say, the.ANI vulnerability.
Yeah, 'cos patched local privilege escalation vulnerabilities that nobody has bothered to exploit is exactly the same as unpatched remote code-execution vulnerabilities affecting a default installation for which exploits are widely circulated in the wild for nefarious purposes.
If you think the two are the same, it's no wonder you think they're all fanboys.
Generally when they say 'secure' they mean 'susceptible to attack'.
Windows is, in its default configuration. FreeBSD, Linux and Mac OS X (not to mention a fair few others) aren't.
Some local privilege escalations that nobody beyond a couple of security researchers have paid attention to is nothing compared to the stuff a Windows user has to put up with.
For average Joe on the street who connects his computer to the Internet and browses the web and so forth, the vulnerabilities mean approximately squat.
Use Public Domain if you don't care what people do with your code.
Use the MIT or X11 license if you want to give it as much chance as possible of being used by as many people as possible, without them being able to pass your code off as theirs.
The BSD (3-clause) license goes further by preventing other people from using you to endorse their products without your permission.
The LGPL ensures that the code will remain 'open' (i.e., distributing altered binaries means you have to distribute the matching sources). The LGPL specifically allows your code to be linked with, but not included in, non-LGPL projects. If your code isn't a library (or included in one), the LGPL isn't hugely different from the GPL, although releasing a program under the LGPL would mean somebody could turn it (or portions of it) into an LGPL-licensed library without any hassle.
The GPL is much the same as the LGPL, but doesn't contain any such provision for linking, so people linking with your code (if it's a library) had better make sure their do their homework first.
The GPL-compatible licenses (which includes PD, MIT/X11 and BSD) are so-called because they don't contain any restrictions beyond those included in the GPL. This means that your code, if released under a GPL-compatible license, can be legally be included in a GPL-licensed work: your code as you originally released it is still under the license you originally used, but the modifications and the derived work could be GPL'd.
Generally, the BSD license is a safe bet if you don't feel passionately about making sure that people who use your code must make their changes available to anybody who wants them, otherwise pick the LGPL or GPL depending on circumstance and requirements.
Avoid non-GPL-compatible licenses, especially home-grown ones: they usually end up doing nothing but preventing people who might want to use your code from doing so. Unless you're a huge multinational company, it's a sure-fire way to ensure that relatively few people will bother with what you've released (in which case, what was the point in releasing it?), and even then it'll stymie adoption.
It doesn't, though: that's the big problem with IE.
IE7 is a lot better than IE6 in this respect, but even in 'Standards compliant' mode, it still differs from what the specs say the behaviour should be, and what real standards-compliant UAs do.
I can't stress enough how much better IE7 is, though. Our IE7-specific stylesheets are typically a few lines long, as opposed to the pages required for IE6, and our internal stats show IE7 and IE6 have about a 50/50 split on IE's marketshare for our clients' visitors, so IE6 is, thankfully, dying quite quickly.
Because, quite simply, the vast majority of end-users don't know how to secure their networks.
The vast majority of homeowners do know how to lock their doors.
You can't make the 'visible, so invited' assumption until you can reasonably assume that a clear majority of people in control of wireless networks actually know how to make them invisible, and why it's a good idea.
The legal situation, as it stands protects the majority, based on general knowledge right now. As the technology and public understanding of it evolves, past experience shows that the legal situation will also (albeit at a considerably slower pace).
No, you don't. You have as much ability to connect to them. World of difference.
The law, in general, has a concept of reasonableness. If it's not reasonable for the owner of the network to be aware that they were making it public, then it's not reasonable to assume that they intended to. It's not reasonable to assume that for the vast majority of consumers out there, and by extension, the vast majority of APs in suburban areas. In fact, the huge number of obviously private, but accidentally open networks out there would suggest that a huge number of people are running unsecured networks, whether they're consumers or not.
As a human making the ultimate decision whether to use the network, what human-visible indication is there that a network is public? Is the SSID the name of a public hotspot provider? Is it named something like 'FreeWiFi'? If not, basic statistics would suggest that it's far more likely to be an accidentally unsecured network than a deliberately open one, which means that you should be working on the principle that all networks are private unless demonstrated otherwise, technical details aside.
No, those ways don't say 'this is private' or 'this is public', they say 'this is visible' or 'this is invisible'.
Don't equate protocol-level advertisements with human-level advertisements, because they're not at all the same.
Just because somebody leaves their front door open isn't an invitation into their home, even though if they were competent they would have closed and locked it. When it comes to technical equipment thrust into the hands of inexperienced mass consumers, it's not reasonable for anybody to expect them to be able to configure it much, if any, beyond manufacturer-guided values. Unless there's a wizard which says 'do you want to make your wireless network private?', you and I both know that people who can barely operate a video recorder won't get anywhere near knowing what the implications of visible SSIDs and a lack of MAC-address filtering are.
Situations like this are yet another product of technology that isn't really ready for consumers being handed to them because the benefits largely outweigh the downsides. Really, most of the blame lies with the manufacturers for providing dumb defaults, and for the whole damned industry for not coming up with a nice simple pairing mechanism (push button on laptop, push button on AP; LCD on the AP flashes a code, type it into the laptop to join the network) that any consumer can use without compromising basic security.
Just because it's XHTML doesn't make it any good (and just because it's not XHTML doesn't make it bad, either, though for generated code XHTML makes a lot of sense by nature).
I've not looked at EWD, but I did play with VWD and VS2005, for a while, though it has been a while. No site I've seen that was built with Microsoft tools has ever come close to being done well, accessibility and standards-wise without having a serious amount of manual tweaking. I'm not saying that other products don't require you to do lots of manual tweaking, too, but the whole marketing pitch for these is that everything (well, all the 'dirty' work) gets done for you, and many (mostly novice to intermediate) web developers get suckered in by that.
I suppose in many way it's similar to the utter abominations of user interfaces found in VB-produced shareware apps in the 1990s. Only this time the potential audience is larger by a factor of a few million...
So it's easier to use. So what? When you're producing output on behalf of a client, you have a wider responsibility: to ensure that the output is actually worthwhile. The tools you use to do that are immaterial. Past history's shown that Microsoft's development tools group 'gets' web standards about as much as Bill Gates himself appears to (Adobe have known to be almost as bad, in absolute fairness).
Just because the tools are easy to use isn't justification for making use of them. Now, I don't know what Microsoft's new stuff is going to spit out. It could do effortless drag-and-drop creation of semantically-correct accessible content-rich, yet multimedia-capable and fluid web applications. It could, but nothing they've produced to date suggests that (despite the rhetoric) they're remotely capable of it. For that matter, nobody is.
The bottom line is: these are tools for web developers to make life easier, but you need to be a good enough web developer to know which of the 'helpful' features to work around, which to ignore, and which are just plain hazardous, before you can think about going near them. Dreamweaver in days of old was terrible, but Microsoft's track record (even fairly recently) is worse.
The problem with all the tools like this is that when you're skilled enough to use them properly, 90% of the features aren't actually worth jack to you. If you're not skilled enough, you probably shouldn't be allowed near them until you fully understand the implications to your clients' customers and potential customers of using them.
You miss the point: the technical protocol-level details are completely irrelevant. If there's no specific advertisment (be it on a signpost, or a SSID name indicating that's it's public, or something else), then there's no invitation.
Just because the default configuration of routers broadcasts the SSID doesn't make it a free-for-all. Similarly, just because a Bluetooth phone is set to 'visible' doesn't mean 'connect to me and do what the hell you like': at a protocol level it means 'you can connect to me', but at a human level there's no such implication made purely by the presence of the packets.
Similarly, just because an operating system finds the packets and produces a UI in response to them doesn't mean there's an invitation either, it just means that the packets have been spotted by the operating system and it's acting in a pre-programmed manner in response to them. Ultimately, you're still given a choice as to whether to connect, and moreso a choice whether to actually use the network or not. The fact that you can doesn't mean you should.
With all this talk of multi-threading on multi-core CPUs, Slashdotters appear to have forgotten that we all run multi-tasking operating systems. An OS isn't forced to schedule all of the threads of a single application between cores: it's perfectly capable of spreading several different single-threaded applications between cores, too.
And no, EFI didn't appear first on Intel Macs. Intel Macs weren't even the first x86-based machines to employ it.
So NetBoot a Darwin installation; it's not going to be vastly different (and indeed it'll be/better/ under these circumstances because it'd understand HFS+) to PxeLinux.
NetBoot Darwin, dd image, mount partition, tweak configuration, unmount, and reboot.
It was very obvious from very early on that she hadn't infringed any of the copyrights they were talking about, and their 'expert' witness was the final nail in the coffin that was their case.
So, to answer your question, 'clear her name of being wrongfully accused of mass copyright infringement', which is a perfectly reasonable and proper thing for her to do.
The sympathy for the kids is largely based on the fact that the RIAA don't and haven't ever cared whether somebody is guilty of what they've been accused of. Pretty much everybody has downloaded/some/ music at one point in time, and the less savvy out there would likely get quite panicked about a legal-type letter from the RIAA offering them an (expensive) get-out. The RIAA casts the net wide with little regard to consequence and bargains on people rolling over and paying up, irrespective of what they should be. The RIAA _would_ get some sympathy if:
* They acted reasonably and properly * They acted on behalf of the artists who got suckered into the retarded contracts they signed instead of the record companies themselves
The recording industry as it stands, with the aid of the RIAA, stinks to high heaven. Being sick to death of the RIAA's motives and methods, not to mention the wider industry's, the average Slashdotter's response is a simple 'Fuck'em'. They might win a civil suit, proving that somebody somewhere has infringed their copyrights, but they haven't yet--instead they rely on people not having the time, energy and money to fight them, which just makes a mockery of the legal processes put in place to protect the rights of those they claim to be representing.
(You'd find the same with SCO versus the world: even if SCO were by some miracle correct about any aspect of their case, no Slashdot reader would likely stand behind them because their tactics are so thoroughly lame).
That's the point, though: it has very little to do with the public Internet. IPv4 traffic is still NATted at the borders and so on as it previously has been, but IPv6 is used within the networks by the networks.
Except that an awful lot of 3G (UMTS) services operate via IP, and are supposed to continue to do so (and be directly addressable from the home network) whilst roaming.
[Aside: Whilst a given phone will invariably have an MSISDN (phone number), it could have two, or three, or four, and it's not necessarily globally unique. Generally a phone won't know its own PSTN number unless it's told it by the network, and in normal useage it's only the SS7 gateways that need to care: the actual MSISDN isn't used a whole heap for call routing). About the only useful ID in this context is the MSIN (mobile subscriber identity number--the number on your SIM), but that's no more helpful to an end-user mapped to an IPv6 address than any other address would be.
I'm not entirely sure how giving every phone the same IP and NATing achieves anything beyond confusion, or what 'NAT them all by PSTN at your border router' means, let alone how it would help.]
3G mobile networks utilise IPv6, AIUI; I've a feeling it's part of the specs (well, everything is specified somewhere in mobile telco land), which makes it part of the business model.
Congratulations on being one of the hoards of people who artificially inflate IE6's market share stats (even if there are better methods than user-agent sniffing out there, they don't necessarily get used...)
Yes, this is certainly true. I recall colleges getting widespread infections of viruses thanks to students running infected programs from floppies, which then remained in memory and infected any programs on any disks that were later inserted until the machine was rebooted (or until it was cleaned, if it had a hard disk).
The thing is, though, that's not how software gets distributed any more: the way things work in the iPodLinux world means that it's a lot harder for you to get infected in the first place, and once you have been there's no way for the infection to spread: the whole setup makes virus writing utterly pointless, not to mention very difficult.
It might be a big WTF, but what's the alternative? Effectively put everything in its own sandbox? The problem is that your files are created and accessed by the very same programs you want to restrict access: without that access, both the programs and the files are useless. If you get into the explicit-permission game, you end up with something like UAC or Java's sandboxing permissions--neither of which have exactly set the world on fire. Essentially it boils down to this: what good's a text editor that can't edit your files, or a file manager that can't open, rename, move, copy or delete your files? Where's the line between programs which can do things and programs which can't? What determines trusted versus untrusted? Is it digital signatures? If so, who issues them? (And with that we're heading rapidly towards TCPA and friends to ensure the validity of the signatures on all of your binaries, including the kernel and drivers).
Personally, I'd rather have an OS in which programs _I_ run can access _my_ files, whereas programs other people run can't, than have an OS where programs I run have to be whitelisted to function properly and I either get really lax about the whitelisting and allow everything that seems like it/might/ be OK to access my stuff, or spend all my time tuning and verifying the permissions for programs and no time at all actually using the things and getting anything done.
Slashdot Mirror
Students not taking A-Level mathematics (or "maths", over here in the UK) is nothing new, typically it was the preserve of those who had a natural aptitude for it, rather than based on the requirements of a degree they might want to study.
This isn't ideal, obviously, but it's been this way (in England & Wales: the Scottish and Northern Irish education systems are quite different, and I don't know how popular Higher Maths is in Scotland) for at least 15 years, probably longer.
Who the hell runs NFS on an untrusted network? In any case, most Xserves don't export NFS; largely just SMB or AFP.
Moreover, it still doesn't affect the vast majority of Mac OS X users, and doesn't affect any in the default configuration.
Yes, the services shouldn't have holes when you enable them, but this is still miles away from Windows-style exploits.
And yet none of those remotely-vulnerable services are enabled by default. Indeed, of the three, two of them wouldn't get switched on by the vast majority of Mac users.
.ANI vulnerability.
Which is somewhat different to, say, the
Yeah, 'cos patched local privilege escalation vulnerabilities that nobody has bothered to exploit is exactly the same as unpatched remote code-execution vulnerabilities affecting a default installation for which exploits are widely circulated in the wild for nefarious purposes.
If you think the two are the same, it's no wonder you think they're all fanboys.
Generally when they say 'secure' they mean 'susceptible to attack'.
Windows is, in its default configuration. FreeBSD, Linux and Mac OS X (not to mention a fair few others) aren't.
Some local privilege escalations that nobody beyond a couple of security researchers have paid attention to is nothing compared to the stuff a Windows user has to put up with.
For average Joe on the street who connects his computer to the Internet and browses the web and so forth, the vulnerabilities mean approximately squat.
In order from least to most restrictive:
Use Public Domain if you don't care what people do with your code.
Use the MIT or X11 license if you want to give it as much chance as possible of being used by as many people as possible, without them being able to pass your code off as theirs.
The BSD (3-clause) license goes further by preventing other people from using you to endorse their products without your permission.
The LGPL ensures that the code will remain 'open' (i.e., distributing altered binaries means you have to distribute the matching sources). The LGPL specifically allows your code to be linked with, but not included in, non-LGPL projects. If your code isn't a library (or included in one), the LGPL isn't hugely different from the GPL, although releasing a program under the LGPL would mean somebody could turn it (or portions of it) into an LGPL-licensed library without any hassle.
The GPL is much the same as the LGPL, but doesn't contain any such provision for linking, so people linking with your code (if it's a library) had better make sure their do their homework first.
The GPL-compatible licenses (which includes PD, MIT/X11 and BSD) are so-called because they don't contain any restrictions beyond those included in the GPL. This means that your code, if released under a GPL-compatible license, can be legally be included in a GPL-licensed work: your code as you originally released it is still under the license you originally used, but the modifications and the derived work could be GPL'd.
Generally, the BSD license is a safe bet if you don't feel passionately about making sure that people who use your code must make their changes available to anybody who wants them, otherwise pick the LGPL or GPL depending on circumstance and requirements.
Avoid non-GPL-compatible licenses, especially home-grown ones: they usually end up doing nothing but preventing people who might want to use your code from doing so. Unless you're a huge multinational company, it's a sure-fire way to ensure that relatively few people will bother with what you've released (in which case, what was the point in releasing it?), and even then it'll stymie adoption.
It doesn't, though: that's the big problem with IE.
IE7 is a lot better than IE6 in this respect, but even in 'Standards compliant' mode, it still differs from what the specs say the behaviour should be, and what real standards-compliant UAs do.
I can't stress enough how much better IE7 is, though. Our IE7-specific stylesheets are typically a few lines long, as opposed to the pages required for IE6, and our internal stats show IE7 and IE6 have about a 50/50 split on IE's marketshare for our clients' visitors, so IE6 is, thankfully, dying quite quickly.
Because, quite simply, the vast majority of end-users don't know how to secure their networks.
The vast majority of homeowners do know how to lock their doors.
You can't make the 'visible, so invited' assumption until you can reasonably assume that a clear majority of people in control of wireless networks actually know how to make them invisible, and why it's a good idea.
The legal situation, as it stands protects the majority, based on general knowledge right now. As the technology and public understanding of it evolves, past experience shows that the legal situation will also (albeit at a considerably slower pace).
No, you don't. You have as much ability to connect to them. World of difference.
The law, in general, has a concept of reasonableness. If it's not reasonable for the owner of the network to be aware that they were making it public, then it's not reasonable to assume that they intended to. It's not reasonable to assume that for the vast majority of consumers out there, and by extension, the vast majority of APs in suburban areas. In fact, the huge number of obviously private, but accidentally open networks out there would suggest that a huge number of people are running unsecured networks, whether they're consumers or not.
As a human making the ultimate decision whether to use the network, what human-visible indication is there that a network is public? Is the SSID the name of a public hotspot provider? Is it named something like 'FreeWiFi'? If not, basic statistics would suggest that it's far more likely to be an accidentally unsecured network than a deliberately open one, which means that you should be working on the principle that all networks are private unless demonstrated otherwise, technical details aside.
No, those ways don't say 'this is private' or 'this is public', they say 'this is visible' or 'this is invisible'.
Don't equate protocol-level advertisements with human-level advertisements, because they're not at all the same.
Just because somebody leaves their front door open isn't an invitation into their home, even though if they were competent they would have closed and locked it. When it comes to technical equipment thrust into the hands of inexperienced mass consumers, it's not reasonable for anybody to expect them to be able to configure it much, if any, beyond manufacturer-guided values. Unless there's a wizard which says 'do you want to make your wireless network private?', you and I both know that people who can barely operate a video recorder won't get anywhere near knowing what the implications of visible SSIDs and a lack of MAC-address filtering are.
Situations like this are yet another product of technology that isn't really ready for consumers being handed to them because the benefits largely outweigh the downsides. Really, most of the blame lies with the manufacturers for providing dumb defaults, and for the whole damned industry for not coming up with a nice simple pairing mechanism (push button on laptop, push button on AP; LCD on the AP flashes a code, type it into the laptop to join the network) that any consumer can use without compromising basic security.
We must have looked at a different ASP.NET, then.
Just because it's XHTML doesn't make it any good (and just because it's not XHTML doesn't make it bad, either, though for generated code XHTML makes a lot of sense by nature).
I've not looked at EWD, but I did play with VWD and VS2005, for a while, though it has been a while. No site I've seen that was built with Microsoft tools has ever come close to being done well, accessibility and standards-wise without having a serious amount of manual tweaking. I'm not saying that other products don't require you to do lots of manual tweaking, too, but the whole marketing pitch for these is that everything (well, all the 'dirty' work) gets done for you, and many (mostly novice to intermediate) web developers get suckered in by that.
I suppose in many way it's similar to the utter abominations of user interfaces found in VB-produced shareware apps in the 1990s. Only this time the potential audience is larger by a factor of a few million...
So it's easier to use. So what? When you're producing output on behalf of a client, you have a wider responsibility: to ensure that the output is actually worthwhile. The tools you use to do that are immaterial. Past history's shown that Microsoft's development tools group 'gets' web standards about as much as Bill Gates himself appears to (Adobe have known to be almost as bad, in absolute fairness).
Just because the tools are easy to use isn't justification for making use of them. Now, I don't know what Microsoft's new stuff is going to spit out. It could do effortless drag-and-drop creation of semantically-correct accessible content-rich, yet multimedia-capable and fluid web applications. It could, but nothing they've produced to date suggests that (despite the rhetoric) they're remotely capable of it. For that matter, nobody is.
The bottom line is: these are tools for web developers to make life easier, but you need to be a good enough web developer to know which of the 'helpful' features to work around, which to ignore, and which are just plain hazardous, before you can think about going near them. Dreamweaver in days of old was terrible, but Microsoft's track record (even fairly recently) is worse.
The problem with all the tools like this is that when you're skilled enough to use them properly, 90% of the features aren't actually worth jack to you. If you're not skilled enough, you probably shouldn't be allowed near them until you fully understand the implications to your clients' customers and potential customers of using them.
You miss the point: the technical protocol-level details are completely irrelevant. If there's no specific advertisment (be it on a signpost, or a SSID name indicating that's it's public, or something else), then there's no invitation.
Just because the default configuration of routers broadcasts the SSID doesn't make it a free-for-all. Similarly, just because a Bluetooth phone is set to 'visible' doesn't mean 'connect to me and do what the hell you like': at a protocol level it means 'you can connect to me', but at a human level there's no such implication made purely by the presence of the packets.
Similarly, just because an operating system finds the packets and produces a UI in response to them doesn't mean there's an invitation either, it just means that the packets have been spotted by the operating system and it's acting in a pre-programmed manner in response to them. Ultimately, you're still given a choice as to whether to connect, and moreso a choice whether to actually use the network or not. The fact that you can doesn't mean you should.
Microsoft wants all of Google's many competitors to get together and complain that Google won't have much competition left if they buy DoubleClick.
Riiight.
With all this talk of multi-threading on multi-core CPUs, Slashdotters appear to have forgotten that we all run multi-tasking operating systems. An OS isn't forced to schedule all of the threads of a single application between cores: it's perfectly capable of spreading several different single-threaded applications between cores, too.
And no, EFI didn't appear first on Intel Macs. Intel Macs weren't even the first x86-based machines to employ it.
Yes, you're completely right. It's useless for anything but current affairs.
Like, for example, http://en.wikipedia.org/wiki/FireWire
That entry (like so many) even helpfully points out where statements aren't backed up with reliable sources, and cites sources where it is.
How much of that entry is 'opinion' and how much is 'factual', do you think?
What about: http://en.wikipedia.org/wiki/Geostationary_orbit
or
http://en.wikipedia.org/wiki/Asia
or
http://en.wikipedia.org/wiki/Crusades
or
http://en.wikipedia.org/wiki/Long_division
(Taking computer technology, science, geography, history and mathematics articles at random)
So NetBoot a Darwin installation; it's not going to be vastly different (and indeed it'll be /better/ under these circumstances because it'd understand HFS+) to PxeLinux.
NetBoot Darwin, dd image, mount partition, tweak configuration, unmount, and reboot.
It was very obvious from very early on that she hadn't infringed any of the copyrights they were talking about, and their 'expert' witness was the final nail in the coffin that was their case.
/some/ music at one point in time, and the less savvy out there would likely get quite panicked about a legal-type letter from the RIAA offering them an (expensive) get-out. The RIAA casts the net wide with little regard to consequence and bargains on people rolling over and paying up, irrespective of what they should be. The RIAA _would_ get some sympathy if:
So, to answer your question, 'clear her name of being wrongfully accused of mass copyright infringement', which is a perfectly reasonable and proper thing for her to do.
The sympathy for the kids is largely based on the fact that the RIAA don't and haven't ever cared whether somebody is guilty of what they've been accused of. Pretty much everybody has downloaded
* They acted reasonably and properly
* They acted on behalf of the artists who got suckered into the retarded contracts they signed instead of the record companies themselves
The recording industry as it stands, with the aid of the RIAA, stinks to high heaven. Being sick to death of the RIAA's motives and methods, not to mention the wider industry's, the average Slashdotter's response is a simple 'Fuck'em'. They might win a civil suit, proving that somebody somewhere has infringed their copyrights, but they haven't yet--instead they rely on people not having the time, energy and money to fight them, which just makes a mockery of the legal processes put in place to protect the rights of those they claim to be representing.
(You'd find the same with SCO versus the world: even if SCO were by some miracle correct about any aspect of their case, no Slashdot reader would likely stand behind them because their tactics are so thoroughly lame).
That doesn't mean they don't use it internally for IMS services, it just means that for customer-visible Internet access it's not directly used.
That's the point, though: it has very little to do with the public Internet. IPv4 traffic is still NATted at the borders and so on as it previously has been, but IPv6 is used within the networks by the networks.
Except that an awful lot of 3G (UMTS) services operate via IP, and are supposed to continue to do so (and be directly addressable from the home network) whilst roaming.
[Aside: Whilst a given phone will invariably have an MSISDN (phone number), it could have two, or three, or four, and it's not necessarily globally unique. Generally a phone won't know its own PSTN number unless it's told it by the network, and in normal useage it's only the SS7 gateways that need to care: the actual MSISDN isn't used a whole heap for call routing). About the only useful ID in this context is the MSIN (mobile subscriber identity number--the number on your SIM), but that's no more helpful to an end-user mapped to an IPv6 address than any other address would be.
I'm not entirely sure how giving every phone the same IP and NATing achieves anything beyond confusion, or what 'NAT them all by PSTN at your border router' means, let alone how it would help.]
3G mobile networks utilise IPv6, AIUI; I've a feeling it's part of the specs (well, everything is specified somewhere in mobile telco land), which makes it part of the business model.
Congratulations on being one of the hoards of people who artificially inflate IE6's market share stats (even if there are better methods than user-agent sniffing out there, they don't necessarily get used...)
Yes, this is certainly true. I recall colleges getting widespread infections of viruses thanks to students running infected programs from floppies, which then remained in memory and infected any programs on any disks that were later inserted until the machine was rebooted (or until it was cleaned, if it had a hard disk).
The thing is, though, that's not how software gets distributed any more: the way things work in the iPodLinux world means that it's a lot harder for you to get infected in the first place, and once you have been there's no way for the infection to spread: the whole setup makes virus writing utterly pointless, not to mention very difficult.
It might be a big WTF, but what's the alternative? Effectively put everything in its own sandbox? The problem is that your files are created and accessed by the very same programs you want to restrict access: without that access, both the programs and the files are useless. If you get into the explicit-permission game, you end up with something like UAC or Java's sandboxing permissions--neither of which have exactly set the world on fire. Essentially it boils down to this: what good's a text editor that can't edit your files, or a file manager that can't open, rename, move, copy or delete your files? Where's the line between programs which can do things and programs which can't? What determines trusted versus untrusted? Is it digital signatures? If so, who issues them? (And with that we're heading rapidly towards TCPA and friends to ensure the validity of the signatures on all of your binaries, including the kernel and drivers).
/might/ be OK to access my stuff, or spend all my time tuning and verifying the permissions for programs and no time at all actually using the things and getting anything done.
Personally, I'd rather have an OS in which programs _I_ run can access _my_ files, whereas programs other people run can't, than have an OS where programs I run have to be whitelisted to function properly and I either get really lax about the whitelisting and allow everything that seems like it