Yeah, Cingular turned to crap after AT&T took over. We switched back to T-Mobile rather than deal with call droppage. We're in Austin, TX.
Actually, it was funny during SXSW Interactive last year, walking around outside the conference halls watching frustrated people trying to make calls on their iPhones while BlackBerry users were chatting away happily.
Yeah. I'm a Mac user, and I'm convinced that Apple is strangling the iPhone. I'm waiting until the 27th to see if they launch a non-jailed device. If they don't, I'm giving up and switching to Android.
When your friends dumped their iPhones (and perhaps the ATT contract), what hardware/carrier did they switch to..and why, besides the "cool" factor like you were mentioning.
I'm not the person you were replying to, but I know five or six people who've switched to Android, and one who has switched from BlackBerry to WebOS.
I have no hard market research, but I definitely get the sense that the tech geeks and early adopters are switching to Android. My Facebook feed is full of stuff posted by Android devices the way it used to be full of stuff posted from an iPhone.
When Oddworld Inhabitants abandoned their PlayStation fanbase and went Xbox-only, they pretty much ensured disaster. Sure enough, the next installment was a flop, and they were bought by the Mudokons... sorry, Microsoft.
then it still beats me why we don't have a.xxx TLD. Apart from policies demanding no porn on non-XXX domains (at risk of having it revoked) it'd make the filtering software work, and produce a lot of revenue from porn operators.
Porn sites that want to be filtered correctly can already get filtered by categorizing themselves as porn using PICS; the information will be picked up by IE, Safari, Surfwatch, etc. There's no need for a special domain.
So basically, a.xxx domain wouldn't get us any filtering ability we don't already have, unless you somehow made it mandatory for porn sites--which probably wouldn't work for all kinds of reasons.
The only reason for a.xxx domain would be if porn sites wanted it for advertising purposes. Apparently they don't, or not enough to pay for it to be set up, so it's not happening.
Apple's partnerships with Microsoft have always ended badly.
Everyone's partnerships with Microsoft have ended badly. I don't think any company has done business with Microsoft without getting shafted. Vivo, Real, Kodak, IBM, the list is lengthy.
So, for Apple's sake, I'd think them making their own search engines/tools or sticking with Google, may be their best bet.
I think un-jailing the iPhone would be their best bet. That's what I think is really strangling the platform right now, causing developers to give up and users to lose interest and consider switching to Android. There's no way a jailed, intentionally crippled platform from a single vendor can compete in the long term with a multi-vendor open platform, even assuming feature parity (i.e. even assuming Apple came up with alternatives to Google's search, mapping, etc.)
Really, it's like 1985 all over again, but even worse, because at least the Mac was open and you could run what software you liked on it. Imagine how much worse the Mac would have fared if you had to get Apple's approval for your software to run on the Mac, and you could only buy Mac software from Apple.
Do you not remember the 1997 agreement between Apple and Microsoft that ended their legal disputes and injected $150 million of badly needed cash into Apple which was teetering on the brink of bankruptcy?
I suggest that you go look at how much cash Apple had in the bank in 1997. They weren't anywhere close to teetering on the brink of bankruptcy, and Microsoft's $150 million was a tenth of the amount Apple had in cash alone.
mkv is a great format, but it isn't supported by Windows 7, Mac OS X (Quicktime), 360 or PS3.
Or AppleTV, or my DVD player, or anything else I have. MKV may be open source, but it's a pain in the ass.
I've got a script which seems to be able to convert most MKV files into MP4s that will play, but I could still use a good, reliable MKV to MP4 converter. Links would be appreciated, OS X or Linux.
I can however play an H.264/AC-3.m2ts file on Windows 7 and PS3.
Using MPEG-2 containers for MPEG-4 is a horrible hack on a par with sticking MPEG-4 in AVI. AVCHD is h.264 in MPEG-2 containers, and look at the problems people have with that. I suspect it was only done because hardware manufacturers already had hardware and firmware to handle MPEG-2 TS and PS, and didn't want to have to implement the more sophisticated and feature-rich MPEG-4.
(And no, MPEG-2 containers (whether TS or PS) don't work in OS X by default.)
Or there's AppleTV. Or Popcorn Hour. Or MviX boxes. Or various $90 media players that access any USB hard drive you have hanging around. (That one even supports ext3.)
I mean, yeah, I have a DVD player that supports DivX that I used a few years ago. But frankly, it's a hell of a lot more convenient to pull stuff across my network or stick it on a hard drive than to mess with burning DVDs, even ignoring the h.264 issue. Spend the $100, you'll thank yourself.
What's amusing about the issue in the kb is that the problem that they're "solving" by breaking the username/password in a URL standard is NOT a problem with username/password URLs, but a problem with how IE displays the URLs.
No, it's much more than a display problem.
URLs get cached. They end up in history files, downloaded files, cache files on proxies, log files, everywhere. You can't guarantee that all the software out there is going to dispose of URLs securely or sanitize out usernames and passwords, so it would not have been safe to put usernames and passwords in URLs even if Internet Explorer had taken pains to avoid information leakage.
Re-defined entrenched URL standards (you cannot specify username/password in an Internet Explorer URL but this is a legal standard form of URL)?
HTTP URLs never supported username and password in the URL, according to the actual standards.
RFC 1738 was the original URL specification. Section 3.1 said that some schemes supported username (and/or password) in the URL, giving the example of ftp urls. However, http was not one of the schemes supporting usernames or passwords, as you can see from the syntax description in section 3.3.
None of the followup RFCs added user or password support to http URLs. In fact, RFC2396 noted in section 3.2.2 that the feature was not recommended even when it was supported. RFC3986 then deprecated the feature, even for ftp URLs.
So user and password in http URLs was a non-standard feature Microsoft should never have implemented in the first place, and they were right to remove it.
As far as I know, the only URL scheme which still officially supports username and password without deprecation is telnet, presumably on the grounds that anyone still using telnet doesn't care about the username and password being hacked anyway.
The phrase "a group" is singular. So it's "a group of cryptographers has developed". Without the phrase "a group" making it singular, it would be "cryptographers have developed".
(Really, niggling about the grammar when there are so many other errors in the summary...)
Well, the day you have to jailbreak a Mac is the day I switch to Linux full time. I'll be sad to go if it happens, though. Things like sound are just such a pain on Linux still.
Just because you've always bought crippled phones doesn't mean they're all like that. I've got a phone that will let me run whatever software I want. My last phone was the same.
But if this new device blurs the line too far away from 'throwaway gadget' to 'computer' Apple may run into trouble.
Yup. I'm interested in an Apple tablet if it's a general purpose computer. I'm not interested in a locked-down and intentionally crippled giant iPod. Apple's grip on the iPhone is killing it, and I see the tablet as a critical test to see whether Apple understands that or not.
At least in 1.3.1, you could just specify -client or -server to choose whether you ran interpreted or compiled. So Java hasn't been solely interpreted since J2SE 1.3, though interpreted Java was a default Sun continued to choose for a while. IBM, on the other hand, had J9 JIT on both server and desktop versions of Java 1.3.
Why do people always think others would think that by default they would state anything else than their own opinion?
Beats me, but IBM has advised me that I should include a brief disclaimer if I write about things which relate to IBM's areas of business, in places where people might think I was repeating IBM policy.
Since I don't try to keep my identity secret on Slashdot, I figure "better safe than sorry".
When writing (for example) about parakeet training, I don't bother with the disclaimer...
Yeah, Cingular turned to crap after AT&T took over. We switched back to T-Mobile rather than deal with call droppage. We're in Austin, TX.
Actually, it was funny during SXSW Interactive last year, walking around outside the conference halls watching frustrated people trying to make calls on their iPhones while BlackBerry users were chatting away happily.
Yeah. I'm a Mac user, and I'm convinced that Apple is strangling the iPhone. I'm waiting until the 27th to see if they launch a non-jailed device. If they don't, I'm giving up and switching to Android.
I'm not the person you were replying to, but I know five or six people who've switched to Android, and one who has switched from BlackBerry to WebOS.
I have no hard market research, but I definitely get the sense that the tech geeks and early adopters are switching to Android. My Facebook feed is full of stuff posted by Android devices the way it used to be full of stuff posted from an iPhone.
When Oddworld Inhabitants abandoned their PlayStation fanbase and went Xbox-only, they pretty much ensured disaster. Sure enough, the next installment was a flop, and they were bought by the Mudokons... sorry, Microsoft.
Porn sites that want to be filtered correctly can already get filtered by categorizing themselves as porn using PICS; the information will be picked up by IE, Safari, Surfwatch, etc. There's no need for a special domain. So basically, a .xxx domain wouldn't get us any filtering ability we don't already have, unless you somehow made it mandatory for porn sites--which probably wouldn't work for all kinds of reasons.
The only reason for a .xxx domain would be if porn sites wanted it for advertising purposes. Apparently they don't, or not enough to pay for it to be set up, so it's not happening.
Serves you right for using Python.
Everyone's partnerships with Microsoft have ended badly. I don't think any company has done business with Microsoft without getting shafted. Vivo, Real, Kodak, IBM, the list is lengthy.
I think un-jailing the iPhone would be their best bet. That's what I think is really strangling the platform right now, causing developers to give up and users to lose interest and consider switching to Android. There's no way a jailed, intentionally crippled platform from a single vendor can compete in the long term with a multi-vendor open platform, even assuming feature parity (i.e. even assuming Apple came up with alternatives to Google's search, mapping, etc.)
Really, it's like 1985 all over again, but even worse, because at least the Mac was open and you could run what software you liked on it. Imagine how much worse the Mac would have fared if you had to get Apple's approval for your software to run on the Mac, and you could only buy Mac software from Apple.
I suggest that you go look at how much cash Apple had in the bank in 1997. They weren't anywhere close to teetering on the brink of bankruptcy, and Microsoft's $150 million was a tenth of the amount Apple had in cash alone.
Or AppleTV, or my DVD player, or anything else I have. MKV may be open source, but it's a pain in the ass. I've got a script which seems to be able to convert most MKV files into MP4s that will play, but I could still use a good, reliable MKV to MP4 converter. Links would be appreciated, OS X or Linux.
Using MPEG-2 containers for MPEG-4 is a horrible hack on a par with sticking MPEG-4 in AVI. AVCHD is h.264 in MPEG-2 containers, and look at the problems people have with that. I suspect it was only done because hardware manufacturers already had hardware and firmware to handle MPEG-2 TS and PS, and didn't want to have to implement the more sophisticated and feature-rich MPEG-4. (And no, MPEG-2 containers (whether TS or PS) don't work in OS X by default.)
Got an Xbox 360 or a PS3? Problem solved.
Otherwise, $80 will get you a Blu-ray player that handles h.264 and upscales DVDs to 1080p.
Or there's AppleTV. Or Popcorn Hour. Or MviX boxes. Or various $90 media players that access any USB hard drive you have hanging around. (That one even supports ext3.)
I mean, yeah, I have a DVD player that supports DivX that I used a few years ago. But frankly, it's a hell of a lot more convenient to pull stuff across my network or stick it on a hard drive than to mess with burning DVDs, even ignoring the h.264 issue. Spend the $100, you'll thank yourself.
I tend to take the default, which includes both, and let the device I'm playing back on decide which is appropriate.
No, it's much more than a display problem. URLs get cached. They end up in history files, downloaded files, cache files on proxies, log files, everywhere. You can't guarantee that all the software out there is going to dispose of URLs securely or sanitize out usernames and passwords, so it would not have been safe to put usernames and passwords in URLs even if Internet Explorer had taken pains to avoid information leakage.
HTTP URLs never supported username and password in the URL, according to the actual standards. RFC 1738 was the original URL specification. Section 3.1 said that some schemes supported username (and/or password) in the URL, giving the example of ftp urls. However, http was not one of the schemes supporting usernames or passwords, as you can see from the syntax description in section 3.3. None of the followup RFCs added user or password support to http URLs. In fact, RFC2396 noted in section 3.2.2 that the feature was not recommended even when it was supported. RFC3986 then deprecated the feature, even for ftp URLs. So user and password in http URLs was a non-standard feature Microsoft should never have implemented in the first place, and they were right to remove it. As far as I know, the only URL scheme which still officially supports username and password without deprecation is telnet, presumably on the grounds that anyone still using telnet doesn't care about the username and password being hacked anyway.
Google hires ex-Microsoft employees all the time.
I'm guessing you don't use Linux. Firefox on Linux is a dog compared to the Chrome betas, even with 4GB of RAM in the machine.
The phrase "a group" is singular. So it's "a group of cryptographers has developed". Without the phrase "a group" making it singular, it would be "cryptographers have developed".
(Really, niggling about the grammar when there are so many other errors in the summary...)
Well, the day you have to jailbreak a Mac is the day I switch to Linux full time. I'll be sad to go if it happens, though. Things like sound are just such a pain on Linux still.
Could you make those error bars a bit bigger? You almost said something.
Just because you've always bought crippled phones doesn't mean they're all like that. I've got a phone that will let me run whatever software I want. My last phone was the same.
Yup. I'm interested in an Apple tablet if it's a general purpose computer. I'm not interested in a locked-down and intentionally crippled giant iPod. Apple's grip on the iPhone is killing it, and I see the tablet as a critical test to see whether Apple understands that or not.
IBM doesn't have the same history of subverting standards bodies.
Ah, but then they'd have to deal with a business process patent from Mr Wongburger.
At least in 1.3.1, you could just specify -client or -server to choose whether you ran interpreted or compiled. So Java hasn't been solely interpreted since J2SE 1.3, though interpreted Java was a default Sun continued to choose for a while. IBM, on the other hand, had J9 JIT on both server and desktop versions of Java 1.3.
Congratulations on irrelevant nitpicking.
Java hasn't been interpreted since J2SE 1.3 introduced HotSpot in 2000.
There's no reason why sandboxing should imply interpreted code.
Beats me, but IBM has advised me that I should include a brief disclaimer if I write about things which relate to IBM's areas of business, in places where people might think I was repeating IBM policy.
Since I don't try to keep my identity secret on Slashdot, I figure "better safe than sorry".
When writing (for example) about parakeet training, I don't bother with the disclaimer...