Jump to content

    

Потребления ресурсов пустой системой

То есть вероятность того, что A. Fig Lee возьмёт любую другую операционку и найдёт в ней 3 бага, велика?

Я, думаю, что не то слово, что велика, а что стремится к 100%. Если брать тот же линукс, то я лично уже в нем выковырял их с десяток минимум... А windows - так еще и не выковыряешь, из-за закрытости, только обходить.

Share this post


Link to post
Share on other sites
Я, думаю, что не то слово, что велика, а что стремится к 100%. Если брать тот же линукс, то я лично уже в нем выковырял их с десяток минимум... А windows - так еще и не выковыряешь, из-за закрытости, только обходить.

Сравнили, конечно, кодовую базу линукса с коос...

Share this post


Link to post
Share on other sites
Сравнили, конечно, кодовую базу линукса с коос...

Так о том и речь, "чем больше, кода, тем..."

Share this post


Link to post
Share on other sites
Так о том и речь, "чем больше, кода, тем..."

Я-то в своём вопросе акцент на другом делал. Ну да фиг с ним.

Share this post


Link to post
Share on other sites
Я, думаю, что не то слово, что велика, а что стремится к 100%. Если брать тот же линукс, то я лично уже в нем выковырял их с десяток минимум... А windows - так еще и не выковыряешь, из-за закрытости, только обходить.

В виндоус помнится выловил гдето в 2000 м году. Там у них обычно в тех местах, где меньше народу ходит, больше багов.

Не помню деталей, функция по извлечению ресурсов из dll. Там диалогов, стрингов и т.д. Чето она заедала у них, то ли 2й диалог не извлекала..

Факт тот, что чтоб сабмитнуть баг, майкрософту надо заплатить.

Потом он расследует, и если решит что это баг, то может даже вернуть деньги.

 

 

Я-то в своём вопросе акцент на другом делал. Ну да фиг с ним.

Товарищ абсолютно правильно выразился.

Количество кода увеличивает количество багов.

Чем менее хоженная ОС, тем больше багов.

 

 

ПыСы. Если у вас "нет багов", это значит их просто пока не нашли или их количество четное и они взаимно компенсируются.

 

Share this post


Link to post
Share on other sites
Товарищ абсолютно правильно выразился.

Количество кода увеличивает количество багов.

Чем менее хоженная ОС, тем больше багов.

 

 

ПыСы. Если у вас "нет багов", это значит их просто пока не нашли или их количество четное и они взаимно компенсируются.

Странно сосуществуют понимание этих вещей со страхом багов, приобрётенным после использования coos (лично у меня не вызывает доверие всё, что связано с кокосом).

Share this post


Link to post
Share on other sites
этих вещей со страхом багов

Нет у программистов нашего уровня (в смысле низкого, на уровне работы с регистрами периферии и инструкциями процессора) никакого страха багов. Есть аксиома - если есть программа, то в ней есть хотя бы один баг. Если его найдут - его следует устранить, но аксиома все равно верна - там наверняка будет еще баг :)

А где он, в линуксе, в коосе, в другом хреносе, были бы исходники, а остальное дело небольшой лишней возни. Что за страхи то? О чем Вы вообще?

Share this post


Link to post
Share on other sites

Ну понеслась... линукс ставить данных из протокола в протокол пихать.

 

Линукс я начал ненавидеть когда мне сказали что vi официально признанный редактор. То есть официально используют начального уровня поделку, в которой автор даже не знал кодов стрелочек, потому курсором рулят буковками... Я как-то поддавшись общему мнению тоже считал его единственным и тем что стоит поднимать как ОС на железе, но вот реально поковырявшись с ним обратил свое внимание на ртосы, все же линукс сильно избыточен, без приложений пользователей он явно не нужен,только ради стека?...

 

Правильно я понимаю что в РТОС задачи переключаются либо по тику системы (это что-то порядка 1-10 мСек) либо по тому как задача отпускает ресурсы. А задрать частоту повыше - это грузить проц переключениями контекста?

 

 

Share this post


Link to post
Share on other sites
Нет у программистов нашего уровня (в смысле низкого, на уровне работы с регистрами периферии и инструкциями процессора) никакого страха багов. Есть аксиома - если есть программа, то в ней есть хотя бы один баг. Если его найдут - его следует устранить, но аксиома все равно верна - там наверняка будет еще баг :)

А где он, в линуксе, в коосе, в другом хреносе, были бы исходники, а остальное дело небольшой лишней возни. Что за страхи то? О чем Вы вообще?

http://electronix.ru/forum/index.php?showt...t&p=1327928

Share this post


Link to post
Share on other sites
все же линукс сильно избыточен, без приложений пользователей он явно не нужен,только ради стека?...

 

Ну, во первых, можно его так минимально сконфигурировать, что там будет ровно необходимый Вам минимум, и ничего более. То, что линукс - монстр, это заблуждение на него поверхностно взглянувших.

 

Во вторых - Ваша программа и будет тем самым приложением пользователя, которое там будет работать. А, возможно, и не одним - почему бы не запускать отдельные приложения для работы с разными портами, например. Хотя, конечно, для этого надо знать все подробности, это только Вам самим виднее. Однако, почти все нужное наверняка уже кем-то и где-то реализовано. Ну или почти все.

 

 

