Announcement

Collapse
No announcement yet.

XBMC Ported To Run On Mir Display Server

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by TheBlackCat View Post
    None of those reasons are valid. For example, he admits he was wrong about the input stack, which could have been avoided just by talking to the Wayland devs (which they never did). Similarly, writing server-side buffer allocation in Wayland is trivial (there are already proof-of-concept version), and is much easier than starting over from scratch. Similarly, anything that they needed to do differently could have been done in extensions.

    So no, they still have not provided any valid reason why Wayland is unsuitable. All of their reasons are either false, or would have taken much less work to do within Wayland than starting over completely from scratch.
    Waylands input stack was at that time not good which isn't wrong. Surly they could have asked the Wayland devs if there soon will be a totally change in input stack soon. I expect that they thought that would have been a very long and difficult journey to make then replace their input stack, I would. Now they didn't and thatís how it is.

    Of course Waylands protocol support server-side buffers. The question is how compatible it would be with the rest of the environments when everyone expects client-side buffers.
    OTE=TheBlackCat;345352]
    First, that assumes Mir will be done before Wayland has implemented the missing parts Canonical needs. This is far from certain.

    Even if it was true, that is why Wayland supports extensions. Canonical could have written their own extensions for Wayland that did things quickly and dirty, then ported away from them (or not) when Wayland devs got better implementations in the official protocol. No fork would have been needed, just extensions.[/QUOTE]
    Mir probably will. It's developed in a much higher peace than Wayland. But I'm also thinking about the future when both are "done"
    and Canonical says next Ubuntu version will have THIS and starts developing it with four months to go.

    And there you have it again. A possible break in compatibility in Ubuntuís Wayland compared to everyone elseís.

    It's better for everyone to have two display servers than one that is incompatible with other builds of itself.

    Comment


    • #47
      Originally posted by Pajn View Post
      Waylands input stack was at that time not good which isn't wrong. Surly they could have asked the Wayland devs if there soon will be a totally change in input stack soon. I expect that they thought that would have been a very long and difficult journey to make then replace their input stack, I would. Now they didn't and thatís how it is.

      Of course Waylands protocol support server-side buffers. The question is how compatible it would be with the rest of the environments when everyone expects client-side buffers.
      Well, probably more compatible than, say... making an entirely new display server?

      Obviously compatibility is not a concern for Canonical... server-side allocation doesn't make sense on non-mobile environments anyway, so they could have used clientside on the desktop where it's shown to work better anyway, and server-side allocation on the mobile, where they're not concerned with compatibility anyway.

      Mir probably will. It's developed in a much higher peace than Wayland.
      No it's not. That's an illusion born from the fact that Mir is taking advantage of all the groundwork done by Wayland devs. The fact is, Wayland will be usable faster - Wayland phones will be on the market before Mir phones, and Wayland desktops will be available before the Mir desktop (native, not some XMir hack).

      But I'm also thinking about the future when both are "done"
      and Canonical says next Ubuntu version will have THIS and starts developing it with four months to go.

      And there you have it again. A possible break in compatibility in Ubuntuís Wayland compared to everyone elseís.

      It's better for everyone to have two display servers than one that is incompatible with other builds of itself.
      That doesn't make any sense, at all. There's no need to break the client-side protocol in Wayland, ever, because of extensions, and because Wayland provides a stable protocol with guaranteed backwards compatibility.

      If Canonical wants to purposely break compatibility,*that's another matter - as that's what it looks like they're aiming to do, right now.

      Comment


      • #48
        Originally posted by Pajn View Post
        Waylands input stack was at that time not good which isn't wrong. Surly they could have asked the Wayland devs if there soon will be a totally change in input stack soon. I expect that they thought that would have been a very long and difficult journey to make then replace their input stack, I would. Now they didn't and that’s how it is.
        So they write an entire display server from scratch based on nothing but wrong assumptions, assumptions a single email could have cleared up.

        Originally posted by Pajn View Post
        Of course Waylands protocol support server-side buffers. The question is how compatible it would be with the rest of the environments when everyone expects client-side buffers.
        Completely, 100% compatible. Wayland is completely agnostic in this regard, Wayland clients don't "expect" either.

        Again, Canonical devs decided to use Mir based on false assumption. They could have cleared this up with one email (the same email they could have used to clear up the input stuff).

        Originally posted by Pajn View Post
        And there you have it again. A possible break in compatibility in Ubuntu’s Wayland compared to everyone else’s.
        First, it is a possible break. But with the extra manpower that Canonical used for Mir going to Wayland, it may not have been an issue at all. But even if it was, it is clear from how other distros have handled Wayland that until it is actually ready Canonical would be the only one using it, so there wouldn't be a break in compatibility anyway.

        Besides, that is the whole point of having extensions, so that it can be tuned to fit the needs of each project.

        Originally posted by Pajn View Post
        It's better for everyone to have two display servers than one that is incompatible with other builds of itself.
        Completely and utter nonsense. First, again there is no guarantee that there would have been any differences to begin with. There is no technical basis for any difference, the only even possible reason for a difference is that Canonical wanted to rush Wayland out the door before it was ready. But with the added manpower from Canonical, Wayland very well could have been done early enough that there was no reason for Canonical to rush at all.

        But even assuming they still did, having two things that are almost completely compatible but may have a handful of differences, which clients can easily recognize and deal (when necessary) by testing for particular extensions, is far better for everyone than having two completely incompatible systems that share nothing. It is less work for the server or protocol developers, less work for window manager developers, less work for application developers, less work for distributions, and less work and confusion for users.
        Last edited by TheBlackCat; 07-24-2013, 12:58 PM.

        Comment


        • #49
          Once this whole Mir business blows up Canonical's face, they'll have to run back to Wayland with their tail between their legs, and all that will be accomplished is that they've wasted tons of money, resources and time of everyone involved.

          Comment


          • #50
            Originally posted by brosis View Post
            Consider opportunity to pull your head out of Canonical and Shuttlewroth propaganda shit(because it is) and think rationally for yourself. There is no such thing as "healthy competition" between opensource projects. There is only competition in reaching the set goal, between projects own "as-is" and "as-planned" that is, but the projects benefit ONLY if their goals do substantially differ. They are fighting with themselves in reaching the goal, not with others.

            For example, Razor-Qt profited from KDE and was never seen as "competition". Now it joined with LXDE and it also was never seen as competition.
            Hell, even BSD profited from Linux opensource driver development by porting. Nothing by rewriting or fighting over community. Competition between opensource projects is actually very harmful.

            Which healthy competition profit do you mean by mentioning "OpenOffice/LibreOffice" ?? Any proof (except worthless taskbar ofc) ? OpenOffice must be burrowed and resources should be used within LibreOffice, or he should completely change its goals to start being profitable instead of damaging behavior.

            For closed source projects, them being completely different world, yes, competition MAY bring improvements in theory, but in practice it brings half-finished projects, with very short support cycle, that are quickly made obsolete by next on-purpose incompatible versions, so that customers upgrade, as in "paying again". It drains money, reassures bad quality over timescale, as well as lots of versions. This is exactly why opensource development is better and is next evolution step. If you call this "healthy competition", no further questions for you.



            Oh, of course he has the evidence. You check the article and report back. Its called wasted resources.

            Second, yes, we would be a LOT better if we had ONE player, browser etc - but UNIQUE in goals. Could be 100 players with own unique approaches. But not 2 display servers targeting same goal, or two Office Suits targeting same goals. Read above - WASTE. And to add spice, its not an end solution, its a display server, its to be built upon. Having several toolkits damages the development rate exactly the same (yes, I am talking about Qt vs GTK useless battle).

            The best solution was to fork Wayland and mod it, then report any changes back. In case they are needed at all. That's how stuff is done.

            Gnome is destroyed thanks to Miguel and co. They abadoned user wishes, they shut the doors, then Canonical had to do something, since they never ever support or package KDE properly for unknown reasons. So they have built their own Gnome and called it Unity. Ofc it WAS different from existing DEs, so it was not met with criticism of fragmentation (except from Gnome), but with criticism of instability (Canonical's unique constant "feature"). Unity is by far not "polished, modern, productive, feature rich (you gotta be kidding me right???)" - Unity is simple and consistent in looks on all possible platforms; and thats where it ends. I worked exclusively with Unity 3-4 months, at first it was very nice, but finally it became very very limited. I got bored. Installed KDE. What a breeze. Canonical thinks now same way with migration to Qt. But this will hardly ever make Unity "feature rich".
            Free and fair competition is one of the reasons why open source development is superior. It makes free competition easier because you don't have to reinvent the wheel before you can get started; instead you take the parts of the code from the other guys you like and add your own things in the stew and then you get what you want. A classic example of this was the Google Linux fork for Android.

            One of the greatest strengths of free software is precisely in that name - we're free to do what we want with it and to combine it in any way we like. By saying "It's Wayland or the highway, pal" you are attempting to construct a monopoly - the very same kind that plague the proprietary software world, and the reason why Richard Stallman started the GNU project in the first place.

            I see there was an edit which didn't show up in my quotebox but did show up in the quote... Oh well.

            I thought it was quite clear by now that the goals of Wayland and Mir are not the same. They're close, but they're not the same.
            Last edited by Ishayu; 07-24-2013, 02:44 PM.

            Comment


            • #51
              Originally posted by dee. View Post
              Once this whole Mir business blows up Canonical's face, they'll have to run back to Wayland with their tail between their legs, and all that will be accomplished is that they've wasted tons of money, resources and time of everyone involved.
              I think that it's looking pretty good for Canonical, their phone project is gaining a lot of support and Mir is developing nicely.

              Comment


              • #52
                Originally posted by mrugiero View Post
                I don't claim Linux is innocent, either.
                Also, I'm mostly ignorant on which approaches those follow. If the change is actually needed, the approach is really different and the goal as well, then maybe it's not an unnecessary breakage. As for Mir and Wayland and the several toolkits (well, only most of them), the goals seem to be shared, and in the particular case of the display servers, there doesn't seem to be significant difference on the approach, aside from Mir being a server (while Wayland doesn't mandate it to be that way, but gives you the freedom to) and doing server side allocation (same clarification for Wayland as before). I understand the difference between GTK and Qt for being a licensing issue, and at the time GTK started Qt was proprietary even. I, too, see the reason for FLTK, since this does differ in approach, trying to prioritize lightweight, while the rest try to be feature complete (this doesn't mean they are willing to waste resources, but they will prioritize features over frugality).

                As for the competition, being loved and being healthy are two different things. I agree most people on the community love to compete. This doesn't make it any healthier for the ecosystem. In situations it is (different approaches might fit different users), in situations it isn't. I don't call it competition when goals and approach doesn't overlap, and that's why I can generalize competition is not healthy on open source. But having multiple solutions, if the approach and golas are significantly different may be a good thing.

                EDIT: I just realized I completely misread your post. My correct answer follows.
                Maybe it's true. But ALSA, I believe (I'm not really that into subject, so I might be wrong) is there to solve lots of problems. On upstart/systemd, based on the fact I toyed a bit with their configs, make it far easier to make a concurrent startup, so again, is not a breakage "just because". What I meant on the other point was actually hostile breakages, aimed mostly to break compatibility with everyone else. I don't know which the licenses are or if they depend on very specific Linux features, though.
                What I do know is that apps don't usually rely on init systems nor are they aware of them, so it doesn't really break compatibility, and just improving owns system doesn't imply competition, but just looking for new features. With ALSA, I have to admit in some cases they do, in other cases they just use OpenAL which in turn chooses an available backend. ALSA I'm aware is GPL, since it's inside the kernel, and is likely to depend on Linux specific features, since there must be a reason why "Linux" is included on its name.
                OpenRC does the same stuff as SystemD (without uDev) and OSS does the same stuff as ALSA, including simultaneous audio output from multiple applications. If they really wanted compatibility, there's no reason they can't fix that.

                Comment


                • #53
                  Originally posted by jakubo View Post
                  I'd recommend to post your distrubution you use in your signature and tell again that different aproaches are wasted resources.
                  I'm pretty sure nobody stated that. Personally, I repeated it to exhaustion, but again. Multiple projects with the same approach are wasted resources. Mir didn't show a significant difference to what Wayland does. All it does right now, and all I hear it's supposed to do, can be done with a Wayland compositor.

                  by the way Martin Luther didnt want to fork the church. And as far as i know he didnt.
                  Nope, the catholic church forked him out.

                  And as said we will see if its that bad. Like unity wasnt loved at the beginning.
                  Nobody is saying it will be technically bad, but that there is no reason to do so, because they proposed (as of now) no technical difference to Wayland

                  And as a company you need to tell investors that you have some kind of thing of your own that no one can change without your permission. they HAVE to do it.
                  [troll] So, they are a company when "they need something of their own" but they aren't when they request common folks to fund their phone prototype, so they don't share the profits. [/troll]
                  So, it's about politics, after all. Wasn't Wayland supporters the ones who only saw politics everywhere?

                  And stop being pissed off because others dont work the way you want. thats just so illeducated, self-righteous and intolerant! Pay them and then you'll get to judge their work and decisions.
                  Considering I'm doing free testing for them, I'm kind of paying them. Time is money.

                  and when someone writes it "SEEMS" then because the thing he is gonna say may not be 100% correct and WILL BARE some subjective portion. there really is no need to put him down because he doesnt have the time and maybe technical understanding to read the mailing lists himself. You ready newspapers dont you? But you probably dont read them all, compare and ask victims and witnesses for first hand information (though asking people is hardly the most objective thing in the world...)
                  And it is true, that there hasnt been much traffic on Phoronix over wayland just before Mir emerged.
                  [troll]So, the "it seems" allows me to say everything I want and expect people to believe me. It seems there are fairies downtown, guys, go see, go![/troll]

                  Originally posted by Pajn View Post
                  Mir probably will. It's developed in a much higher peace than Wayland. But I'm also thinking about the future when both are "done"
                  and Canonical says next Ubuntu version will have THIS and starts developing it with four months to go.

                  And there you have it again. A possible break in compatibility in Ubuntuís Wayland compared to everyone elseís.

                  It's better for everyone to have two display servers than one that is incompatible with other builds of itself.
                  First, no, they didn't "start developing four months ago", they just announced it four months ago, and they acknowledge it. Development started around 9 months before that moment. Also, for what they'll do in 13.10 and 14.04, there is nothing missing on Wayland. They could use their own patches out of tree to add support for XWayland running a desktop, if they want. But since running a desktop over XWhatever brings no benefits over running it on X.org, they won't bother. For running a desktop in XMir, basically, you need a pageflipper. That's it. So, if that's what makes you think it's getting developed faster, then you might as well had running desktops on XWayland last year. XMir is nothing but XWayland adapted to run on Mir, so I wouldn't call this a faster development, but a port. Porting is in most cases something a lot faster than writing from scratch.
                  On the breakage, you can't seriously compare Wayland with client side allocations versus Wayland with server side allocations against Wayland versus Mir. We have a case where a dev just need to make a macro for creating the window that implies allocating the buffer in the case of client side and only calls for the window creation in the case of server side, against a complete rewrite because the APIs are completely different.

                  Originally posted by Ishayu View Post
                  One of the greatest strengths of free software is precisely in that name - we're free to do what we want with it and to combine it in any way we like. By saying "It's Wayland or the highway, pal" you are attempting to construct a monopoly - the very same kind that plague the proprietary software world, and the reason why Richard Stallman started the GNU project in the first place.
                  Richard Stallman actually cares more about the community, and that's why he states there is a difference between open source (even GPL open source) and free software. Also, he started the GNU project because of programmed obsolescence of a printer: the manufacturer didn't want to provide drivers for a newer version of an OS, so he started coding it himself. He wanted people to share, that's what he considers the four freedoms, and everyone to get the benefits. As it is right now, the only ones who could benefit from Mir are Canonical. I'd like to know his real opinion on the matter, I think I'll mail him.

                  Originally posted by Ishayu View Post
                  I thought it was quite clear by now that the goals of Wayland and Mir are not the same. They're close, but they're not the same.
                  Oh, really? Point out the differences. As I said tons of times before, I'm open to change my mind if anyone gives me a good reason. As of now, I read all the articles I've found, and I saw nothing to justify this. Even when there are slight differences between how the reference compositor does things and how Mir does things, all of them seem to be shallow enough to just require a different compositor.

                  Originally posted by intellivision View Post
                  I think that it's looking pretty good for Canonical, their phone project is gaining a lot of support and Mir is developing nicely.
                  I'm still waiting for that ugly cursor to go out of my screen. It was supposed to be fixed in 0.0.7, but they didn't upload it to the PPA (it's in another one, mir-edge I believe, but testing that would make no good for anyone, since I'm using the one they want me to), even when just released 0.0.8.

                  Comment


                  • #54
                    Originally posted by intellivision View Post
                    OpenRC does the same stuff as SystemD (without uDev) and OSS does the same stuff as ALSA, including simultaneous audio output from multiple applications. If they really wanted compatibility, there's no reason they can't fix that.
                    I'll take your word, then. I didn't state they wanted compatibility, though, but not caring is not the same as actively trying to hurt them.

                    EDIT: I'd prefer them to care.

                    Comment


                    • #55
                      Originally posted by mrugiero View Post
                      Richard Stallman actually cares more about the community, and that's why he states there is a difference between open source (even GPL open source) and free software. Also, he started the GNU project because of programmed obsolescence of a printer: the manufacturer didn't want to provide drivers for a newer version of an OS, so he started coding it himself. He wanted people to share, that's what he considers the four freedoms, and everyone to get the benefits. As it is right now, the only ones who could benefit from Mir are Canonical. I'd like to know his real opinion on the matter, I think I'll mail him.
                      As far as I know this is just what pushed him over the edge. He was an integral part of the hacker community back then, and he was disappointed with the corporatism of it which caused things like planned obsolesce, and restrictions on his freedom to inspect, change, and share his software with friends.

                      Anyway, you're most certainly welcome to send him an e-mail. I'm extremely interested to know this, myself. To be honest, I don't think it cares, but I'd love to know for sure.

                      His stated difference between open source and free software is purely in the naming as far as I know. He didn't like the term "open source" because it shifted the ideals of the movement away from the political implications and over to the practical implications of his ideas. Both terms are all about the community sharing and helping each other, but free software wants it because it is ethically right to let the users control the program, and open source does it because it means more people can inspect the code and fix bugs.

                      Originally posted by mrugiero View Post
                      Oh, really? Point out the differences. As I said tons of times before, I'm open to change my mind if anyone gives me a good reason. As of now, I read all the articles I've found, and I saw nothing to justify this. Even when there are slight differences between how the reference compositor does things and how Mir does things, all of them seem to be shallow enough to just require a different compositor.
                      The main difference is not actually in the software itself, but in how it is maintained. Wayland is going to be defined as a standard, i.e. similarly to X.org there are a certain list of functions that must be there in exactly one and only one form. Mir does not try to make such a standard, and so the API may change over time.

                      Secondly, Mir is designed to switch smoothly between using the SurfaceFlinger drivers from the Android world and the free drivers we know from Linux on the desktop. As far as I know, Wayland can't do this. It can use both (although SurfaceFlinger support was added AFTER Canonical announced Mir) but it can't smoothly switch between them without a flicker, and due to the defined standard it can't do it. As far as I know this is because Mir uses server-allocated buffers while Wayland does not - and never will because of the rigid standard.

                      Comment


                      • #56
                        Originally posted by Ishayu View Post
                        although SurfaceFlinger support was added AFTER Canonical announced Mir
                        Libhybris was written for Wayland BEFORE Canonical announced Mir.
                        As far as I know this is because Mir uses server-allocated buffers while Wayland does not - and never will because of the rigid standard.
                        You can use client side buffers with Wayland just fine. But keep spreading the FUD!

                        Comment


                        • #57
                          Originally posted by Ishayu View Post
                          The main difference is not actually in the software itself, but in how it is maintained. Wayland is going to be defined as a standard, i.e. similarly to X.org there are a certain list of functions that must be there in exactly one and only one form. Mir does not try to make such a standard, and so the API may change over time.
                          Yet, they say they'll keep the API stable. Will it change, or will it not change? Also, remember how Windows developers praise the fact on the Linux world APIs are broken periodically? Oh, right, they don't, they complain about it. So, if you want people to migrate to Linux, you want developers to code for it, and thus, you want them happy, with stable APIs. I'm aware of that difference, but since it's not in the software itself, it's not in the approach the software follows. Also, Wayland only mandates you to follow compliance to the protocol. Your compositor may do whatever it wants, as long as it respects the protocol.

                          Secondly, Mir is designed to switch smoothly between using the SurfaceFlinger drivers from the Android world and the free drivers we know from Linux on the desktop. As far as I know, Wayland can't do this. It can use both (although SurfaceFlinger support was added AFTER Canonical announced Mir) but it can't smoothly switch between them without a flicker, and due to the defined standard it can't do it. As far as I know this is because Mir uses server-allocated buffers while Wayland does not - and never will because of the rigid standard.
                          Wayland can use Android drivers, since the library Mir uses to do so is designed for Wayland.
                          As for server-allocation of buffers, Wayland lets you do so, just Weston (a reference compositor) doesn't use it. But nothing on the protocol (the standard you must follow) mandates either way of allocation. And there is a demo using server allocation on Wayland, so yes, it will be able, because it's able right now. In fact, even Canonical doesn't spread FUD about it, since Christopher Halse Rogers himself said it's only Weston the one who can't do server side allocation on his first article.
                          On switching drivers smoothly, I can't see how this is needed at all. Either you go with our drivers or you go with the others. Either they fit a particular user or doesn't. There's no reason to really care about switching smoothly, since this should be done at most once on the lifetime of the OS.

                          Comment


                          • #58
                            Originally posted by mrugiero View Post
                            Yet, they say they'll keep the API stable. Will it change, or will it not change? Also, remember how Windows developers praise the fact on the Linux world APIs are broken periodically? Oh, right, they don't, they complain about it. So, if you want people to migrate to Linux, you want developers to code for it, and thus, you want them happy, with stable APIs. I'm aware of that difference, but since it's not in the software itself, it's not in the approach the software follows. Also, Wayland only mandates you to follow compliance to the protocol. Your compositor may do whatever it wants, as long as it respects the protocol.


                            Wayland can use Android drivers, since the library Mir uses to do so is designed for Wayland.
                            As for server-allocation of buffers, Wayland lets you do so, just Weston (a reference compositor) doesn't use it. But nothing on the protocol (the standard you must follow) mandates either way of allocation. And there is a demo using server allocation on Wayland, so yes, it will be able, because it's able right now. In fact, even Canonical doesn't spread FUD about it, since Christopher Halse Rogers himself said it's only Weston the one who can't do server side allocation on his first article.
                            On switching drivers smoothly, I can't see how this is needed at all. Either you go with our drivers or you go with the others. Either they fit a particular user or doesn't. There's no reason to really care about switching smoothly, since this should be done at most once on the lifetime of the OS.
                            I stand corrected.

                            However, I still believe that the API being controlled by Canonical is the main reason why Canonical decided to make their own.

                            But frankly, if nearly every component is the same anyway... why are people so pissed about it?

                            Comment


                            • #59
                              Originally posted by Ishayu View Post
                              I stand corrected.

                              However, I still believe that the API being controlled by Canonical is the main reason why Canonical decided to make their own.

                              But frankly, if nearly every component is the same anyway... why are people so pissed about it?
                              Yes, most of us say the real reason is for the API to be controlled by Canonical, and one of the reasons most people is pissed off is because instead of saying so, they keep pointing fictitious problems, or making vague statements that tend to show Wayland as a half-assed, crippled solution it's not. For example, the bold claim Mark did about Wayland sharing all of the X.org problems, while not clarifying what he bases this claim on.
                              About being pissed despite both are almost the same anyway, it's because the API is different, and that means the software you write (except when targeting a toolkit, but there are cases where this is undesirable) can't run on both seamlessly, you need to make a backend for Wayland and another one for Mir. If they'd implement it as a Wayland compositor, they can expose their own API, but things written for Wayland will run on their compositor seamlessly, because they'd support also the standard protocol; if the Mir API is supposed to be used for apps, though, the incompatibility will still be there; it solves the problem if that API is meant only for Ubuntu and Unity specifics, since this could be done without messing with anyone else. In the worst case, you'd need to macro the window creation to allocate on the client or not, according to the model your compositor use (or maybe even be announced by the compositor, so you can check on runtime).

                              Comment


                              • #60
                                Originally posted by CrvenaZvezda View Post
                                Yeah! Like the Suffragettes, the Solidarność, like the women in The March on Versailles, this old guy Mandela who spent many years on Robben Island and the Boston Tea Party participants. Fools all of them! Why did they ever bother complaining...
                                ...Because complaining on Phoronix forums is equivalent to the Suffragettes, the Solidarność, like the women in The March on Versailles, this old guy Mandela who spent many years on Robben Island and the Boston Tea Party participants. They were doing what they did in the back streets among the 5 other people in their situations...

                                Comment

                                Working...
                                X