1. 43
  1.  

  2. 6

    Reading things like this renews my interest in distributed software distribution systems.

    1. 2

      People often make that far leap when better centralized systems will do. In this case, they can use one of the FOSS alternatives like Mattermost.

      1. 2

        Using Mattermost to distribute software? Maybe if someone built some kind of directory into it ala DC++?

        1. 1

          Mattermost is a Slack alternative. They were talking about sanctions keeping Slack from serving people in Iran. So, I brought up an open-source one as an alternative. They already have ways of getting software into the country if it’s available. Keep giving them F/OSS.

          1. 2

            I’m a frequent Mattermost user.

            My comment stems from the article’s discussion of being unable to access Dockerhub, bintray, and presumably many other software distribution methods. Reliance on distribution methods subject to US law is a security problem for the rest of the world.

            1. 1

              Oh, I agree. I figured they’d just P2P it or use whatever bypasses people in such countries use. Maybe they should pass around hard drives like the Cubans do. We carpet bomb them with flash drives containing free tips, entertainment, and useful software. :)

              1. 2

                I’ve dreamed of a dependency manager that was p2p-aware. I started on a p2p method for one dependency manager but never finished it before there were some upstream changes the broke what I’d done and I didn’t feel like rejiggering it. One of these days, maybe I will.

    2. 5

      Few months ago, Slack team, decided to join the sanctions Do I get it right that it was their own idea rather than a government requirment?

      If yes, that’s a real dick move. I would understand if someone like RTEMS, but only if it was a political statement, else that move would be misguided. People in the nuclear program would not have any troubles circumventing it.

      But Slack and Docker? The people from the iranian government you don’t like aren’t using your products. They may not even know they exist. The ones you are punishing are people who haven’t voted for that government and have no influence on it. “You were born in a wrong place, have a 403”.

      On a related note, I find people setting up blanket GeoIP bans for “security” reasons just as odd. “Most attacks come from $country”. No, they don’t, and you’d be wrong to think botnet operators don’t have thousands machines in your own country. “I’m not going to have legitimate legitimate visitors from $country”. You are not seeing them because you banned them.

      1. 1

        I think it’s a fair assumption that Slack/Docker will have been told to join the sanctions. I doubt they’d take any action which they don’t have to. Would be pretty concerning if they did and would suggest that it’s time to yet again look at upstarts/alternatives for both products.

        1. 5

          Slack and Docker don’t have a choice, they are US companies and are prohibited by US law from engaging in trade with people and businesses in sanctioned countries. The fact that they were allowing Iranian users on their platforms meant that they were technically breaking the law up until they acted to block those users. Aside from negative PR, the penalties for ignoring sanctions are non-trivial.

          My opinion is that blanket sanctions are shitty politics that only entrench the receiving country’s power structure while penalizing its citizens. But my opinion doesn’t change how the law works. (Only voting can do that.)

      2. 3

        This reminds me of my experience in Libya. Same problems, different flag. The best option is to go with satellite internet, but it’s insanely hard to get the equipment in such countries and getting caught might be a death sentence.

        1. 1

          It might not be totally thought through, but I think the situation might also have an advantage: In my opinion many developers rely too heavily on Cloud services (may it be IaaS like AWS or SaaS like Slack) and thus totally depend on their availability. Even for many company-internal installations we do not care about replicating the dependencies and if the dependencies in the Python Package Index or similar go away we cannot install our package anymore.

          If you know that everything might be blocked at any time you will develop countermeasures. You will setup a local repository for all dependencies, you will not rely on cloud services so heavily (but e.g. for SaaS prefer self-hosted solutions and if you really want to use Docker create your own images).

          1. 8

            It might not be totally thought through, but I think the situation might also have an advantage

            I’d take the fattest docker image that ever existed over that advantage, and I’ve been through that scenario where everything was blocked, literally all of the internet was cut off for 6 whole months (Tripoli, Libya, FEB/2011 - AUG/2011).

            This is a bit like saying a drought might be advantageous because most people in the developed world are so used to the scarcity of food that they throw a lot of it away.

            I do agree with your general point though and specially about the importance of replicating the dependencies on internal servers.