4 ms·

I would love to post a reply which answers these and other excellent questions from some of the replies here! But if I were to write such a comment, it would,

I would love to post a reply which answers these and other excellent questions from some of the replies here! But if I were to write such a comment, it would, in a sense, be the code. Not that I wouldn't love to post the latter, when it is ready, but this is not the intended use of this site. My apologies if this sounds like a slick excuse, but it is the truth.

mindslight 16y ago
Well, I'm curious about your conceptual design for this, because to me, the whole No Formats post directly contradicts your seventh rule. We can make the network transparent, but we cannot ignore the authority boundary between our two nodes. If I am to control the code running on my node, then I can't be expected to pull in common library code from your service to view your published data. For example, this is the way things work with a standardized format. ( -x-> means depends on and trusts through some interface (non-transitive!)) MyEnv -1-> MyImageLib ---> Jpeg specification YourCode ---> YourImageLib ---> Jpeg specification MyEnv -2-> YourCode Interface 1 defines what I may do with images, while interface 2 defines how I may interact with your service. MyImageLib and YourImageLib may of course be the same library, or they may not. This is what I interpret your post as saying: MyEnv -3-> YourCode -4-> YourImageLib In this new relationship, I am relying on interface 3 both for my relationship with you and for what I am allowed to do with images. If you are nice as well as thorough, I am able to rely on interface 3 to get the identity of interface 4 such that I can both work with the image library directly, as well as override the reference after forking my own copy. However, if you wish to restrict me, or even simply update reference 4 to an incompatible api, my ability to work with the library directly goes away and/or my local modifications are no longer referenced. What have I misunderstood?
- asciilifeform 16y ago
  Copy-on-write. And, as I've said before, you can't "technology-away" moral problems. All you can do is to refrain from deliberately hardcoding them into your creations.
  - mindslight 16y ago
    Are not your laws of computing, specifically (VII, VI, IV, II, I), moral judgments? Trying to "technology-away" a preexisting moral problem is folly, but software, platforms especially, set a stage of default behaviors. One could argue that those who blindly go along with said default are moral failures (for their lack of analysis), but this would do little to negate the resulting effects of those masses. On the technical front, what do you propose to copy-on-write? I'll presume by "morals", you mean that I should trust the authors of the hypothetical ImageLib and YourCode to not restrict my use of images through technical means, and to generally do the right thing when it comes to library changes. Let's say I wish to modify ImageLib as used in your application. For copy-on-write, what is "written" ? Forking YourCode along with ImageLib (immutable references) is a non-starter, as the common case is that YourCode changes periodically, and that I'm uninterested in manual merging, as YourCode just isn't a large part of my life. So, I've got my locally forked version of ImageLib, but any changes I make are only applied to that specific version of ImageLib. Every other XXCode which uses a different lineage or revision of ImageLib will lack the customizations I've made! So how can this be solved? Freezing the API of ImageLib would alleviate the need for incompatible releases. But to freeze the API, it needs to be trimmed down to the bare minimum of core functionality, with extras pushed out into other modules using well thought out hooks. After eventually reaching perfection, the API can finally stop changing, and overriding all possible ImageLibs is easy (as only one exists). However, we have completely locked down the API (and thus cut off unexpected new functionality), and have effectively created a format! (also, a tidbit that's kind of a continuation: http://news.ycombinator.com/item?id=2121549 http://news.ycombinator.com/item?id=2121549)

mindslight 16y ago

Well, I'm curious about your conceptual design for this, because to me, the whole No Formats post directly contradicts your seventh rule. We can make the network transparent, but we cannot ignore the authority boundary between our two nodes. If I am to control the code running on my node, then I can't be expected to pull in common library code from your service to view your published data. For example, this is the way things work with a standardized format. ( -x-> means depends on and trusts through some interface (non-transitive!)) MyEnv -1-> MyImageLib ---> Jpeg specification YourCode ---> YourImageLib ---> Jpeg specification MyEnv -2-> YourCode Interface 1 defines what I may do with images, while interface 2 defines how I may interact with your service. MyImageLib and YourImageLib may of course be the same library, or they may not. This is what I interpret your post as saying: MyEnv -3-> YourCode -4-> YourImageLib In this new relationship, I am relying on interface 3 both for my relationship with you and for what I am allowed to do with images. If you are nice as well as thorough, I am able to rely on interface 3 to get the identity of interface 4 such that I can both work with the image library directly, as well as override the reference after forking my own copy. However, if you wish to restrict me, or even simply update reference 4 to an incompatible api, my ability to work with the library directly goes away and/or my local modifications are no longer referenced. What have I misunderstood?

asciilifeform 16y ago
Copy-on-write. And, as I've said before, you can't "technology-away" moral problems. All you can do is to refrain from deliberately hardcoding them into your creations.
- mindslight 16y ago
  Are not your laws of computing, specifically (VII, VI, IV, II, I), moral judgments? Trying to "technology-away" a preexisting moral problem is folly, but software, platforms especially, set a stage of default behaviors. One could argue that those who blindly go along with said default are moral failures (for their lack of analysis), but this would do little to negate the resulting effects of those masses. On the technical front, what do you propose to copy-on-write? I'll presume by "morals", you mean that I should trust the authors of the hypothetical ImageLib and YourCode to not restrict my use of images through technical means, and to generally do the right thing when it comes to library changes. Let's say I wish to modify ImageLib as used in your application. For copy-on-write, what is "written" ? Forking YourCode along with ImageLib (immutable references) is a non-starter, as the common case is that YourCode changes periodically, and that I'm uninterested in manual merging, as YourCode just isn't a large part of my life. So, I've got my locally forked version of ImageLib, but any changes I make are only applied to that specific version of ImageLib. Every other XXCode which uses a different lineage or revision of ImageLib will lack the customizations I've made! So how can this be solved? Freezing the API of ImageLib would alleviate the need for incompatible releases. But to freeze the API, it needs to be trimmed down to the bare minimum of core functionality, with extras pushed out into other modules using well thought out hooks. After eventually reaching perfection, the API can finally stop changing, and overriding all possible ImageLibs is easy (as only one exists). However, we have completely locked down the API (and thus cut off unexpected new functionality), and have effectively created a format! (also, a tidbit that's kind of a continuation: http://news.ycombinator.com/item?id=2121549 http://news.ycombinator.com/item?id=2121549)