At its root religions are unchanging, or at least the Judeo-Christian ones are meant to be.
Certainly the Abrahamic faiths all hold that there exist unchanging eternal truths. But all of them are also pretty fundamentally based on the idea that people keep getting those wrong, and certainly there are strains of thought within at least some of those faiths that relate to a progressively improving understanding of the truth moving humanity forward.
Certainly there are strains of thought within each that oppose that viewpoint, too, but I don't think you'll get any agreement on what that the Abrahamic faiths (or even just Judaism and Christianity) are "supposed" to be in this regard, even among adherents of those religions.
Not the % of which is axiom, In fact the whole christian belief system IS a huge axiom
That's certainly one possible approach to Christian theology, but its hardly the only one. "Christianity" is generally defined in terms of certain beliefs (one not-uncommon definition within Christianity is adherence to the beliefs articulated in the Nicene Creed, though there are even debates over what the content of that creed properly is), but the basis for those beliefs is rarely part of the definition. I doubt even most Christian theologians would distinguish Christian from non-Christian based on holding the defining beliefs contingently vs. axiomatically.
Recently, paradigms in physics have been interesting in this respect as the new perfectly subsume the prior in their limits. I am not sure that this is a tautology of science, but it is an elegant means of progression.
It seems to be, if not quite a "tautology" in the sense of true-by-definition, a fairly clear practical consequence of the scientific method. Since to be accepted as a scientific theory explaining behavior in some domain, a hypothesis must propose a falsifiable predictive models that fails efforts to falsify it, it necessarily must correctly predict observed behavior in some domain.
In order to displace such a theory, a new hypothesis must explain the behavior explained by the first theory as well as explaining some behavior that the old theory failed to explain. Consequently, while the mechanisms proposed may be different, insofar as a mathematical model is proposed, it pretty much has to reduce to either something identical to the old one or something indistinguishable from it within the limits of the accuracy of the test of the old theory, within the domain in which the old theory was successful.
Wouldn't be correct if it didn't. Newton wasn't *wrong*, he just didn't specify the parts he couldn't see.
Insofar as the model he proposed is not accurate, he certainly was. Of course, the wrongness was not evident within the limits of measurement accuracy in the conditions his models were tested in during his time (or for quite some time thereafter), and there certainly weren't any better models proposed, so the scientific community was not wrong to accept Newton's models as the best available models.
Same with Einstein
Well, Einstein's model had some problems that were known fairly shortly after they were proposed (the relation to with quantum mechanics, for instance). Science is, ultimately, pragmatic -- its not about ultimate truth (though the hope is that successive refinement will let us approach that to an ever-increasing degree) but about getting successively better models of reality.
Except neither Scala nor Erlang are functional languages....
Erlang and Scala are both languages designed to support programming in a functional style, and both are "recursive style" languages in that they optimize tail calls generally (Erlang) or at least in the most important case of self-recursive calls (Scala) and thus make tail-recursive (or, in Erlang's case, more general tail calling with unlimited depth) programming styles efficient.
Neither is a pure functional programming language, true.
Well, all functional programming languages use recursion
Most procedural programming languages use (or at least support) recursion, too. The difference is that (1) pure functional language cannot express certain algorithms with iteration instead of recursion because of the lack of mutable state, and (2) languages that don't support tail call optimization (at least in the trivial case of self-recursive tail calls) generally also don't efficiently support recursion, since recursion results in the accumulation of stack frames. A consequence of #1 and #2 is that pure functional languages almost without exception, as well as many less purely functional languages that designed to support programming in a functional style (e.g., Scheme), feature tail call optimization and have tail-recursive constructs as the most idiomatic way of expressing certain algorithms, whereas languages that aren't functional or designed with functional-style programming in mind, often have an iterative approach as the most idiomatic -- and most efficient -- expression of the same algorithms.
I admit that a function with no side effects can ease making things thread safe, but are recursive style functional programming languages really used that much in "SMP and concurrency programming" nowadays.
If by "recursive style functional programming languages" you mean (more or less) functional programming languages that support tail call optimization so that tail calls, including self-recursive calls, are efficient, then the answer is "yes".
Besides Haskell, Erlang, for instance, is such a language , and concurrent applications are one of its main strengths.
Definate killer application: Cloud-like sharing services but you retain total control of your data.
What's cloud like about it? It doesn't feature abstracting physical servers or dynamic provisioning, so its nothing like a cloud. Its a local server, so I suppose you could say "remote web hosting like", since its just like that, except that the content is locally hosted, and only the URL is someone elses.
Its an easy to configure web server plus a service -- that you don't control any more than you control "cloud" services you might use -- for mapping operaunite URLs to your computer. Its a nice tool/service, but I don't see any reason it should have any relationship to a browser. And, if its a popular kind of service, I expect something like it will be rolled into common OS's in not too long.
In what way? During the brief period I tried Bing, I was thoroughly unimpressed.
Me too, but they can learn if they want to.
I will grant that this is possible, but Microsoft has been in the web search business for quite a while, and hasn't shown much sign of wanting to.
Sure, they do periodic rebrandings with new features and huge PR campaigns that generate lots of media "Microsoft is seriously making an effort in search", but they don't seem to be interested in doing much more than what is required to periodically make it look like they might become relevant.
And competition can only be good for the search engine market, assuming it happens on a decent level.
Competition on user experience and search algorithms would be good. Competition that amounts to bribing sites to be listed only one engine -- which MS is apparently doing with Bing, witness the recent story about the Microsoft - News Corp discussions -- less so. Competition centering around deceptive bribes to users, as in this story, also less so.
But Chrome OS? I understand netbooks will run slightly faster with linux or some lightweight variant than with Windows XP, but really, the hardware's the limitation here, not the OS.
The big deal, as I see it, with Chrome OS isn't that the OS is so much more efficient, but things like the UI model (which isn't finalized and there are several possible directions), the security model designed to support both owner control and easy "pass-around" sharing without compromising things that should be secure, etc.
Browser speed is, of course, a focus of the Chromium projects (both the Chromium browser and the Chromium OS operating system and its specialized derivative of the browser), but really that's just part of the user experience focus in Chromium OS.
Still, he accurately predicted many techologies: communicator (i. e., cell phone)
ST communicators (at least in TOS, which was the only version of the show before actual cell phones) weren't very different from handheld radios, with a manual tuning knob that was shown used to try to improve the reception. Except for the size (and, IIRC, the fact that they were identified as transmitting FTL, though that might have only been in later written material), they weren't all that much different from what existed at the time the show was made.
phasors (i. e., laser cannon, for which the Pentagon has already designated a prime contracror to build the device
Lasers existed at the time Star Trek was made, too. Handheld laser weapons didn't, but Star Trek wasn't at all the first place where eitehr laser weapons specifically (which are treated as "old tech" in ST) or beam weapons more generally were predicted.
and warp drive (hyperdrive, which the Pentagon is now attempting to build).
As your own hyperdrive link states, both the "hyperdrive" and the "subspace" (a term also used by ST in the same context) were theorized in the 1950s. And other concepts of FTL travel existed. Star Trek was hardly the first place the existence of an FTL drive was proposed.
Way before Microsoft Powerpoint and other presentation software we had H. Ross Perot and his charts and graphs.
Business presentation software existed before H. Ross Perot's 1992 campaign. Harvard Presentation Graphics, from the mid-1980s, is one of the better known earlier examples, if not necessarily the first dedicated business presentation software.
Actually, checking Wikipedia, PowerPoint was around before H. Ross Perot's 1992 campaign, as well, being first released for the Mac in 1987 and for Windows 3.0 in 1990.
v8, Chrome's Javascript engine, is what started most browsers, including Firefox, improving their Javascript engines by 2, 3, even 10 times.
IIRC, Mozilla had already committed to a particular new Javascript engine for future Firefox because of speed advantagages when Google Chrome and V8 were announced.
I also have to stop saying Chromium, because that is just the browser. The whole OS project is just called Chrome.
Regarding the "Chrome" and "Chromium" names from Google:
The open source browser project is "Chromium". The open source OS project is "Chromium OS". The Google-branded browser product is "Chrome". The Google-branded OS product which has been announced is "Chrome OS".
Repeat after me. I want my applications locally, where I can use them regardless of having a network or not.
The intent is for that facility to be provided by web apps with offline functionality, something that has been important to Google since before Chrome OS was conceived (or, at least, announced as something they were working on.)
The whole world could burn down and I could still do my work with my PC (as long as I survived).
The only initial barrier to do that with Chrome seems to be that the first time a user logs on, network connectivity and a Google Account is required, although Google has stated that that initial limitation is just that: they want to work with other authentication sources, specifically they've cited having an OpenID alternative as a goal. While this still requires network connectivity, something as simple as a home LAN with an lightweight server doing authentication would work. And, since Chrome OS is targetted for netbooks, a certain degree of network dependency is not as critical as it would be if it was intended to be a general-purpose desktop OS.
Now, you may have an issue with the entire idea of a netbook-specific OS and prefer just a general purpose desktop OS with slight visual adaptation to the limit screen real estate -- and that's certainly a reasonable preference. But I don't think that all netbook users are going to share that preference.
I don't think a great deal of thought actually went into it.
I think that its pretty clear from reading the pages on the design and plans that a great deal of thought has gone into it.
I think its equally clear that what has been released has not realized all of the things that are planned for it, and that it is not intended to be a production release, a release candidate, a beta, or even an alpha release, but more an opening up of the development code base and the work-in-progress plans to public view and comment.
Face it, "Chrome OS" isn't an operating system in any way. It's a web browser running on a Linux distribution.
Chrome OS is an operating system. Specifically, it is specialized a Linux distribution where the in place of a traditional desktop environment, a variation of the Chrome browser is sued. Since a specialized Linux distribution is an operating system, so is Chrome OS.
It may not do what you want out an operating system to do, and that may make it a bad operating system for your use. That doesn't make it not an operating system, however.
Pervasively object-oriented, with anonymous classes, metaclasses and proper private methods. However, if your keyboard doesn't have a period, you could be convinced it pervasively functional, since it has 1st-class blocks, closures and continuations.
Continuations have been removed from the core of Ruby, though they remain a library feature available with the main Ruby 1.9 implementation. They were removed for a number of reasons -- one is that no one was using them directly in production code (in part, that was a result of the fact that the pre-1.9 implementation was horrendously inefficient and produced memory leaks), and other features that they were in theory useful for (and the one thing in the standard library that leveraged them) were replaced with a more limited, tightly focussed coroutine feature (Fibers).
With the cleaned-up continuation implementation in 1.9, if enough of the alternative interpreters do implement them as well (I think its on the plans for some, though not JRuby, the main alternative) and they get much use, I can see them working back into the language core.
I think that refusing to pay *any* dividend is just control-freakery.
I think its just a response to tax policy. Money spent on dividends directly reduces the value of stock compared to not paying the dividend, and since (but for fairly recent tax policy changes that sunset soon, and so would form a poor basis for corporate policy changes) long-term capital gains are more favored under the tax code than dividends, offering dividends is directly contrary to the financial interests of the shareholders.
If the Chrome OS is only an access point into a Google (or other) cloud then it is of no interest to me and shouldn't be of interest to anyone else.
Its not.
Its primarily designed as an interface into remotely hosted applications (though supporting applications that can run in an "offline mode" is a key feature) using web standards, but cloud computing (server abstraction and dynamic provisioning) have little to do with that except that it can provide a convenient platform for web apps, and the parts of "cloud computing" (really, just remote application hosting, which was around long before cloud computing) that Slashdotters tend to complain about ("ZOMG! I can't control my own data!") have even less to do with it, since nothing stops the apps you use on your Chrome OS device from being hosted on the inexpensive Linux-based server you've got plugged into your home router.
About the only thing either of those have to do with Google Chrome OS is that some aspects of Chrome OS will leverage facilities on Google's cloud, and that Google of course hopes that beyond that, Chrome OS users will find it a convenient platform for using Google's existing cloud-based apps. But its an open source project, so the first of those things can be replaced, and you are no more forced to use Google's other cloud apps with Chrome OS than you are with the existing Chrome browser.
Poor Fox - they think their content is important enough to change the behavior of the entire web surfing public.
Wouldn't that be "poor Microsoft"? After all, Microsoft is the one that would be paying for exclusive listings for News Corp. sites. If it doesn't help Microsoft gain search market share, News Corp. still gets the money, and I'm guessing that their audience is pretty dedicated, and isn't getting to their pages incidentally through search, so I don't think they stand to lose much even if the search audience doesn't follow them to Bing.
They have to know that they're never going to get the source code. A) It'd be an incredibly earth-shattering precedent, and B) it's beside the point to what they're charging.
No, it wouldn't; source code has been ordered produced in discovery before (and this is a discovery motion, not a requested remedy), and its directly relevant to what they are charging.
It doesn't matter of Apple and AT&T colluded to brick one hacked phone, odd-numbered hacked-phones, or even hacked phones on Verizon's network.
Actually, it does, especially since the plaintiffs are seeking certification of the suit as a class action suit, and which of those AT&T targetted has a pretty serious effect on the identity and size of the class.
If the issue is the practice of tying the purchase of an iPhone to the purchase of an AT&T service plan, the source code is not relevant.
The issue isn't just the practice of tying the purchase of an iPhone to the purchase of an AT&T service plan, it is the damage that was inflicted on iPhone owners in Apple & AT&T's attempt to enforce the restriction on the use of the iPhone to only be used with the AT&T service plan (which is distinct from and goes beyond tying the purchase of the device to the purchase of a service plan.)
How exactly does an antitrust suit work against a player that doesn't have anything resembling monopoly power in the market in which it operates?
Probably because, while monopolies are specifically a subject of antitrust law, they aren't the only thing it covers. Antitrust laws deal with a wide range of anticompetitive and unfair practices in trade.
Not only that -- why exactly would relief by gained by Apple turning over the source to the iPhone OS?
The demand for the source code isn't as a remedy, its a discovery motion. The plaintiffs' reason for it is addressed in TFA, which quotes the motion itself: "Unless Plaintiffs are given access to Version 1.1.1 source code, their ability to prove the size and scope of the Class affected by Version 1.1.1 will be severely compromised and unfairly prejudiced."
Slashdot Mirror
Certainly the Abrahamic faiths all hold that there exist unchanging eternal truths. But all of them are also pretty fundamentally based on the idea that people keep getting those wrong, and certainly there are strains of thought within at least some of those faiths that relate to a progressively improving understanding of the truth moving humanity forward.
Certainly there are strains of thought within each that oppose that viewpoint, too, but I don't think you'll get any agreement on what that the Abrahamic faiths (or even just Judaism and Christianity) are "supposed" to be in this regard, even among adherents of those religions.
That's certainly one possible approach to Christian theology, but its hardly the only one. "Christianity" is generally defined in terms of certain beliefs (one not-uncommon definition within Christianity is adherence to the beliefs articulated in the Nicene Creed, though there are even debates over what the content of that creed properly is), but the basis for those beliefs is rarely part of the definition. I doubt even most Christian theologians would distinguish Christian from non-Christian based on holding the defining beliefs contingently vs. axiomatically.
It seems to be, if not quite a "tautology" in the sense of true-by-definition, a fairly clear practical consequence of the scientific method. Since to be accepted as a scientific theory explaining behavior in some domain, a hypothesis must propose a falsifiable predictive models that fails efforts to falsify it, it necessarily must correctly predict observed behavior in some domain.
In order to displace such a theory, a new hypothesis must explain the behavior explained by the first theory as well as explaining some behavior that the old theory failed to explain. Consequently, while the mechanisms proposed may be different, insofar as a mathematical model is proposed, it pretty much has to reduce to either something identical to the old one or something indistinguishable from it within the limits of the accuracy of the test of the old theory, within the domain in which the old theory was successful.
Insofar as the model he proposed is not accurate, he certainly was. Of course, the wrongness was not evident within the limits of measurement accuracy in the conditions his models were tested in during his time (or for quite some time thereafter), and there certainly weren't any better models proposed, so the scientific community was not wrong to accept Newton's models as the best available models.
Well, Einstein's model had some problems that were known fairly shortly after they were proposed (the relation to with quantum mechanics, for instance). Science is, ultimately, pragmatic -- its not about ultimate truth (though the hope is that successive refinement will let us approach that to an ever-increasing degree) but about getting successively better models of reality.
Erlang and Scala are both languages designed to support programming in a functional style, and both are "recursive style" languages in that they optimize tail calls generally (Erlang) or at least in the most important case of self-recursive calls (Scala) and thus make tail-recursive (or, in Erlang's case, more general tail calling with unlimited depth) programming styles efficient.
Neither is a pure functional programming language, true.
Most procedural programming languages use (or at least support) recursion, too. The difference is that (1) pure functional language cannot express certain algorithms with iteration instead of recursion because of the lack of mutable state, and (2) languages that don't support tail call optimization (at least in the trivial case of self-recursive tail calls) generally also don't efficiently support recursion, since recursion results in the accumulation of stack frames. A consequence of #1 and #2 is that pure functional languages almost without exception, as well as many less purely functional languages that designed to support programming in a functional style (e.g., Scheme), feature tail call optimization and have tail-recursive constructs as the most idiomatic way of expressing certain algorithms, whereas languages that aren't functional or designed with functional-style programming in mind, often have an iterative approach as the most idiomatic -- and most efficient -- expression of the same algorithms.
If by "recursive style functional programming languages" you mean (more or less) functional programming languages that support tail call optimization so that tail calls, including self-recursive calls, are efficient, then the answer is "yes".
Besides Haskell, Erlang, for instance, is such a language , and concurrent applications are one of its main strengths.
What's cloud like about it? It doesn't feature abstracting physical servers or dynamic provisioning, so its nothing like a cloud. Its a local server, so I suppose you could say "remote web hosting like", since its just like that, except that the content is locally hosted, and only the URL is someone elses.
Its an easy to configure web server plus a service -- that you don't control any more than you control "cloud" services you might use -- for mapping operaunite URLs to your computer. Its a nice tool/service, but I don't see any reason it should have any relationship to a browser. And, if its a popular kind of service, I expect something like it will be rolled into common OS's in not too long.
I will grant that this is possible, but Microsoft has been in the web search business for quite a while, and hasn't shown much sign of wanting to.
Sure, they do periodic rebrandings with new features and huge PR campaigns that generate lots of media "Microsoft is seriously making an effort in search", but they don't seem to be interested in doing much more than what is required to periodically make it look like they might become relevant.
Competition on user experience and search algorithms would be good. Competition that amounts to bribing sites to be listed only one engine -- which MS is apparently doing with Bing, witness the recent story about the Microsoft - News Corp discussions -- less so. Competition centering around deceptive bribes to users, as in this story, also less so.
The big deal, as I see it, with Chrome OS isn't that the OS is so much more efficient, but things like the UI model (which isn't finalized and there are several possible directions), the security model designed to support both owner control and easy "pass-around" sharing without compromising things that should be secure, etc.
Browser speed is, of course, a focus of the Chromium projects (both the Chromium browser and the Chromium OS operating system and its specialized derivative of the browser), but really that's just part of the user experience focus in Chromium OS.
Chromium is the Google-run open source browser project on which the Google-branded Chrome browser is based.
Chromium OS is the Google-run open source OS project which uses a Chromium-based browser on top of a (somewhat tweaked, IIRC) Linux kernel and X11.
ST communicators (at least in TOS, which was the only version of the show before actual cell phones) weren't very different from handheld radios, with a manual tuning knob that was shown used to try to improve the reception. Except for the size (and, IIRC, the fact that they were identified as transmitting FTL, though that might have only been in later written material), they weren't all that much different from what existed at the time the show was made.
Lasers existed at the time Star Trek was made, too. Handheld laser weapons didn't, but Star Trek wasn't at all the first place where eitehr laser weapons specifically (which are treated as "old tech" in ST) or beam weapons more generally were predicted.
As your own hyperdrive link states, both the "hyperdrive" and the "subspace" (a term also used by ST in the same context) were theorized in the 1950s. And other concepts of FTL travel existed. Star Trek was hardly the first place the existence of an FTL drive was proposed.
Business presentation software existed before H. Ross Perot's 1992 campaign. Harvard Presentation Graphics, from the mid-1980s, is one of the better known earlier examples, if not necessarily the first dedicated business presentation software.
Actually, checking Wikipedia, PowerPoint was around before H. Ross Perot's 1992 campaign, as well, being first released for the Mac in 1987 and for Windows 3.0 in 1990.
IIRC, Mozilla had already committed to a particular new Javascript engine for future Firefox because of speed advantagages when Google Chrome and V8 were announced.
Regarding the "Chrome" and "Chromium" names from Google:
The open source browser project is "Chromium".
The open source OS project is "Chromium OS".
The Google-branded browser product is "Chrome".
The Google-branded OS product which has been announced is "Chrome OS".
The intent is for that facility to be provided by web apps with offline functionality, something that has been important to Google since before Chrome OS was conceived (or, at least, announced as something they were working on.)
The only initial barrier to do that with Chrome seems to be that the first time a user logs on, network connectivity and a Google Account is required, although Google has stated that that initial limitation is just that: they want to work with other authentication sources, specifically they've cited having an OpenID alternative as a goal. While this still requires network connectivity, something as simple as a home LAN with an lightweight server doing authentication would work. And, since Chrome OS is targetted for netbooks, a certain degree of network dependency is not as critical as it would be if it was intended to be a general-purpose desktop OS.
Now, you may have an issue with the entire idea of a netbook-specific OS and prefer just a general purpose desktop OS with slight visual adaptation to the limit screen real estate -- and that's certainly a reasonable preference. But I don't think that all netbook users are going to share that preference.
I think that its pretty clear from reading the pages on the design and plans that a great deal of thought has gone into it.
I think its equally clear that what has been released has not realized all of the things that are planned for it, and that it is not intended to be a production release, a release candidate, a beta, or even an alpha release, but more an opening up of the development code base and the work-in-progress plans to public view and comment.
Face it, "Chrome OS" isn't an operating system in any way. It's a web browser running on a Linux distribution.
Chrome OS is an operating system. Specifically, it is specialized a Linux distribution where the in place of a traditional desktop environment, a variation of the Chrome browser is sued. Since a specialized Linux distribution is an operating system, so is Chrome OS.
It may not do what you want out an operating system to do, and that may make it a bad operating system for your use. That doesn't make it not an operating system, however.
I think it would be more accurate for you to say "I prefer" rather "you need" here.
Continuations have been removed from the core of Ruby, though they remain a library feature available with the main Ruby 1.9 implementation. They were removed for a number of reasons -- one is that no one was using them directly in production code (in part, that was a result of the fact that the pre-1.9 implementation was horrendously inefficient and produced memory leaks), and other features that they were in theory useful for (and the one thing in the standard library that leveraged them) were replaced with a more limited, tightly focussed coroutine feature (Fibers).
With the cleaned-up continuation implementation in 1.9, if enough of the alternative interpreters do implement them as well (I think its on the plans for some, though not JRuby, the main alternative) and they get much use, I can see them working back into the language core.
I think its just a response to tax policy. Money spent on dividends directly reduces the value of stock compared to not paying the dividend, and since (but for fairly recent tax policy changes that sunset soon, and so would form a poor basis for corporate policy changes) long-term capital gains are more favored under the tax code than dividends, offering dividends is directly contrary to the financial interests of the shareholders.
Its not.
Its primarily designed as an interface into remotely hosted applications (though supporting applications that can run in an "offline mode" is a key feature) using web standards, but cloud computing (server abstraction and dynamic provisioning) have little to do with that except that it can provide a convenient platform for web apps, and the parts of "cloud computing" (really, just remote application hosting, which was around long before cloud computing) that Slashdotters tend to complain about ("ZOMG! I can't control my own data!") have even less to do with it, since nothing stops the apps you use on your Chrome OS device from being hosted on the inexpensive Linux-based server you've got plugged into your home router.
About the only thing either of those have to do with Google Chrome OS is that some aspects of Chrome OS will leverage facilities on Google's cloud, and that Google of course hopes that beyond that, Chrome OS users will find it a convenient platform for using Google's existing cloud-based apps. But its an open source project, so the first of those things can be replaced, and you are no more forced to use Google's other cloud apps with Chrome OS than you are with the existing Chrome browser.
Wouldn't that be "poor Microsoft"? After all, Microsoft is the one that would be paying for exclusive listings for News Corp. sites. If it doesn't help Microsoft gain search market share, News Corp. still gets the money, and I'm guessing that their audience is pretty dedicated, and isn't getting to their pages incidentally through search, so I don't think they stand to lose much even if the search audience doesn't follow them to Bing.
Its possible, to use a lose analogy, to oppose gluttony and sloth, you know, you don't have to choose one or the other.
The key action that is the focus of this lawsuit is the charge that Apple issues a software update designed to brick some or all jailbroken iPhones.
I haven't heard of any similar action regarding the HTC Touch Pro.
No, it wouldn't; source code has been ordered produced in discovery before (and this is a discovery motion, not a requested remedy), and its directly relevant to what they are charging.
Actually, it does, especially since the plaintiffs are seeking certification of the suit as a class action suit, and which of those AT&T targetted has a pretty serious effect on the identity and size of the class.
The issue isn't just the practice of tying the purchase of an iPhone to the purchase of an AT&T service plan, it is the damage that was inflicted on iPhone owners in Apple & AT&T's attempt to enforce the restriction on the use of the iPhone to only be used with the AT&T service plan (which is distinct from and goes beyond tying the purchase of the device to the purchase of a service plan.)
Probably because, while monopolies are specifically a subject of antitrust law, they aren't the only thing it covers. Antitrust laws deal with a wide range of anticompetitive and unfair practices in trade.
The demand for the source code isn't as a remedy, its a discovery motion. The plaintiffs' reason for it is addressed in TFA, which quotes the motion itself: "Unless Plaintiffs are given access to Version 1.1.1 source code, their ability to prove the size and scope of the Class affected by Version 1.1.1 will be severely compromised and unfairly prejudiced."