Weekly Edition
Return to the Front page
| |||||||||||||
|
| |||||||||||||
How (not) to run a developer programThe Android developer phone (ADP1) is a nice piece of hardware which allows freedoms that the T-Mobile standard-issue G1 does not allow. As the name might imply, it is targeted at developers so that they can more easily develop applications for the Android Market, but also so that they can hack on the Android platform itself. So far, though, the Android development community has been less-than-satisfied with the development support provided by Google. In fact, the recent decision to disallow access to copy-protected applications in the Android Market has a lot of ADP1 purchasers up in arms. But that isn't the only thing that has annoyed—or worse—Android hackers. The idea behind a developer program is, or should be, that developers get early access to the code that customers will soon be running, so that they can test their applications—finding and fixing bugs before the general public ever sees them. For whatever reason—manpower is the oft-stated problem—Google has turned this on its head. Customers who purchase the consumer version (i.e. G1), will get the RC33 version (in the US, European version numbering is different) of the firmware. The G1 phones ship with an earlier version, but an over-the-air upgrade will eventually bring them up to that version. For developers who purchased an ADP1, however, there is no equivalent upgrade, at least officially. There has been a fair amount of complaining about the lack of an ADP1 upgrade on the android-developers mailing list. Jean-Baptiste Queru, who seems to be the Android engineer who was selected or volunteered to answer questions on the list, is unhappy about the delay—and lack of information—as well:
There's no news on that subject as there isn't anything to announce
yet. We're still pushing hard to get 1.1 available for ADP1 owners,
but some things take time and no matter how quickly we want them done
we can't skip the necessary steps.
[...] You're not the only one frustrated about this. I am too. The 1.1 firmware release for the ADP1 is supposed to have more-or-less equivalent functionality to the RC33 release for the G1. But what, exactly, that release will contain is still a closely-held secret. That seems to be one of the biggest complaints about how Google is treating Android developers: lack of information. The problem with copy-protected applications for the ADP1 is just another example. Android offers application developers two restrictions that they can apply to their programs in the Android Market: for-sale and copy-protection. It is believed that most for-sale applications will also carry the copy-protection restriction, but that is not required. Gratis applications can also be copy-protected if the developer wishes to do so. The ADP 1.0 code does not allow access to either kind of application in the Market. ADP 1.1 is believed to relax that restriction to only those that specify copy-protection, though that may not be much different in practice. The reasoning, according to Queru, is that "copy-protected apps aren't offered on devices where the copy-protection is known to be ineffective." Because the ADP1 phones are unlocked, there are various ways that the copy protection could be overridden. The fear seems to be that developers might pay for an application, then squirrel it away and apply for a refund. Developers could restore the deleted application after receiving the refund or copy it to other phones. While that is a possibility, it leaves some feeling like developers are being singled out as pirates. One of the problems is that folks who have gotten root access on their G1 phones can access copy-protected applications. In the end, folks who want to pirate applications—be they developers or consumers—will find a way to do it. It is a time-honored tradition amongst software developers to check out the competition. Many of the hobbyist developers hoping to strike it rich with Android Market applications purchased the ADP1 in the belief that it would have the same functionality that the consumer version does. Now they have found out that they can't purchase competitor's applications (at least in the likely case that they are copy-protected), on top of the realization that they can't get a blessed version of the latest code. Other ADP1 purchasers were looking to get around the geographic and/or cellular carrier restrictions of the G1, but now have a phone with fewer capabilities. There are alternative firmware loads for the ADP1, but it doesn't sit well that Google has yet to provide one. A somewhat popular alternative is to use the so-called "holiday" version—the version that shipped on the ADP1s that Google gave its employees as a holiday bonus. Interestingly, that code does not allow accessing copy-protected Market applications either, which makes it likely that the restriction is simply an attempt to be consistent about copy protection, as Queru stated, rather than a real belief that developers are more likely to be pirates. Google could have avoided much of the outcry by being more transparent—something the company seems to have a general problem with—and by paying more attention to its developer program. The official developers blog does not seem to cover many of the areas that are of concern to the community. One must wander through the mailing list or third-party sites to find information about the restriction on copy-protected applications, for example. There are alternative mechanisms for handling copy protection, of course. Several were bandied about on the mailing list as the "forward locking" scheme—essentially signing the application in such a way that it won't run on other phones—is seen as suboptimal. The alternatives are other forms of DRM, however, as Queru points out:
No doubt that using a DRM solution that is not based on
forward-locking is the right long-term approach. We know what it would
take to implement it. There just wasn't enough time to do it.
Developers just want a phone that can do what they need it to, so some are starting to feel like they made a bad decision by purchasing the ADP1. That has led to suggestions that folks should just sell their ADP1 and use the emulator or a G1 phone to do their development. That may be a bit of an extreme reaction, but there are probably some who have done that or are considering it. A bigger worry for Google might be that they decide to ditch the Android platform entirely for something more developer-friendly. Some have portrayed Android as the future of the Linux desktop—on phones and netbooks at least—but the problems that are currently being experienced on phones could well spill over. DRM and locking devices to particular vendors are not "features" that people normally associate with Linux and free software, but they are being demanded by some vendors. Those kinds of restrictions are really meant to keep consumers from reaping the benefits of freedom. While folks may be used to that treatment from mobile phones, one hopes they don't have to get used to it from their computers as well. (Log in to post comments)
Right, room for OpenMoko yet... Posted Mar 5, 2009 2:49 UTC (Thu) by mjr (subscriber, #6979) [Link]
Though really, I'm beginning to be of the opinion that both Android and OpenMoko are good for one thing: getting commodity Linux-supporting phones out there on the market, hopefully some of them working with free software on the Linux system side (like the OpenMoko Freerunner, for all its other lackings [it being my current phone by the way, though no, I don't recommend it for the normal user], and unlike the G1). I would sincerely hope OpenMoko, as the pioneer in this respect, will make it at least as a hardware company with the abovementioned focus. Failing that, one hopes some of the Android hardware manufacturers will come out with products that meet this criteria.
Then we won't be limited to that wholly non-Linuxy Android thing that just happens to run on the Linux kernel, or even OpenMoko's OpenEmbedded derivative which I find somewhat inconvenient as well (though it at least uses standard components such as X). Rather, those of us who want a truly flexible GNU/Linux system with no silly restrictions and good app compatibility on our phone can run something like Debian with the more-GNU/Linuxy-than-Android http://freesmartphone.org phone stack (once that matures, which wasn't quite yet when I tried it last fall). And incidentally, props to OpenMoko for spurring the development of said stack. I might not like their distro a great deal, but that doesn't mean I don't appreciate their software development efforts in general - even if things go more slowly and erratically than one would like, but it happens.
Anyway, here's hoping for commoditization of phone hardware and more free Linux drivers for the embedded space as well. And sure, why not that Android VM's port to X so we can run software written for it on our Debian phones ;)
PS: To be fair to the G1 and the Google team, it does seem surprisingly low on proprietary stuff considering the earlier http://openhandsetalliance.com PR about everything being able to be closed up, "yay". The biggest (and most problematic) piece is of course - tah-dah - the OpenGL driver (which can be done without in a pinch, but then wouldn't rather pay for the GPU either), and there were a couple of others as well. Taking an Android dev at his word on an IRC conversation on #openmoko, apparently the dev team _do_ try to influence openness in the actual implementations as well, which is good, even if the success is limited.
PPS: Yeah, the Freerunner has a GPU with _no_ OpenGL drivers, but to be fair, the chip isn't so capable on that front that this would be a big deal ;/ "Looked better on paper." It does do some stuff, like mpeg-4 decoding with a patched mplayer, though all and all, it ended up being more trouble than worth and is ditched in the next generation of OM hardware. I just mention it so nobody else feels obligated to after my G1 GPU comment ;)
Right, room for OpenMoko yet... Posted Mar 5, 2009 4:44 UTC (Thu) by zooko (subscriber, #2589) [Link]
Maybe people who want to develop apps for Android should buy an OpenMoko and install Android on it?
Right, room for OpenMoko yet... Posted Mar 5, 2009 11:43 UTC (Thu) by mjr (subscriber, #6979) [Link]
Well, I doubt the app store with its DRM'd apps would co-operate any better with any unlocked Android installation, such as they would necessarily be on the OpenMoko phone :]
But yeah, it's worth mentioning there's a port being developed.
Right, room for OpenMoko yet... Posted Mar 5, 2009 13:24 UTC (Thu) by mjr (subscriber, #6979) [Link]
I'll just quickly note that I expanded a bit on my reply here in my blog: http://mjr.iki.fi/blog/index.php?/archives/43-Freedom-to-...
How (not) to run a developer program Posted Mar 5, 2009 6:20 UTC (Thu) by jamienk (guest, #1144) [Link]
I didn't follow Android in detail, but I had thought that google was throwing their lot in with the Linux crowd. But this article really removes the big advantage that I thought Android had over the iPhone: openness. That fact that google is offering DRM on a Linux based device is sickening. They have lost me right there.
How (not) to run a developer program Posted Mar 5, 2009 9:50 UTC (Thu) by fb (subscriber, #53265) [Link]
I own a (continental European) G1, which I rooted, and installed one of the "alternative" ADP firmwares that the article mentions.
Honestly and respectfully, IMHO the point you made is pure non-sense. You can't compare the Android platform with whatever runs in the iPhone.
The iPhone is a 100% closed software device, with draconian licensing terms. The Android is what? 80%? 90%? BSD & GPL licensed stack. Also, compare the trouble of getting your hands into the Android SDK with the iphone's.
The Android is so open that there are people porting to other hardware. Did you **ever** heard of any hobbyist posting the iPhone stack to another phone?
[...]
All this complaining about the ADP needs to be given its proper perspective: Is there any other 'consumer ready' phone that is anywhere as open as Android? No.
The G1 is not the OpenMoko. Both in the sense that it's less open, and that it actually works. At the same time, the iphone is the most restrictive phone released in the past years. I really can't figure how people can place both at the same level of openness.
"forward locking" vs. other DRM? Posted Mar 5, 2009 6:55 UTC (Thu) by brouhaha (subscriber, #1698) [Link] Several were bandied about on the mailing list as the "forward locking" scheme—essentially signing the application in such a way that it won't run on other phones—is seen as suboptimal. The alternatives are other forms of DRM, however,As a developer, I've been concerned about this. My own preference would be to have the marketplace generate a certificate when an app is sold, with the certificate tied to one of the unique IDs of the phone (possibly the IMEI). It would be up to the developer to have their application verify the certificate or not. There could be a CRL for the applications that have been "returned", and it would be up to the developer as to whether their application checks the CRL. My proposal is DRM, and the Marketplace would participate in it by issuing the certificates, but it would be entirely optional as to whether any particular application uses it. I've never heard the term "forward locking" before, and I'm not sure how it compares to what I've described above, but how is it worse than any other kind of DRM?
"forward locking" vs. other DRM? Posted Mar 5, 2009 10:39 UTC (Thu) by fb (subscriber, #53265) [Link]
Suppose I let my phone fall down, breaking it; later I buy a new phone. Shouldn't I still have access to the applications?
"forward locking" vs. other DRM? Posted Mar 5, 2009 19:13 UTC (Thu) by brouhaha (subscriber, #1698) [Link] Playing Devil's advocate for a moment, suppose that I buy some kind of physical device that attaches to the phone and does something I want. If I drop the phone and break both the phone and the add-on device, I won't get another add-on device from its manufacturer for free, and I'm not going to complain about that.Certainly I realize that software is dissimilar to physical objects, and that generally our expectations are different as a result. However, as with everything else about "intellectual property", any "rights" regarding software are inherently an artificial construct. Where we draw the line regarding what rights we will give the copyright holder, and what rights we give the end user, are essentially arbitrary. The copyright holder makes the case that since the software is the fruit of his labor, he should have almost unlimited control over it. The end user claims that since it is just bits, the copyright holder should have very little or no control over it. Neither position follows logically from how we handle rights to physical objects. Anyhow, to answer your scenario, here's how it could be handled with a certificate scheme: If a phone gets destroyed, you should be able to report it to the carrier and buy a new phone with a new IMEI. The carrier could put the certificates for your old phone on the CRL, inform the Android Marketplace of the change, and the Marketplace could issue you new copies of your applications with new certificates. If the old phone still works, and application developer chose not to have the application check the CRL, then the application on the old phone will still work. If the application checks the CRL periodically, it could refuse to work either it finds the certificate on the CRL, or the CRL check has not occurred within some period of time. As an end user, and a developer of some Free Software myself, I don't like DRM. If there's going to be DRM, I want it to be as unobtrusive as possible. As an end user, I think the kind of certificate scheme I have proposed would rarely cause me any grief. As a developer of phone applications for sale (currently through iTunes for the iPhone, but in the future for Android as well), I don't want it to be easy for people to "share" the applications without having purchased them from the store. These are obviously conflicting positions. When as a user I'm looking for software, one of the things that enters into my decisions about which software to use is whether it has DRM. I don't take the position that I won't use software with DRM, but if I have the choice between two programs, one with DRM and one without, I certainly going to favor the one without.
"forward locking" vs. other DRM? Posted Mar 7, 2009 6:14 UTC (Sat) by lacostej (subscriber, #2760) [Link]
I don't like the phone home action. Nor something tied to my hardware. I have been beaten by the Microsoft activation thing once. Not fun.
You don't treat one use case here: my phone gets stolen and I buy a new one.
"forward locking" vs. other DRM? Posted Mar 7, 2009 9:14 UTC (Sat) by brouhaha (subscriber, #1698) [Link] The CRL in the proposal handles the stolen phone case just as well as the broken phone case.I didn't expect that you'd like the proposed DRM scheme. You probably wouldn't like *any* DRM that actually is effective in the eyes of the application vendor. That's a fundamental problem with DRM; anything that gives more control to the application vendor can only do so by taking away some control from the end user. Wearing my end-user hat, I hate all DRM. I do find some DRM schemes to be more odious than others. Wearing my commercial-software-developer hat, I can see the desire to have some degree of DRM to try to prevent rampant piracy. (I write some GPL'd Free Software too, but I disagree with those that think that all software should be Free Software or Open Source Software.) The best thing for people that don't like DRM to do is to vote with their wallets. Don't buy DRM'd software or media. Don't buy systems that use DRM. If people don't buy it, the vendors will eventually figure it out and stop pushing it. For phones, this means buying an OpenMoko phone, or an ADP1, but then don't complain if you aren't able to run DRM'd software on it. When you buy an open platform, you get the benefits as well as the drawbacks, with one of those drawbacks being that some commercial developers will choose not to support it. You have to decide for yourself whether the benefits outweigh the drawbacks.
Stay away from Google Posted Mar 5, 2009 8:57 UTC (Thu) by jhs (guest, #12429) [Link] I'm not an anti-Google conspiracy theorist, but their record speaks for itself. Due to its corporate culture, Google is a very high-risk partner to be in bed with. How many people here have used AdWords? It is indeed fancy, but after the honeymoon phase, one realizes that it is extremely opaque and inflexible. (Any AdSense users feel the same?) Next, you have the long list of Google projects that come out with big fanfare and then become abandoned. Not all of these are developer platforms, but some are, like Jaiku. And if you are fortunate enough to commit to a technology that Google doesn't deep-six, next you get to deal with their completely unacceptable working pace. My specific experience, about which I've written elsewhere, is about App Engine issues. (I submitted a patch to their bug tracker, which wasn't even acknowledged for six weeks and has subsequently been totally ignored (i.e. not Invalid, not WontFix, but just languishing in an open state). That was pretty much the last straw that showed me that even compared to Microsoft and Apple, Google is just a terrible platform to develop with.
Stay away from Google Posted Mar 5, 2009 17:41 UTC (Thu) by man_ls (subscriber, #15091) [Link] It is sad to hear this, given the hopes laid on Android, but it's not too surprising. Apple and Microsoft have had decades to get their dev programs up and running; Apple in particular has passed many crises (like the '94-'96 period) before the whole company realized that they had to be quite more open with their external developers. Right now Apple is even able to play ball with external free projects (as seen with WebKit). Google, it seems, still has a lot to learn about platform development.
How (not) to run a developer program Posted Mar 5, 2009 12:15 UTC (Thu) by fb (subscriber, #53265) [Link]
>DRM and locking devices to particular vendors are not "features" that people normally associate with Linux and free software, but they are being demanded by some vendors.
So far so good. Is anyone surprised that telecoms are reluctant in walking away from these things?
> Those kinds of restrictions are really meant to keep consumers from reaping the benefits of freedom.
Aren't you stepping a bit over the line here?
The marketplace allows developers to post their own applications (closed source, BSD, GPL, LGPL etc). Given that the developer owns the rights to the code, and assuming that it only makes sense to apply DRM to proprietary code, how exactly is anyone prevented from "reaping the benefits of freedom"? Given that the user never had the right to the application in the first place, and that other developers are still allowed to post competing "Free" applications with similar functionality.
How (not) to run a developer program Posted Mar 6, 2009 18:03 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I think this is largely a semantic disagreement, since there are many ways to view freedom. One man's freedom is typically another man's bondage, so we have to expect people to be constantly trying to stop others from reaping the benefits of freedom.But I'd like to point out a way in which DRM/locking actually increases freeedom and our ability to reap its benefits. I would feel freer with my phone if I had a catalog full of high quality applications from which to choose -- applications which someone spent a great deal of money engineering. I believe that without the ability to withhold rights (such as copying) from users unless they pay for them, there wouldn't be that selection and I would feel more restricted.
How (not) to run a developer program Posted Mar 6, 2009 23:31 UTC (Fri) by drag (subscriber, #31333) [Link]
It prevents freedom because if your a user using a consumer phone you have no more control over your device then if you owned a IPhone or any other phone OS.
That is you can look, but you can't touch. What is the point of open source when your not allowed to modify any of the software?
All in all it's a rather shitty thing to do. It may be less shitty then what Apple does, but it's still shitty.
> But I'd like to point out a way in which DRM/locking actually increases freedom and our ability to reap its benefits. I would feel freer with my phone if I had a catalog full of high quality applications from which to choose -- applications which someone spent a great deal of money engineering. I believe that without the ability to withhold rights (such as copying) from users unless they pay for them, there wouldn't be that selection and I would feel more restricted.
Hrm. That feeling of freedom will last until you realize that:
And on a side note:
You can do what you want and if you want to trade in the ability to modify your phone for the ability to pay for closed source applications, then that's fine. It's your choice. Seems silly to me, but that's just a opinion and has zero affect on you and your choice has zero effect on me.
Just don't come to me and tell me that you feel more free because the handcuffs your wearing are comfortable, shiny and fashionable. It's just kinda insulting.
(personally I think android is a great improvement and I understand why Google is doing what they are doing and I hope they are successful and if they are it will lead the way to more openness... so don't get me wrong here.)
How (not) to run a developer program Posted Mar 7, 2009 20:14 UTC (Sat) by giraffedata (subscriber, #1954) [Link] It prevents freedom because if you're a user using a consumer phone you have no more control over your device than if you owned an IPhone or any other phone OS. And it enables freedom in other ways, especially for other people. My point was that freedom is not black and white and when people argue over whether something is designed to stop people from reaping the benefits of freedom, they are more likely arguing over semantics than over actual freedom. Just don't come to me and tell me that you feel more free because the handcuffs your wearing are comfortable, shiny and fashionable. Sure, and I haven't said anything even close to that. I said a) the guards are more free when I'm wearing handcuffs; and b) I am more free in that the guards are willing to let me out of my cell if I wear handcuffs, whereas if they got the idea that handcuffing people is immoral, I would spend all my time behind bars.
How (not) to run a developer program Posted Mar 17, 2009 20:41 UTC (Tue) by Duncan (guest, #6647) [Link]
I've come to look at software freedom this way, based to a large degree on
a quote from Richard Stallman, below, that forms my sig on various newsgroups and mailing lists, on slashdot, and elsewhere.
I look at proprietaryware vendors much as I would slave masters. They
For this reason I can't agree to the EULA of proprietaryware, which of
Since I can't agree to run it, and given the blackbox conditions presented
Bringing it all back home to the topic in question, why would I want to
Notice that all the above is simply the position I've worked out for me.
The quote that pointed my way down this road?
"Every nonfree program has a lord, a master --
Duncan
How (not) to run a developer program Posted Mar 9, 2009 17:44 UTC (Mon) by martinfick (subscriber, #4455) [Link] It prevents freedom because if your a user using a consumer phone you have no more control over your device then if you owned a IPhone or any other phone OS. That is you can look, but you can't touch. What is the point of open source when your not allowed to modify any of the software? I fail to see how this applies to the G1 dev phone? You essentially have an open phone which has an almost completely free software stack. I believe that you could live without the free parts on the phone and still have a usable phone. You CAN modify the software, unless you are talking about proprietary software that you can purchase for the phone, but how is that any different than any other free operating system?
Freedom is not grey as you would like to paint it. You are simply confusing freedom, which is usually interpreted as the ability to do what you want with your property, with the ability to do what ever you want with other people's property. In this case, it is other people's property (the proprietary apps, and the google web service) that are being restricted to you, not your property (your phone). Do not twist things and make it seem like the phone is the limiting factor. You and your property (a red shirt) are not less free because your neighbor decides to kick you out of his house, even if it is for reasons you disagree with like say: wearing a red shirt. Yes, currently the dev phone cannot participate in google's web service (marketplace for paid apps). This is not a restriction of the phone, but rather of google's web service. So while you may not like google's behavior and treatment of its developers, this hardly makes the phone less free! If it did, than one could conclude that if MS decided to make it difficult or impossible to use firefox (or other free browsers) with their website that suddenly it would make linux less free. This is obviously non sense. It does not matter what others allow you to do with their web services and your linux machine (with only free software on it), the machine is still free to you.
How (not) to run a developer program Posted Mar 9, 2009 19:00 UTC (Mon) by giraffedata (subscriber, #1954) [Link] Freedom is not grey as you would like to paint it. Actually, the post to which you responded didn't make any claims about freedom being gray; in fact, I think it was pretty much the opposite, a refutation of my earlier post painting freedom as a gray thing.
You are simply confusing freedom, which is usually interpreted as the ability to do what you want with your property, with the ability to do what ever you want with other people's property. I think very few people interpret freedom that way; I think most leave off the "with your property" part. At best, it's a circular definition, because your property is defined as stuff that you are free to do what you want with. If you think about a pretty cut-and-dried freedom issue -- 19th century US African plantation slavery -- the issue was wasn't whether people who were the property of others should be free to do what they want with themselves, but whether people should be the property of others. Freedom wrt free software is the same. I don't think there's any doubt that the holder of copy-protected software is less free than the holder of the same unprotected software and the holder of a phone on which he can install certain applications is more free than the holder of a phone that is barred from those applications. The only thing we've been arguing about is whether simple statements like that Google's policy is meant to interfere with freedom are valid.
How (not) to run a developer program Posted Mar 9, 2009 21:56 UTC (Mon) by martinfick (subscriber, #4455) [Link] You are simply confusing freedom, which is usually interpreted as the ability to do what you want with your property, with the ability to do what ever you want with other people's property. I think very few people interpret freedom that way; I think most leave off the "with your property" part. Perhaps, you are correct, perhaps not, I should not speculate about majorities. Although, I would guess (there I go again) that most people have probably never tried to define it, perhaps they should. :) Through my research, of those who have tried, the most logical have often come to that conclusion, the epidemy being Rothbard . I think that many courts will also end up enforcing "freedom" issues along those lines. What I find most useful is that such a clear definition does not make things grey! At best, it's a circular definition, because your property is defined as stuff that you are free to do what you want with. No, I respectfully disagree. Your property is defined as things you own the title to (whether a paper title, or simply a legal implied title). In other words: things you homestead (which includes yourself and things you find that cannot be traced to being owned by someone else), things you create (grow...), things you trade for (purchase, work for...), or are given (inherit...). No circularity here, no need to make property dependent upon freedom. Think of it this way, I can be partially free or unfree and still own property (even if jailed), but I will never be completely free if there is property that I own and cannot legally control. I don't think there's any doubt that the holder of copy-protected software is less free than the holder of the same unprotected software and the holder of a phone on which he can install certain applications is more free than the holder of a phone that is barred from those applications. Yes, but this is in no way the fault of the phone. No one is arguing that proprietary software is not free. Those are not hardware (phone) restrictions, but restrictions imposed by the proprietary software.
How (not) to run a developer program Posted Mar 10, 2009 15:53 UTC (Tue) by giraffedata (subscriber, #1954) [Link] Your property is defined as things you own the title to (whether a paper title, or simply a legal implied title). So you're talking about law. We weren't talking about law before, i.e. when the article says a feature of Android is intended to prevent people from reaping the benefits of freedom, it's not saying Google is breaking the law or even circumventing it. But speaking of law, I think what you have here is a definition of title more than a definition of property. Title is a legal device that stands for official ownership of property. What it means to own property is another matter.
|
|
||||||||||||