Это не просто плохое. А ужасное.
Добровольно вести досье на себя и друзей, да еще и во многих случаях с компроматом…
Это-ж надо додуматься!
А ведь ведут. И имя им легион.
Ну, если вы вообще имеете дело с индексированными массивами — то счет с нуля более «правилен» математически (не улетает в переполнение — в минус — на границах диапазона). Почитайте по ссылкам, там в общем-то довольно понятно. Хотя и на английском. Да, да тоже терпеть не могу математику — а куда деваться...
Ну а если вы работаете на высоком уровне — то это скорее «старость» языка. Современные языки для перебора коллекций используют итераторы и индексами там и не пахнет. Никакими… foreach($cmments as $comment){
}
Так что, возвращаясь к исходному вопросу — для «старых» языков удобство в том, что при счете с нуля вы наделаете меньше ошибок :-)
А для новых — индексы и вовсе не очень-то нужны, да и сделать можно любые, какие хочется (привет итераторам)
Именно, это техническая особенность адресации современных процессоров, которую, конечно, можно скрыть (на этапе компиляции) — но зачем?
Это создаст дополнительный слой преобразования, головную боль с переполнениями и отладкой (когда в исходниках одно — а в ассемблерном режиме — совсем даже другое).
А оно надо?
Да еще потому, что в низкоуровневых языках (ассемблер) для адресации элементов используется указатель на начало массива, а номер элемента является смещением. Соответственно, адрес первого элемента это [указатель]+0, а не [указатель]+1
Вообще говоря, ассемблерные вставки в не самом новом языке Паскаль (во всех средах, Turbo Pascal, Delphi, Lazarus) никто вроде не отменял. Равно как и возможность дебажить / просматривать в нативных средах разработки ассемблерный код.
Так что с новизной тут как-то не очень…
Наличие while в TSQL коде в большинстве случаев означает плохое знание самого TSQL.
99% операций могут и должны делаться стандартными операторами SELECT/UPDATE
С ходу — только один безусловный случай когда применение курсоров оправдано — вызов других процедур для каких-то строк выборки. Причем, зачастую, и их можно заменить «неправильными» функциями, меняющими данные (их вызов будет осуществлен при выборке самим TSQL). В других случаях — для построчной обработки выгодно использовать триггеры.
Одним словом, случаев безусловной надобности курсоров в реальных проектах очень мало.
Никто не требует от подсистемы хранения 100% сохранности и правильности данных. Но требуют 100% информации о факте сохранности и правильности данных.
Это не дно и то же!
Если узел недоступен или поврежден — задача подсистемы хранения информировать об этом приложение, возможно, опционально, предложив запрошенную информацию в виде «что смогла — то нашла».
Таким образом, приложения готовые работать с неполными данными — смогут продолжить работу. А не готовые — сообщат о фатальном сбое.
То, что вы предлагаете может стать расширением протокола обмена.
Но вот «тихая» подмена данных (или информации о состоянии данных — при записи например) в рамках существующих протоколов IO никак не допустима.
Хранение данных — не та область, где допустимы какие-бы то ни было потери.
В теории — 1 убитый байт может сделать все данные (единицы хранения) полностью негодными к использованию. Причем «без вариантов» исправления (на существующем уровне всего стека технологий).
Согласитесь, даже один битый байт в системном файле ОС «живущей» в таком облачном хранилище может привести к чему угодно, включая полный фатальный выход из строя системы в целом.
Ведь все дело в том, какой слой абстракции ответственен за целостность данных. Сейчас за него отвечает устройство хранения — просто потому, что нереально (и экономически не обосновано, в первую очередь) перекладывать этот контроль на уровень приложения. Вы вообще себе представляете контроль целостности всех структур данных всех приложений? И обработку всех возможных повреждений?
К слову, существующий уровень работы с устройствами хранения, кстати, отнюдь не подразумевает бесконечной надежности. И отказ чтения одиночного сектора может (но не обязан) обрабатываться на прикладном уровне.
И задача подсистемы хранения или выполнить команду и доложить об успехе — или честно сообщить, что вышел облом. А никак не строить предположения на тему «а может приложение обойдется без этих ХХ байт?», «А может ему сойдут эти байты их прошлого бэкапа?»
А на практике — по данным ЛК за 2013 год — топовая уязвимость CVE-2011-3402
Цитирую
На втором месте расположилась категория «Windows компоненты», которая включает уязвимые файлы семейств ОС Windows, не относящиеся к Internet Explorer и программам Microsoft Office – их мы выделили отдельно. В этой категории самое большое количество атак приходится на обнаруженную в win32k.sys уязвимость CVE-2011-3402, которую впервые использовал Duqu.
Также можете сравнить кол-во атак с 2012 годом, например. И увидите, что не смотря на снижение доли ХР до 25% (грубо) ситуация с кол-вом заражений, численностью ботнетов и т.п. — ну никак не улучшилась
Т.е. реально никакой пользы от нововведений MS просто нет.
Я отнюдь не против новых технологий. Но дело-то в том, что ничего реально нового M$ не предлагает и не делает.
На то есть объективные причины. И причина номер один — совместимость с существующим софтом.
А все эти DEP, ASLR и прочее баловство — это мелкие твики, раздутые маркетингом.
Запрет на исполнение кода из памяти данных существует еще, дай бог памяти, с 386 процессоров… А DEP это те же яйца- только в профиль. И с такой же эффективностью.
ASLR — ноги растут еще из 97 года (если верить Википедии).
UAC — вообще бесполезная вещь. За примерами далеко не пойду. Привет от Яндекс-диска…
Есть личный опыт, так что знаю точно. Очень много. И с XP и с 2000 и с NT (но это уже совсем старички)
Сами-то станки как правило управляются разными ПЛК. Но вот к ним «в комплекте» идут компы со всякими разными интерфейсными картами. Часто — проприетарщина голимая, втыкаемая как в PCI так и в LPT, USB, COM…
И вот к этим-то железкам дрова «ровесники» станка. И новые для вас никто делать не собирается.
И получается очень неприятная штука. Обновлять ОС нельзя. А дырки-то затыкать надо. Ибо иногда комп нужно и в сеть выткать — для оперативности, да, впрочем, и на флэшке всякую дрянь притащить могут.
Дешевле. Но
1. LibreOffice !== Microsoft office (причем, даже если брать без Access… Проблем совместимости документов с libre чуть более чем дофига…
2. Есть еще такая опция как 1С. Пока с линухом не очень дружит… Костыли есть — но они такие костыли…
Насчет безопасности…
Тут выше в другой ветке пишут. И DEPa в хрюше нету и ASLR и UAC (чур меня, чур!) тоже нет. Какой ужас.
Но, одна мелочь: osvdb.org — делаем выборку по вендору.
Смотрим последнюю десятку уязвимостей…
Офигеваем. ВСЕ дырки работают по vista/7/8
100764: Microsoft Office Shared Component Crafted Webpage Handling Address Space Layout Randomization (ASLR) Bypass
100759: Microsoft Windows Win32k.sys Crafted TrueType Font (TTF) File Handling DoS
100760: Microsoft Windows portcls.sys Driver Memory Object Handling Double-fetch Local Privilege Escalation
…
И т.д.
Даже хуже. Большая часть списка работает под > XP…
И что из этого нужно для типично офисной машины?
Почта + скайп+ ворд?
Учитывая, что компы, лицензии на винду и офис уже куплены?
Вот, поставьте себя на место владельца компании. У вас есть прекрасно справляющийся со своей работой комп с чем-то 1-2х ядерным, на 2-3ГГц
Вы будете покупать новый комп (9000) + винда (6000) + офис (9000) + работа (2400 [8 часов при почасовой ставке 300, учитываем простой сотрудника и время на перенос данных и настройку])?
Отдать практически косарь баксов на каждый хост за «няшные цветовые решения»?
Причем, цены я брал по уровню плинтуса и с «самосбором». Брэндовые решения — это где-то вдвое дороже.
Не надо устраивать гонку версий рад самих версий. ОС — это всего лишь инструмент, решающий довольно узкий круг задач, на самом деле.
А свистелки-перделки это не инструмент…
Добровольно вести досье на себя и друзей, да еще и во многих случаях с компроматом…
Это-ж надо додуматься!
А ведь ведут. И имя им легион.
Да, да тоже терпеть не могу математику — а куда деваться...Ну а если вы работаете на высоком уровне — то это скорее «старость» языка. Современные языки для перебора коллекций используют итераторы и индексами там и не пахнет. Никакими…
foreach($cmments as $comment){ }Так что, возвращаясь к исходному вопросу — для «старых» языков удобство в том, что при счете с нуля вы наделаете меньше ошибок :-)
А для новых — индексы и вовсе не очень-то нужны, да и сделать можно любые, какие хочется (привет итераторам)
Это создаст дополнительный слой преобразования, головную боль с переполнениями и отладкой (когда в исходниках одно — а в ассемблерном режиме — совсем даже другое).
А оно надо?
Вот «оригинал»
Да еще потому, что в низкоуровневых языках (ассемблер) для адресации элементов используется указатель на начало массива, а номер элемента является смещением. Соответственно, адрес первого элемента это [указатель]+0, а не [указатель]+1
Так что с новизной тут как-то не очень…
99% операций могут и должны делаться стандартными операторами SELECT/UPDATE
С ходу — только один безусловный случай когда применение курсоров оправдано — вызов других процедур для каких-то строк выборки. Причем, зачастую, и их можно заменить «неправильными» функциями, меняющими данные (их вызов будет осуществлен при выборке самим TSQL). В других случаях — для построчной обработки выгодно использовать триггеры.
Одним словом, случаев безусловной надобности курсоров в реальных проектах очень мало.
:-)
Как вы себе представляете обработку на прикладном уровне ответа подсистемы хранения вида «вот вам данные, содержащие ошибку с вероятностью 0,0005%»?
Какова степень полезности такого ответа подсистемы хранения для прикладного уровня?
Никто не требует от подсистемы хранения 100% сохранности и правильности данных. Но требуют 100% информации о факте сохранности и правильности данных.
Это не дно и то же!
Если узел недоступен или поврежден — задача подсистемы хранения информировать об этом приложение, возможно, опционально, предложив запрошенную информацию в виде «что смогла — то нашла».
Таким образом, приложения готовые работать с неполными данными — смогут продолжить работу. А не готовые — сообщат о фатальном сбое.
То, что вы предлагаете может стать расширением протокола обмена.
Но вот «тихая» подмена данных (или информации о состоянии данных — при записи например) в рамках существующих протоколов IO никак не допустима.
Хранение данных — не та область, где допустимы какие-бы то ни было потери.
В теории — 1 убитый байт может сделать все данные (единицы хранения) полностью негодными к использованию. Причем «без вариантов» исправления (на существующем уровне всего стека технологий).
Согласитесь, даже один битый байт в системном файле ОС «живущей» в таком облачном хранилище может привести к чему угодно, включая полный фатальный выход из строя системы в целом.
Ведь все дело в том, какой слой абстракции ответственен за целостность данных. Сейчас за него отвечает устройство хранения — просто потому, что нереально (и экономически не обосновано, в первую очередь) перекладывать этот контроль на уровень приложения. Вы вообще себе представляете контроль целостности всех структур данных всех приложений? И обработку всех возможных повреждений?
К слову, существующий уровень работы с устройствами хранения, кстати, отнюдь не подразумевает бесконечной надежности. И отказ чтения одиночного сектора может (но не обязан) обрабатываться на прикладном уровне.
И задача подсистемы хранения или выполнить команду и доложить об успехе — или честно сообщить, что вышел облом. А никак не строить предположения на тему «а может приложение обойдется без этих ХХ байт?», «А может ему сойдут эти байты их прошлого бэкапа?»
А на практике — по данным ЛК за 2013 год — топовая уязвимость CVE-2011-3402
Цитирую
Пруф 1: www.securelist.com/ru/analysis/208050822/Kaspersky_Security_Bulletin_2013_Osnovnaya_statistika_za_2013_god
Пруф 2: www.securelist.com/ru/blog/207768987/Obnovleniya_Microsoft_za_dekabr_2013_g_patch_kriticheskoy_0_day_uyazvimosti_ekspluatiruemoy_v_dikoy_prirode
Также можете сравнить кол-во атак с 2012 годом, например. И увидите, что не смотря на снижение доли ХР до 25% (грубо) ситуация с кол-вом заражений, численностью ботнетов и т.п. — ну никак не улучшилась
Т.е. реально никакой пользы от нововведений MS просто нет.
Я отнюдь не против новых технологий. Но дело-то в том, что ничего реально нового M$ не предлагает и не делает.
На то есть объективные причины. И причина номер один — совместимость с существующим софтом.
А все эти DEP, ASLR и прочее баловство — это мелкие твики, раздутые маркетингом.
Запрет на исполнение кода из памяти данных существует еще, дай бог памяти, с 386 процессоров… А DEP это те же яйца- только в профиль. И с такой же эффективностью.
ASLR — ноги растут еще из 97 года (если верить Википедии).
UAC — вообще бесполезная вещь. За примерами далеко не пойду. Привет от Яндекс-диска…
Есть личный опыт, так что знаю точно. Очень много. И с XP и с 2000 и с NT (но это уже совсем старички)
Сами-то станки как правило управляются разными ПЛК. Но вот к ним «в комплекте» идут компы со всякими разными интерфейсными картами. Часто — проприетарщина голимая, втыкаемая как в PCI так и в LPT, USB, COM…
И вот к этим-то железкам дрова «ровесники» станка. И новые для вас никто делать не собирается.
И получается очень неприятная штука. Обновлять ОС нельзя. А дырки-то затыкать надо. Ибо иногда комп нужно и в сеть выткать — для оперативности, да, впрочем, и на флэшке всякую дрянь притащить могут.
Так что, проблема имеет место быть.
1. LibreOffice !== Microsoft office (причем, даже если брать без Access… Проблем совместимости документов с libre чуть более чем дофига…
2. Есть еще такая опция как 1С. Пока с линухом не очень дружит… Костыли есть — но они такие костыли…
Насчет безопасности…
Тут выше в другой ветке пишут. И DEPa в хрюше нету и ASLR и UAC (чур меня, чур!) тоже нет. Какой ужас.
Но, одна мелочь:
1. LibreOffice !== Microsoft office (причем, даже если брать без Access… Проблем совместимости документов с libre чуть более чем дофига…
2. Есть еще такая опция как 1С. Пока с линухом не очень дружит… Костыли есть — но они такие костыли…
Насчет безопасности…
Тут выше в другой ветке пишут. И DEPa в хрюше нету и ASLR и UAC (чур меня, чур!) тоже нет. Какой ужас.
Но, одна мелочь:
osvdb.org — делаем выборку по вендору.
Смотрим последнюю десятку уязвимостей…
Офигеваем. ВСЕ дырки работают по vista/7/8
100764: Microsoft Office Shared Component Crafted Webpage Handling Address Space Layout Randomization (ASLR) Bypass
100759: Microsoft Windows Win32k.sys Crafted TrueType Font (TTF) File Handling DoS
100760: Microsoft Windows portcls.sys Driver Memory Object Handling Double-fetch Local Privilege Escalation
…
И т.д.
Даже хуже. Большая часть списка работает под > XP…
Почта + скайп+ ворд?
Учитывая, что компы, лицензии на винду и офис уже куплены?
Вот, поставьте себя на место владельца компании. У вас есть прекрасно справляющийся со своей работой комп с чем-то 1-2х ядерным, на 2-3ГГц
Вы будете покупать новый комп (9000) + винда (6000) + офис (9000) + работа (2400 [8 часов при почасовой ставке 300, учитываем простой сотрудника и время на перенос данных и настройку])?
Отдать практически косарь баксов на каждый хост за «няшные цветовые решения»?
Причем, цены я брал по уровню плинтуса и с «самосбором». Брэндовые решения — это где-то вдвое дороже.
Не надо устраивать гонку версий рад самих версий. ОС — это всего лишь инструмент, решающий довольно узкий круг задач, на самом деле.
А свистелки-перделки это не инструмент…