Я про ГМО и сбособы вырщивания всяких полезных культур знаю только на уровне общего знания, то есть, по сути ничего. Поэтому, на всякие каверзные вопросы (не относящиеся к моему замечанию) ответить не могу. По-умолчанию, отношусь к ГМО хорошо, так как люблю вкусные помидоры.
Итак, я сказал, что отталкивался от следующих высказываний:
ГМО-растения при опылении дают стирильные семена
если обычное растение, опыляется ГМО-пыльцой, то оно произодит семена из которых вырастает ГМО-растение
Эти мне сообщил ГМО-фоб, я не знаю верны ли они или нет. Если хочется что-либо опровергнуть, то лучше начать с них, я буду только рад.
Если эти высказывания верны, то если плантация не закупает семена, но использует свои, и доля ГМО растений не нулевая, то эта доля будет расти с каждым сезоном (высказывание #2) до критического значения, а затем вся вымрет (высказывание #1).
Я не знаю, все ли производители закупают семена, если нет, то ситуация вполне реальна.
Кроме этого, возможна следующая неприятная схема: если две плантации находятся рядом и одна закупает ГМО семана, а другая не закупает семена вообще, то через некоторое время вторая вынуждена тоже перейти на закупку семян из-за опыления с первой плантации.
Кстати, как программисту, который из-за профессиональной деформации везде видит слабые места, вариант с закупкой семян тоже не кажется надежным, так как нет способов защитить плантацию, на которой производятся семена, от случайного попадения туда ГМО-растений, а дальше — экспонента:)
Повторюсь, буду рад, если вы меня опровергните, лучше всего, если найдется опровержение для:
если обычное растение, опыляется ГМО-пыльцой, то оно произодит семена из которых вырастает ГМО-растение
Недавно общался с одним contra-ГМО и вспомнил про этот пост, а точнее про кажещуюся бредовость объединения:
ГМО-растение может скреститься с диким и уйти в дикую природу
ГМО-семена специально делают бесплодными, чтобы фермеры были вынуждены покупать их каждый год
По словам этого человека схема следующая:
Многие ГМО-растения при опылении дают семена, которые стирильны
При опылении обыкновенного растения пыльцой ГМО-растения, получаются семена, из которых вырастают ГМО-растения
Я провел численное моделирование и получилось, что при таких параметрах ГМО-растения расспространяются как вирус, пока не вытесняют обыкновенные растения, а затем вымирают из-за стирильности. Получается, если в пределах одной плантации начили выращивать ГМО-растения, то вся плантация «заражается» и вынужденна перейти на закупку семян.
Да на все вопросы. В статье в первом абзаце дается определение подмножества и надмножества. Множество программ на C являются подмножеством программ на ObjC, следовательно C подтип ObjC или ObjC надтип (надстройка) C.
Аналогия с человеком и обезъяной не работает, так как не выполняется принцип подстановки Лисков.
Очень просто, заменяем коммутативное сложение в их примере, на некоммутативное приравнивание. Пусть наша модель состоит из двух переменных и модель считается консистентной, когда переменные равны друг другу. Смотрим, что может получиться, при двух параллельных транзакциях.
// начальное состояние
db.var.save({name: "a", value: 1, tx: []})
db.var.save({name: "b", value: 1, tx: []})
// создаем транзакции (будем считать, что мы их уже перевели в pending)
db.txs.save({changes : [{a : 2}, {b : 2}], state: "pending"})
// { "_id" : ObjectId("5072b0ee39d8ecf4ceb7865b"), "changes" : [ { "a" : 2 }, { "b" : 2 } ], "state" : "initial" }
db.txs.save({changes : [{a : 3}, {b : 3}], state: "pending"})
// { "_id" : ObjectId("5072b3ca39d8ecf4ceb7865c"), "changes" : [ { "a" : 3 }, { "b" : 3 } ], "state" : "initial" }
// константы
var tx1 = db.txs.findOne({_id:ObjectId("5072b0ee39d8ecf4ceb7865b")})
var tx2 = db.txs.findOne({_id:ObjectId("5072b3ca39d8ecf4ceb7865c")})
// step2 из туториала (две транзакции в перемешку)
db.vars.update({name: "a", tx: {$ne: tx1._id}}, {$set: {value: 2}, $push: {tx: tx1._id}})
// оба-на уже неконсистентное состояние a=2, b=1, но это можно простить так как транзакции еще выполняются
db.vars.update({name: "b", tx: {$ne: tx2._id}}, {$set: {value: 3}, $push: {tx: tx2._id}})
db.vars.update({name: "b", tx: {$ne: tx1._id}}, {$set: {value: 2}, $push: {tx: tx1._id}})
db.vars.update({name: "a", tx: {$ne: tx2._id}}, {$set: {value: 3}, $push: {tx: tx2._id}})
// остальные шаги я опустил, так как они не меняют value
// состояние базы после успешного завершения транзакций
db.vars.find()
// { "_id" : ObjectId("5072b07739d8ecf4ceb7865a"), "name" : "a", "tx" : [ ], "value" : 3 }
// { "_id" : ObjectId("5072b06f39d8ecf4ceb78659"), "name" : "b", "tx" : [ ], "value" : 2 }
Получилось, что после успешного(!) выполнения двух транзакций, база находиться в неконсистентном состоянии. Спрашивается, почему?
Она реализована по разному, есть и MVCC, а для redo логов, если я не ошибаюсь нужна тесная интеграция с самим хранилищем или демон который будет очень часто её пинговать.
Я не эксперт по монге, просто увидел: 1. поддержку cas 2. множество коментариев, что она не поддервивает не транзакций.
На самом деле на сайте монги механизм репликации расписан не достаточно точно, поэтому я не могу дать 100% гарантии, что в очень редких случаях (мастер упал до того как начал репликацию) все будет хорошо.
Если мы изначально используем монго, то готовы к потере данных, при использовании транзакций мы от них не защищаемся, мы защищаемся от неконсистентного состояния в базе, но из-за возможных потерь оно не всегда последнее консистентное состояние.
Дожидание репликации по всех серверов не решает проблему, но снижает её вероятность.
Кстати, даже с включенном журналированием мы можем получить выйгрыш в скорости за счет шардирования.
На самом деле, очень часто пишут, что в MongoDB нет транзакций, хотя там есть compare-and-set, поверх которых можно реализовать вариацию на тему MVCC, чем не транзакции?
Итак, я сказал, что отталкивался от следующих высказываний:
Эти мне сообщил ГМО-фоб, я не знаю верны ли они или нет. Если хочется что-либо опровергнуть, то лучше начать с них, я буду только рад.
Если эти высказывания верны, то если плантация не закупает семена, но использует свои, и доля ГМО растений не нулевая, то эта доля будет расти с каждым сезоном (высказывание #2) до критического значения, а затем вся вымрет (высказывание #1).
Я не знаю, все ли производители закупают семена, если нет, то ситуация вполне реальна.
Кроме этого, возможна следующая неприятная схема: если две плантации находятся рядом и одна закупает ГМО семана, а другая не закупает семена вообще, то через некоторое время вторая вынуждена тоже перейти на закупку семян из-за опыления с первой плантации.
Кстати, как программисту, который из-за профессиональной деформации везде видит слабые места, вариант с закупкой семян тоже не кажется надежным, так как нет способов защитить плантацию, на которой производятся семена, от случайного попадения туда ГМО-растений, а дальше — экспонента:)
Повторюсь, буду рад, если вы меня опровергните, лучше всего, если найдется опровержение для:
По словам этого человека схема следующая:
Я провел численное моделирование и получилось, что при таких параметрах ГМО-растения расспространяются как вирус, пока не вытесняют обыкновенные растения, а затем вымирают из-за стирильности. Получается, если в пределах одной плантации начили выращивать ГМО-растения, то вся плантация «заражается» и вынужденна перейти на закупку семян.
Аналогия с человеком и обезъяной не работает, так как не выполняется принцип подстановки Лисков.
Получилось, что после успешного(!) выполнения двух транзакций, база находиться в неконсистентном состоянии. Спрашивается, почему?
По поводу ACID, вы правы, я отредактировал статью.
На самом деле на сайте монги механизм репликации расписан не достаточно точно, поэтому я не могу дать 100% гарантии, что в очень редких случаях (мастер упал до того как начал репликацию) все будет хорошо.
Если мы изначально используем монго, то готовы к потере данных, при использовании транзакций мы от них не защищаемся, мы защищаемся от неконсистентного состояния в базе, но из-за возможных потерь оно не всегда последнее консистентное состояние.
Дожидание репликации по всех серверов не решает проблему, но снижает её вероятность.
Кстати, даже с включенном журналированием мы можем получить выйгрыш в скорости за счет шардирования.
На самом деле, очень часто пишут, что в MongoDB нет транзакций, хотя там есть compare-and-set, поверх которых можно реализовать вариацию на тему MVCC, чем не транзакции?