Про аллокаторы - берём какой-нибудь более-менее сложную программу на языке уборкой мусора - что-то вроде Netbean или eclipse и с ужасом види что они засирают >500 МБ памяти за две секунды работы. Плюс до трети процессорного времни уходит на уборку мусора.
Так чтобы с ходу - архиваторы, медипроигрыватели, медиакодеки, работа с графикой.
Пока что вся философия сводится к тому, что каждая проверенная библиотека и программа считается 100% безопасной. Для яэра и это может быть справедливо - можно вылизать ядро так, чтобы оно было безопасно, но что будете делать, например, с HD-video компрессором/декомпрессором? В ядро встривать? Для каждого кодека? Не реально. Писать на .NET? Нихватит никакой просизводительности производительности. Придётся допустить использовать библиотеки, написанные сторонними авторами. В реальной жизни есть миллион задач, в том числе повседневных, где просто необходимо использовать очень сложные библиотеки написанные на нативном коде или имеющие доступ непосредственно к ядру - это антивирусы, архиваторы, кодеки и прочее, включая видеодрайверы. И уязвимость в любом из них будет глобальной уязвимостью системы.
Пока что это попытка натянуть новый подход к написанию ОС к старому подходу в написании программ и драйверов. А нужно что-то гораздо более масштабное.
Ээээ... а ваш аллокатор не соврешенно не будет использовать никаких объектных типов, включая встроенные? Если да, то он всё равно будет засирать свою память. Во-вторых, строить свой аллокатор это бред, а кучу расширять тоже самому? Может ещё и аналог MMU для простоты написать и поверх него свою ось? :))))
Что-то где-то как-то не так... Что мешает криворукому драйверописателю написать драйвер под некое своё устройство, который будет через DMA гробить систему? Некий плумифический IOMMU? А как он работает на системах, где контроллер шины и памяти находится не в CPU, а в чипсете? Он же 100% аппаратно зависымый от чипсета. У AMD он реализован в гипертранспорте, у Интела - через их чудо-виртуализацию. Я если процессор не Intel и не AMD? А если архитектура не x86?
Второй момент - если все исполняется в одном коце защты, то любая минимальаня уязвимость даёт полный и абсолютный контроль над системой и никакие антивирусы не помогут, т.к. они тоже работают на более высоком уровне. А уязвимостей будет вагон - сделать 100% надёжный анализатор это нынче из области фантастики - нужно менять всю филисофию программирования. Плюс, уязвимость в любом компоненте автоматически распространяет её на всю систему - с таким механизмом защиты достатончо пропустить однин модуль и все кто нипопадя смогут им воспорльзоваться, ведь он страсть какой доверенный.
Третий момент - все эти танцы с динамической компиляцией и уборкой мусора на данный момент работают весьма сомнительно. Уборка мусора в частности приводит к крайне неравномерной производительности системы - скорость исполнения может меняться в стотни раз в зависимости от объёма доступной памяти. Не говоря о том, что это большой тормоз на многих алгоритмах.
Короче, идея забавная, но на нынешнем этапе развития науки и техники слабореализуемая. Хотя кто знает, куда этот путь выведет...
А если за неделю завалят ресурс мусором? Ну, напрмер, сто тыщь мульёном сообщений/действий или что у вас там от пользователся + 100 липовый пользователей. Этак можно сугубо из вредности по два виртуала в день регистрорвать и обновлять всю срань на сайте. По мере удаления старой, уже будет выалено новая (срань).
Сначала, посмеялся и подумал,ч то у меня всё хороши правильно, а потом с ужасом вспомнил, сколько стоит всякого проксирующего железа - от простыейших WiFi точек, до весьма мозговитых маршрутизаторов. И много где реализован и включен DNS-прокси. А стоит оно и дома и на работе и вообще куда ни ткни.
Всё! полный крах и ужас и кошмар - бегу отключать все железо или пернастривать на "свои" DNS сервера.
То есть ничего принципиального нового не появляе тся, а сложность и объём возрастает? Всё это можно было сделать в три раза меньше используя только базовое знаение SQL. И это было понятно каждому. А в этой мути без понимания чудо-hibernate не разберёшься. Плюс несколько дополнительных шагов в сосздании работаебщего проекта (все эти танцы с XML) не факт, что положительно скажутся на простоте отладки и поддержки.
"1. Любая предметная область состоит из сущностей и отношений между ними, а не из каши атрибутов. Поэтому оперировать объектами удобнее и правильней, нежели полями."
Именно так. Но для этого вы и пишене на Java, а не GW-BASIC. Все те же сущности реализуются и при меньшем числе телодвижений.
"2. В ORM вы определяете структуру данных и отношения ОДИН РАЗ, и не задумываетесь при выборке данных. В SQL же вы в каждом запросе цепляете абсолютно глупый компот из JOIN и заново указываете связи (несмотря на то, что структура уже определена DDL)."
Как-то плохо согласуется с ООП. для работы с такого рода данными вам нужно три-вида запросов - инкапсулируйте их в объект. Опять же, объём кода меньше, сложность меньше, телодвижений меньше, понятность больше.
"3. Hibernate-реализация не зависит от движка БД. Чтобы перейти на новый движок вам не нужно будет перелопачивать тонны кода, достаточно поменять пару строчек в конфигурации. Более того, к Hibernate можно прикрутить сторонние движки, например Lucene."
Тем, кто пишет программы (тем более реализиующие столь просте отношения) зависящие от движка БД никакой hibernate не поможет. Как я уже говорил - тут несколько запросов - все замечательно укладывается в страницу кода и бедет полная независимость от БД. Используя hibernate вы лишь пытается уйти от ручного написания это кода (котрый пишется один раз), за счёт странных танцев с XML, но сложность от этого только возрастает - используется две дополнительных технологии (XML и hibernate) плюс крайне сомнительная наглядность результата (который кстати с трудом ложится в идеологию ООП).
"4. Hibernate позволяет в простой форме реализовать наследование". Т.е. все эти мутные class-factory это "простая форма"? Наследование можно реализовать намного проще. тем более в Java.
"5. Кеш данных, кеш второго уровня и прочие вкусности."
Тут совсем не понял. Как можно ускорить выборку из БД не нарушая целостность - не понятно. Хотя допускаю.
"При переименовании таблиц/полей не придется апдейтить все запросы (количество которых может быть вырасти до тысяч), а достаточно лишь поменять меппинг."
Шутите? Вы, что все SQL запросы в своих программах руками пишите и сто раз поторяете если придётся?! При правильной структуре программы при переименованеии полей нужно лишь изменить одну-две строчки кода и собственно саму базу.
"А теперь самое главное:
bus.getDrivers() намного проще, чем
SELECT * FROM drivers, busdriver WHERE drivers.driver_id = busdriver.driver_id AND bus_id "
Т.е. после всех вот тех промежуточных классах проще? :) Т.е. инкапсуляция SQL в отдельный класс и реализация всей вон той мути прямо в классе bus это сложнее? :))))
"В добавок, в IDEs типа Eclipse при вводе "bus." вылезет полный список полей объекта. В SQL же запросах постоянно придется консультировать правильное написание полей в структуре данных."
Нет, правда, скажите, что Вы не серьёзно!!! Или хотите, я вам продам за сто тыщ мульёнов идею, как не писать в каждом методе SQL код? :)))))
СОбственно в данном случае стратегия защиты видится такой: Порше (или его законные представители) продаёт машины? Продаёт. Накладываются ли при этом на проданые машины какие-либо ограничения? Не накладываются (собственно простекает из самого определения "продажи" и "владения" - можно распряжаться, дарить, продавать, наследовать, завещать и т.п, иначе это будет уже аренда. В состав продаваемого входит товраный знак, как неотъемлемая часть товара? Входит. (Более того, используется в рекламных целях). Т.о. при продаже мне передаётся и право владения товарным знаком, как неотъемлемой части товара. С этим судимся аж до Конституционного Суда. Собственно крыть-то ппорше и не чем. Если попытаются доказать, что они продают товар без торговой марки, то пусть снимают лейблы со всех машин, либо это будет аренда.
Кстати именно по эой причние в большинсто стран разрешён ввоз "серых" товаров в единичных количествах - ибо ранее продавец сам этот това продал и теперь уже ограничить его использование никак не может. Можно только обязать маркировать товар,как "серый", можно брать пошлины, но запретить ввоз - малореально.
Из привеведённых цитат закона имеем, что ввоз частным лицом товаров содержажщий товарные знаки (т.е. практический всех товаров) также запрещён, т.к. ничто не запрещает мне этот товар в дальнейшем продать, т.е. ввести в гражданский оборот.
Более того, тут есть один момент - я законно приобрёл товар, содержащий на сабе товарный знак у предыдущего владельца, который приобрёл его у производителя. При этом сам товарный знак был размещён на товрае (как неотъемлемая его часть) его (товраного знака) законным владельцем и на момент продажи никаких огрничений на его использование (товраного знака нанесённого на товар) и/или продажу (как часть товара) не налагалось. Таким образом, я приобрёл право на использование этого товарного знака (как часть товара). Каким таким чудом, некая контора умудриляется задним числом (!!) отнять у меня (а соотвественно, и у всех предыдущих владельцем товара), ранее проданое мне право на использование товара? С этим можно и в КС идти - шансы есть.
Второй момент - если я рашпилем стесал к чертям собачачьим логотип Порше с автомобиля? Автомобиль есть. Номер кузова и двигателя есть. В крайнем случае марка автомобиля устанавливается по суду, по запросу в фирму производитель. Документы есть. Товарного знака нет.
Скорее всего это их работа и бдома они обкатывают/тестируют какие-то решения. У меня тоже в шкафу в прихожей куча железа стоит, хотя канал в инет минимальный. Просто я там тренеруюсь - удобно иметь своё 24/7 IT-хозяйство.
А откуда уверенность, что сообщение пришло именно от этого номера? В аське же, вроде как, можно подделывать номер адрес отправителя, если порты открыты и разрешены сообщения от неавторизированных пользователей.
Вполне хорошая щутка.
Господа, всё гораздо проще. Достатончо вставить в документ ссылку находящуюся на "своём" сервере и потом в логах посмотреть кто и когда попытался обратиться к этому файлу. Вот и весь "пинг".
ARM изначально заточен под оптимизацию кристалла - максимум возможностей при минимуме транзисторов. Из-за этого масса ограничений по архитектуре. ARM - это архитектура на продажу. Первый (и похоже на данный мемент последний), кто попытался серьёзно оптимизировать ARM по призводительности это Интел, но и они не стали выжимать из него максимум возможностей - ачем создавать конурент Атому?
Так чтобы с ходу - архиваторы, медипроигрыватели, медиакодеки, работа с графикой.
Пока что это попытка натянуть новый подход к написанию ОС к старому подходу в написании программ и драйверов. А нужно что-то гораздо более масштабное.
Второй момент - если все исполняется в одном коце защты, то любая минимальаня уязвимость даёт полный и абсолютный контроль над системой и никакие антивирусы не помогут, т.к. они тоже работают на более высоком уровне. А уязвимостей будет вагон - сделать 100% надёжный анализатор это нынче из области фантастики - нужно менять всю филисофию программирования. Плюс, уязвимость в любом компоненте автоматически распространяет её на всю систему - с таким механизмом защиты достатончо пропустить однин модуль и все кто нипопадя смогут им воспорльзоваться, ведь он страсть какой доверенный.
Третий момент - все эти танцы с динамической компиляцией и уборкой мусора на данный момент работают весьма сомнительно. Уборка мусора в частности приводит к крайне неравномерной производительности системы - скорость исполнения может меняться в стотни раз в зависимости от объёма доступной памяти. Не говоря о том, что это большой тормоз на многих алгоритмах.
Короче, идея забавная, но на нынешнем этапе развития науки и техники слабореализуемая. Хотя кто знает, куда этот путь выведет...
Всё! полный крах и ужас и кошмар - бегу отключать все железо или пернастривать на "свои" DNS сервера.
"1. Любая предметная область состоит из сущностей и отношений между ними, а не из каши атрибутов. Поэтому оперировать объектами удобнее и правильней, нежели полями."
Именно так. Но для этого вы и пишене на Java, а не GW-BASIC. Все те же сущности реализуются и при меньшем числе телодвижений.
"2. В ORM вы определяете структуру данных и отношения ОДИН РАЗ, и не задумываетесь при выборке данных. В SQL же вы в каждом запросе цепляете абсолютно глупый компот из JOIN и заново указываете связи (несмотря на то, что структура уже определена DDL)."
Как-то плохо согласуется с ООП. для работы с такого рода данными вам нужно три-вида запросов - инкапсулируйте их в объект. Опять же, объём кода меньше, сложность меньше, телодвижений меньше, понятность больше.
"3. Hibernate-реализация не зависит от движка БД. Чтобы перейти на новый движок вам не нужно будет перелопачивать тонны кода, достаточно поменять пару строчек в конфигурации. Более того, к Hibernate можно прикрутить сторонние движки, например Lucene."
Тем, кто пишет программы (тем более реализиующие столь просте отношения) зависящие от движка БД никакой hibernate не поможет. Как я уже говорил - тут несколько запросов - все замечательно укладывается в страницу кода и бедет полная независимость от БД. Используя hibernate вы лишь пытается уйти от ручного написания это кода (котрый пишется один раз), за счёт странных танцев с XML, но сложность от этого только возрастает - используется две дополнительных технологии (XML и hibernate) плюс крайне сомнительная наглядность результата (который кстати с трудом ложится в идеологию ООП).
"4. Hibernate позволяет в простой форме реализовать наследование". Т.е. все эти мутные class-factory это "простая форма"? Наследование можно реализовать намного проще. тем более в Java.
"5. Кеш данных, кеш второго уровня и прочие вкусности."
Тут совсем не понял. Как можно ускорить выборку из БД не нарушая целостность - не понятно. Хотя допускаю.
"При переименовании таблиц/полей не придется апдейтить все запросы (количество которых может быть вырасти до тысяч), а достаточно лишь поменять меппинг."
Шутите? Вы, что все SQL запросы в своих программах руками пишите и сто раз поторяете если придётся?! При правильной структуре программы при переименованеии полей нужно лишь изменить одну-две строчки кода и собственно саму базу.
"А теперь самое главное:
bus.getDrivers() намного проще, чем
SELECT * FROM drivers, busdriver WHERE drivers.driver_id = busdriver.driver_id AND bus_id "
Т.е. после всех вот тех промежуточных классах проще? :) Т.е. инкапсуляция SQL в отдельный класс и реализация всей вон той мути прямо в классе bus это сложнее? :))))
"В добавок, в IDEs типа Eclipse при вводе "bus." вылезет полный список полей объекта. В SQL же запросах постоянно придется консультировать правильное написание полей в структуре данных."
Нет, правда, скажите, что Вы не серьёзно!!! Или хотите, я вам продам за сто тыщ мульёнов идею, как не писать в каждом методе SQL код? :)))))
Более того, тут есть один момент - я законно приобрёл товар, содержащий на сабе товарный знак у предыдущего владельца, который приобрёл его у производителя. При этом сам товарный знак был размещён на товрае (как неотъемлемая его часть) его (товраного знака) законным владельцем и на момент продажи никаких огрничений на его использование (товраного знака нанесённого на товар) и/или продажу (как часть товара) не налагалось. Таким образом, я приобрёл право на использование этого товарного знака (как часть товара). Каким таким чудом, некая контора умудриляется задним числом (!!) отнять у меня (а соотвественно, и у всех предыдущих владельцем товара), ранее проданое мне право на использование товара? С этим можно и в КС идти - шансы есть.
Второй момент - если я рашпилем стесал к чертям собачачьим логотип Порше с автомобиля? Автомобиль есть. Номер кузова и двигателя есть. В крайнем случае марка автомобиля устанавливается по суду, по запросу в фирму производитель. Документы есть. Товарного знака нет.
Вполне хорошая щутка.