4 ms·

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 c

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)

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)