Админ удали тему...
Вид для печати
Админ удали тему...
какого характера операционка?
графический интерфейс (кривой или крутой)- это еще не операционка, это только надводная часть айсберга, могу сказать по своему небольшому опыту.
в качестве примера могу посоветовать сравнить win3.1 и UNIX. в первом все красиво, а внутри- пустышка. во втором случае- командная строка с мигающим курсором и неограниченные возможности.
эта тема меня тоже очень занимает, но к сожалению катастрофически нет времени чтобы чтото делать (учеба, работа, хочется другие проекты делать). хотя одна из разработок имеет прямое отношение к ОСям и разрабатывалась в рамках подобного экспериментального проекта.
А почему бы не экспериментировать с очередным проектом, а в рамках того же эксперимента не присоединиться к тов.Breeze, чтобы помочь ему в разработке его ОС AQUA DOORS?
посмотрел, заценил. чувствуется системный подход :)Цитата:
Сообщение от spectrum
плиз, в следующий раз делай картинки гифами или пнгшками чтоб меньше весили.
я пока долго и нудно раздумывал на тему осей, стал пристально поглядывать в сторону unix и потратил уже почти штуку на закупку книжек по этой тематике. и если честно, думаю это самое то что нужно для спектрума.
во-первых, графический интерфейс не обязателен. в условиях довольно скромных аппаратных ресурсов это будет немаловажный фактор
во-вторых, не существует проблемы поддержки других файловых систем (в плане расширяемости) и эмуляции виртуальных дисков. (а также поддержки любого железа и прочего, за подробностями- к источникам о файловой системе юниха)
в-третьих, данная система изначально разрабатывалась для слабых компьютеров, несмотря на то, что написана на языке довольно высокого уровня (Си), показала довольно хорошие результаты.
зы. если интересно- стучись в аську
minix?!?!?!?!?! это не тот ли самый миникс, с которого торвальдс начинал? :)Цитата:
Сообщение от spectrum
если переделывать вручную, то думаю и в 16 поместится. потому как там компилятор юзает передачу параметров через стек, что с точки зрения клиента (то бишь вызываемой процедуры) просто замечательно, но с точки зрения вызывающего просто хреново (и это мягко сказано).
концепции графического интерфейса были разработаны и стандартизированы еще черт-те когда, зачем изобретать велосипед? хотя, с другой стороны, нельзя просто брать и бездумно сдирать все подряд, нужно перерабатывать все в зависимости от обстоятельств.
заходи ко мне в аську, а то форум тут чат уже напоминает :)
Имеется ввиду UZI (unix z80 implementation). Рекомендую смотреть в сторону UZIX -- реализация UZI на MSX. uzix.sf.net, если не ошибаюсь.Цитата:
Сообщение от Vitamin
посмотрел на сайт. впечатлился по самое не балуйся :)Цитата:
Сообщение от fk0
вопрос- на MSX есть текстовый режим? или все как на спеке?
Выдержка из http://www.work.de/nocash/portar.htm#videomodesscreens:
Код:M1 M2 M3 M4 M5 Screen format
1 0 0 0 0 Text 40x24 (BASIC SCREEN 0)
0 0 0 0 0 Half text 32x24 (BASIC SCREEN 1)
0 0 1 0 0 Hi resolution 256x192 (BASIC SCREEN 2)
0 1 0 0 0 Multicolour 4x4pix blocks (BASIC SCREEN 3)
----Below MSX2 only----
0 0 0 1 0 Screen2 with 8 Sprites/Line (BASIC SCREEN 4)
0 0 1 1 0 256*212, 16 colours/pixel (BASIC SCREEN 5)
0 0 0 0 1 512*212, 4 colours/pixel (BASIC SCREEN 6)
0 0 1 0 1 512*212, 16 colours/pixel (BASIC SCREEN 7)
0 0 1 1 1 256*212, 256 colours/pixel (BASIC SCREEN 8)
1 0 0 1 0 Text 80x24 (BASIC SCREEN 0, WIDTH 80)
Чтобы остудить пыл спектрумистов в области UZIX, приведу цитату уважаемого dhau из соседнего топика:Цитата:
Сообщение от Vitamin
Цитата:
Насчет Uzix - да - все продумано хорошо, и реально работает, сам пробовал, *НО*, !!!сюрприз-сюрприз!!!, все тормозит просто ужастно. Более ли менее идет только на моей MSX TurboR GT, но в этой машине стоит R800 - недо-рисковский аппаратный эмулятор Z80, который любую Z80 комманду выполняет за один такт и работает на частоте 7MHz! Кто-то из MSX-еров говорил что грубо говоря это примерно как обычный Z80, но разогнанный на 40MHz. Как только все спектрумы обзаведутся Z80 @ 40MHz, можно смело переходить на Uzix
а кто сказал что необходимо брать этот юзикс и переносить вот так сразу? для начала можно поучиться что там и как сделали. с другой стороны можно самостоятельно попробовать себя в роли компилятора и писать код по исходу на С. это даст прирост скорости в 2 и более раза. плюс другие изменения/дополнения и может чтото из этого выйдет
Человек в роли оптимизирующего компилятора может побороться лишь со старыми компиляторами 80-х годов - большого прироста скорости это не даст, а вот времени убъет немерянно :wink:Цитата:
Сообщение от Vitamin
Ну не скажи. Ни один компилятор сей не догадается на з80 юзать стек как попало (даже скорее как обычно =). Для всяких "недо"процессоров типа з80, мцс51, пик, авр вряд ли хоть один компилятор сравнится по извращенским оптимизациям с человеком =). А вот для таких монстров, как например ppc - компайлеры могут уже и порулить человека. Как-то я видел доку от мутороллы - что надо менять в компайлерах, чтоб код оптимизировали не под g3, а под g4. Там столько разных заморочек, незнание которых приводит к СОВСЕМ не оптимизированному коду.Цитата:
Сообщение от Shaos
Даже для z80 есть компиляторы, которые аргументы функций не через стек передают (точнее не все через стек), а по мере возможности через регистры. Хотя может критические участки кода и можно человеку писать, например внутренности циклов или разворачивать циклы работы с экраном и т.д. - где выигрышь в одном проходе не единицы тактов может дать существенный прирост в цикле.Цитата:
Сообщение от lvd
Никто не спорит. Но к времени когда ты докончишь оптимизировать ls и chmod, миром уже будут управлять органические роботы-киборги, а земля будет эксклюзивной курортной зоной для туристов из альдебарана :)Цитата:
Сообщение от lvd
Мое мнение - операционки надо писать на С и только на С. Разумется, после отладки - критичные места надо оптимизить ручками на асме.
Мнение основано на том, что в свое время я разрабатывал специфичные реал-таймовые микро-операционки для AVR, сейчас реал-таймовую разрабатываю операционку для ядер ARM. Уже работает уровень драйверов. Сейчас вожусь с менеджером задач и файловым уровнем. Еще пришлось работать с операцонкой для 196го писанной на асме. Кошмар!
В общем асм - это не для больших проектов. Однозначно. Лично мне по душе такой подход:
- Разрабатывается структура системы (я за основу принял UNIX-идеологию).
- Пишется на С вся ОС в общем виде.(особенно удобно на С описание структур, без которых ни одна нормальная ОС не обходится).
- Все отлаживается (особенно попистая отладка - это менеджеры памяти и задач).
- Выделяются узкие по производительности места.
- Переписываются узкие места (возможно на асме), оптимально.
Времени экономится - масса.
А с нуля раскорячивать идеи в ассемблер - никакого времени не хватит. Убъешь массу времени на "супер-оптимальный" кодинг, а потом окажется, что вся структура системы или части системы - плохо продумана и надо все переделывать.
Это мое ИМХО.
Целиком поддерживаю коллегу.Цитата:
Сообщение от SfS
Осталось только оптимизирующий C компилятор где нить нарыть :)
Очень интересно было бы узнать чего вам не хватило в SDCC. (это серьезный вопрос, без иронии :))Цитата:
Сообщение от GriV
Я во флейме писал - есть свободный кроскомпилер. Правила оптимизации можешь писать к нему сам, если стандартных не хватает. Оптимизирует на уровне ассемблерного исходника. Для обкатки идей - более чем достаточно.Цитата:
Сообщение от GriV
Цитата:
Сообщение от spectrum
Какие графические интерфейсы, какой C? Вы что и зачем писать хотите, сами понимаете? Операционка ради операционки – это, конечно, хороший способ набраться опыта в работе с текстовым редактором, но разве она не должна решать существующие проблемы? Кто-то в этом форуме уже предлагал добавить в ПЗУ несколько RST для нормальной работы с памятью и файловой системой, вот уж что действительно было бы полезно. А какая польза будет от новой графической запускалки?Цитата:
Сообщение от SfS
Эээ - по поводу оптимизации лс и чмода - это к Робусу =)))Цитата:
Сообщение от dhau
Боюсь с начальным опытом MS Visio и схемами плана USER->KEYBOARD->MONITOR никуда не уедешь....Цитата:
Сообщение от spectrum
Хорошая ось - это очень непросто... Тот же IS-DOS огого написать...
скинуться по 100$ и заказать у майкрософт на заказ ;)
или у Genesi или их там омижниковых морфосников...
Я уже писал, почему С. Потому что пока ты на асме отладишь все эти RST дополнительные - у тебя столько времени уйдет - что все надоест. А "нормальная работа с памятью и файловой системой" вообщето и является одними из основных функций почти любой ОС. Что значит "добавить несколько RST" ? Одного достаточно. Но дело не в RST. Дело в том, что ОС обеспечиват прежде всего работу с разнородным оборудованием, устраняя проблемы несовместимости. Грубо говоря - программа пользователя обратилась к ОС с запросом - "дай мне 2к памяти", ОС должна вернуть адрес выделенного блока в какойто форме или код ошибки, если памяти нет. А уж на какие там порты подключено переключение страниц памяти и в какие окна и как все это делается - это сугубо интимные проблемы дрпайвера памяти, установленного на данной ОС в данной машине. И они никак не должны касаться программы пользователя.Цитата:
Сообщение от hex
Или работа с файлами - на кой программе юзера знать - на какой физической файловой системе лежит файл с данными игрушки ? Пусть эти проблемы мучают ОС. А программа пользователя должна только уметь сказать ос "myfileid=open("/games/mysupergame.dat",O_RDONLY):read(myfileid, &buffer, size);close(myfileid); - все !!! Остальное - интимные проблемы драйверов файловой системы и драйверов устройств !
Все нормальные компы так работают....
чем вам IS-DOS не угодил? его б лучше дорулить...
Товарищ экспериментатор ! Может я несколько самонадеян, НО !!!! ОС - это не ГРАФ ИНТЕРФЕЙС. Это НЕ КНОПОЧКИ !!!! ЧТО ЗА ВИНДОВОЗНО-МИКРОСОФТНЫЙ ПОДХОД ?!Цитата:
Сообщение от spectrum
ОС - это прежде всего работа с оборудованием.
Подумай вот над чем:
- Как будет реализована работа с памятью. Алгоритм выделения, освоюождения памяти. То есть менеджер памяти.
- Как будет выглядеть единый интерфейс драйверов устройств.
- Как будут отображаться устройства на виртуальную файловую систему.
- Как будут подключаться файловые системы устройств к виртуальной файловой системе.
- Как буде реализована файловая система и взаимодействие с ней.
- Как будет работать менеджер задач. (Тип многозадачности, распределение времени)
И только потом, когда ты нарисуешь и обкатаешь эти схемы - сможешь подумать "кнопочках, рюшечках и прочей байде". Событийный графинтерфейс написать - несложно.
Всем. По сути это не ОС, а только ДОС. На кой нам однозадачная ОС ? Это неправильно.Цитата:
Сообщение от DizZy
Странно, что ты свалил всё в кучу - ФС и задачи с памятью.Цитата:
Сообщение от SfS
Надо сильно думать вот над чем
1. механизмы многозадачности.
2. память.
3. 'событийные' механизмы: сигналы, мессаги, семафоры.
Все драйвера далее могут взаимодействовать с задачами на основе этих механизмов. ФС/etc же вообще тут не причём - её можно добавить как отдельную либу, у которой уже свои механизмы работы (основывающиеся на событийных и тасковых механизмах) с драйверами ФСов и драйверами накопителей.
По крайней мере так ось сделана на амиге - всем осописателям кстати рекомендуется ознакомиться. =)
Ну да, всё это сделать-то несложно, но применительно к спеку возникают проблемы нехватки памяти, быстродействия, етц. И возможно не так уж неправы были исдосники, что сделали монолитную систему-командер.Цитата:
И только потом, когда ты нарисуешь и обкатаешь эти схемы - сможешь подумать "кнопочках, рюшечках и прочей байде". Событийный графинтерфейс написать - несложно.
В Unix-системах драйвера взаимодействуют с программой пользователя как файлы устройств. В этом отношении мне Юниксы нравятся своей простотой и логичностью. Возможно мы имеем ввиду разные файловые системы ? Есть файловые системы хранения файлов на физ. уровне (FAT, Ext2 и тд), а я говорил о виртуальной файловой системе, которая объединяет все файловые системы в одно дерево. В этом дереве - и фйлы данных и файлы устройств и файлы-ссылки и т.д. и т.п.Цитата:
Сообщение от lvd
Не спорю. А так же всем осописателям рекомендуется изучить книги "Операционные системы" Т.Б.Большаков - Д.В.Иртегов и "Сетевые операционные системы" Н. А. Олифер, В. Г. Олифер... В общем и обзорно и с реальными примерами рассмотрены типы ОС, типы менеджеров памяти, файловых систем, методов взаимодействия с драйверами и т.п.Цитата:
Сообщение от lvd
Они просто копировали Нортон и идеологию ДОС (заметь - не ОС, а ДОС!), распостраненных на тот момент. Привязывать ядро ОС к пользовательскому интерфейсу - глупость несусветная ! Причем выигрыша в быстродействии никакого не дает. Какая разница - загружена у тебя программа, выводящая на экран окошки как внешняя или вкомпилена в ядро ОС ? Для процессора - никакой. Он и то и это будет выполнять с примерно равной скоростью. А вот с памятью ситуевина как раз прямо обратная. Вкомпиленный в ядро интерфейс пользователя - это ПОПА !!! В том смысле - что он жрет память не зависимо от того нужен он реально пользователю или нет. А если он подгружаемый - то все более приятно. Есть память - можно подгружать оконно-мышинный супероконный. Нет памяти - подгрузил маленкий интерпретатор комстроки - или нечто Нортон-подобное...Цитата:
Сообщение от lvd
принял бы участие в написании unix подобной оси/ядра для спека. опыт в языке Си - 9 лет. только давайте действительно сначала определимся с многозадачностью и системой меж процессовых комуникаций. остальное, в принципе, уже пройденный путь. естественно файл система будет модульной. но нам, для начала, микро ядро надо продумать.
может сделать отдельную ветку? с идеей автора данной темы это довольно большая разница. (я вообще против графического интерфейса в составе оси как таковой. если программе понадобится графика, пускай сама делает. в крайнем случае напишем либу какую-нибудь).
целью считаю размещение самого ядра и минимума драйверов в 16кб странице (вместо пзу).
PalmOS, например, сразу изначально базировалась на GUI, хотя на самом первом Палме памяти было как у современного Спектрума, процессор стоял слабенький (сопоставимый по мегагерцам со Спектрумовским) и однобитный экран 160х160. Я помнится даже в REAL.SPECCY кидал скриншоты с палмовских электронных таблиц в формате SCR 6912... Так что может быть не стоит вот так сразу откидывать идею с GUI? Хотя, вероятно, именно для Спектрума GUI вовсе и не нужен...Цитата:
Сообщение от random
Примерно об этом я и писал вот здесь: http://zx.pk.ru/showthread.php?t=168Цитата:
Сообщение от random
Это как раз идеология унихов - всякие там / и все девайсы как файлы etc. В результате имеем монструозное ядро. Да и к тому же унихам ММУ нужен (ну есть конечно uClinux, но думаешь он спасёт на Z80?).Цитата:
Сообщение от SfS
Ну да - глупость, когда например в винде таски обменивааться месагами могут только через окошки =) Я говорю, что может быть это и глупость, но таки позволила хоть куда-то уехать - мне навскидку трудно прикинуть, с какой скоростью будет работать честная многозадачная ос на спеке и сколько будет жрать ОЗУ, етц.Цитата:
Они просто копировали Нортон и идеологию ДОС (заметь - не ОС, а ДОС!), распостраненных на тот момент. Привязывать ядро ОС к пользовательскому интерфейсу - глупость несусветная ! Причем выигрыша в быстродействии никакого не дает.
От ГУЯ отказываться не надо. Просто ГУЙ - это отдельная довеска, которая может быть в ОС, а может ее и не быть. Короче уровень ОС - это драйвер экрана, мыши и клавиатуры. А уровень ГУИ - это просто программа или набор библиотек для рисования окошек, кнопок и так далее. Нужен пользовательской программе ГУЙ - подгружаем этот набор библиотек и используем, не нуже - не надо и память занимать.Цитата:
Сообщение от CityAceE
В общем ОС - это ядро. А ГУЙ - это пользовательская программа. ИМХО так правильнее.
ММУ - не обязателен, хотя и желателен. Что касается "монстроидности" ядра - все зависит от набора его функций. Если взять минимальный набор - то ядро совсем компактненькое получается. Реально - у меня для ARMа реализация менеджера памяти (кстати - тоже без ММУ) и стандартного интерфейса драйверов - около 5 Кбайт занимает. И это учитывая, что длина команды ARMa - 16 бит всегда (в режиме THUMB, который я использую). Для Z80 - программа явно короче будет.Цитата:
Сообщение от lvd
Основная память и ресурсы - жруться не ядром ОС, а программами пользователя и подгружаемыми драйверами. Отсюда вывод - чем больше у тебя устройств приткнуто к спеку - тем больше памяти драйвера будут занимать. Сколько временннЫх ресурсов ОС жрать будет - это вообще отдельный вопрос. Тут все зависит от того какой тип многозадачности и какими приоритетами обладают задачи. Главное - следует помнить, что большинство функций ОС запускаются не "сами по себе", а только в результате обращения к ОС программы пользователя.Цитата:
Сообщение от lvd
Особенно важно распределить приоритеты задач. Я в свое время писал для AT90S8535 программку для управления тех процессом. У меня была жесткая привязка к реальному времени следующих вещей - 4 7сегментника, три канала АЦП - измерения напряжения трежфазной сети. Молодой был, глупый. Пока приоритеты правильно между задачами не распределил - индикатор маргал неравномерно и ьбезбожно, сеть мерялась ужасно. Думал быстродействия не хватает, а оказалось - приоитеты задач - это не пустой звук. Переделал - все как часы заработало.
С точки зрения программ пользователя - ресурсопрожорливость вообще не оценить - откуда я могу знать какой очередной изврат "крутых хацкеров" пожелают под ОС запустить ? Скорее всего придется делать режим "монопольное использование процессора" для нормального запуска программ, где все привязано к тактам проца.
налопался шоколада, почитал данный тред, полистал рульную книжку "UNIX изнутри" и пробило на высказывание некоторых мыслёв народу. от народа требуется высказывание мнений по каждому пункту. желательно с аргументацией и разумными доводами
1) многозадачность нужна. как показывает практика, большую часть времени процессы проводят в ожидании ввода/вывода, т.е. ожидания чтения с носителей (в случае спека не совсем актуально- чтением занимается процессор) или ввода пользователем чего-нибудь. имеет смысл использовать свободное время с пользой.
2) прошивка ядра ОС вместо ПЗУ (как вариант- кеш), потому что основной памяти и так мало
3) делать ядро из модулей (типа линуха). в начальной поставке идет универсальное ядро, поддерживающее всевозможное железо или минимальную конфигурацию, работающую где угодно. юзер на целевой машине конфигурирует сборщик, определяя нужные ему возможности и выкидывая ненужные. ядро пересобирается. все довольны.
4) графический пользовательский интерфейс (не путать с Hacker User Interface :) ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. отсюда вытекает невозможность привязки событий и проч. к оконной структуры (как в винде). имхо, следует обратить свой взор к *nix системам (что было сделано в предыдущих постах)
5) если углубляться дальше, то нужно затронуть тему диспетчеризации процессов. с целью уточнения, проконсультировался с преподом у себя в универе. согласно выдвинутым требованиям, он предложил схему с двумя классами процессов- реального времени и разделения времени. процессы реального времени выполняются каждый квант диспетчеризации по цепочке. это могут быть процессы времени, обслуживания ау и проч. остальные процессы распределяются согласно своим приоритетам в оставшееся свободное время.
6) менеджмент памяти. вот тут возникают довольно большие проблемы. в частности изза страничной организации памяти. нижнюю память можно отдать на откуп системы для хранения структур, таблиц и проч. а в верхних страницах хранить процессы. проблема в диспетчере, который должен обеспечивать контроль всей доступной верхней памяти (пусть с точностью до блока в 256 байт)- сложности в ее переменном количестве и возможности разделения одной области памяти несколькими процессами. в принципе эта проблема почти решена, дело за реализацией чтобы проверить идею.
фух. выдохся %)
хочется услышать мнение народа
(2spectrum: я же тебе говорил, что надо делать базу а не оболочку ;)
оболочка без содержания- воздушный шарик, который можно помять)
Согласен - простейший вариант реализации - повешать на NMI таймер, который будет слать прерывания скажем каждую миллисекунду. Пришло прерывание - опросил все устройства (через их драйвера) - есть ли что читать-писать, выполнил нужное. Разумеется это не оптимально. По идее каждое устройство должно уметь само послать прерывание, чтобы драйвер его обработал. Но зато вариант с таймером на NMI - самый простой.Цитата:
Сообщение от Vitamin
Однозначно - кэш. Тогда ОС можно апгрейдить и изменять без перепрошивки ПЗУ. Огромный плюс.Цитата:
Сообщение от Vitamin
Ядро и драйвера к нему должно поставляться либо в исходных текстах (для крутых кульхацкеров) либо просто под конкретную конфигурацию, которая в общем определяется набором встроенных- и подгружаемых драйверов. Скажем будет версия "SuperpuperOS v,Pentagon-1024" или версия "SuperpuperOS v,АТМ-7.10". Пользователь ее скачивает, устанавливает и работает - без гребли с компиляцией.Цитата:
Сообщение от Vitamin
Привязка событий к окошкам - это извратик. Есть понятие "процесс". Есть понятие "сигнал". Несколько "процессов" могут обмениваться "сигналами" межу собой. А рисует процесс окошко или передает данные по модему - не принципиально.Цитата:
Сообщение от Vitamin
Согласен. К процессам реального времени - относятся драйвера и ядро. К остальным - пользовательские (за исключением некоторых - скажем старых программ, которые требуют монопольного выделения процессорного времени).Цитата:
Сообщение от Vitamin
Не вижу больших проблем. Надо хранить таблицу (точнее список) страниц по 16К и свободного места на них. При программировании вся программа разбивается на сегменты длиной не более 16К, что вполне достаточно для весма нехилого куска кода. В начале кажого сегмента программы имеется таблица адресов точек входа. Никакой сегмент программы не может обращаться к другому сегменту иначе, как через эту таблицу. Данными процессы обмениваются через посылку сигналов друг другу, через файлы и через область разделяемых данных в памяти.Цитата:
Сообщение от Vitamin
Распределение памяти мне видется примерно таким:
------------------------- #FFFF
Пользовательские процессы.
------------------------- #C000
Область разделяемых данных
------------------------- #8000
Системные таблицы+подгружаемые драйвера
------------------------- #4000
Ядро+встроенные драйвера.
------------------------- #0000
Такая схема будет работать минимум на 128к, если есть возможность повешать на NMI таймер (хотя можно и через INT - но повиснуть может). Главное, чтобы имелся порт для включения теневого ОЗУ с адреса #0000.
в общем я полностью согласен, именно так себе и представляю такую ОСь.
только одно дополнение к таблице памяти - возможное резервирование экрана (пускай даже Ч/Б) максимум 6912 байт.
Теоретиков, вижу, много. А где же практики??? :)
давайте уже составлять ТЗ, я повторяю, готов потратить часть своего свободного времени на написание C кода.
Мдя :cool: Идей вижу много, идей хороших и неочень, но вот в чем вопрос, а чего всё это грузить? с дискет ? не кажется ли вам, что стоит начать написание оси с начального старта компьютера, с boot-strap'а ?
короче нужна FS! будет FS - будет над чем работать! (я как раз и работаю над этим вопросом :rolleyes: )
кста по поводу раздела памяти #4000 - #8000 - таблицы и подгружаемыые драйвера ? по поводу таблиц ничего против не имею, а вот надчет дров, все видимо дружно заб(и/ы)ли что это область slow memory !!! и всё это будет жутко торрмозить! единственное для чего эта область пригодна это для хранения данных!!! :sleep:
breeze, не тормози. написание оси да и вообще всего что угодно начинается не с bootstrap'а, а с толкового ТЗ. с чего грузить, с чего грузить. это вообще вопрос десятый.
Золотые слова. Поэтому скорей всего никогда Оси не появится, ибо во первых делают в одиночку, а во вторых не знают совершенно что делают :smile: .Цитата:
Сообщение от random
Кстати не раз уже об этом писал!