Now, looking at this iPhone SDK, the VoIP over Cellular is totally understandable, because if they allow that, then it'll totally undermine the revenue stream of the cell phone carriers. The iPhone, afterall, is first and foremost a phone.
Yeah, God knows you can't get Skype for a mobile phone. (Admittedly, they do say "In order to use Skype for Windows Mobile, your device must have a high speed wireless Internet connection over WiFi or 3G"; Skype over EDGE might not be good enough.)
Regarding Java, Apple might claim a legitimate concern that having a VM-based language will prevent programs from reaching guaranteed performance levels that native iPhone apps can achieve, thus "downgrading the user experience".
...which certainly explains why they haven't promoted the notion of Web apps on the iPhone.:-)
Regarding Firefox and Opera, I think the same argument can be used for game developers against XBox360 or PS3 or Wii consoles. As a hardware manufacturer, they have more rights to control what software goes onto their system (or what games).
And the argument against the consoles might be legitimate, too. Yes, the hardware manufacturer, if they also do the device firmware and software, has the technical capability to restrict the software that can be run, but the mere fact that they can do it doesn't oblige people to think it's OK for them to do so.
And looking at the chaotic state of Linux and GUIs (too much customizations means no standard to identify with), maybe Apple would like a firmer grip at the user experience.
However, I don't see the logic behind this move - or equally, behind anyone writing free apps for the iPhone via a jailbreak app.
...
Then a later version can close you out and bang, lay off time is here again.
Oh, noes! I've been laid off from my job of writing free apps for jailbroken iPhones for the fun of it!
(Yes, I suspect that's at least part of the logic - doing it for the fun of it. I doubt, for example, that there are zillions of customers who just won't buy an iPhone without term-vt100 and the BSD subsystem.)
And, quite frankly, if, for example, KDE were to implement a special set of calls that Konqueror could use to make it run faster, and that the KDE developers didn't consider "good enough to release", and that they didn't document because they didn't consider them "good enough", and somebody else wrote an application that used them, and KDE 4.1 or 5.0 replaced those calls with something the KDE developers considered more sustainable, and that broke that other application, my sympathy would be entirely with the KDE developers and not at all with the developer of the application in question.
What you say would make sense if closed source software was honest but honest people don't keep secrets.
Hopefully, honest people also, when they "reveal" an interface they consider to be an internal interface subject to change, and then have devlopers whine at them that an update broke their (application, plugin, etc.) because the interface changed, are in a position where they can be honest enough to say "tough shit" to the whiner. If not, that really removes an incentive to be honest.
(That isn't necessarily the only reason to keep secrets, but it's one reason to keep secrets. I get the impression that Linus, for example, is more than willing to say "tough shit" if somebody writes kernel code that assumes the kernel will always work the way it does now and has their code breaks because it starts working differently; if he says "tough shit" in that case, my sympathy would entirely be with him, not with whoever's software breaks. Don't want your software to break? Don't use interfaces that the supplier of the interface doesn't guarantee won't change in an incompatible fashion.)
You can see some evidence of the fact that IBM are trying to lower costs by sharing a lot of the design between the two lines though from certain new additions to the POWER instruction set, such as hardware support for Binary Coded Decimals (useful in high-throughput financial systems and present in the mainframe line since the 1401 and 700-series, which preceded System/360).
...and also present in the AS/400^WiSeries^WSystem i, which currently uses POWER processors, although the BCD stuff in POWER6 is probably as much for IEEE 754r floating-point decimal as for any commercial fixed-point BCD stuff.
My thinking was that since the Higgs boson is supposed to explain mass it may also help explain gravitation, since the two are obviously linked in some way.
Actually, in general relativity, gravitation is linked to energy and momentum, not just (rest) mass (well, to the stress-energy tensor, which includes not just energy and momentum per unit of space - energy and momentum density - but the flux of energy and momentum), which is why, for example, photons, with no rest mass, are still affected by gravity and affect other particles through gravity.
That's why physicists are so keen on finding a so called "God Particle", because gravity still can't be explained. We can model its effects, but since space doesn't curve some other mechanism must be at work to transfer gravitational force between objects.
The Higgs boson isn't what transfers gravitational force between objects, so finding it won't help there. (And one could argue that the Higgs field is a mathematical model, too.)
Zen Buddhists "knew", or rather *experienced* such things twenty five centuries ago, and they weren't first either.
They knew, or rather *experienced*, that mass was due to spontaneous breaking of electroweak gauge symmetry by a scalar field?
(Hint: there's a lot more to this than "woo woo, there's something out there that interacts with everything". That's why some people are irritated by the Gizmodo quote in question.)
Photons aren't supposed to have mass (otherwise they couldn't travel at light speed), so how are they affected by gravity?
By having momentum and energy, even if they don't have rest mass, and by living in a world where, it appears, Einsteinian gravity (i.e., general relativity), where it's energy and momentum, rather than just (rest) mass, that matters, rather than Newtonian gravity.
In fact, the gcc or g++ commands are 'drivers' that first call a preprocessor, then a compiler, then an assembler and finally a linker (all of them separate executables).
...following in a UN*X tradition that dates back long before GCC (at least back to Dennis Ritchie's C compiler for PDP-11 UNIX).
No, not every compiler does. Most if not all UN*X compilers do ("generate assembly and let the assembler handle generating an object code file" is a long-standing UN*X tradition, antedating GCC), but at least some compilers on non-UN*X OSes generate object code directly.
They are studying CP violation which is the difference between matter and anti-matter
Well, perhaps more precisely, it's the difference between matter and anti-matter as a whole - the difference between a particular bit of matter and the particular corresponding bit of anti-matter is that their quantum numbers, such as charge, are inverted (so that, for example, a particle with charge N has an anti-particle with charge -N). It was originally thought that if you had some physical interaction between particles, and you replaced all particles with their anti-particles, you'd get the same interaction (modulo flipping all the charges) - and that if you had some interaction between particles, and you reversed all three dimensions in a mirror, you'd again get the same interaction (modulo flipping all the dimensions). However, that doesn't happen for weak interactions; you have to flip all the charges and mirror-reflect all the dimensions to get the same behavior.
And then they found that even doing that wasn't good enough - flipping the charges and mirror-reflecting all three dimensions doesn't do the job, either, which is what CP violation refers to. You also have to run the interactions backwards in time to get them to work the same way. (If that doesn't work, cats and dogs start living together.:-))
For the benefit of those who think "Dolly" when they hear "Parton", the parent artice is presumably talking about the parton model, devised by Feynman to explain some high-energy collision results; as the article says, eventually the partons Feynman talked about were identified with the quarks that Gell-Mann and Zweig proposed, and the gluons that bind them together in hardons^Whadrons. (Oh, and "Bjorken" is James Bjorken.)
You mean the Linux distro that doesn't support the iPod touch (that being one of the two machines the original article was talking about) - and thus probably doesn't support the iPhone (that being the other of the two machines the original article was talking about), either?
Just thought of this: Make it stipulation of GPL that if you publically report bugs or bug counts in GPL software, that you must also produce a detailed account of how to reproduce the bug, and you must provide that report to the maintainer of the current source (who you got it from, or the root source as listed in the code). Possibly a two-week window between notification (and acknowledgement) and publication.
Not all bugs are easily reproducible - and not all bugs are found by tripping over them. Consider, for example, bugs found by various of the warnings enabled by GCC's -W options. I.e., you get reports saying "this code path has these problems", not reports saying "this code path blew up when I did XXX".
I just looked at an old report from Coverity on one of the free-software projects with which I'm involved - one of the problems it found was in a chunk of code
if (cfg->in)use) { report an error; return; } if (cfg != NULL) { process what it points to; } else { report an error and clean up; return; }
where it quite appropriately pointed out that we were checking whether cfg was null after dereferencing it rather than before dereferencing it. We subsequently fixed that problem.
It might be possible to construct a scenario where the application would crash due to that bug - or it might not; that bug is in "framework" code, and if the code using that framework code doesn't happen to pass an argument that would cause cfg to be null, there won't be a crash, but some code in the future might pass such an argument (which might be an argument that comes from user input, so it's not as if passing such an argument is a bug - perhaps the code using the framework code is expecting that code to tell the user of the error).
Even if it's possible to construct such a scenario, the software that found the problem doesn't have a deep enough understanding of the code to say "hey, if you open up the app on a file like with this in it and select this menu item and type this into the dialog box that pops up and then click 'OK', it'll crash", so it's not as if the software that's reporting this problem (non-publicly - to see the reports on an app, you have to be a "member" of the project whose code is being scanned, and sign up for an account) can give "a detailed account of how to reproduce the bug".
Slashdot Mirror
The Communist Party's newspaper's Web site doesn't appear to run on Linux, unless there's an IIS port to Linux:
As opposed to those other Apple products that are only sold to hackers, not to consumers, and thus don't need those restrictions.
Yeah, God knows you can't get Skype for a mobile phone. (Admittedly, they do say "In order to use Skype for Windows Mobile, your device must have a high speed wireless Internet connection over WiFi or 3G"; Skype over EDGE might not be good enough.)
...which certainly explains why they haven't promoted the notion of Web apps on the iPhone. :-)
And the argument against the consoles might be legitimate, too. Yes, the hardware manufacturer, if they also do the device firmware and software, has the technical capability to restrict the software that can be run, but the mere fact that they can do it doesn't oblige people to think it's OK for them to do so.
Gee, I think Apple makes some equipment whose software isn't nearly so restrictive but still manage to keep from having anything as "chaotic" as the UNIX+X11 desktop.
Oh, noes! I've been laid off from my job of writing free apps for jailbroken iPhones for the fun of it!
(Yes, I suspect that's at least part of the logic - doing it for the fun of it. I doubt, for example, that there are zillions of customers who just won't buy an iPhone without term-vt100 and the BSD subsystem.)
No, regulation of phone companies began long before that.
Yes, I do.
And, quite frankly, if, for example, KDE were to implement a special set of calls that Konqueror could use to make it run faster, and that the KDE developers didn't consider "good enough to release", and that they didn't document because they didn't consider them "good enough", and somebody else wrote an application that used them, and KDE 4.1 or 5.0 replaced those calls with something the KDE developers considered more sustainable, and that broke that other application, my sympathy would be entirely with the KDE developers and not at all with the developer of the application in question.
Hopefully, honest people also, when they "reveal" an interface they consider to be an internal interface subject to change, and then have devlopers whine at them that an update broke their (application, plugin, etc.) because the interface changed, are in a position where they can be honest enough to say "tough shit" to the whiner. If not, that really removes an incentive to be honest.
(That isn't necessarily the only reason to keep secrets, but it's one reason to keep secrets. I get the impression that Linus, for example, is more than willing to say "tough shit" if somebody writes kernel code that assumes the kernel will always work the way it does now and has their code breaks because it starts working differently; if he says "tough shit" in that case, my sympathy would entirely be with him, not with whoever's software breaks. Don't want your software to break? Don't use interfaces that the supplier of the interface doesn't guarantee won't change in an incompatible fashion.)
Early '90's, as in 1990.
...and also present in the AS/400^WiSeries^WSystem i, which currently uses POWER processors, although the BCD stuff in POWER6 is probably as much for IEEE 754r floating-point decimal as for any commercial fixed-point BCD stuff.
Not really, but the zero rest mass is sort of a limit case.
Exactly zero, no, but you can put an upper limit on it, and the measurements say the upper limit is 1.1x10^52 kg. (One way to test it is to see whether the force between two electric charges is inversely proportional to the square of the distances between the particles - any deviation from that means the photon isn't massless.)
Yes.
Actually, in general relativity, gravitation is linked to energy and momentum, not just (rest) mass (well, to the stress-energy tensor, which includes not just energy and momentum per unit of space - energy and momentum density - but the flux of energy and momentum), which is why, for example, photons, with no rest mass, are still affected by gravity and affect other particles through gravity.
The Higgs boson isn't what transfers gravitational force between objects, so finding it won't help there. (And one could argue that the Higgs field is a mathematical model, too.)
They did, as far as I can tell; I couldn't find any sign of references to "The Force" in their article. That crap is from the Gizmodo article.
They knew, or rather *experienced*, that mass was due to spontaneous breaking of electroweak gauge symmetry by a scalar field?
(Hint: there's a lot more to this than "woo woo, there's something out there that interacts with everything". That's why some people are irritated by the Gizmodo quote in question.)
By having momentum and energy, even if they don't have rest mass, and by living in a world where, it appears, Einsteinian gravity (i.e., general relativity), where it's energy and momentum, rather than just (rest) mass, that matters, rather than Newtonian gravity.
...following in a UN*X tradition that dates back long before GCC (at least back to Dennis Ritchie's C compiler for PDP-11 UNIX).
No, not every compiler does. Most if not all UN*X compilers do ("generate assembly and let the assembler handle generating an object code file" is a long-standing UN*X tradition, antedating GCC), but at least some compilers on non-UN*X OSes generate object code directly.
Well, perhaps more precisely, it's the difference between matter and anti-matter as a whole - the difference between a particular bit of matter and the particular corresponding bit of anti-matter is that their quantum numbers, such as charge, are inverted (so that, for example, a particle with charge N has an anti-particle with charge -N). It was originally thought that if you had some physical interaction between particles, and you replaced all particles with their anti-particles, you'd get the same interaction (modulo flipping all the charges) - and that if you had some interaction between particles, and you reversed all three dimensions in a mirror, you'd again get the same interaction (modulo flipping all the dimensions). However, that doesn't happen for weak interactions; you have to flip all the charges and mirror-reflect all the dimensions to get the same behavior.
And then they found that even doing that wasn't good enough - flipping the charges and mirror-reflecting all three dimensions doesn't do the job, either, which is what CP violation refers to. You also have to run the interactions backwards in time to get them to work the same way. (If that doesn't work, cats and dogs start living together. :-))
For the benefit of those who think "Dolly" when they hear "Parton", the parent artice is presumably talking about the parton model, devised by Feynman to explain some high-energy collision results; as the article says, eventually the partons Feynman talked about were identified with the quarks that Gell-Mann and Zweig proposed, and the gluons that bind them together in hardons^Whadrons. (Oh, and "Bjorken" is James Bjorken.)
You mean the Linux distro that doesn't support the iPod touch (that being one of the two machines the original article was talking about) - and thus probably doesn't support the iPhone (that being the other of the two machines the original article was talking about), either?
So what is the evidence that conclusively shows that this has something to do with DRM?
Note, BTW, that one Adobe person says that "We're working with Apple to resolve the problem".
Offtopic? That is an example of LOLCODE, and the article does note that there's an implementation of LOLCODE atop Parrot.
Somehow the link to the story appears to have gotten lost.
Not all bugs are easily reproducible - and not all bugs are found by tripping over them. Consider, for example, bugs found by various of the warnings enabled by GCC's -W options. I.e., you get reports saying "this code path has these problems", not reports saying "this code path blew up when I did XXX".
I just looked at an old report from Coverity on one of the free-software projects with which I'm involved - one of the problems it found was in a chunk of code
where it quite appropriately pointed out that we were checking whether cfg was null after dereferencing it rather than before dereferencing it. We subsequently fixed that problem.
It might be possible to construct a scenario where the application would crash due to that bug - or it might not; that bug is in "framework" code, and if the code using that framework code doesn't happen to pass an argument that would cause cfg to be null, there won't be a crash, but some code in the future might pass such an argument (which might be an argument that comes from user input, so it's not as if passing such an argument is a bug - perhaps the code using the framework code is expecting that code to tell the user of the error).
Even if it's possible to construct such a scenario, the software that found the problem doesn't have a deep enough understanding of the code to say "hey, if you open up the app on a file like with this in it and select this menu item and type this into the dialog box that pops up and then click 'OK', it'll crash", so it's not as if the software that's reporting this problem (non-publicly - to see the reports on an app, you have to be a "member" of the project whose code is being scanned, and sign up for an account) can give "a detailed account of how to reproduce the bug".