1. 23
  1. 15

    Bravo! I cringe everytime I see a technical article on Medium, mostly because it’s possible that site will either close or take the next step in their ‘incredible journey’. Devs should be setting an example for why we should self-host: complete control of content we’ve produced.

    This is what the Internet is about: freely sharing content we’ve produced, not sharecropping.

    1. 1

      Thank you! :)

      You will be probably happy to know that the blog i CC BY v4 and available on github. I can literally tell people to do a PR on spotted typos (not that I would, I appreciate people pointing out my mistakes and eager to fix them myself).

    2. 5

      Having your data tied inside a platform or a proprietary format is part of the vendor lock-in problem.

      1. 2

        Yes, but the bigger problem is the vendor suddenly going away. When people think ‘vendor lock-in’ they mostly mean no ability to migrate from current format to a different one - being forced to use the current solution. You can still hope to fight in court for an export, but when the lights go off there’s no one left to help you use the data in any way - including continuing with your current vendor.

        1. 4

          No, No,

          I can’t believe “Having your data tied inside a platform or a proprietary format is part of the vendor lock-in problem.” isn’t on top, in flashing lights.

          It’s the basic “give a man a fish, feed for a day, etc' point. Letting your data stay in a proprietary format seems a form of "learned helplesssness” to me.

          A good vendor keeps data in an open format and encourages, aggressively, frequent backups. A not-as-good vendor just keep stuff in an open format and an evil vendor keeps things in a proprietary format.

          “You can still hope to fight in court for an export, but when the lights go off there‚Äôs no one left to help you use the data in any way - including continuing with your current vendor.”

          I’m even sure exactly what this means but I’d point out vendors with proprietary formats are especially likely to actually hose their entire setup and leave things truly, truly dead.

          1. 1

            Exactly, when the lights go off hopefully you have relatively recent backups, your data might be in tact.
            But it doesn’t really help if you can’t be emailed @gmail.com any more, can’t talk to people or show them your Facebook/Twitter page any more and can’t do future sharing/backups on Flickr/Dropbox/iCloud. Not to mention if you can’t download your purchased apps/music/movies/books from Steam/iTunes/Google/Amazon.

        2. 2

          I agree with the sentiment of knowing what happens if your data goes away on someone else’s rack, but more generally I agree even if it’s on your own rack (home or colocated). The issue pointed out here seems to be of forgetting to migrate your data because you assumed the services would be forever. This just goes back to the age-old wisdom of keeping backups, which nobody takes seriously until they need backups, at which point it’s too late. So yes, definitely make sure you can migrate off a thing, or just don’t use it.

          That said, I’d really like for a lot of the services we can host ourselves to go away (I’m looking at you, SMTP).

          1. 4

            I have backups covered now (see my previous post ;)). Though the bigger issue is ‘can you restore from your backup’.

            I could have made an export of My Opera blog post every day, store it on 3 external servers every day and still be in the same situation when their site went down. You can’t restore if you’re backups can’t be understood by any system except the one that just went dark.

            So yes, make backups but make sure you can restore somewhere. Wheter a new service provider or custom rolled server on a different stack.

            I’m currently using tarsnap and happy with it. Already brought me some piece of mind when my current VPS provider had a large hiccup.

            Regarding SMTP. I’m actually quite happy with it when served by OpenSMTPD. Hard to imagine a sane replacement for it to be honest.

            1. 1

              True, the cardinal rule of backup: if you can’t restore from it, it’s not a backup. My Opera had some tools to export (third party, don’t know what quality) into other things like wordpress, but ultimately it is difficult without an adequate converter. Day of their site going down that would be a problem.

              SMTP just needs to be revisited. We’ve tacked on a lot of extra stuff that fundamentally is still based on 50 year old needs and still supports spam (and you can’t retrofit this without just cutting off most email servers, at which point why are we trying to still speak SMTP anyway?)

              As a fun aside, this reminds me that SMS is essentially telecoms having the chance to do short emails right, and failing on every front. They built the ability to spam into the protocol, and considered it a feature. (I know this only because I work in VoIP currently, and have to deal with SMS standards).

              I feel SMTP just needs to go away and some other protocol with full encryption required the entire way, all tied to IDs, and yet entirely federated (like email currently is, so you can host it on your own, but a gmail or hotmail service can provide for the masses, too). It could use the same IDs for IM, IRC, forums, news (the protocol) etc. Someday… Someday…

          2. 1
            1. 1

              Agreed :) https://archive.org/details/homing-on-code_grab_20151006

              Should have mentioned archive.org in the blog post but it was written rather hastily between tasks.

            2. 1