This isn't about equipment purchased from AT&T, on or off contract, with an AT&T SIM, SIM-locked to AT&T's network. This is about equipment purchased from Apple, off contract, with an Apple SIM, not SIM-locked to any network. AT&T is locking that Apple SIM (not the device) to AT&T's network, forcing you to buy another Apple SIM if you wish to switch carriers, something no other carrier is doing. A SIM card, once locked to a carrier, can not be unlocked.
What claim that I supposedly made are you arguing? My claim was based on my own personal experience; I went to patch my CentOS boxes first and there was no patch available, so I patched my Debian and Ubuntu boxes, then came back and the patch was available for CentOS. I never claimed that Canonical had any involvement in creating the patch, which appears to be the point you're arguing. RedHat likely had the patch in their repos before anyone, as the developer of the patch, as you correctly point out, works for them; however, that does not change the fact that it was available *to me* in Ubuntu and Debian's repos before I was able to get it from CentOS's repos.
Real life personal experience: the most reliable source of all.
"Most". You make it sound like they never fix *any* bugs. Funny, in the past month I've updated a few dozen packages and about 1/3 of those were security updates, so it sure looks like they're covering their bases regardless of their upstream provider's security team. For example, I didn't see any remarkable delay in the release for Shellshock patches; Ubuntu had them all out before CentOS, for example, and they were available for my Ubuntu systems by the time Debian had them out. I oversee systems running on all three distros and CentOS has been, by far, the worst in this regard.
Well, yes, Ubuntu forks its development releases from Debian's development release, which would be Debian Unstable. That would seem to make sense, and they're not just taking Debian's Unstable branch, throwing their branding onto it, and calling it an Ubuntu release. Way to throw half-facts out there and spread FUD, though.
Actually reading the thread (I know, this is/. and that doesn't happen), the issue is that OwnCloud wanted the package removed from an *already released* repository, which Ubuntu refused, so as not to affect users actually using it, while providing three possible interim solutions. The end result was removal of the package from the repo of the next release. Problem solved.
115,000 open bugs in how many different packages/projects that comprise the entirety of the OS? A hair over 70k, so averaging less than 2 bugs per package. And of those 70k packages, how many are installed on a default Ubuntu desktop system? On my server, there are only 660; that's including server packages that a desktop wouldn't have and excluding desktop packages that my server doesn't need, so I don't know if the desktop install has more or less.
Statistically, assuming even distribution of bugs across all packages in the system, I should expect to be affected by about 1100 bugs. There are some real questions that need to be asked, though. For instance: How many of those bug reports are actually valid? How many were fixed upstream and simply never closed? How many are stupid shit like "this text should be in that font" versus the number that actually impact performance or productivity? And, most importantly, how does Ubuntu compare with other distros, offering fewer packages overall, in bugs-per-package?
You know, it may be the case that the Jews in government do look out for each other, but that doesn't necessarily extend to all Jews; in fact, it's just as likely that all members of the government cover each others' asses equally, Jew or not.
Likewise, gang members looking out for each other doesn't extend to them looking out for members of other gangs. The implication you're making is akin to saying black people can't be racist, or that all white people are.
On one hand, he's mostly correct about the correlation. On the other, he's way off base with regard to causation. Jews aren't bad people, they're just Jews.
No, it's not. Dragging the icon for the image into the icon for the image viewer is exactly the same, in that you're specifying "open this file with that application". Doublie-clicking is most certainly not the same, especially when Windows defaults to "hide known file extenstions" and your malicious application is named "bigboobies.jpg.exe" with an icon that looks like a thumbnail of some boobs. The user sees "bigboobies.jpg", thoughtlessly ignores that no other legitimate images on their system show a file extension, and double clicks it; the malicious application now executes. Hell, if known extensions are hidden, simply naming it bigboobies.exe and giving it a titillating icon would fool 99% of users, even power users.
Here's why:
Typing "image_viewer.exe bigboobies.jpg" would launch image_viewer.exe, which would then tell you the file was not found. Dragging the icon of the "image" to the icon for "image_viewer.exe" or typing "image_viewer.exe bigboobies.jpg.exe", were you not to notice the ".exe" at the end, would launch image_viewer.exe, which would then complain that the file you fed it was not an image. Double-clicking an icon triggers the default action for the file type of the file the icon belongs to; in other words, if it's a sneakily-named executable, it executes it.
That may or may not be true, but Slashdot uses Arial and I'm far too lazy to override fonts for every site I visit. Given that I'm running Yosemite, however, your point is moot; I've got Helvetica (actually Helvetica Neue) all over the place.
That was a good jab, though, and I wish you a +5, Funny.
For example their best selling model of laptop for many years is the 13" macbook pro
So, we're in agreement, then, that their best selling laptop is the cheapest non-Air model they currently sell? Good.
Meanwhile, the rest of your argument comes down to "the screen you said has the best DPI actually has the worst". For the benefit of any readers we are entertaining with our debate, the comment in question is:
The new 27" retina 5k iMac ships with a screen that's much higher resolution than retina. It's really the only display they sell, currently, that comes close to possibly cleanly rendering the print font they've co-opted as a display font.
I then stated, in a subsequent post:
I misspoke in my previous reply.
In other words, I acknowledge that parts of my previous post were incorrect and hereby retract the arguments made therein. Yet you continue attacking those retracted arguments. That you can't argue the points I've left on the table shows just how weak your position actually is.
The fact is that Apple sells more MacBook Air and non-retina MacBook Pros (by your own admission, the 13" non-retina is the most popular model) than they do Retina Macbook Pros and there is a single Retina iMac model, the most expensive (and, historically, the most expensive product in one of Apple's lines has always sold marginally worse than the least, with the best seller being somewhere in the middle; the current MacBook Pro line being the outlier, with the least expensive model leading the pack), which is competing with 5 lower-priced models, ranging from 43% (coming in at the same price as the non-retina 13" MBP) to 80% of the price of the Retina model. From the cheapest iMac, that's a $1400 price differential; from the most expensive non-retina, it's a $400 jump; the jump from the non-retina 13" MBP to the Retina 13" MBP is only half that, $200. Are you seriously expecting me, or anyone else here, to believe that people who won't pay $200 for a retina display will somehow pay $400 for one?
I'm assuming you realize what that means and were just making a point. Since I was also making a point, allow me to clarify. A "normal listening volume" is one at which you can hear the music over the ambient noise in the room; "especially if" means "in addition to this case, there are other, possibly more common, cases where this happens". In short, you don't have to listen to Bose drivers at eardrum-splitting volumes to hear them distort and, without active noise cancellation, they're typically going to be driven at a level where the distortion is glaringly noticeable.
Even when they're not "driven to distortion", they're still just "acceptable okay"; is that what you want in a >$100 pair of headphones? Probably not; consider that you can get noise isolating headphones with drivers that blow away anything Bose currently puts out for half the price and get the same listening experience, as the outside noise that does get through in your average semi-quiet listening environment (e.g. anywhere you don't have to blast your eardrums to drown out the background noise) will be roughly equivalent to the distortion you'd get from the Bose drivers. Where the Bose set wins out is in louder environments, and they license the tech, so why not buy a pair from someone else, with better drivers and the Bose ANC?
In short, I don't think we disagree, I think my point was simply not made clearly enough the first time around.
There we go! Someone arguing with logic! I actually hadn't thought of that; I guess it's for the best, then, that I think Helvetica looks just fine at 133ppi on my 17" MBP. Too bad I'm still going to have to hear a substantial portion of the rest of the population groaning about it, though...
So then, you're implying that I must be spending time manually resolving conflicts within my solution? It's possible that you're implying that I've never encountered two people editing the same file between syncs, let alone the same line, but let me assure you that I have; which leaves the former option. Let me also tell you that I've not had to manually resolve any conflicts, as the solution I built does a fine job of this. For you to tell me that I do not understand data sync when I've built a data sync solution myself; many, in fact, the Git-based solution I'm bringing up here is simply the most recent, is the insult. If you think the problem is so difficult, it is not unreasonable for me to wish to avoid your work, even if you do find it insulting. There's nothing empty about that.
I really need to start proofreading my longer posts better... "When you're using an all" should read "When you're using an app" and the last line should contain a question.
What you haven't realised is the difficult part is automatically resolving sync conflicts.
Well, it doesn't seem to be a problem in the solution I'm currently using. Mind you, sarcasm>I probably have no clue how it works, given that I implemented it/sarcasm>. But you go right on ahead and keep telling me it's a hard problem. Difficult for you, perhaps, but not hard; there are a finite number of possible solutions and it should not be difficult for a well-built system to solve. True, Git (which I used as the basis for my solution) doesn't do a very good job of this natively; it took some creative and well thought out commit and merge hooks to accomplish it, a good day's work, for sure.
You are correct, though, that there is no one-size-fits-all solution for what to sync and how to handle merging of whatever does eventually get synched. But, then, I never claimed that there was; my claim was that the transport part of the equation is, and has been for decades, solved. Can you argue that point?
Earlier, you said:
They are file formats. They are not methods of handing off open documents between different devices without first saving them somewhere. Completely different thing.
And I didn't disagree. I did, however, point out that the documents are, in fact, saved somewhere (e.g. a temporary file, at the very least), out of necessity. I also pointed out why this was necessary, e.g. if you at all care about data consistency and preventing work loss in case of loss of power or a software or system failure. Can it be done without a temporary file somewhere local? Sure, and without issue, as long as you never lose connectivity or power while working, and your software and system never crash. If you live in a perfect world, you are correct to say that a temp file provides no benefit; however, neither I, nor anyone else I know, live in such a world. When you're using an all that utilizes cloud storage and the app crashes or you close it while you happen to not have any connectivity, it is able to restore your work only because it stored it in a local temp file somewhere.
What application(s) are you involved in. I would like to avoid them.
So, one iMac base model, the most expensive, renders the other 5 base models that will comprise at least 90% of iMac sales insignificant? The two MacBook Air base models and 13" non-retina MacBook Pro base model which, combined, outsell the 5 retina MacBook Pro retina base models, are insignificant? What of the argument in my other post, to which this was a follow-up and correction?
I misspoke in my previous reply. The 5k 27" is considered retina, the 21" and non-5k 27" are not. Look at Apple's own marketing for validation of my claim. You, sir, are wrong.
That's what I prefer to do. Sometimes I get my facts mixed up, but I tend to admit it when it's pointed out to me, and often even thank whoever corrected me. It's the only reason I still have excellent karma despite being regularly downmodded for posting correct information.:)
What you fail to see is that I addressed the fact that what he claims is only possible on OSX is, in fact, possible in Windows and Linux, as well. You can, in fact, install a second OS on a separate partition and both boot to it and run it in a VM, in both Windows and Linux; you can also do the same installing a second OS on a virtual disk. Bootloader support is there in Windows and most major Linux distros, out of the box. Hell, you can boot 3, 4, or any arbitrary number of operating systems you wish on a Windows or Linux PC; you just can't natively boot OSX on one.
That you can't boot OSX on commodity PC hardware, which hasn't been blessed by Apple, is an artificially enforced a shortcoming of OSX, as Apple does actively work to prevent that. Were apple to remove the "genuine hardware" checks (which Chameleon bypasses) from the kernel, OSX would boot just the same on any PC build with supported (whether blessed or not) hardware. And, before anyone jumps on my for trying to make this a religious issue, I'd like to point out two facts:
Slashdot Mirror
Why spend the $10 most carriers charge for a SIM if you don't have to?
Yes, in most cases, that's what happens. However, this article is about iPads bought from Apple, which AT&T has no right to lock.
This isn't about equipment purchased from AT&T, on or off contract, with an AT&T SIM, SIM-locked to AT&T's network. This is about equipment purchased from Apple, off contract, with an Apple SIM, not SIM-locked to any network. AT&T is locking that Apple SIM (not the device) to AT&T's network, forcing you to buy another Apple SIM if you wish to switch carriers, something no other carrier is doing. A SIM card, once locked to a carrier, can not be unlocked.
What claim that I supposedly made are you arguing? My claim was based on my own personal experience; I went to patch my CentOS boxes first and there was no patch available, so I patched my Debian and Ubuntu boxes, then came back and the patch was available for CentOS. I never claimed that Canonical had any involvement in creating the patch, which appears to be the point you're arguing. RedHat likely had the patch in their repos before anyone, as the developer of the patch, as you correctly point out, works for them; however, that does not change the fact that it was available *to me* in Ubuntu and Debian's repos before I was able to get it from CentOS's repos.
Real life personal experience: the most reliable source of all.
"Most". You make it sound like they never fix *any* bugs. Funny, in the past month I've updated a few dozen packages and about 1/3 of those were security updates, so it sure looks like they're covering their bases regardless of their upstream provider's security team. For example, I didn't see any remarkable delay in the release for Shellshock patches; Ubuntu had them all out before CentOS, for example, and they were available for my Ubuntu systems by the time Debian had them out. I oversee systems running on all three distros and CentOS has been, by far, the worst in this regard.
Well, yes, Ubuntu forks its development releases from Debian's development release, which would be Debian Unstable. That would seem to make sense, and they're not just taking Debian's Unstable branch, throwing their branding onto it, and calling it an Ubuntu release. Way to throw half-facts out there and spread FUD, though.
Actually reading the thread (I know, this is /. and that doesn't happen), the issue is that OwnCloud wanted the package removed from an *already released* repository, which Ubuntu refused, so as not to affect users actually using it, while providing three possible interim solutions. The end result was removal of the package from the repo of the next release. Problem solved.
115,000 open bugs in how many different packages/projects that comprise the entirety of the OS? A hair over 70k, so averaging less than 2 bugs per package. And of those 70k packages, how many are installed on a default Ubuntu desktop system? On my server, there are only 660; that's including server packages that a desktop wouldn't have and excluding desktop packages that my server doesn't need, so I don't know if the desktop install has more or less.
Statistically, assuming even distribution of bugs across all packages in the system, I should expect to be affected by about 1100 bugs. There are some real questions that need to be asked, though. For instance: How many of those bug reports are actually valid? How many were fixed upstream and simply never closed? How many are stupid shit like "this text should be in that font" versus the number that actually impact performance or productivity? And, most importantly, how does Ubuntu compare with other distros, offering fewer packages overall, in bugs-per-package?
Anything in the name of racism and classism. Right?
You know, it may be the case that the Jews in government do look out for each other, but that doesn't necessarily extend to all Jews; in fact, it's just as likely that all members of the government cover each others' asses equally, Jew or not.
Likewise, gang members looking out for each other doesn't extend to them looking out for members of other gangs. The implication you're making is akin to saying black people can't be racist, or that all white people are.
On one hand, he's mostly correct about the correlation. On the other, he's way off base with regard to causation. Jews aren't bad people, they're just Jews.
No. I was explaining, to you, how clicking an icon and typing into the command line are not the same. It's really not my fault you missed that.
No, it's not. Dragging the icon for the image into the icon for the image viewer is exactly the same, in that you're specifying "open this file with that application". Doublie-clicking is most certainly not the same, especially when Windows defaults to "hide known file extenstions" and your malicious application is named "bigboobies.jpg.exe" with an icon that looks like a thumbnail of some boobs. The user sees "bigboobies.jpg", thoughtlessly ignores that no other legitimate images on their system show a file extension, and double clicks it; the malicious application now executes. Hell, if known extensions are hidden, simply naming it bigboobies.exe and giving it a titillating icon would fool 99% of users, even power users.
Here's why:
Typing "image_viewer.exe bigboobies.jpg" would launch image_viewer.exe, which would then tell you the file was not found. Dragging the icon of the "image" to the icon for "image_viewer.exe" or typing "image_viewer.exe bigboobies.jpg.exe", were you not to notice the ".exe" at the end, would launch image_viewer.exe, which would then complain that the file you fed it was not an image. Double-clicking an icon triggers the default action for the file type of the file the icon belongs to; in other words, if it's a sneakily-named executable, it executes it.
That may or may not be true, but Slashdot uses Arial and I'm far too lazy to override fonts for every site I visit. Given that I'm running Yosemite, however, your point is moot; I've got Helvetica (actually Helvetica Neue) all over the place.
That was a good jab, though, and I wish you a +5, Funny.
For example their best selling model of laptop for many years is the 13" macbook pro
So, we're in agreement, then, that their best selling laptop is the cheapest non-Air model they currently sell? Good.
Meanwhile, the rest of your argument comes down to "the screen you said has the best DPI actually has the worst". For the benefit of any readers we are entertaining with our debate, the comment in question is:
The new 27" retina 5k iMac ships with a screen that's much higher resolution than retina. It's really the only display they sell, currently, that comes close to possibly cleanly rendering the print font they've co-opted as a display font.
I then stated, in a subsequent post:
I misspoke in my previous reply.
In other words, I acknowledge that parts of my previous post were incorrect and hereby retract the arguments made therein. Yet you continue attacking those retracted arguments. That you can't argue the points I've left on the table shows just how weak your position actually is.
The fact is that Apple sells more MacBook Air and non-retina MacBook Pros (by your own admission, the 13" non-retina is the most popular model) than they do Retina Macbook Pros and there is a single Retina iMac model, the most expensive (and, historically, the most expensive product in one of Apple's lines has always sold marginally worse than the least, with the best seller being somewhere in the middle; the current MacBook Pro line being the outlier, with the least expensive model leading the pack), which is competing with 5 lower-priced models, ranging from 43% (coming in at the same price as the non-retina 13" MBP) to 80% of the price of the Retina model. From the cheapest iMac, that's a $1400 price differential; from the most expensive non-retina, it's a $400 jump; the jump from the non-retina 13" MBP to the Retina 13" MBP is only half that, $200. Are you seriously expecting me, or anyone else here, to believe that people who won't pay $200 for a retina display will somehow pay $400 for one?
It came with ipfw, but that was deprecated and replaced with PF in Lion. In short, ipfw has been removed from Yosemite.
especially if
I'm assuming you realize what that means and were just making a point. Since I was also making a point, allow me to clarify. A "normal listening volume" is one at which you can hear the music over the ambient noise in the room; "especially if" means "in addition to this case, there are other, possibly more common, cases where this happens". In short, you don't have to listen to Bose drivers at eardrum-splitting volumes to hear them distort and, without active noise cancellation, they're typically going to be driven at a level where the distortion is glaringly noticeable.
Even when they're not "driven to distortion", they're still just "acceptable okay"; is that what you want in a >$100 pair of headphones? Probably not; consider that you can get noise isolating headphones with drivers that blow away anything Bose currently puts out for half the price and get the same listening experience, as the outside noise that does get through in your average semi-quiet listening environment (e.g. anywhere you don't have to blast your eardrums to drown out the background noise) will be roughly equivalent to the distortion you'd get from the Bose drivers. Where the Bose set wins out is in louder environments, and they license the tech, so why not buy a pair from someone else, with better drivers and the Bose ANC?
In short, I don't think we disagree, I think my point was simply not made clearly enough the first time around.
There we go! Someone arguing with logic! I actually hadn't thought of that; I guess it's for the best, then, that I think Helvetica looks just fine at 133ppi on my 17" MBP. Too bad I'm still going to have to hear a substantial portion of the rest of the population groaning about it, though...
So then, you're implying that I must be spending time manually resolving conflicts within my solution? It's possible that you're implying that I've never encountered two people editing the same file between syncs, let alone the same line, but let me assure you that I have; which leaves the former option. Let me also tell you that I've not had to manually resolve any conflicts, as the solution I built does a fine job of this. For you to tell me that I do not understand data sync when I've built a data sync solution myself; many, in fact, the Git-based solution I'm bringing up here is simply the most recent, is the insult. If you think the problem is so difficult, it is not unreasonable for me to wish to avoid your work, even if you do find it insulting. There's nothing empty about that.
I really need to start proofreading my longer posts better... "When you're using an all" should read "When you're using an app" and the last line should contain a question.
What you haven't realised is the difficult part is automatically resolving sync conflicts.
Well, it doesn't seem to be a problem in the solution I'm currently using. Mind you, sarcasm>I probably have no clue how it works, given that I implemented it/sarcasm>. But you go right on ahead and keep telling me it's a hard problem. Difficult for you, perhaps, but not hard; there are a finite number of possible solutions and it should not be difficult for a well-built system to solve. True, Git (which I used as the basis for my solution) doesn't do a very good job of this natively; it took some creative and well thought out commit and merge hooks to accomplish it, a good day's work, for sure.
You are correct, though, that there is no one-size-fits-all solution for what to sync and how to handle merging of whatever does eventually get synched. But, then, I never claimed that there was; my claim was that the transport part of the equation is, and has been for decades, solved. Can you argue that point?
Earlier, you said:
They are file formats. They are not methods of handing off open documents between different devices without first saving them somewhere. Completely different thing.
And I didn't disagree. I did, however, point out that the documents are, in fact, saved somewhere (e.g. a temporary file, at the very least), out of necessity. I also pointed out why this was necessary, e.g. if you at all care about data consistency and preventing work loss in case of loss of power or a software or system failure. Can it be done without a temporary file somewhere local? Sure, and without issue, as long as you never lose connectivity or power while working, and your software and system never crash. If you live in a perfect world, you are correct to say that a temp file provides no benefit; however, neither I, nor anyone else I know, live in such a world. When you're using an all that utilizes cloud storage and the app crashes or you close it while you happen to not have any connectivity, it is able to restore your work only because it stored it in a local temp file somewhere.
What application(s) are you involved in. I would like to avoid them.
So, one iMac base model, the most expensive, renders the other 5 base models that will comprise at least 90% of iMac sales insignificant? The two MacBook Air base models and 13" non-retina MacBook Pro base model which, combined, outsell the 5 retina MacBook Pro retina base models, are insignificant? What of the argument in my other post, to which this was a follow-up and correction?
I misspoke in my previous reply. The 5k 27" is considered retina, the 21" and non-5k 27" are not. Look at Apple's own marketing for validation of my claim. You, sir, are wrong.
That's what I prefer to do. Sometimes I get my facts mixed up, but I tend to admit it when it's pointed out to me, and often even thank whoever corrected me. It's the only reason I still have excellent karma despite being regularly downmodded for posting correct information. :)
What you fail to see is that I addressed the fact that what he claims is only possible on OSX is, in fact, possible in Windows and Linux, as well. You can, in fact, install a second OS on a separate partition and both boot to it and run it in a VM, in both Windows and Linux; you can also do the same installing a second OS on a virtual disk. Bootloader support is there in Windows and most major Linux distros, out of the box. Hell, you can boot 3, 4, or any arbitrary number of operating systems you wish on a Windows or Linux PC; you just can't natively boot OSX on one.
That you can't boot OSX on commodity PC hardware, which hasn't been blessed by Apple, is an artificially enforced a shortcoming of OSX, as Apple does actively work to prevent that. Were apple to remove the "genuine hardware" checks (which Chameleon bypasses) from the kernel, OSX would boot just the same on any PC build with supported (whether blessed or not) hardware. And, before anyone jumps on my for trying to make this a religious issue, I'd like to point out two facts:
A) I'm a Mac user and
B) "Blessed" is Apple's own term.