Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 4, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Общие :: Разное |
|
<< Предыдущая тема | Следующая тема >> |
| Язык как основа операционной системы | ||
| Переход на страницу 1 2 3 ... 5 [6] 7 ... 15 16 17 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| cmp |
| ||
 ID пользователя #279 Зарегистрирован: Понедельник 18.04.2005 15:35Сообщений: 131 |  по ходу моей работы я пишу на php. мне очень нравится отношение времни затраченного на работу к времени выполнения скрипта, я писал системного демона на perl и он тоже справлялся, даже мысли не было намекать на некомпетентность, не спорю, что практики больших проэктов на чем бы то нибыло у меня нет, но тем не менее считаю, что именно дисциплина и жесткий контроль, а не сборщики мусора, решают проблемы. Законы Мерфи.. мы же не кардио стимуляторы собираем, а всего лишь программы, и никто не умрет пока они тестируются и правятся, да и вообще, всегда есть вероятность, что комп попадет в точку пересечения неких космических лучей и решит что 0 равен 1, бывало и такое в моей практике, так что нужно адекватно смотреть на вещи и не искать черных кошек в темных комнатах после обработки комнат напалмом. [ Редактирование Вторник 16.10.2007 02:31 ] | ||
| Наверх | | ||
| ossadchy |
| ||
 ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | Значит я не понял  Мои извинения.Поверьте -- когда проект подходит к 10000 строк -- отношение к многим вещам меняется. Понимаете ли, в конечном счете все выливается в все те же баксы -- если нужна дисциплина и контроль - на это нужны дополнительные ресурсы в процессе разработки -- зачем платить больше? Законы Мерфи.. ну никто не знает где может быть применено ядро Linux завтра -- может и в системах жизнеобеспечения... просто выводы такие -- надо исключать, по возможности, все что может привести к ошибкам. К вопросу о PHP -- почему вы не пишете на C? -- получите более эффективный код, а пользователь не почувствует разницы Улавливаете -- вы тоже снимаете с себя часть проблем используя такой язык как PHP -- хотя конечному пользователю от этого не лучше -- растет нагрузка на сервер, увеличивается время обработки запросов и т.д., но так делают ибо ПРОГРАММИСТАМ ТАК УДОБНЕЙ -- и это далеко не последний вопрос. Система удобная для программистов имеет бОльшие шансы найти поддержку нежели НЕудобная. | ||
| Наверх |
| ||
| cmp |
| ||
| ID пользователя #279 Зарегистрирован: Понедельник 18.04.2005 15:35Сообщений: 131 | Потому что речь идет об офисных приложения, импорт/экспорт в ms-office формат, бд, и тд. тут до меня кое-что было на аксеси намалевано, а по большей часте тетрадочки с табличками, тут php сам бог велел использовать, тем более что узеры сами не знают чего хотят, приходится по пять раз переделывать,,, ладно не о том, по бывает системное и прикладное, в прикладном использование всяких извращения я допускаю и до известного предела приветствую, но когда речь идет о системном, нафиг, потому как это часть подразумевает использование ее специалистами которые знаю что делаю и способны себя проконтролировать, да в конечном итоге это вопрос сводящейся к тому, должна ли система запрашивать подтверждение на удаление файла, люди бывабт разные, я бы не пользовался корзиной если бы она отрубалась стандартными средствами, кто-то по сути хранит там файлы.. | ||
| Наверх | | ||
| Roman I Khimov |
| ||
  ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | cmp написал(а) ... ядро Линукс достаточно большой проэкт по вашему? и что, ткните меня носом в утечку памяти Можно не буду ссылки приводить? Просто скажу, что исправляются они пачками, почти ежедневно. Желающие могут заглянуть в git историю или архивы LKML. Греби и улыбайся! | ||
