Monitoring a folder is something you can script. Slashdotters ought have no problems with this...
Applescript (weird, english-like language that it is) is actually pretty powerful - Apple do make an effort to open up their apps for scripting, even though they're really GUI apps, and it's a really under-used feature. Shame.
I read it as the other way around. Linux, Windows, the Mac, just about everything cheat on fsync(). Posix allows this, and even allows a null implementation. Note that linux implements fsync() as a no-op for some filesystems, and that some versions (I don't know which) of Windows can remove fsync() functionality via a registry setting.
On the Mac, calling fsync() does the same thing as it does on anything else with a working fsync() call - it flushes all the data out to the drive and returns.
What the mac also provides is the F_FULLFSYNC fcntl, which does an fsync() then resets the drive controller to force the in-built RAM caches on the drive to be purged out to the physical disk platters. This is glacially slow, compared to the 'normal' fsync(), but under some circumstance may be worth it.
Even if you view this as anti-competitive, it's perfectly ok for Apple to be anti-competitive unless they have a monopoly in the relevant market (ie: phones).
They don't, so it's fine. Microsoft did, so it was a problem.
Wikipedia (of course!) talks about HCF - style instructions, and also mentions the killer poke specifically as "a killer poke is a method of inducing hardware damage (i.e., actual physical, irreversible damage) on a machine and/or its peripherals by the insertion of invalid values, via e.g. BASIC's POKE command, into a memory-mapped control register."
Er, it's easy to make software that irreparably damages embedded systems. We're not talking about software that runs in nice safe wrap-you-in-bubblewrap PCs any more.
Send the wrong configuration down to a CPLD or FPGA device and you can configure the voltage inputs to be (say) 1.2 volts when a 5v signal is being applied. Kiss bye-bye to that oxide layer in minutes (or seconds). If the part that's now burnt out is only used during configuration, or even just rarely (say a low-power situation), it may not be obvious that you're SOL.
Along comes a new configuration (the Apple one) and Boom!(TM) - dead hardware.
I don't know if the iphone contains configurable parts with that sort of vulnerability (like FPGA's) - I do know it contains an embedded system for the baseband receiver which needed to be configured for that update.
Embedded processor systems like these are *much* more vulnerable to the halt-and-catch-fire because they're expected to be configured in a certain way, and the QA is rarely done to make them bulletproof, like traditional processors.
As far as I can see, Apple were only being reasonable: it's entirely possible for the hacked reconfiguration of the GSM baseband system to have completely screwed it up (because it probably didn't dot every 'i' and cross every 't' - it was a trial-and-error job after all), and the problem to only become apparent when a new "proper" configuration was attempted.
So, pretty *not* precisely, IMHO. For what it's worth, I've blown CPLDs up on one project and months later come back to use the same board on another project and found out it was no longer reconfigurable. It worked fine in the configuration it had, but as soon as I reconfigured, no dice.
Go to the Apple store right now, and a refurbished macbook pro is indeed $1999. Click on the checkbox to add it to your basket, and the next page has Applecare for the MBP (with or without an extra screen) for $350.
Now you might still argue that's high, but that's what I'd expect to pay in *tax* in the UK...
I was under the impression that it did, and that it even used its predictive-text system with the pictogram-style input ?
Add that to the question: "What the hell has Apple got to "lose" regarding touch-screens anyway?" and it looks to me like someone wanted some hits, and Apple is a good brand-name to use to get them....
... the title is the start of the second paragraph. Perhaps Glen didn't read TFA...
From later on in TFA...
These clients pass their requests along, and it seems unlikely that they could be attacked directly unless an attacker had a computer on the same local network segment as the exposed system. In that case, the attacker would have a panoply of other network information poison available, and could disrupt DNS in a more efficient manner
[sigh] even the article title is "DNS Clients Have Small Vector of Risk after Patch",,, where is the word 'small' in the/. title... ?
Sounds like he followed the usual guidelines (well explained here). The slime-ball didn't actually divulge the fine details, just summarized that it was not cancer.
How, exactly ? There doesn't appear to be anything germane in that article.
After that rather arresting opening, he went on to say that he would give me some details about his recent health problems, but only if I would agree to keep them off the record.
...
Suffice it to say that I didn't hear anything that contradicted the reporting that John Markoff and I did this week. While his health problems amounted to a good deal more than "a common bug," they weren't life-threatening and he doesn't have a recurrence of cancer
This particular slime-ball obviously uses some definition of "off the record" that I am unaware of.
I don't care what you criticise Apple for, unless it's plain wrong. If it's wrong, I'll correct you, generally. You said:
If the FSF had said that it's completely impossible to write F/OSS for the iPhone, then yes, it's a lie, but so far all I've seen are comments pointing out that they obfuscate it needlessly
iPhone completely blocks free software. Developers must pay a tax to Apple, who becomes the sole authority over what can and can't be on everyone's phones.
So I guess you agree with me that they're lying, then ?
I had thought this was just a splinter group deciding to go it alone. I had thought that sanity would prevail, and that the FSF would step in and say "Sorry, we made a mistake". I hadn't for one minute considered that the FSF would simply abandon the moral high ground and deliberately go out of their way to harass Apple's customers like this.
But John Sullivan (Hi John!) is the manager of operations at the FSF. I now have to assume this is an official policy of the FSF, and an indicator of how the FSF intend to "communicate" with Apple from now on. Boy! Look how far the mighty have fallen. Such a pity. The FSF used to stand for the high ideals of freedom (that's freedom for everyone, John, not just for those politically-aligned with yourself).
Here's a suggestion, John, let those of you who oppose Apple's policies stop buying Apple products, and don't "keep quiet about it", shout it from the rooftops, declare it on your websites, start (non e-) mail campaigns, whichever method you like. I suspect you've been doing all that, and no-one who hears your message cares about it - that's the cold hard truth of the matter. So now you're going to go out of your way to interfere in and hassle these people who are ignoring you. Way to go, John, that'll get us all on-side.
And I love that second-to-last paragraph...
As for taking time away from Apple customers who need tech support, that is indeed regrettable but it's also inevitable
alternatively: The suffering of other people is a useful tool that I can use to try and get my message some more metaphorical airtime. As used by tinpot dictators throughout history.
Um, pay the cash if you want to install on the phone, but if all you're interested in are the principles of open-source s/w (which is what I understand by "the point of using Free Software"), then don't pay anything and just use the freely-downloadable SDK and the simulator. No need for any cash payments then....
There's free-as-in-speech, and free-as-in-beer. I was under the impression the freedoms that the FSF cared about were of the 'as-in-speech' variety. They do charge for "free" software delivered on tape, for example (well, they always did, I don't know if they do in this day and age).
For what it's worth, I've contributed to FSF projects (eg: gcc), and I've written a fair amount of software that I've open-sourced, even before the term became popular. I just disagree with lying to make a point (*) and with unnecessary guerilla tactics. I doubt the FSF will be seeing any more of my work - this recent tactical shift of theirs has seriously lowered my opinion of them.
Oh, and if you're going to quote me, please get the spelling right, as well. There's little point in misspelling a word I correctly spelt in the original, then putting quotation marks around it!
Simon.
(*) It becomes lying once a mistake has been pointed out, when no retraction is published, and when further action is taken which purports to be a consequence of the original position. We're waaaay beyond an innocent mistake here...
Yes. Nothing in the procedure I outline in the links requires a jail-broken phone. Everything there is an approved method of installing software onto the phones as recommended by Apple.
Apple does NOT (repeat that, NOT) prevent people from developing open-source applications. The FSF's rant was just that, an uninformed screed directed at a company that doesn't play ball with the FSF's politics.
Proof: Read the first link. I downloaded some source from the 'net, I compiled it, I modified it and compiled it again, then I installed it on my phone and it works just fine.
I had an email exchange with the author of the FSF's rant, and pointed out his errors. I think he and I still disagree, but to not even acknowledge the possibility that FOSS s/w is just fine and peachy on the iphone is intellectually dishonest. Not that that will stop the crazies from apple-hating... [sigh]
The first thing I ever did when I was on a system with 'mc' was to add
alias mc mv
into my ~/.tcshrc - One loose keytap and suddenly my whole terminal exploded with weird stuff happening. It was even worse when you're on dialup over a 9600 baud line to a unix box at the university.
[insert deity] I loathed that program, if only for its name.
Back in the mists of time, I wrote the database for the content management system that Lucas used on Star Wars I (the Phantom Menace). For reasons I won't go into, it was called 'Cakes', but ILM rebranded it internally as Media-DB.
At the peak of filming, it was coping with 40 DTF tapes/day being ingested. A DTF held 120GB back then (I think), and they were filming for ~3 months. At the same time as ingesting, it had to stream low-res proxies of all the footage to multiple destinations (some local, some not), and deliver high-res frames across the internal network to the animators etc.
Now, I doubt it was doing 40 tapes/day solidly - it'd depend on filming, but even taking 20 tapes/day, over 3 months that comes to ~160TB (assuming a 22-working-day month).
I do have fond memories of doing the James Bond intro-sequence (The world is not enough) with Smoke & Mirrors in London. When there were thousands of frames of nearly-naked highly-attractive women having oil poured all over their bodies, the visualisation tools became... significantly more advanced at a rapid rate:-)
Well, you only need a certificate if you want to build-and-install-on-the-phone, of course. If you don't want to splash out $99 on the developer-rights licence, you can still download the source and run on the simulator.
Something that no-one seems to pick up on is that the ad-hoc certificates basically allow full open-source distribution without any recourse to the app-store. See my blog post for more details.
You only have to pay $99 if you want to install open-source apps onto your phone as a developer. If you want to avoid paying Apple, you can just use the (free) simulator and get all the same (free) software development kit from Apple as the paid developers. You can still develop and share your code.
Additionally, the equivalent device for Microsoft would be the xbox (or the zune). Do MS even allow people other than large companies to develop for those platforms ? I'm not aware that they do... Perhaps you're holding Apple to a far higher standard here because obviously the (full, professional) Mac development kit is free from Apple - don't you have to pay for the professional version of Microsoft's developer tools ?
Seems to me as though Apple is giving a far better deal no matter how you look at it...
Hmm. PhD in Physics. Not *too* far over my head, I think. I can always be wrong (astrophysics wasn't my specialty), but I actually think it *is* a bold claim. When you extrapolate (note, not interpolate) *anything* by several orders of magnitude, you better be sure of your deductions.
Radiant energy intensity falls off with the square of the distance. Variation within that intensity therefore falls off at the same rate, and is consequently harder to detect above the noise threshold - with the relative distances we're talking about here, that noise threshold is looking scarily close...
Let's say there's a civilisation on Gamma Cephei (about 50 light years distant). Even if we just take into account the inverse-square law, the signal:noise ratio on Gamma Cephei is 27,808,132,115 *times* worse than the (already poor) signal:noise ratio of the reported experiment. Now toss in scattering due to space-born dust/whatever, red-shift effects, any interference effects, any gravitational effects, and it starts to look just a *little* bit harder, don't you think ?
Slashdot Mirror
Care to post the machine brand and model which matches a $2700 MBP, that we can buy for $799 ?
Didn't think so.
Simon.
If you read the link, I "got the idea" from the authors of SQLite. It's their claim, not mine.
Simon.
Monitoring a folder is something you can script. Slashdotters ought have no problems with this...
Applescript (weird, english-like language that it is) is actually pretty powerful - Apple do make an effort to open up their apps for scripting, even though they're really GUI apps, and it's a really under-used feature. Shame.
Simon
I read it as the other way around. Linux, Windows, the Mac, just about everything cheat on fsync(). Posix allows this, and even allows a null implementation. Note that linux implements fsync() as a no-op for some filesystems, and that some versions (I don't know which) of Windows can remove fsync() functionality via a registry setting.
On the Mac, calling fsync() does the same thing as it does on anything else with a working fsync() call - it flushes all the data out to the drive and returns.
What the mac also provides is the F_FULLFSYNC fcntl, which does an fsync() then resets the drive controller to force the in-built RAM caches on the drive to be purged out to the physical disk platters. This is glacially slow, compared to the 'normal' fsync(), but under some circumstance may be worth it.
See here for more info, specifically section 9.2.
Simon
Even if you view this as anti-competitive, it's perfectly ok for Apple to be anti-competitive unless they have a monopoly in the relevant market (ie: phones).
They don't, so it's fine. Microsoft did, so it was a problem.
Hope that clears things up...
Sorry to reply to my own post, but:
Wikipedia (of course!) talks about HCF - style instructions, and also mentions the killer poke specifically as "a killer poke is a method of inducing hardware damage (i.e., actual physical, irreversible damage) on a machine and/or its peripherals by the insertion of invalid values, via e.g. BASIC's POKE command, into a memory-mapped control register."
Er, it's easy to make software that irreparably damages embedded systems. We're not talking about software that runs in nice safe wrap-you-in-bubblewrap PCs any more.
Send the wrong configuration down to a CPLD or FPGA device and you can configure the voltage inputs to be (say) 1.2 volts when a 5v signal is being applied. Kiss bye-bye to that oxide layer in minutes (or seconds). If the part that's now burnt out is only used during configuration, or even just rarely (say a low-power situation), it may not be obvious that you're SOL.
Along comes a new configuration (the Apple one) and Boom!(TM) - dead hardware.
I don't know if the iphone contains configurable parts with that sort of vulnerability (like FPGA's) - I do know it contains an embedded system for the baseband receiver which needed to be configured for that update.
Embedded processor systems like these are *much* more vulnerable to the halt-and-catch-fire because they're expected to be configured in a certain way, and the QA is rarely done to make them bulletproof, like traditional processors.
As far as I can see, Apple were only being reasonable: it's entirely possible for the hacked reconfiguration of the GSM baseband system to have completely screwed it up (because it probably didn't dot every 'i' and cross every 't' - it was a trial-and-error job after all), and the problem to only become apparent when a new "proper" configuration was attempted.
So, pretty *not* precisely, IMHO. For what it's worth, I've blown CPLDs up on one project and months later come back to use the same board on another project and found out it was no longer reconfigurable. It worked fine in the configuration it had, but as soon as I reconfigured, no dice.
Simon.
No need to invoke conspiracy theories - just use good old Occam ...
WHILE TRUE
INT hatesAllThingsMac:
SEQ
IF
hatesAllThingsMac = 1
to.slashdot = post
Simon.
Go to the Apple store right now, and a refurbished macbook pro is indeed $1999. Click on the checkbox to add it to your basket, and the next page has Applecare for the MBP (with or without an extra screen) for $350.
Now you might still argue that's high, but that's what I'd expect to pay in *tax* in the UK...
Simon
I was under the impression that it did, and that it even used its predictive-text system with the pictogram-style input ?
Add that to the question: "What the hell has Apple got to "lose" regarding touch-screens anyway?" and it looks to me like someone wanted some hits, and Apple is a good brand-name to use to get them....
Simon the cynic.
Really ? Troll ? For pointing out that content *within* the article counters the sensationalism of the /. submission ?
Or is that one of those 'I hate Apple' moderations, or perhaps 'I disagree with your point of view' moderations ?
Hmm. Let me think...
Simon
... the title is the start of the second paragraph. Perhaps Glen didn't read TFA...
From later on in TFA...
[sigh] even the article title is "DNS Clients Have Small Vector of Risk after Patch" ,,, where is the word 'small' in the /. title... ?
Simon.
Sounds like he followed the usual guidelines (well explained here). The slime-ball didn't actually divulge the fine details, just summarized that it was not cancer.
How, exactly ? There doesn't appear to be anything germane in that article.
Simon
From TFA:
This particular slime-ball obviously uses some definition of "off the record" that I am unaware of.
Simon.
I don't care what you criticise Apple for, unless it's plain wrong. If it's wrong, I'll correct you, generally. You said:
From The FSF rant:
So I guess you agree with me that they're lying, then ?
Simon.
Jesus H Christ.
I had thought this was just a splinter group deciding to go it alone. I had thought that sanity would prevail, and that the FSF would step in and say "Sorry, we made a mistake". I hadn't for one minute considered that the FSF would simply abandon the moral high ground and deliberately go out of their way to harass Apple's customers like this.
But John Sullivan (Hi John!) is the manager of operations at the FSF. I now have to assume this is an official policy of the FSF, and an indicator of how the FSF intend to "communicate" with Apple from now on. Boy! Look how far the mighty have fallen. Such a pity. The FSF used to stand for the high ideals of freedom (that's freedom for everyone, John, not just for those politically-aligned with yourself).
Here's a suggestion, John, let those of you who oppose Apple's policies stop buying Apple products, and don't "keep quiet about it", shout it from the rooftops, declare it on your websites, start (non e-) mail campaigns, whichever method you like. I suspect you've been doing all that, and no-one who hears your message cares about it - that's the cold hard truth of the matter. So now you're going to go out of your way to interfere in and hassle these people who are ignoring you. Way to go, John, that'll get us all on-side.
And I love that second-to-last paragraph ...
alternatively: The suffering of other people is a useful tool that I can use to try and get my message some more metaphorical airtime. As used by tinpot dictators throughout history.
Simon.
Um, pay the cash if you want to install on the phone, but if all you're interested in are the principles of open-source s/w (which is what I understand by "the point of using Free Software"), then don't pay anything and just use the freely-downloadable SDK and the simulator. No need for any cash payments then....
There's free-as-in-speech, and free-as-in-beer. I was under the impression the freedoms that the FSF cared about were of the 'as-in-speech' variety. They do charge for "free" software delivered on tape, for example (well, they always did, I don't know if they do in this day and age).
For what it's worth, I've contributed to FSF projects (eg: gcc), and I've written a fair amount of software that I've open-sourced, even before the term became popular. I just disagree with lying to make a point (*) and with unnecessary guerilla tactics. I doubt the FSF will be seeing any more of my work - this recent tactical shift of theirs has seriously lowered my opinion of them.
Oh, and if you're going to quote me, please get the spelling right, as well. There's little point in misspelling a word I correctly spelt in the original, then putting quotation marks around it!
Simon.
(*) It becomes lying once a mistake has been pointed out, when no retraction is published, and when further action is taken which purports to be a consequence of the original position. We're waaaay beyond an innocent mistake here...
Yes. Nothing in the procedure I outline in the links requires a jail-broken phone. Everything there is an approved method of installing software onto the phones as recommended by Apple.
Simon.
Apple does NOT (repeat that, NOT) prevent people from developing open-source applications. The FSF's rant was just that, an uninformed screed directed at a company that doesn't play ball with the FSF's politics.
Proof: Read the first link. I downloaded some source from the 'net, I compiled it, I modified it and compiled it again, then I installed it on my phone and it works just fine.
I had an email exchange with the author of the FSF's rant, and pointed out his errors. I think he and I still disagree, but to not even acknowledge the possibility that FOSS s/w is just fine and peachy on the iphone is intellectually dishonest. Not that that will stop the crazies from apple-hating... [sigh]
Simon
The first thing I ever did when I was on a system with 'mc' was to add
alias mc mv
into my ~/.tcshrc - One loose keytap and suddenly my whole terminal exploded with weird stuff happening. It was even worse when you're on dialup over a 9600 baud line to a unix box at the university.
[insert deity] I loathed that program, if only for its name.
Simon
Back in the mists of time, I wrote the database for the content management system that Lucas used on Star Wars I (the Phantom Menace). For reasons I won't go into, it was called 'Cakes', but ILM rebranded it internally as Media-DB.
At the peak of filming, it was coping with 40 DTF tapes/day being ingested. A DTF held 120GB back then (I think), and they were filming for ~3 months. At the same time as ingesting, it had to stream low-res proxies of all the footage to multiple destinations (some local, some not), and deliver high-res frames across the internal network to the animators etc.
Now, I doubt it was doing 40 tapes/day solidly - it'd depend on filming, but even taking 20 tapes/day, over 3 months that comes to ~160TB (assuming a 22-working-day month).
I do have fond memories of doing the James Bond intro-sequence (The world is not enough) with Smoke & Mirrors in London. When there were thousands of frames of nearly-naked highly-attractive women having oil poured all over their bodies, the visualisation tools became... significantly more advanced at a rapid rate :-)
Simon.
Well, you only need a certificate if you want to build-and-install-on-the-phone, of course. If you don't want to splash out $99 on the developer-rights licence, you can still download the source and run on the simulator.
Simon.
Something that no-one seems to pick up on is that the ad-hoc certificates basically allow full open-source distribution without any recourse to the app-store. See my blog post for more details.
Simon
You only have to pay $99 if you want to install open-source apps onto your phone as a developer. If you want to avoid paying Apple, you can just use the (free) simulator and get all the same (free) software development kit from Apple as the paid developers. You can still develop and share your code.
Additionally, the equivalent device for Microsoft would be the xbox (or the zune). Do MS even allow people other than large companies to develop for those platforms ? I'm not aware that they do... Perhaps you're holding Apple to a far higher standard here because obviously the (full, professional) Mac development kit is free from Apple - don't you have to pay for the professional version of Microsoft's developer tools ?
Seems to me as though Apple is giving a far better deal no matter how you look at it...
Simon
Hmm. PhD in Physics. Not *too* far over my head, I think. I can always be wrong (astrophysics wasn't my specialty), but I actually think it *is* a bold claim. When you extrapolate (note, not interpolate) *anything* by several orders of magnitude, you better be sure of your deductions.
Radiant energy intensity falls off with the square of the distance. Variation within that intensity therefore falls off at the same rate, and is consequently harder to detect above the noise threshold - with the relative distances we're talking about here, that noise threshold is looking scarily close...
Let's say there's a civilisation on Gamma Cephei (about 50 light years distant). Even if we just take into account the inverse-square law, the signal:noise ratio on Gamma Cephei is 27,808,132,115 *times* worse than the (already poor) signal:noise ratio of the reported experiment. Now toss in scattering due to space-born dust/whatever, red-shift effects, any interference effects, any gravitational effects, and it starts to look just a *little* bit harder, don't you think ?
Simon