Правильно я понимаю что в РТОС задачи переключаются либо по тику системы (это что-то порядка 1-10 мСек) либо по тому как задача отпускает ресурсы. А задрать частоту повыше - это грузить проц переключениями контекста?

Если очень грубо, то правильно.

 

PS

А vi - отличная вещь. Через практически любой, самый тормозной терминал, типа ком-порта на 2400, позволяет редактировать любой текст! Попробуйте в виндовс так сделать встроенными средствами...

 

Я не вижу ни одного страха. Обычная рабочая ситуация.

Share this post


Link to post
Share on other sites
Я не вижу ни одного страха. Обычная рабочая ситуация.

Предпоследняя строчка. По-русски вроде написано.

 

Share this post


Link to post
Share on other sites
Ну, во первых, можно его так минимально сконфигурировать, что там будет ровно необходимый Вам минимум, и ничего более. То, что линукс - монстр, это заблуждение на него поверхностно взглянувших.

Насколько я знаю если линукс себе файловую систему не примаунтит он дальше работать откажется. Опять же линукс без ММУ-МПУ тоже вещь в себе, все из-за тех же пользовательских программ..

Если конечно под конфигурацией ядра понимать разодрать исходники выкинуть все и оставить только то что надо, то да, но это еще большей перебор...

 

Опять же уровень абстракции, драйверы, среда запуска... не линукс перебор, сто пудово. а VI - говноредактор:)

 

Предпоследняя строчка. По-русски вроде написано.

сдается мне у вас личные счеты и вы хотите уесть китайского чертика:)...

Share this post


Link to post
Share on other sites
Правильно я понимаю что в РТОС задачи переключаются либо по тику системы (это что-то порядка 1-10 мСек) либо по тому как задача отпускает ресурсы. А задрать частоту повыше - это грузить проц переключениями контекста?

 

10 мс и не меньше. Если тик 2 мс или меньше на Cortex-M, то значит хотите нагрузить RTOS чем-то ей несвойственным.

 

Под планировщиком должны находится длительные задачи, где хотите одним дать производительности и реалтайма, а другими занимаете все оставшееся время.

 

Задачи успевающие за тик исполнится два и больше раз планировщиком трогаться не должны, они не в контексте RTOS должны работать. Ну по крайней мере так стараться.

Share this post


Link to post
Share on other sites
Насколько я знаю если линукс себе файловую систему не примаунтит он дальше работать откажется. Опять же линукс без ММУ-МПУ тоже вещь в себе, все из-за тех же пользовательских программ..

Если конечно под конфигурацией ядра понимать разодрать исходники выкинуть все и оставить только то что надо, то да, но это еще большей перебор...

 

Это да, без файловой системы оно работать не будет, если не лезть в исходники. Как и без MMU, оно кастрированное. Но - ведь речь о простоте и быстроте реализации, наплевав на ресурсы памяти и стоимость проца! А вот тут линукс, скорее всего, окажется сильно впереди, в том числе, и из-за наличия (хотя бы) простой файловой системы, и из-за кучи готовых протоколов, драйверов, средств отладки, логирования, и вообще огромного объема готовых программ. И в части расширения на будущее - к примеру, почти любой Cortex-A содержит в себе сразу сильный видеоконтроллер, вдруг захочется поднять некое видео - и за день работы можно "поднять" любое разрешение, от мелкого QVGA до Full HD. Ну и т.п.

 

А под конфигурацией я имел в виду именно конфигурацию (.config)

Share this post


Link to post
Share on other sites
То есть официально используют начального уровня поделку, в которой автор даже не знал кодов стрелочек, потому курсором рулят буковками...

 

Правильно я понимаю что в РТОС задачи переключаются либо по тику системы (это что-то порядка 1-10 мСек) либо по тому как задача отпускает ресурсы. А задрать частоту повыше - это грузить проц переключениями контекста?

 

Если вам чтото кажется глупым, скорее всего не автор глупец, а вы чтото не понимаете.

 

I remember when first using vi, many years ago, a senior colleague advising me "Make sure you learn to use the h, j, k, and l keys because one day you'll end up on machine at a client site where the arrow keys don't work, and you'll look like a complete d***head if you can't even work vi."

 

2. Угу

 

 

Странно сосуществуют понимание этих вещей со страхом багов, приобрётенным после использования coos (лично у меня не вызывает доверие всё, что связано с кокосом).

 

Ну точнее было бы наверное сказать не "боюсь", а опасаюсь.

Кто ж знал что тут такие придиры будут. Вроде все понятно.

Баги, как дождь, или смерть, опасайся не опасайся но они есть.

Другой вопрос, что ты уже знаешь, "когда идет дождь" со своей операционкой.

А опасения связаны в первую очередь с тем что будет как всегда - тестировать никто не тестирует,

всем некогда. Погоняли немножко и в продакшн. А там условия разные и понеслась..

"Бессоные ночи в городе Сочи".. Надо срочно, еще вчера, бросай все.

Если чисто ковырятся, то ладно, ну баг и баг.

 

ПыСы кокос тут не причем, баги есть и в других ОС. А когда ее вылижут, выходит новая версия.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this