| Наверх |
| ||
| cmp |
| ||
| ID пользователя #279 Зарегистрирован: Понедельник 18.04.2005 15:35Сообщений: 131 | В тестовых ветвях не спорю, даже в ваниле иногда наверное бывают, но как тогда объяснить, что за недели и месяцы работы память никуда не деется | ||
| Наверх | | ||
| alman |
| ||
 ID пользователя #753 Зарегистрирован: Суббота 28.10.2006 01:21Местонахождение: планета Земля Сообщений: 95 | ossadchy написал(а) ... Суть обсуждения: имеет ли перспективы построение ОС на типобезопасных и managed языках -- от ядра до прикладных программ. Имеет. Во всяком случае некоторые компоненты. | ||
| Наверх |
| ||
| Dron |
| ||
  ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Для каждой задачи нужно выбирать соответствующий инструментарий... Типобезопасный язык не спасет от ошибок. В любом случае управление проектами нужно. (Посади 1000 обезъян, дай им типобезопасный язык и они напишут линукс??? да никогда) Чем больше проект, тем больше вероятность ошибок в нем, но никто не заставляет писать большие проекты... Пишите большие Системы, состоящие из примитивных модулей. В примитивных модулях гораздо проще не допустить ошибок. Не зависимо от того, на каком языке ты пишешь. Я тоже пользуюсь Perl например для утилит... он очень не плохо с этим справляется. И не надо заставлять меня использовать для этого C#. PS: У меня в ядре 10233 строки... оно написано полностью на ассемблере... По работе проекты поскромнее... 4512, 6920, 7481 (все С++)... [ Редактирование Вторник 16.10.2007 11:17 ] Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | Dron написал(а) ... Для каждой задачи нужно выбирать соответствующий инструментарий... Типобезопасный язык не спасет от ошибок. В любом случае управление проектами нужно. Вопрос в затратах человеческих и финансовых ресурсов. Dron написал(а) ... (Посади 1000 обезъян, дай им типобезопасный язык и они напишут линукс??? да никогда) Никто и не утверждал что "напишут" Dron написал(а) ... Чем больше проект, тем больше вероятность ошибок в нем, но никто не заставляет писать большие проекты... Пишите большие Системы, состоящие из примитивных модулей. Любая система -- набор взаимодействующих компонент, не важно - машинных операций, классов, функций, компонент, модулей. Проблем это не снимет. Dron написал(а) ... В примитивных модулях гораздо проще не допустить ошибок. Не зависимо от того, на каком языке ты пишешь. Но модули взаимодействуют между собой -- ошибки появятся тут. Еще раз повторю: не пытайтесь доказать свою уникальность и гениальность -- мол мы можем написать все без ошибок. НЕ МОЖЕТЕ ВЫ cmp & dron И НЕ МОЖЕТ НИКТО. Такова суть человеческого мозга -- там где можно допустить ошибку она будет. Dron написал(а) ... Я тоже пользуюсь Perl например для утилит... он очень не плохо с этим справляется. И не надо заставлять меня использовать для этого C#. Вот покажите место где было сказано: применяйте *исключительно* C# или Java или Smalltalk. Никто не отрицает возможности(и НЕОБХОДИМОСТИ) применения адекватных решаемой задаче инструментов. Ведь правильный их выбор -- 50% успеха. Dron написал(а) ... PS: У меня в ядре 10233 строки... оно написано полностью на ассемблере... По работе проекты поскромнее... 4512, 6920, 7481 (все С++)... Ну и не приятно сэкономить на дебаге 50% времени? По проектированию ОС: мне хочется найти подход который сделает систему действительно униформной, удобной для программиста и даст возможность ей оставаться РЕАЛЬНОЙ а не исследовательской и академической системой. Этому стремлению уже много лет, написано много тысяч строк кода. И все что отрицается изначально, часто воспринимается потом совсем в другом ракурсе. Просто каждый человек должен пережить эволюцию общечеловеческого сознания в своем уменьшенном варианте. Если рассмотреть подход который я описал изначально, то можно выделить следующие тезы. 1. Система разрабатывается на базе единной объектной системы - это уменьшает дублирование как исходного кода так и уменьшает объем загруженного в память бинарного кода. Вместе с тем это не означает что все пишется на ОДНОМ языке. 2. Может отсутстовать как таковое деление на адресные пространства. В работах по L4 (посвященным small address spaces) приведены исследования которые показывают что источник трат времени в микроядерных системах -- как раз переключение адрессных пространств. 3. При размещении всех компонент в едином адресном пространстве ищезает проблема обеспечения коммуникаций между задачами пользователя -- IPC заменяется простым вызовом метода или посылкой сообщения. 4. Не составляет проблем сделать прозрачным взаимодействие объектов находящихся на разных машинах. По-настоящему ОО языки дают такие возможности -- Java, C#, Objective-C, Smalltalk -- кое-что у них можно позаимствовать. 5. Единый набор базовых классов, инструментов и подходов к разработке всех компонент системы -- например, драйвера устройств могут задействовать всю мощь системной библиотеки классов для решения задач взаимодействия с периферией. Все это экономит усилия программистов и ускоряет процесс разработки. 6. Униформный интерфейс всех компонент системы, что фактически "выводит за кулисы" множество проблем взаимодействия между оными(компонентами) - не надо изобретать методов посылки сообщений, ищезает понятие системного вызова как такового(достаточно накладный процесс, даже при задействии "быстрых" системных вызовов), для того чтоб взаимодействовать с любым процессом достаточно изучить API(который легко можно генерировать используя инструменты типа doxy, javadoc и т.д.). Кто имеет желание -- по списку аргументированно доводы за и против. А то сильно отошли от темы Прошу обратить внимание -- нигде не сказано "ограничить", "заставить", "задавить котком" ..  Т.е. призываю к дискуссии а не сорре. | ||
| Наверх |
| ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Одно адресное пространство имеет в частности такой недостаток, как ограничение в 4 гига. (хотя 64-х битные системы этого наверное лишены, там вроде бы можно большее пространство линейно адресовать? не силен я в x64) Мне больше нравится изолировать приложения друг от друга, ИМХО так спокойнее, хотя для конечных пользователей это глубоко пофиг. Еще не люблю смешивать документацию и код... я понимаю что это с одной стороны удобнее, тем, что все в одном месте... Но с другой стороны код должен всетаки просматриваться. это ИМХО... В остальном ничего невозможного не вижу... Тока фраза 'например, драйвера устройств могут задействовать всю мощь системной библиотеки' немного пугает Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | Dron написал(а) ... Одно адресное пространство имеет в частности такой недостаток, как ограничение в 4 гига. (хотя 64-х битные системы этого наверное лишены, там вроде бы можно большее пространство линейно адресовать? не силен я в x64) Сейчас все следует делать с прицелом на 64 бита -- за этим будущее. Вместе с тем не исключается возможность работы в 32х битах -- 4Г для большинства настольных систем сегодня -- даже не ограничение. Системы с большей памятью как правило уже могут работать в 64 битах -- а это теоретически 2^64 байт памяти. Dron написал(а) ... Мне больше нравится изолировать приложения друг от друга, ИМХО так спокойнее, хотя для конечных пользователей это глубоко пофиг. Нравится, спокойней -- славянский подход. Ну а если осмыслить суть подхода? Ведь просто есть замена привычным нам механизмам -- в чем страх? Dron написал(а) ... Еще не люблю смешивать документацию и код... я понимаю что это с одной стороны удобнее, тем, что все в одном месте... Но с другой стороны код должен всетаки просматриваться. это ИМХО... Ну конечно можно и просматривать, просто удобно когда есть спецификация API и она изменяется синхронно с изменением кода. Dron написал(а) ... В остальном ничего невозможного не вижу... Тока фраза 'например, драйвера устройств могут задействовать всю мощь системной библиотеки' немного пугает Опять же пугает | ||
| Наверх |
| ||
| Переход на страницу 1 2 3 ... 5 [6] 7 ... 15 16 17 | |
Powered by e107 Forum System