forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Взлом Linux через подключение USB-устройства стал реальностью, opennews (ok), 08-Мрт-11, (0) [смотреть все]

Ещё одно доказательство того, что строки неизвестной длины с завершающим нулём в, iZEN (ok), 11:54 , 08-Мрт-11, (1) –27 //

Ну а в PHP даже указателей нет Так что паскалю с сями до него как пешком до Кит, klalafuda (?), 11:58 , 08-Мрт-11, (4) +11 //

И в Java нет , и что с того Недавно оба засветились с переполнениями базовых т, follow_me (?), 14:56 , 08-Мрт-11, (63) +2 //

Вы про баг с плавающей запятой Переполнения нашли в реализации интерпретатора PH, FastDuck (?), 19:45 , 08-Мрт-11, (130) +1

C C изначально создавались как языки сочетающие в себе высокий уровень програм, MiG (?), 22:07 , 08-Мрт-11, (175) +5

и низкоуровневую эффективность Я понимаю что историю сейчас знать ни к чему, но , anonymous vulgaris (?), 01:21 , 09-Мрт-11, (201) –2

но при этом в PHP забыли сделать слабые ссылоки weak ref о боже -- этоже ЛО, Аноним123321 (ok), 15:01 , 08-Мрт-11, (64) –1
Языки из разных категорий Сравнивать их может только новичек в программировании, rshadow (?), 18:41 , 08-Мрт-11, (121) //

Кто такие новичеки , Аноним (-), 12:20 , 09-Мрт-11, (237) –1

Оберон - наше всё , Аноним (-), 23:30 , 08-Мрт-11, (193) +2
Это Вам наверное в PHP порушенные поинтеры не встречались, а мне как-то довелось, cobold (ok), 13:28 , 10-Мрт-11, (287)

Ок, для успешной индексации строк с over 2 млрд символов всегда надо будет хран, доброжелатель (?), 12:11 , 08-Мрт-11, (9) //

да хоть 8 байт, хоть 32-а, это один фиг лучше, чем рут полученный через переполн, Аноним (-), 12:18 , 08-Мрт-11, (11) –3 //

Т е хранить 32 байта с длинной строки, когда сама строка занимает один байт это, Аноним (-), 12:22 , 08-Мрт-11, (13) +3

Поле длины строки необязательно должно быть фиксированной длины 8212 есть алг, iZEN (ok), 12:40 , 08-Мрт-11, (18) +2

Это дополнительная сложность и время Спорный оверхед, в общем Может где-то и н, Аноним (-), 13:15 , 08-Мрт-11, (34) +3

а перераспределение памяти и поиск конца строки это не лишние ресурсы , Аноним (-), 23:17 , 08-Мрт-11, (192) +2

Проще разработать 1024битную архитектуру с sizeof int 1024, запихать туда 2 , cmp (ok), 14:26 , 08-Мрт-11, (54) +5
только парсить долго а теперь представь что тебе придется рюхать миллион , User294 (ok), 03:09 , 09-Мрт-11, (209) –1

Что парсить Как рюхать Да чо уж там, берите сразу триллион - он в тыщу раз внуш, коксюзер (?), 03:30 , 09-Мрт-11, (210) +2

Я так понимаю что изен про кодирование интегеров с переменной длиной или типа то, User294 (ok), 05:27 , 09-Мрт-11, (215) –1

Он вообще-то о строках, как я понял В нормальных языках это происходит просто , коксюзер (?), 06:07 , 09-Мрт-11, (220) +3

Я так понял что он предлагал хранить длину строки как variable length integer А, User294 (ok), 15:31 , 09-Мрт-11, (246) –1

Грубо говоря, я предложу такую структуру struct String len_of_len длина п, iZEN (ok), 17:31 , 09-Мрт-11, (261)
Трололо, придумаем проблему и выделим ей абзац в нашей простыне Ха, данные по се, коксюзер (?), 17:52 , 09-Мрт-11, (264)

я бы посмотрел, как мир бы тужился с виндоус и линукс на джаве или питоне, спидф, Dvorkin (??), 18:43 , 09-Мрт-11, (268)
Когда я пишу другие низкоуровневые языки , обвиняют в отсутствии конкретики, ко, коксюзер (?), 18:54 , 09-Мрт-11, (270)

Удивительно, но в ядре вражеской системы от МС этот тип строк используется пов, caps (?), 12:40 , 08-Мрт-11, (19)

Ну и как, сильно безопасное получилось , test (??), 17:10 , 08-Мрт-11, (103) +8

Несильно, ибо строки не единственная и даже не самая серьёзная проблема си , коксюзер (?), 17:14 , 08-Мрт-11, (104) +1

Да уж Индусы успешно доказывают что обделаться с критичными последствиями можно, User294 (ok), 05:36 , 09-Мрт-11, (216) +2

блин - проверка должна быт ьи в функцию должна передаваться длина строки, Sw00p aka Jerom (?), 14:52 , 08-Мрт-11, (61)

Конечно должна Это же какой контроль , коксюзер (?), 16:16 , 08-Мрт-11, (79)

Ненормально - путать биты с байтами и забывать о возможности параметризации типо, коксюзер (?), 16:14 , 08-Мрт-11, (77) +5

А тебе успешного выяснения длинны строки Жди когда найдет заветный байт в 2хгиг, Аноним (-), 15:41 , 08-Мрт-11, (69) //

А в чем принципиальная разница по скорости проверять ли байт на то что он равен, User294 (ok), 15:38 , 09-Мрт-11, (247)

В некоторых алгоритмах желательно иметь длину строки заранее, например, для скле, Аноним (-), 16:31 , 09-Мрт-11, (251)

Это только в том относительное редком случае, если destination совпадает с пер, User294 (ok), 17:39 , 09-Мрт-11, (262)

Проблема в том, что в сях оно будет не на уровне компилятора, а где-то сбоку в, iZEN (ok), 17:43 , 09-Мрт-11, (263) +1
А если не совпадает, длину обеих строк не обязательно знать для выделения буфера, коксюзер (?), 18:15 , 09-Мрт-11, (266) +1

А если не совпадает, обе строки пробегаются в любом случае, и разницы по времени, Аноним (-), 19:42 , 09-Мрт-11, (274)

Не в любом случае, а в ряде случаев В любом случае как раз нужно знать длину ка, paxuser (ok), 20:05 , 09-Мрт-11, (277) +1

строкам второй раз, при копировании strcat не выделяет память И я вроде уже пис, фыв (??), 23:17 , 09-Мрт-11, (281)

Ещё бы выделял Всё руками Накладно, но всегда возможно или допустимо, в отличие, paxuser (ok), 04:31 , 10-Мрт-11, (285) +1

А если мне нужна строка 255 символов Думай прежде, чем писать, Аноним (-), 12:12 , 08-Мрт-11, (10) –8 //

учил turbo pascal Выходи из анабиоза, есть строки в паскале превышающие 255 т, frankl (?), 12:51 , 08-Мрт-11, (21) +1

ну и какое отношение имеют стандартные библиотеки C, которые ориентрируются на т, anonymous (??), 12:23 , 08-Мрт-11, (14) +5 //

прошу прощения, невнимательно читал новость таки они скопировали часть функций в, anonymous (??), 13:12 , 08-Мрт-11, (31) +1 //

Конечно-конечно Уж в языке-то есть тип данных, позволяющий отказаться от ручног, коксюзер (?), 16:19 , 08-Мрт-11, (80)

ВНЕЗАПНО И С, и тем более С позволяют реализовать строку именно так, как вам , тоже Аноним (ok), 12:34 , 08-Мрт-11, (16) +15 //

Именно так А еще, в ряде случаев, можно сделать проверки длин и расстановку защ, Ytch (?), 15:50 , 08-Мрт-11, (73)
Особенно в Си Прямо бери и реализуй литералы и неявные преобразования типов Аг, коксюзер (?), 16:27 , 08-Мрт-11, (82) //

Вы не любите языки, на которых нельзя написать фреймворк и сделать вид, что это , тоже Аноним (ok), 22:10 , 08-Мрт-11, (176)

Пляска вокруг убогой системы типов и её последствия - фамильная черта языков сем, коксюзер (?), 22:57 , 08-Мрт-11, (187) +1

Фамильная черта тех, кто гонит на С - упоминание неких нормальных языков без к, тоже Аноним (ok), 08:33 , 09-Мрт-11, (226) –1

Ада А отгадка в том, что вы вынимаете слова из контекста , коксюзер (?), 08:56 , 09-Мрт-11, (227)

Конечно Нет унаследованного кода - нет проблемы , тоже Аноним (ok), 10:29 , 09-Мрт-11, (230)

Да что вы говорите Ещё раз у Си полно проблем помимо кривых строк Чтобы их ре, коксюзер (?), 17:26 , 09-Мрт-11, (259)

Ну и где операционки на ней и желающие на оной их писать Не хочу ничего сказать, User294 (ok), 15:57 , 09-Мрт-11, (248) –1

Непосредственно загнать 4 байта в регистры вон той железяки - это примерно 0 цел, klalafuda (?), 16:12 , 09-Мрт-11, (250) +1

Угу, а код драйверов вы смотреть не пробовали Там такого кода - хоть отбавляй, , User294 (ok), 18:27 , 09-Мрт-11, (267)

Теоретики такие теоретики на дворе XXI век, а они до сих в порты по 4 байта пиш, коксюзер (?), 18:53 , 09-Мрт-11, (269) +1

Несмотря на XXI век, компьютер до сих пор включается в розетку и оперирует битам, тоже Аноним (ok), 23:16 , 09-Мрт-11, (280)
Да, у меня как впрочем и у вас дрова давно гоняют данные с на железо в основно, paxuser (ok), 01:06 , 10-Мрт-11, (283)

В гугле МЕШАТЬСЯ 111 8- Так спидфаг или не спидфаг А то спидфаги выравнив, коксюзер (?), 18:06 , 09-Мрт-11, (265) +1

В гугле обычный линух на дешевых серверах P Да-да, гуглить для вас будет это р, User294 (ok), 19:07 , 09-Мрт-11, (271)

Поставим ответ иначе гугль знает Ну так сделайте Линух вон сперва вылез из гря, paxuser (ok), 19:37 , 09-Мрт-11, (273)

Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо этот путь не , Аноним (-), 13:05 , 08-Мрт-11, (28) +1 //

Поскольку это ядро, то очевидно не std string , Аноним (-), 13:18 , 08-Мрт-11, (35)
СТЛ ваш ни чем не лучше, Sw00p aka Jerom (?), 14:53 , 08-Мрт-11, (62)
А я бы на вашем месте изучил языки с более строгими системами типов, прежде чем , коксюзер (?), 16:31 , 08-Мрт-11, (83) –1 //

Предлагаете писать ядро на лиспе , анон (?), 16:45 , 08-Мрт-11, (93) –1

То есть лисп в ваших глазах - это язык со строгой системой типов , коксюзер (?), 17:07 , 08-Мрт-11, (100) +2

хаскель окамл уточните, на чем же нада писать ядра , анон (?), 17:57 , 08-Мрт-11, (113)

Очевидно Ада На пару с Обероном , klalafuda (?), 19:33 , 08-Мрт-11, (126) –1

Это просто бред или какая-то очень тонкая ирония , Ytch (?), 20:49 , 08-Мрт-11, (155)

А что, разве на Аде и оберонах не написано ни одного ядра , коксюзер (?), 20:54 , 08-Мрт-11, (160)

неа, pavlinux (ok), 21:42 , 08-Мрт-11, (171)

http en wikipedia org wiki Oberon_ operating_system , gegMOPO4 (ok), 22:18 , 08-Мрт-11, (178)

Исходники ядра можно , pavlinux (ok), 22:44 , 08-Мрт-11, (183)
Да, там свободная лицензия , gegMOPO4 (ok), 22:59 , 08-Мрт-11, (188)
ftp ftp inf ethz ch pub ETHOberon Native StdAlone не , Аноним (-), 23:31 , 08-Мрт-11, (194)
Не, там бинарники и примеры , pavlinux (ok), 23:50 , 08-Мрт-11, (197)
Эта операционка была для Вирта самым большим фейлом в его жизни, IMHO Крах идеи, cobold (ok), 13:58 , 10-Мрт-11, (288)
Действительно, фейл Но не по части инженерных и потребительских качеств Он дол, paxuser (ok), 19:17 , 10-Мрт-11, (291)

Т е вы мне кагбе придлогаите передти от тролинга к розговору по сущиству , коксюзер (?), 19:33 , 08-Мрт-11, (127)

Нет не предлагаю, т к по существу вам просто нечего сказать Иначе б давно сказ, анон (?), 20:36 , 08-Мрт-11, (147)

Я говорил и не раз Если вы считаете, что нет Тюринг-полных типобезопасных языко, коксюзер (?), 20:47 , 08-Мрт-11, (154)

Ядро на Хаскеле - это интересно Уж оно-то будет отлично параллелизоваться, бы, Аноним (-), 19:53 , 09-Мрт-11, (276)

хехе, красноглазое быдло заминусовало правильный пост Не только строки но и мас, Толстый (ok), 13:47 , 08-Мрт-11, (44) –17 //

Что Вам мешает написать собственную реализацию Вот к примеру как выглядят строки, Udzhen (ok), 14:11 , 08-Мрт-11, (53) +1 //

Вот именно, у каждого Васи своя реализация, несовместимая с реализацией Пети А , Толстый (ok), 16:20 , 08-Мрт-11, (81)

Ну так вперед Докажите миру что Ваша реализация безопасней, быстрей и удобней В, Udzhen (ok), 18:52 , 08-Мрт-11, (122) +2

Всё уже реализовано и доказано Нет, все будут жаловаться на необходимость изуч, коксюзер (?), 19:40 , 08-Мрт-11, (129)

Да, это помогает избежать сегфолта, разменивая его на логические ошибки, вот тол, анон (?), 16:42 , 08-Мрт-11, (91) //

Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам зн, коксюзер (?), 17:18 , 08-Мрт-11, (106) –1

А вы, простите, видели, что я делал а что нет Зато баттхерта и агрессии у вас -, анон (?), 17:58 , 08-Мрт-11, (114)

Вот я и спрашиваю вы видели, делали Если нет, к чему эти юления со смайликами , коксюзер (?), 19:54 , 08-Мрт-11, (134)

Если вы такой умный и знаете как надо а как ненадо, почему работаете на работе, , анон (?), 20:37 , 08-Мрт-11, (148)

Потому что других ОС у рынка для меня нет , коксюзер (?), 20:42 , 08-Мрт-11, (152)

Вы его не спрашивали, а предположили заранее Надменность - не лучший способ док, Аноним (-), 02:06 , 09-Мрт-11, (202)

Не лучший, но любые попытки доказать правоту тут как правило тщетны я уже пытал, коксюзер (?), 02:58 , 09-Мрт-11, (206)

Ну вон quicklz - одна и та же либа, при том авторами писаны реализации на сях, с, User294 (ok), 19:14 , 09-Мрт-11, (272)

Значит и Ада сольёт в 3 раза Тут к гадалке не ходи В ней же строки тоже немута, paxuser (ok), 19:45 , 09-Мрт-11, (275)

Кто вам мешает сделатьstruct my_str char ptr size_t len и писать над, анон (?), 14:31 , 08-Мрт-11, (55) +2 //

ты очень умный, только почему тогда никто этого не сделал, а вместо этого мы име, Толстый (ok), 16:16 , 08-Мрт-11, (78) –4 //

Это сделала например майкрофост в MFC да и много где еще Что значит никто не сд, анон (?), 16:32 , 08-Мрт-11, (84) +2

Ура, он противоречит сам себе Наличие проблемы заретушировано претензиями к опп, коксюзер (?), 16:34 , 08-Мрт-11, (86) –3

Проблема у тебя в голове , Аноним (-), 14:16 , 09-Мрт-11, (242) –1

Литерал этого типа в студию, для начала , коксюзер (?), 16:33 , 08-Мрт-11, (85) –1 //

Что еще за литерал типа В str указатель, в len длина строки, что непонятного , анон (?), 16:34 , 08-Мрт-11, (87)

С вами - всё предельно ясно , коксюзер (?), 17:09 , 08-Мрт-11, (101) –2

Ок , анон (?), 18:06 , 08-Мрт-11, (117)

struct my_str s abc , 3 , gegMOPO4 (ok), 19:22 , 08-Мрт-11, (125)

Ну вот, вычисление длины строки на глазок и ошибка на единицу в простейшем при, коксюзер (?), 19:36 , 08-Мрт-11, (128) –2

Чтобы не морочить себе голову и не ошибиться, можно использовать простой макрос , gegMOPO4 (ok), 19:52 , 08-Мрт-11, (133) +1

Это феерический мрак sizeof L вернёт количество элементов в массиве, включая т, коксюзер (?), 20:06 , 08-Мрт-11, (136) –2

Что вас удивляет Что строковые литералы в Си неявно содержат терминирующий NUL , gegMOPO4 (ok), 20:28 , 08-Мрт-11, (142) +1

Меня удивляет, что в ответ на замечание об ошибке на единицу вы написали эквивал, коксюзер (?), 20:37 , 08-Мрт-11, (149)

Я написал, как избежать ошибки в подсчёте числа символов Да, теперь я вижу в чё, gegMOPO4 (ok), 20:54 , 08-Мрт-11, (159) +1

Какой ошибки Давайте по порядку Если следовать вашей логике, по которой в len п, коксюзер (?), 21:20 , 08-Мрт-11, (166) –1

Признаюсь, я неправильно понял ваш первый комментарий Показалось, что вы намека, gegMOPO4 (ok), 22:39 , 08-Мрт-11, (181)
К чему эти абсурдные инсинуации Вы прекрасно понимаете, что я имел ввиду В len, коксюзер (?), 23:43 , 08-Мрт-11, (196) –1
В len обычно хранят длину строки, а размер массива обычно называют size Для при, arturpub (ok), 11:14 , 09-Мрт-11, (233) +1
Вы мне ещё букварь почитайте по слогам, в едином дидактическом порыве А по-моему, коксюзер (?), 17:17 , 09-Мрт-11, (256) –1
Вы просили пример, вот я и подумал, что созвучия разбудят вашу интуицию Ничего з, arturpub (ok), 13:12 , 10-Мрт-11, (286)
Не просил Мне всё равно, как называется атрибут, главное - что он хранит В слу, paxuser (ok), 18:58 , 10-Мрт-11, (290)
Ну даете, блин зы посоветуйте плиз что-нибудь из цикла Ада за 3 дня не для , arturpub (ok), 11:42 , 11-Мрт-11, (299)
Я изначально говорил о размерах массивов, а не длинах строк Умеющий читать, да , paxuser (ok), 12:08 , 11-Мрт-11, (300)
Сенкс, а то как раз пятница свободная выдалась , arturpub (??), 17:07 , 11-Мрт-11, (301)

Если у вас есть голова, попробуйте воспользоватся ей Тогда, может, дойдет, что , анон (?), 20:29 , 08-Мрт-11, (144) +1

В литерале 0 в конце строки есть, почему в len он учитываться не должен И пр, коксюзер (?), 21:35 , 08-Мрт-11, (169) –3

Есть тут ошибка или нет, можно сказать только взглянув на функции, работающие с , анон (?), 20:24 , 08-Мрт-11, (139)

Я ждал этой отмазки, но она не катит, поскольку собеседник отвечал на моё замеча, коксюзер (?), 20:26 , 08-Мрт-11, (141) –1

Где там ошибка-то Строка из 3 трех элементов, нулл не нужен т к указываем н, анон (?), 20:30 , 08-Мрт-11, (145) +1

my_str s MY_STR RTFM , Аноним (-), 14:23 , 09-Мрт-11, (243)

Попроси разработчиков ядра FreeBSD, пусть они его на жабе перепишут , СуперАноним (?), 14:48 , 08-Мрт-11, (59) +5
1чт оприкольно - они не хотят это изменятьмол какая разница проверку сделает пр, Sw00p aka Jerom (?), 14:50 , 08-Мрт-11, (60) //

Чем будет лучше, если библиотека проверит и обнаружит обращение за границы масси, анон (?), 16:47 , 08-Мрт-11, (94) //

Действительно, ну чем DoS лучше полной компрометации Да ничем , коксюзер (?), 17:10 , 08-Мрт-11, (102)

Вот почему OpenBSD написали ядро на C и особых проблем не ощущают На мой взгляд, FFASM (?), 19:49 , 08-Мрт-11, (132) +2 //

Джо ты Тебя так до сих пор и не поймали , klalafuda (?), 19:55 , 08-Мрт-11, (135) –1 //

Напишите востребованную ОС с непозорными параметрами на чем-то еще, фигле Кто-т, User294 (ok), 05:00 , 09-Мрт-11, (213)

Зачем Мне и линуксы вполне хватает , klalafuda (?), 15:05 , 09-Мрт-11, (245)

http openbsd org images hackathons c2k10 gifЭто пройдёт Скорость - не единстве, коксюзер (?), 20:24 , 08-Мрт-11, (140) //

Да, да, да JIT в теории может, блабла На практике - а хрен там Вот когда ядра, Аноним (-), 22:50 , 08-Мрт-11, (185)
Почему микроядро еще не везде где можно Почему ядра ОС, игры с графикой, рендеры, Аноним (-), 02:13 , 09-Мрт-11, (203)

А кто из крупных игроков на рынке стоит за этими микроядрами, безопасными языкам, коксюзер (?), 03:08 , 09-Мрт-11, (208)

Крупные игроки приходят когда видят что получилась нужная штука, лучше других, т, User294 (ok), 05:12 , 09-Мрт-11, (214)

Ага, это даже доказательства не требует Оно же очевидно Ну да, тред можно не чи, коксюзер (?), 05:58 , 09-Мрт-11, (218) +2

Хорошо, ну так крупные игроки добровольно выбрали то что им пришлось по в, User294 (ok), 16:58 , 09-Мрт-11, (253)

Ооо, какая знатная простыня И как же я тебя пропустил, дорогая Сейчас наката, paxuser (ok), 02:56 , 10-Мрт-11, (284)

Имейте совесть В вашей яве дыры безопасности чинят ДЕСЯТКАМИ в каждом релизе С, Аноним (-), 22:47 , 08-Мрт-11, (184) //

Пруф или не было The Maxine Virtual Machine Project http labs oracle com proj, iZEN (ok), 17:04 , 09-Мрт-11, (254) //

Он конечно же имел в виду, что ты ещё не дописал корректнес-прувер Си -кода н, Andrey Mitrofanov (?), 17:12 , 09-Мрт-11, (255)

Ждём от тебя ОС на паскакале, а также компилятор умеющий все те же платформы и о, Аноним (-), 11:01 , 09-Мрт-11, (232)
Согласен А Java не подходит для написания ядра операционных систем , Алексей (??), 00:54 , 10-Мрт-11, (282)

Забавно но не более Ядро - точно такой же обычный код как и любой другой, котор, klalafuda (?), 11:57 , 08-Мрт-11, (2) +13 //

просто ошибок скорее всего много, усб драйвера писались не очень квалифицированн, Аноним (-), 15:47 , 08-Мрт-11, (71) //

А где не так , Аноним (-), 21:46 , 08-Мрт-11, (173)

Мдееееееее, Аноним (-), 11:59 , 08-Мрт-11, (5) –1
Предупрежден - значит вооружен , anonymous (??), 12:06 , 08-Мрт-11, (6) +1
А почему бы ядру предварительно не подравнять строку идентификации устройства,, balex (??), 12:07 , 08-Мрт-11, (7) +1 //

И еще немножечко шить Если вы хотите пользоваться системой, которая лучше програ, тоже Аноним (ok), 12:36 , 08-Мрт-11, (17)

Ого, таки к 2011 году они нашли способ как сломать линуху через флешку типа у, Анон (?), 12:29 , 08-Мрт-11, (15) +18 //

Ну да, в Иране тоже думали, что используя флешку и отключив авторан - все будет , caps (?), 12:46 , 08-Мрт-11, (20) //

Вообще то это как бы ортогонально Совершенно похрену, что именно пробивать ядр, klalafuda (?), 12:54 , 08-Мрт-11, (24) +3

так это просто говорит о том, что линукс стал популярнее, не более того если бы, user455 (?), 14:10 , 08-Мрт-11, (52) +1
Идите на Full-Disclosure и расскажите всем, как сложно, оказывается, адаптироват, коксюзер (?), 16:39 , 08-Мрт-11, (89)
интересно сработает уязвимость к виртуалке с проброшенным юсб, A1ek (ok), 17:39 , 08-Мрт-11, (109) //

Скорее, сработает еще в гипервизоре - ибо проброс допустим в том же ESXi осущест, К.О. (?), 21:29 , 08-Мрт-11, (168)

Не, ну а что, плохо чтоли Пока выпускают патч, куча двуногих отхватит экспериен, User294 (ok), 05:59 , 09-Мрт-11, (219)
Ога, идешь так по ДЦ, хоп, стойка не закрытая - тык-вытык флеху и дальше идешь, , Аноним (-), 11:39 , 09-Мрт-11, (234) //

А видеокамер там типа нету , Аноним (-), 14:40 , 09-Мрт-11, (244)
Нормальный такой ДЦ, где посторонние могут безнаказанно тыкать ваш сервер , User294 (ok), 16:04 , 09-Мрт-11, (249)

Реальность приблизилась к картине из боевика Типа, в бункер проникает группа, strange (??), 12:53 , 08-Мрт-11, (23) +2 //

Вообще то, это сможет сделать даже уборщица Будучи предварительно снабжена соот, klalafuda (?), 12:57 , 08-Мрт-11, (25) +3 //

Не, это конечно да Но с перестрелкой и спецэффектами веселее как-то Не везде , strange (??), 13:05 , 08-Мрт-11, (27) +2 //

Не завидую админам, в серверные которых никогда не пускают уборщиц , klalafuda (?), 13:11 , 08-Мрт-11, (30) +2

в нашей серверной уборщиц не было лет 5 и почему Вы нам не завидуете , arachnid (ok), 13:25 , 08-Мрт-11, (37) +2

Грязь же, нет Разве что эта серверная все пять лет была закрыта и работала аб, klalafuda (?), 13:31 , 08-Мрт-11, (41) +2

Раз в три месяца подмести и раз в пол-года помыть полы не так уж трудно Если, к, Demo (??), 14:00 , 08-Мрт-11, (48) +4

Ну так нефик на чистоте экономить Нужно брать бабушек с профильным ВО в звании , klalafuda (?), 14:08 , 08-Мрт-11, (51) +4

Тогда уже лучше самому сообщить капитану рутовый пароль и пододвинуть удобное кр, the joker (ok), 15:33 , 08-Мрт-11, (67) +1
Нужно Но по поводу брать не ко мне Я лишь винтик в огромной бюрократическо, Demo (??), 23:16 , 08-Мрт-11, (191)

Играть в серверной Брр, какой ужас, холодно, шумно, неудобно Неужели не приятн, zazik (ok), 09:35 , 09-Мрт-11, (229) +1
ну вот нет грязи в уличной обуви там никто не ходит, окон нет не буду говорить, arachnid (ok), 14:40 , 10-Мрт-11, (289)

Вполне реально, почему нет Пыли-грязи нет, потому как очистка воздуха и кондюшн, strange (??), 13:52 , 08-Мрт-11, (45) +2

Ога, корпоративный кластер, на корпоративных кластерах этот модуль так необходим, alf (??), 13:14 , 08-Мрт-11, (33) +1 //

Ну если на то пошло, то на корпоративном кластере вообще очень необходимы ядра 2, klalafuda (?), 13:21 , 08-Мрт-11, (36) +3 //

Других переполнений в других драйверах нет, да А все кластеры работают на перес, коксюзер (?), 16:44 , 08-Мрт-11, (92)

Вы сперва доберитесь до USB на лезвии, угу , Michael Shigorin (ok), 22:18 , 08-Мрт-11, (177)

Короче это феерическая уязвимость в вакуме, все бы такие, массово эпидемию церве, Аноним (-), 12:57 , 08-Мрт-11, (26) +4
Что делать, если я не использую этот драйвер caiaq Что делать, как помочь потен, ФФ (ok), 13:09 , 08-Мрт-11, (29) +4 //

А его не нужно использовать Вполне достаточно, чтобы он присутствовал в систе, klalafuda (?), 13:13 , 08-Мрт-11, (32) +1 //

не использую отсутствует в системе , ФФ (ok), 08:19 , 09-Мрт-11, (225)

Расскажи о методе терморектального криптоанализа, rocketman (?), 21:42 , 08-Мрт-11, (172)

In order to successfully exploit the vulnerability described in this advisory, a, Иван Иванович Иванов (?), 13:25 , 08-Мрт-11, (38) +5 //

Уязвимость класса а я сервак забутал и вместо инита шелл вписал -D Только сло, ram_scan (?), 14:05 , 08-Мрт-11, (50)
Ну так даже дядя -- не мой -- Билл сказал, что если у злоумышленника есть физи, the joker (ok), 15:39 , 08-Мрт-11, (68) +1
Hint ты можешь сам подключить подключить такое устройство Вредоносное ПО для с, Andrey (??), 07:30 , 09-Мрт-11, (224)

Уязвимость 8212 она, конечно, и в Африке уязвимость, но что-то мне кажется, ч, Аноним (-), 13:27 , 08-Мрт-11, (39) //

После решения в обернуть устройство в корпус флешки не составит труда б , segoon (ok), 13:46 , 08-Мрт-11, (43) +1
И какой процент линуксов идёт с такими ядрами Никакой Это запросто Оставить ф, коксюзер (?), 16:51 , 08-Мрт-11, (95) +1 //

К примеру, в Owl вообще нет модулей ядра для звука, они там ни к чему , segoon (ok), 20:22 , 08-Мрт-11, (138) +1 //

Я знаю И какой процент у Owl Никакой, хоть и незаслуженно , коксюзер (?), 20:28 , 08-Мрт-11, (143)

Ой, анонимусы вон натянули конторку безопасностью методом инженерии без всяких, User294 (ok), 06:09 , 09-Мрт-11, (221)

контроллер стоит около 3-5 , в корпус флешки умещается на раз, конечное устройст, Аноним (-), 16:58 , 08-Мрт-11, (97)

Зачем на серверной системе нужна звуковая плата и вообще поддержка звуковых уст, А. Н. Оним (?), 13:28 , 08-Мрт-11, (40) +1
Чтобы предотвратить загрузку драйвера echo 0 sys bus usb devices usbX autho, segoon (ok), 13:33 , 08-Мрт-11, (42) +4 //

Сколько понаписали и только один человек догадался написать простое решение Как, crypt (??), 21:11 , 08-Мрт-11, (164) +1 //

В authorized в некотором смысле более жёсткое разграничение - можно запретить по, segoon (ok), 21:19 , 08-Мрт-11, (165) +1 //

Ответ оценил Интересную штуку написал Инакий Перец-Гонзалес из Интел - Скоре, crypt (??), 22:02 , 08-Мрт-11, (174)

Уже размышляли и не раз Последний раз тут http www openwall com lists oss-se, segoon (ok), 22:23 , 08-Мрт-11, (179)

Я верю, что не америку открыл, просто хотел сказать, что пишу одну теорию Модел, crypt (??), 22:54 , 08-Мрт-11, (186)

А новость писал чем-то обрадованный пользователь OpenBSD, исходя из имени правил, Yuriy (??), 13:55 , 08-Мрт-11, (47) //

http git kernel org p linux 2Fkernel 2Fgit 2Ftiwai 2Fsound-2 6 git a commitdi, klalafuda (?), 14:46 , 08-Мрт-11, (57) +1 //

С критикой, конечно, нельзя не согласиться А вот с тем, что на основании этой к, nuclight (ok), 15:54 , 08-Мрт-11, (74) +1 //

Это - ANSI C Плох он или хорош - это тем не менее стандарт Так что - приходитс, klalafuda (?), 16:10 , 08-Мрт-11, (75) –1

Glibc - единственная мейнстримная libc, в которой нет strl-функций , коксюзер (?), 16:57 , 08-Мрт-11, (96) +1

Fixed, исчо_адын_аноним (?), 17:15 , 08-Мрт-11, (105)

А подумать В стандарте оно до сих пор именно по причине совместимости Дядя Дреп, nuclight (ok), 17:02 , 08-Мрт-11, (98) +1

При чем здесь - подумать Стандарт на libc есть Есть В стандарте strcpy K пр, klalafuda (?), 17:43 , 08-Мрт-11, (110) +1

klalafuda, вот не надо FUDа В этом сообщении нет ни одного аргумента, одна херо, nuclight (ok), 17:48 , 08-Мрт-11, (111) +1

Ну и что, что некоторые пакеты включают А некоторые ещё и BSDшные анахронизмы з, klalafuda (?), 18:05 , 08-Мрт-11, (115) +1

Это не аргумент, потому что расширения сверх стандарта в glibc присутствуют, и н, nuclight (ok), 18:23 , 08-Мрт-11, (120) –1

1 не стоит я был против допущения его в ALT и свои разрушения там он нанёс 2 , Michael Shigorin (ok), 22:29 , 08-Мрт-11, (180)

Михаил, я немного более в курсе ситуации с Луговским, чем большинство сторонних , nuclight (ok), 18:43 , 24-Май-11, (307)

А скажите мне не посвященному, какая проблема админу отключать и включать драйв, Марат (??), 14:44 , 08-Мрт-11, (56) –1 //

Ээээ И что же должно стоять на этом, другом, компе Что туда можно совершенно, klalafuda (?), 14:47 , 08-Мрт-11, (58) //

Я понимаю что вы мне намекаете что второй комп тоже будет взломан с пом этой ту, Марат (??), 15:17 , 08-Мрт-11, (65)

Хы, прикол Молодцы, развили всё-таки идею Пользу людям сделали , Zenitur (ok), 15:26 , 08-Мрт-11, (66) –2
это же победа me достал свою плату на at91sam7s128 и пошел писать усб, Аноним (-), 15:45 , 08-Мрт-11, (70) +1 //

И правда - победа Попрактиковаться в програминге sam7 - всяко не вредно Хо, User294 (ok), 04:53 , 09-Мрт-11, (211) //

M официально запатчил авторан , crypt (??), 13:25 , 09-Мрт-11, (238) //

Ага, не прошло и 20 лет как до них все-таки дошло, что у юзеров от этого оказыва, User294 (ok), 17:21 , 09-Мрт-11, (258)

Если есть физический доступ к серваку, то и без всяких USB-приблуд можно получит, anthonio (ok), 15:48 , 08-Мрт-11, (72) +1 //

Без клавиатуры и монитора И вероятность быть пойманным и замеченным при этом, uldus (ok), 16:10 , 08-Мрт-11, (76) +2 //

Только планы спалили, дырки починят не так уж и плохо вроде , User294 (ok), 04:56 , 09-Мрт-11, (212) //

ЗЫ кстати судя по планам конторы HBGary - у них там сплошные Наполеоны работают , User294 (ok), 17:27 , 09-Мрт-11, (260)

О Сделали удобный просмотр Я видать жираф и только что увидел , crypt (??), 13:30 , 09-Мрт-11, (239)

конечно большое IMHO, но все это очень смахивает на нормальный такой бэк-дор, devlink (?), 18:54 , 08-Мрт-11, (123)
даа зачетная такая дырень, слепить usb хреновину и по пути к своей циске незаме, deadless (ok), 20:15 , 08-Мрт-11, (137) –6 //

вначале подождём пока ломающие драйвера появятся а то что Линукс может работа, botman (ok), 20:38 , 08-Мрт-11, (150)
Ващето сегодня, если конечно кто не заметил - 8е марта Праздник типа на дворе , klalafuda (?), 20:42 , 08-Мрт-11, (151) +1 //

Да, поздравили с утра ещё А вот часов с трех дня, наблюдаю за кипишем Глав, pavlinux (ok), 23:02 , 08-Мрт-11, (189)
Я день выступлений проституток, импортированный кларой цеткин, не праздную и дру, Michael Shigorin (ok), 00:46 , 09-Мрт-11, (198) –3 //

Тут новость об эксплуатации ошибки, а не фичи А доступ к памяти в том же 1394 п, коксюзер (?), 01:06 , 09-Мрт-11, (200)
ну да клара цеткин проститутка, один шигорин дартаньян, угу, nucliht мне открыл , deadless (ok), 11:51 , 09-Мрт-11, (235)

Как ярый пользователь Hardened Gentoo, подтверждаю Всё так , коксюзер (?), 17:21 , 09-Мрт-11, (257)
Прежде чем публично бросать тень на Вадима, подумайте о том, что неадекватность , Michael Shigorin (ok), 11:25 , 15-Апр-11, (306)

Сэр, поищите тут посты некоего paxuser, он доступно рассказывал у кого как с дыр, Аноним (-), 23:03 , 08-Мрт-11, (190)
Ну, расскажите тогда в какой системе таких дыреней нет и быть не может Ну, наве, User294 (ok), 02:35 , 09-Мрт-11, (204) //

Слишком много если все сказанное выше отменяет дырень И таки да, ковырял я юсб, deadless (ok), 12:14 , 09-Мрт-11, (236) //

User-friendlySecureFunctionalPick any two , crypt (??), 13:45 , 09-Мрт-11, (241)
Ну, количество если потребное для успешного взлома линуха через этот баг не ме, User294 (ok), 22:34 , 09-Мрт-11, (278)

спасибо юзер, день сегодня и так офигенный, солнышнко и все такое, и ты в очеред, deadless (ok), 23:02 , 09-Мрт-11, (279)
почитал я пакса твоего, на мое имхо просто больной причем на всю голову, либо ра, deadless (ok), 23:53 , 10-Мрт-11, (292)

А я здесь и всё вижу По диагонали вы меня почитали-то, любезный , paxuser (ok), 00:58 , 11-Мрт-11, (293)

Я тоже тебя почитал Ты больной на голову параноик Лучше иди читай Криса Каспер, iZEN (ok), 01:18 , 11-Мрт-11, (294)

И тоже по диагонали, с тем же результатом Касперски не эксперт, мысль эта не его, paxuser (ok), 01:48 , 11-Мрт-11, (295)

Бтв, что-то я в вашем надрывном потоке сознания не досчитался некоторой доли это, paxuser (ok), 09:11 , 11-Мрт-11, (296)

Ну и какой главный вывод В том что фря сосёт, а линукс рулит Таки да, в FreeBSD, deadless (ok), 09:41 , 11-Мрт-11, (297)

Да, такой главный вывод Написано же прямым текстом фря сосёт Вот тут Афтар пе, paxuser (ok), 10:51 , 11-Мрт-11, (298)

Я уже читал что MAC вы считаете лишь помощником руткитерам, а подсистему Audit в, deadless (ok), 23:03 , 11-Мрт-11, (302)

Лишь - вы от себя добавили Пока ядро не защищено, с моей точки зрения польза , paxuser (ok), 00:41 , 12-Мрт-11, (304)

find lib modules uname -r -name snd-usb-caiaq ko -o -name iowarrior ko Ну, Гентушник (ok), 22:44 , 08-Мрт-11, (182) +4 //

Модули ищутся через modprobe -an, через find это как-то по-слакваревски,а настоя, pavlinux (ok), 23:40 , 08-Мрт-11, (195) //

Спасибо, схоронил в памяти , Гентушник (ok), 06:45 , 09-Мрт-11, (223)

Мне вот интересно другое А ты осилил их целиком прочесть И как тебе этот , User294 (ok), 02:39 , 09-Мрт-11, (205) //

Ну я их давно изучал Ща ковырнул, чтоб уж точно глянуть размер А самом деле та, pavlinux (ok), 03:07 , 09-Мрт-11, (207) //

И как, мозг не опух Для сравнения - иди вон драйвер UART какогонить заэйс, User294 (ok), 05:46 , 09-Мрт-11, (217) +2

Что вы глупости такие спрашиваете Если б он не то чтоб читал, а хотя бы посмотре, guest (??), 09:32 , 09-Мрт-11, (228) //

Ну давай дальше, вместе посмеёмся подсказка char 80 , char 0xff , pavlinux (ok), 13:41 , 09-Мрт-11, (240)

Не страшно, можно сконфигурировать и собрать ядро без этого драйвера А вот что , lucentcode (ok), 00:16 , 12-Мрт-11, (303)
Аааааааа линух уязвим с любым ядром ААааааа - я нашел уязвимость - это винчесте, Slot (?), 11:17 , 12-Мрт-11, (305)
Народ, можно ли такой схемкой http conture by post 347 запустить движок от вен, Аноним (-), 17:49 , 05-Дек-11, (308)

Сообщения [Сортировка по времени | RSS]

1. "Взлом Linux через подключение USB-устройства стал реальность..." –27 +/–

Сообщение от iZEN (ok), 08-Мрт-11, 11:54

Ещё одно доказательство того, что строки неизвестной длины с завершающим нулём в качестве признака конца данных этого типа данных, никуда не годятся — паскалевский тип строки с указанием точной длины в заголовке безопасный и предсказуемый.
EPIC FAIL C/C++.

Ответить | Правка | Наверх | Cообщить модератору

4. "Взлом Linux через подключение USB-устройства стал реальность..." +11 +/–

Сообщение от klalafuda (?), 08-Мрт-11, 11:58

Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю..

Ответить | Правка | Наверх | Cообщить модератору

63. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от follow_me (?), 08-Мрт-11, 14:56

И в Java нет , и что с того ? Недавно оба засветились с переполнениями базовых типов. Нет совершенных систем, ошибки можно найти везде.
А по поводу топика - не более чем локальная уязвимость с повышением привилегий, только тяжелее в реализации по сравнению с прочими уязвимостями такого рода

Ответить | Правка | Наверх | Cообщить модератору

130. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от FastDuck (?), 08-Мрт-11, 19:45

> И в Java нет , и что с того ? Недавно оба засветились с переполнениями базовых типов. Нет совершенных систем, ошибки можно найти везде.
Вы про баг с плавающей запятой?

Переполнения нашли в реализации интерпретатора PHP, а не в  пользовательских приложениях как в этом случае. К тому же, код интерпретатора PHP написан C.

Вообще, в случае Java/PHP и им подобных достаточно исправить переполнение в сам компиляторе/интерпретаторе, в случае C вся ответственность ложиться на плечи разработчиков приложений. Панацеи пока нет, а хотелось бы - лично я вижу решение в мощном безопасном рантайме (минимиизирует ошибки на низком уровне) и мощной системе типов (минимизирует ошибки на всех уровнях).

Ответить | Правка | Наверх | Cообщить модератору

175. "Взлом Linux через подключение USB-устройства стал реальность..." +5 +/–

Сообщение от MiG (?), 08-Мрт-11, 22:07

C/C++ изначально создавались как языки сочетающие в себе высокий уровень программирования и низкоуровневую эффективность. Ответственность за содеянное лежит на программисте.  Хочешь быстро ехать - отключай ABS, ESP, traction control и пр.. Новичок разобъётся, профессионал даст нужный результат. В конце концов если молотком ударил по пальцу, то виноват не инструмент. ;-)

Ответить | Правка | Наверх | Cообщить модератору

201. "Взлом Linux через подключение USB-устройства стал реальность..." –2 +/–

Сообщение от anonymous vulgaris (?), 09-Мрт-11, 01:21

> C/C++ изначально создавались как языки сочетающие в себе высокий уровень программирования
и низкоуровневую эффективность.
Я понимаю что историю сейчас знать ни к чему, но вообще то C лепился кое-как чтоб было хоть чуть получше ассемблера. Ну и чтоб можно было работать на компе с 8 кБ ОЗУ (отсюда и так называемый лаконичный синтаксис). Ну а C++ лепился кое-как чтоб было чуть получше С.

Ответить | Правка | Наверх | Cообщить модератору

64. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от Аноним123321 (ok), 08-Мрт-11, 15:01

> Ну а в PHP даже указателей нет.
но при этом в PHP забыли сделать слабые ссылоки (weak ref)... о боже -- этоже ЛОЛ:-D
таким образом PHP обречён на _цыклические_ ссылочные _сильные_ связи :-) :-) :-) [что совершенно не важно если приложение не должно жить более чем пару десятков милисекунд. поэтому всем php-web-программистом пофиг на отсутствие weak refs :-), а вот написать долгоиграющщую не-web-программу уже не получится :-)]

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

121. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от rshadow (?), 08-Мрт-11, 18:41

Языки из разных категорий. Сравнивать их может только новичек в программировании =)

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

237. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от Аноним (-), 09-Мрт-11, 12:20

Кто такие новичеки?

Ответить | Правка | Наверх | Cообщить модератору

193. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от Аноним (-), 08-Мрт-11, 23:30

>Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю..
Оберон - наше всё!

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

287. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от cobold (ok), 10-Мрт-11, 13:28

> Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю..
Это Вам наверное в PHP порушенные поинтеры не встречались, а мне как-то довелось с ними пободаться - когда по ходу встроенной функции по какой-то причине генерируется warning, изза этого переаллоцируется стек, а локальные переменные уже хранят указатели на прошлый stack frame. Вот результаты скрипта потом весело выглядят :)
Да, в 5.3 это исправили.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

9. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от доброжелатель (?), 08-Мрт-11, 12:11

Ок, для успешной индексации строк с over 2 млрд. символов всегда надо будет хранить лишних 4 байта, для любой строки, удачи !

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

11. "Взлом Linux через подключение USB-устройства стал реальность..." –3 +/–

Сообщение от Аноним (-), 08-Мрт-11, 12:18

> Ок, для успешной индексации строк с over 2 млрд. символов всегда надо
> будет хранить лишних 4 байта, для любой строки, удачи !
да хоть 8 байт, хоть 32-а, это один фиг лучше, чем рут полученный через переполнение.

Ответить | Правка | Наверх | Cообщить модератору

13. "Взлом Linux через подключение USB-устройства стал реальность..." +3 +/–

Сообщение от Аноним (-), 08-Мрт-11, 12:22

Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один байт это нормально?

Ответить | Правка | Наверх | Cообщить модератору

18. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от iZEN (ok), 08-Мрт-11, 12:40

Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы кодирования длины произвольной последовательности. И лучше, чтобы оно всё-таки было в заголовке данных, а не в конце в виде завершающего нуля, чтобы ядро не занималось счётом байтов и динамическим перевыделением памяти под неизвестное число байтов, пока не будет считан последний байт строки, а заранее знало, сможет оно вместить всю строку в доступную память или нет.

Ответить | Правка | Наверх | Cообщить модератору

34. "Взлом Linux через подключение USB-устройства стал реальность..." +3 +/–

Сообщение от Аноним (-), 08-Мрт-11, 13:15

> есть алгоритмы кодирования длины произвольной последовательности.
Это дополнительная сложность и время. Спорный оверхед, в общем. Может где-то и нужно, в большинстве применений - нет.

Ответить | Правка | Наверх | Cообщить модератору

192. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от Аноним (-), 08-Мрт-11, 23:17

>> есть алгоритмы кодирования длины произвольной последовательности.
> Это дополнительная сложность и время. Спорный оверхед, в общем. Может где-то и
> нужно, в большинстве применений - нет.
а перераспределение памяти и поиск конца строки это не лишние ресурсы?

Ответить | Правка | Наверх | Cообщить модератору

54. "Взлом Linux через подключение USB-устройства стал реальность..." +5 +/–

Сообщение от cmp (ok), 08-Мрт-11, 14:26

Проще разработать 1024битную архитектуру с sizeof(int) == 1024, запихать туда 2^1024 ОЗУ и не парится храня там ежесекундные снапшоты вселенной.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

209. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от User294 (ok), 09-Мрт-11, 03:09

> Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы
> кодирования длины произвольной последовательности.
... только парсить долго :) а теперь представь что тебе придется рюхать миллион таких полей? А миллиард не хочешь? Не как тупо 1 регистровую операцию, как раньше, что быстро, а как целая уйма хитрых операций с регистрами и прочая, т.к. проц не умеет нативно работать с таким представлением.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

210. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от коксюзер (?), 09-Мрт-11, 03:30

>> Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы
>> кодирования длины произвольной последовательности.
> ... только парсить долго :) а теперь представь что тебе придется рюхать
Что парсить? Как рюхать?
> миллион таких полей? А миллиард не хочешь? Не как тупо 1
Да чо уж там, берите сразу триллион - он в тыщу раз внушительнее миллиарда звучит.
> регистровую операцию, как раньше, что быстро, а как целая уйма хитрых
> операций с регистрами и прочая, т.к. проц не умеет нативно работать
> с таким представлением.
Так бы и написали: "Все это очень сложно и очень затратно. Правда-правда."

Ответить | Правка | Наверх | Cообщить модератору

215. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от User294 (ok), 09-Мрт-11, 05:27

>> ... только парсить долго :) а теперь представь что тебе придется рюхать
> Что парсить? Как рюхать?
Я так понимаю что изен про кодирование интегеров с переменной длиной или типа того. Бывает такое, можно и правда закодировать интегер произвольного диапазона более компактно чем обычно. И такое кодирование часто попадается в транспортных протоколах двинутых на компактности любой ценой :). Расплатой за это обычно является некоторая геморность парсинга всего этого - на реконструкцию интегера из такой конструкции требуется несколько лишних операций. Одно дело погрузить в регистры проца число "как есть" и другое - пачка хитрых преобразований чтобы понять какой реально размер у variable-length integer и получить его в нормальном виде понятном процу. В итоге выигрывается в занимаемом числом месте (в байтах) - малые числа получаются короче. Но проигрывается в трудоемкости разбора этого представления.
>> миллион таких полей? А миллиард не хочешь? Не как тупо 1
> Да чо уж там, берите сразу триллион - он в тыщу раз
> внушительнее миллиарда звучит.
А тут все просто: вы не заметите 10 микросекунд вместо 1. Зато вы легко заметите 10 часов вместо 1 часа. Хотя в обоих случаях разница в все те же 10 раз, совершенно одинаковые ;)
> Так бы и написали: "Все это очень сложно и очень затратно. Правда-правда."
Ну одно дело тупо затолкать число в регистры (в лучшем случае аж 1 команда проца будет), а другое varibale-length кодирование сперва расколупать для этого :). Как бы будет некоторая разница в числе команд которые потребны для одного и того же действа - некое число доступно теперь процу для обработки в виде который был изначально задуман :)

Ответить | Правка | Наверх | Cообщить модератору

220. "Взлом Linux через подключение USB-устройства стал реальность..." +3 +/–

Сообщение от коксюзер (?), 09-Мрт-11, 06:07

> Я так понимаю что изен про кодирование интегеров с переменной длиной или
> типа того. Бывает такое, можно и правда закодировать интегер произвольного диапазона
> более компактно чем обычно. И такое кодирование часто попадается в транспортных
> протоколах двинутых на компактности любой ценой :). Расплатой за это обычно
Он вообще-то о строках, как я понял. В нормальных языках это происходит просто: вы параметризуете строковый тип максимальным размером строки, а компилятор выбирает, сколько байт под величину размера выделить. Не говоря о наличии возможности работать с нуль-терминированными строками и прочей ересью, если приспичило.
> А тут все просто: вы не заметите 10 микросекунд вместо 1. Зато
> вы легко заметите 10 часов вместо 1 часа. Хотя в обоих
> случаях разница в все те же 10 раз, совершенно одинаковые ;)
Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах всё не так очевидно, как в листинге ассемблера. Хотите узнать оверхед, надо профилировать, а не спекулировать.

Ответить | Правка | Наверх | Cообщить модератору

246. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от User294 (ok), 09-Мрт-11, 15:31

> Он вообще-то о строках, как я понял.
Я так понял что он предлагал хранить длину строки как variable length integer?
> В нормальных языках это происходит просто: вы параметризуете строковый тип
> максимальным размером строки, а компилятор выбирает, сколько байт под
> величину размера выделить.
А при нужде интероперабельно с остальными слить это на диск в файл или передать по сети в *предсказуемом* виде, который потом ремота/другая программа сможет распарсить без привязки к языку, платформе, етц - мы жесточайше факаем мозг, делаем не слишком тривиальные преобразования и что там еще, в общем как обычно. Известное дело, ага. Не, ну можно конечно себе поднасрать на ровном месте, затребовав сложную сериализацию-десериализацию, но это похоже на создание себе проблем сначала, а потом героическую борьбу с ними. Нахрена бы? :)
> Не говоря о наличии возможности работать с нуль-терминированными строками
> и прочей ересью, если приспичило.
Ну, эта ересь как-то исторически прижилась, поэтому она есть. Если так придираться, UTF-8 с его переменным числом байтов на символ - тоже не подарок, только вот кодировать каждую букву как 32 или более битов ради того чтобы японцы/китайцы могли свои иерглифы пропихивать - жирновато будет, не? :)
> Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах
> всё не так очевидно, как в листинге ассемблера.
Ессно, зависит от, но в общем случае чем больше инструкций, обращений к памяти и прочая - тем дольше они выполняются. И чем жирнее код - тем меньше шансов что он целиком попадет в кеш и резко выиграет в скорости.
> Хотите узнать оверхед, надо профилировать, а не спекулировать.
Ну да, всякие там жабисты любят дрюкаться с профайлером: их софт вечно тормозит, поэтому они зеленеют в профайлерах намного больше чем сишники/сиплюсплюсники, я это заметил, ыгы :))). И главное почему-то никто не пишет критичные к скорости программы на этих ваших крутых и правильных языках. Почему-то игры, сжатие, шифрование, кодеки, ну 3D и прочая навернутая математика которую надо в реалтайме успевать - все как одно на сях или плюсах. Хотя казалось бы JIT дает кучу теоретических преимущесв и что там еще. Обычно умудряются эти преимущества легко похерить кучей рантайм проверок, излишне задрюканными сущностями типа "интегер - это объект" и прочими наворотами.

Ответить | Правка | Наверх | Cообщить модератору

261. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от iZEN (ok), 09-Мрт-11, 17:31

>> Он вообще-то о строках, как я понял.
> Я так понял что он предлагал хранить длину строки как variable length integer?
Грубо говоря, я предложу такую структуру:
struct String {
   len_of_len; //длина поля длины в байтах
   len_of_data;//поле длины строки в символах
   data;//ссылка на контейнер данных перечислимого типа [1...len_of_data]
}
Плюсы такой структуры:
+ независимость структуры от базовых типов short, int, long, ограничивающих длину строки и отсутствие избыточности служебной информации для коротких строк;
+ элементы данных строки счётны от 1 до len_of_data без нужны вычислять конец строки и идиотского "нулевого элемента", принятого в C для элементов массива (по-мне, так символы в строке — это не массив!);
+ контейнер данных может поддерживать любой доступ к элементам строки (хранить разреженные строки, например), но перечислимость [1...len_of_data] элементов должен обеспечивать — это даёт нам гибкость в абстрагировании от конкретной реализации контейнера.

Ответить | Правка | Наверх | Cообщить модератору

264. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 09-Мрт-11, 17:52

>> Он вообще-то о строках, как я понял.
> Я так понял что он предлагал хранить длину строки как variable length
> integer?
>> В нормальных языках это происходит просто: вы параметризуете строковый тип
>> максимальным размером строки, а компилятор выбирает, сколько байт под
>> величину размера выделить.
> А при нужде интероперабельно с остальными слить это на диск в файл
Трололо, придумаем проблему и выделим ей абзац в нашей простыне.
> или передать по сети в *предсказуемом* виде, который потом ремота/другая программа
Ха, данные по сети всегда передаются с таким оверхедом по заголовкам, что сравнивать его с 32/64-битной величиной длины строки - вообще срам. ;)
> сможет распарсить без привязки к языку, платформе, етц - мы жесточайше
> факаем мозг, делаем не слишком тривиальные преобразования и что там еще,
Это всё чушь. Поточная сущность ввода-вывода позволяет подставить любые заголовки до или после строк. Хоть терминировать '\0', хоть записать размер в беззнаковое целое - как угодно. А уж вес этих операций делает любые разговоры об оверхеде на пару-тройку операций с двойным словом просто неприличными. Это всё троллинг. iZEN вообще всех затроллил - начал тред и сел смотреть на массакр. :)
> в общем как обычно. Известное дело, ага. Не, ну можно конечно
Угу, да. Не, ну конечно же можно.
> себе поднасрать на ровном месте, затребовав сложную сериализацию-десериализацию, но это
> похоже на создание себе проблем сначала, а потом героическую борьбу с
> ними. Нахрена бы? :)
Вот именно, нахрена бы?
> Ну, эта ересь как-то исторически прижилась, поэтому она есть. Если так придираться,
Вы уже определитесь, вам ASCIIZ-строки не нравятся или их альтернативы? ;)
> UTF-8 с его переменным числом байтов на символ - тоже не
Вот уж где оверхед, так это парсинг не-ASCII текста в UTF-8! Правда, даже этот оверхед в большинстве случаев ничего не решает, и мы тут просто троллим порожняком.
> подарок, только вот кодировать каждую букву как 32 или более битов
Кодировать! О, кошмар! О, ужас!!!1 Бегом переходить на UTF-8 за полчаса - уж там-то, наверное, кодирования нет. ;)
> ради того чтобы японцы/китайцы могли свои иерглифы пропихивать - жирновато будет,
> не? :)
Гы. Лол.
>> Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах
>> всё не так очевидно, как в листинге ассемблера.
> Ессно, зависит от, но в общем случае чем больше инструкций, обращений к
Тролололо в общем случае.
> памяти и прочая - тем дольше они выполняются. И чем жирнее
> код - тем меньше шансов что он целиком попадет в кеш
> и резко выиграет в скорости.
И чем дольше, тем жирнее, ага. ;)
> Ну да, всякие там жабисты любят дрюкаться с профайлером: их софт вечно
> тормозит, поэтому они зеленеют в профайлерах намного больше чем сишники/сиплюсплюсники,
> я это заметил, ыгы :))). И главное почему-то никто не пишет
> критичные к скорости программы на этих ваших крутых и правильных языках.
Потому что пока правильные языки проектировались с учётом требований и обязывали производителей компиляторов к стандартизации для применения торговых марок-названий языка, академическое сообщество весело и задорно клепало экосистему Си-подобных языков, включая ОС, и её апологетов, привлекая внимание индустрии к тому, что уже освоено и "is just good enough".
> Почему-то игры, сжатие, шифрование, кодеки, ну 3D и прочая навернутая математика
> которую надо в реалтайме успевать - все как одно на сях
На ассемблере.
> или плюсах. Хотя казалось бы JIT дает кучу теоретических преимущесв и
Или фортране. Алсо, спидфаг детектед.
> что там еще. Обычно умудряются эти преимущества легко похерить кучей рантайм
> проверок, излишне задрюканными сущностями типа "интегер - это объект" и прочими
> наворотами.
Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок, которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть).

Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

268. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Dvorkin (??), 09-Мрт-11, 18:43

> Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок,
> которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ > и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть).
я бы посмотрел, как мир бы тужился с виндоус и линукс на джаве или питоне,
спидфаги, говоришь, хреновы?

Ответить | Правка | Наверх | Cообщить модератору

270. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 09-Мрт-11, 18:54

>> Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок,
>> которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ > и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть).
> я бы посмотрел, как мир бы тужился с виндоус и линукс на
> джаве или питоне,
> спидфаги, говоришь, хреновы?
Когда я пишу "другие низкоуровневые языки", обвиняют в отсутствии конкретики, когда пишут "Ада", переводят разговор на джавы и питоны. Что за жизинь, э! ;)

Ответить | Правка | Наверх | Cообщить модератору

19. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от caps (?), 08-Мрт-11, 12:40

Удивительно, но в ядре "вражеской" системы от МС этот тип строк используется повсеместно. Наверняка там работают тупые придурки, которые  для безопасности пространства ядра бездарно тратят целых 2 байта на строку. (там для длины строки используется word тип)

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

103. "Взлом Linux через подключение USB-устройства стал реальность..." +8 +/–

Сообщение от test (??), 08-Мрт-11, 17:10

Ну и как, сильно безопасное получилось?

Ответить | Правка | Наверх | Cообщить модератору

104. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 17:14

> Ну и как, сильно безопасное получилось?
Несильно, ибо строки не единственная и даже не самая серьёзная проблема си.

Ответить | Правка | Наверх | Cообщить модератору

216. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от User294 (ok), 09-Мрт-11, 05:36

> Несильно, ибо строки не единственная и даже не самая серьёзная проблема си.
Да уж. Индусы успешно доказывают что обделаться с критичными последствиями можно и на яве, питоне, пхп, [insert your favorite language here]. Ну не переполнение буфера так ремот инклюд, sql иньекция, XSS, CSRF ... - вам как, сильно полегчало? Ну упрет хацкер 100500 аккаунтов от гмыльников, фэйсовконтактов и прочая и вообще базу похерит/изменит, наприер - не факт что это нанесет меньше ущерба чем какое-то там переполнение буфера. В конечном итоге хакерье нынче давно уже не интересует возможность выполнить код ради возможности выполнить код. Это их интересует чтобы поиметь профит или данные пользователей. И возможность с дикими извращениями при физическом доступе к машине поиметь доступ к 1 машине - далеко не самая страшная дырень в свете таких реалий. Куда моднее массовое, ремотное поимение, bulk-рассылка спама, массовой кражи конфиденциальных и ценных данных, при том первое как правило нужно в основном для второго и третьего. Самое странное в этом то что дыры в сишном коде при работе с сетью встречаются весьма редко - дыр в web-приложениях например почему-то в 100500 раз больше оказывается. Хотя, казалось бы, переполнений буферов нет, стек хрен сорвешь, ну что еще этим ... не хватает для безопасного написания программ?!

Ответить | Правка | Наверх | Cообщить модератору

61. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Sw00p aka Jerom (?), 08-Мрт-11, 14:52

> Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один
> байт это нормально?
блин - проверка должна быт ьи в функцию должна передаваться длина строки

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

79. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 16:16

> блин - проверка должна быт ьи в функцию должна передаваться длина строки
Конечно должна. Это же какой контроль!

Ответить | Правка | Наверх | Cообщить модератору

77. "Взлом Linux через подключение USB-устройства стал реальность..." +5 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 16:14

> Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один
> байт это нормально?
Ненормально - путать биты с байтами и забывать о возможности параметризации типов.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

69. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 08-Мрт-11, 15:41

> Ок, для успешной индексации строк с over 2 млрд. символов всегда надо будет хранить лишних 4 байта, для любой строки, удачи !
А тебе успешного выяснения длинны строки. Жди когда найдет заветный байт в 2хгиговом куске данных

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

247. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от User294 (ok), 09-Мрт-11, 15:38

> А тебе успешного выяснения длинны строки. Жди когда найдет заветный байт в
> 2хгиговом куске данных
А в чем принципиальная разница по скорости: проверять ли байт на то что он равен нулю, и если да - то забить, или проверять что счетчик байтов дотикал до нужного значения, и если равен - то забить? С точки зрения трансформации в машинный код - получится примерно одинаково. С точки зрения попадания в кещ - по идее  в него не попадет только 2Гб данных, остальное уместится даже в самый мизерный в кеш. Я что-то упустил и в каком-то месте наступает зверский профит?

Ответить | Правка | Наверх | Cообщить модератору

251. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 09-Мрт-11, 16:31

В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания двух строк должна быть известна длина первой, т.е. имеем бесполезное пробегание циклом по строке. В результате, если надо склеить 10 строк по 10 символов, получаем 10*(1+2+...+9) = 450 чтений символов. Для 100-символьной строки замедление в 6 раз, круто? )

Ответить | Правка | Наверх | Cообщить модератору

262. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от User294 (ok), 09-Мрт-11, 17:39

> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания
> двух строк должна быть известна длина первой,
Это только в том (относительное редком) случае, если destination совпадает с первой строкой, там есть достаточно места куда можно отрастить результат и допустимо менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно и иногда это и правда будет эффективнее. А какая проблема сделать это на си если такая задача есть и ее скорость критична? :) А то что все и вся не пихают по дефолту - ну так если впихать все и вся по принципу "а вдруг пригодится?!" - получится еще одна ява, где можно уснуть пока hello world стартанет...

Ответить | Правка | Наверх | Cообщить модератору

263. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от iZEN (ok), 09-Мрт-11, 17:43

>> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания
>> двух строк должна быть известна длина первой,
> Это только в том (относительное редком) случае, если destination совпадает с первой
> строкой, там есть достаточно места куда можно отрастить результат и допустимо
> менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно
> и иногда это и правда будет эффективнее. А какая проблема сделать
> это на си если такая задача есть и ее скорость критична?
Проблема в том, что в сях оно будет не на уровне компилятора, а где-то "сбоку" в левой библиотечке, о которой многие разработчики будут не в курсе, и будут писать собственные велосипедики, несовместимые с ней.

Ответить | Правка | Наверх | Cообщить модератору

266. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от коксюзер (?), 09-Мрт-11, 18:15

>> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания
>> двух строк должна быть известна длина первой,
> Это только в том (относительное редком) случае, если destination совпадает с первой
> строкой, там есть достаточно места куда можно отрастить результат и допустимо
А если не совпадает, длину обеих строк не обязательно знать для выделения буфера под результат, ага-ага. ;)
> менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно
> и иногда это и правда будет эффективнее. А какая проблема сделать
> это на си если такая задача есть и ее скорость критична?
Проблема не в том, чтобы сделать это на Тюринг-полном языке, а в том, что что решение получится относительно неудобным. Можно вообще проставить вопрос, зачем Си если есть лисп, фортран и ассемблер?
> :) А то что все и вся не пихают по дефолту
> - ну так если впихать все и вся по принципу "а
> вдруг пригодится?!" - получится еще одна ява, где можно уснуть пока
> hello world стартанет...
Закупайте Фейри в цистернах. :Р

Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

274. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 09-Мрт-11, 19:42

> А если не совпадает, длину обеих строк не обязательно знать для выделения буфера под результат, ага-ага. ;)
А если не совпадает, обе строки пробегаются в любом случае, и разницы по времени никакой, что со счетчиком, что без.
Другое дело, что это далеко не каждый случай. В том же примере со строками 10х10 очень накладно будет перебрасывать строки между буферами туда-сюда, выделять память каждый раз, это же страшно медленно, лучше заранее выделить буфер с запасом. Существует рекомендация выделять память блоками по 2^N байт, это здорово сокращает фрагментацию и количество выделений-освобождений, при этом прога сжирает максимум вдвое больше памяти, чем ей реально нужно.
> Проблема не в том, чтобы сделать это на Тюринг-полном языке, а в том, что что решение получится относительно неудобным. Можно вообще проставить вопрос, зачем Си если есть лисп, фортран и ассемблер?
Стандарт скоро не перепишешь, а отдельно взятый компилер (GCC) - запросто. В настройках компиляции переключатель типов строк по умолчанию, и строковая библиотека в двух вариантах.

Ответить | Правка | Наверх | Cообщить модератору

277. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от paxuser (ok), 09-Мрт-11, 20:05

> А если не совпадает, обе строки пробегаются в любом случае, и разницы
> по времени никакой, что со счетчиком, что без.
Не в любом случае, а в ряде случаев. В любом случае как раз нужно знать длину каждой строки ("пробежаться" по обеим один раз), выделить буфер размером с обе и "пробежаться" по строкам второй раз, при копировании.
> Другое дело, что это далеко не каждый случай. В том же примере
> со строками 10х10 очень накладно будет перебрасывать строки между буферами туда-сюда,
Обсуждение абстрактных алгоритмов класса "туда-сюда" вносит конструктив и способствует взаимопониманию.
> выделять память каждый раз, это же страшно медленно, лучше заранее выделить
> буфер с запасом. Существует рекомендация выделять память блоками по 2^N байт,
> это здорово сокращает фрагментацию и количество выделений-освобождений, при этом прога
> сжирает максимум вдвое больше памяти, чем ей реально нужно.
Я так понял, когда та же джава разом выделяет память под кучу, сишники тычат в неё пальцами и сравнивают такой расход памяти с утечками. А прижмешь их на предмет эффективной работы со строками, начинают рассказывать о преаллокации и оверхеде "максимум вдвое больше". Очень показательно.
Наверное, если спросить про сериализацию строк с предварительным указанием размера в заголовках (тот же HTTP), они будут рассказывать о хранении длины в структурах и массивах. Ведь это же так медленно, пересчитывать её каждый раз! Поэтому в Си всё быстро, и контроль полный (ну ведь можно же хранить в структурах, кто не даёт-то?). То ли дело в других языках - всё джавой накрылось и дотнет полный.
> Стандарт скоро не перепишешь, а отдельно взятый компилер (GCC) - запросто. В
> настройках компиляции переключатель типов строк по умолчанию, и строковая библиотека в
> двух вариантах.
Дооо, нужно просто допилить GCC, добавить строковый тип (который не нужен, ведь оверхед максимум вдвое больше!), и всё пучком. Других проблем нет.

Ответить | Правка | Наверх | Cообщить модератору

281. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от фыв (??), 09-Мрт-11, 23:17

> Не в любом случае, а в ряде случаев. В любом случае как раз нужно знать длину каждой строки ("пробежаться" по обеим один раз), выделить буфер размером с обе и "пробежаться" по
строкам второй раз, при копировании.
strcat не выделяет память. И я вроде уже писал, что выделять каждый раз память зело накладно, особенно если заранее известна предельная длина результата.
> Обсуждение абстрактных алгоритмов класса "туда-сюда" вносит конструктив и способствует взаимопониманию.
См выше. Попробуйте представить, что будет в том примере 10х10, если каждый раз под результат будет выделяться память, и оцените быстродействие. Помимо указанной задержки в 6 раз на лишнее копирование/пробегание будет задержка при выделении огрызков 10, 20, ..., 90, 100 байт, которые по окончании операции станут не нужны и освободятся, отлично фрагментировав память. Неужели не проще выделить буфер на 100 байт _один раз_ и работать с ним?
> Я так понял, когда та же джава разом выделяет память под кучу, сишники тычат в неё пальцами и сравнивают такой расход памяти с утечками. А прижмешь их на предмет эффективной работы со строками, начинают рассказывать о преаллокации и оверхеде "максимум вдвое больше". Очень показательно.
Это вы сами с собой разговариваете? Красиво у вас там все, должно быть, черт побери
> Дооо, нужно просто допилить GCC, добавить строковый тип (который не нужен, ведь оверхед максимум вдвое больше!), и всё пучком. Других проблем нет.
Вас сишники в магазине что ли обвешали? Или в детстве отнимали деньги на обеды?

Ответить | Правка | Наверх | Cообщить модератору

285. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от paxuser (ok), 10-Мрт-11, 04:31

> strcat не выделяет память. И я вроде уже писал, что выделять каждый
Ещё бы выделял. Всё руками.
> раз память зело накладно, особенно если заранее известна предельная длина результата.
Накладно, но всегда возможно или допустимо, в отличие от преаллокации по оценке сверху. И давайте без strcat как-то уже. Или проверку на выход за границы буфера в общем случае тоже можно не делать? :) Алсо, с вами скучно троллить.
> выделить буфер на 100 байт _один раз_ и работать с ним?
В этом случае проще. А когда нужно дать отлуп пользователю (источнику входных данных), если результат не вместится в буфер? Предложите начать копировать, а ошибку вернуть в случае заполнения буфера? Нет, вы спросите, что мешает пользователю передать размер строки вместе со строкой (как собственно и происходит чаще всего). То есть, предложите так или иначе пробросить передачу размера по всей цепочке вызовов. Мол, пользователь знает длину строки, поскольку он её откуда-то получил, вот пусть и передаст. И вроде бы проблема решена, но традиционно для Си - нагибая пользователей API. А если API чего-то не предусматривает (плохие проектировщики изначально сделали его простым) - это не проблема языка. Ведь так?
И потом, конкатенация - частный случай. Как думаете, сложно найти задачу по эффективной работе со строками, для которой придётся переизобрести строки с хранимой длиной? С подстроками у си как? Ах, ну да: изобретаем свой структурный тип (не совместимый с нуль-терминацией и стандартными функциями), и всё замечательно. Полный контроль. И не рассказывайте мне, что таких задач нет - есть, решал пару месяцев назад и плевался.
> Это вы сами с собой разговариваете? Красиво у вас там все, должно
> быть, черт побери
Это я рассуждаю вслух. Вам, вот, повод поёрничать дал. А вы продолжайте, не стесняйтесь - ваши догадки о причинах моей нелюбви к Си весьма любопытны.
> Вас сишники в магазине что ли обвешали? Или в детстве отнимали деньги
> на обеды?
Ну конечно же дело во мне. Придумал проблемы, которых нет.

Ответить | Правка | Наверх | Cообщить модератору

10. "Взлом Linux через подключение USB-устройства стал реальность..." –8 +/–

Сообщение от Аноним (-), 08-Мрт-11, 12:12

А если мне нужна строка > 255 символов? Думай прежде, чем писать

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

21. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от frankl (?), 08-Мрт-11, 12:51

учил turbo pascal? Выходи из анабиоза, есть строки в паскале превышающие 255...
>Думай прежде, чем писать
ты хотя бы думай. Хоть когда нибудь.

Ответить | Правка | Наверх | Cообщить модератору

14. "Взлом Linux через подключение USB-устройства стал реальность..." +5 +/–

Сообщение от anonymous (??), 08-Мрт-11, 12:23

ну и какое отношение имеют стандартные библиотеки C, которые ориентрируются на терминирующий нулевой символ к коду ядра линукс, где этих библиотек нет и быть не может? не надо путать язык и используемые им библиотеки. да, покормил.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

31. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от anonymous (??), 08-Мрт-11, 13:12

прошу прощения, невнимательно читал новость.
>связанный с использованием для копирования содержимого строки небезопасной функции strcpy(), вместо учитывающего длину строки варианта strlcpy().
таки они скопировали часть функций в ядро. впрочем, всё равно, это недостаток  этих функций, а никак не языка.

Ответить | Правка | Наверх | Cообщить модератору

80. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 16:19

> таки они скопировали часть функций в ядро. впрочем, всё равно, это недостаток
>  этих функций, а никак не языка.
Конечно-конечно. Уж в языке-то есть тип данных, позволяющий отказаться от ручного управления границами. И стандарт на библиотеки есть, и их реализаций - пруд пруди. А виноваты программеры, да.

Ответить | Правка | Наверх | Cообщить модератору

16. "Взлом Linux через подключение USB-устройства стал реальность..." +15 +/–

Сообщение от тоже Аноним (ok), 08-Мрт-11, 12:34

ВНЕЗАПНО! И С, и тем более С++ позволяют реализовать строку именно так, как вам это нужно.
С любыми проверками и любой оптимизацией - по вкусу. Без хитрых хаков для кривых костылей...

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

73. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Ytch (?), 08-Мрт-11, 15:50

Именно так! А еще, в ряде случаев, можно сделать проверки длин и расстановку защитных '\0' в концах массивов ДО вызова продедур копирования/сравнения/и т. п. и не тратить время на лишние проверки на каждой итерации циклов.

Ответить | Правка | Наверх | Cообщить модератору

82. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 16:27

> ВНЕЗАПНО! И С, и тем более С++ позволяют реализовать строку именно так,
> как вам это нужно.
> С любыми проверками и любой оптимизацией - по вкусу. Без хитрых хаков
> для кривых костылей...
Особенно в Си. Прямо бери и реализуй литералы и неявные преобразования типов. Ага, ну-ну. А в С++ кроме строк проблем нет, конечно же - полный контроль над адресной арифметикой, ага. Ну-ну. ;)

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

176. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от тоже Аноним (ok), 08-Мрт-11, 22:10

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

Ответить | Правка | Наверх | Cообщить модератору

187. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 22:57

> Вы не любите языки, на которых нельзя написать фреймворк и сделать вид,
> что это другой язык? Тогда низкоуровневые языки просто не для вас.
Пляска вокруг убогой системы типов и её последствия - фамильная черта языков семейства Си. В нормальных низкоуровневых языках этого нет.
> Проблема, которую вы пытаетесь придумать, решается одной функцией. Если в вашем коде
Реальная, а не абстрактная, проблема, отсутствие которой вы пытаетесь придумать, воплощена в массе унаследованного кода. Обсуждаемая новость - об одном из её проявлений. Предлагаемые структурные строковые типы на Си - это неудобный костыль без нативной поддержки в языке и библиотеках, который используют единицы из тысяч, в лучшем случае.
> используется только определенный вами тип строк и любая входящая строка преобразуется
> к вашему типу через одну, предусматривающую вероятность переполнения, функцию, то в
> вашем коде переполнения строки не будет. Вот и все...
Действительно, вот и всё: и удобно, и все пользуются, и унаследованный код сам себя переписал, и все остальные проблемы Си решились сами собой.

Ответить | Правка | Наверх | Cообщить модератору

226. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от тоже Аноним (ok), 09-Мрт-11, 08:33

Фамильная черта тех, кто гонит на С - упоминание неких "нормальных языков" без конкретизации...
Каким образом людям, писавшим драйвера, удалось унаследовать у кого-то код - для меня загадка.

Ответить | Правка | Наверх | Cообщить модератору

227. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 09-Мрт-11, 08:56

> Фамильная черта тех, кто гонит на С - упоминание неких "нормальных языков"
> без конкретизации...
Ада.
> Каким образом людям, писавшим драйвера, удалось унаследовать у кого-то код - для
> меня загадка.
А отгадка в том, что вы вынимаете слова из контекста.

Ответить | Правка | Наверх | Cообщить модератору

230. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от тоже Аноним (ok), 09-Мрт-11, 10:29

Конечно! Нет унаследованного кода - нет проблемы!

Ответить | Правка | Наверх | Cообщить модератору

259. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 09-Мрт-11, 17:26

> Конечно! Нет унаследованного кода - нет проблемы!
Да что вы говорите! Ещё раз: у Си полно проблем помимо кривых строк. Чтобы их решить, нужно превратить Си в Cyclone. Никакой пляской с идиомами и API здесь не отделаться.

Ответить | Правка | Наверх | Cообщить модератору

248. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от User294 (ok), 09-Мрт-11, 15:57

> Ада.
Ну и где операционки на ней и желающие на оной их писать? Не хочу ничего сказать, но все навороты типизации и излишние умничания компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуется например загнать ровно 4 байта да еще в строго определенном endianess'е в регистры вон той железяки. И заметьте, железяка хочет только так и никак иначе. На сях это даже относительно реально делать без огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов там где они только мешаются.

Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

250. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от klalafuda (?), 09-Мрт-11, 16:12

> Ну и где операционки на ней и желающие на оной их писать? Не хочу ничего сказать, но все навороты типизации и излишние умничания компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуется например загнать ровно 4 байта да еще в строго определенном endianess'е в регистры вон той железяки. И заметьте, железяка хочет только так и никак иначе. На сях это даже относительно реально делать без огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов там где они только мешаются.
Непосредственно загнать 4 байта в регистры вон той железяки - это примерно 0 целых хрен десятых % от трудоемкости общего кода ядра. Решается минимальным тоненьким врапером над непосредственным доступом к физической памяти/регистрам/etc хоть на ассемблере. Который вылизывается до блеска специальным стадом котов. Все остальное - это самый обычный код. В котором собственно и делают те самые неприятные ошибки самые обычные люди. И уже на этом уровне 'широкие возможности C' - это скорее геморрой нежели благо. Никому в трезвом умен и здравом сознании не приходит в голову браться писать на C действительно сложный ответственный код в 21м веке. Как минимум - выбор за C++. А зачастую и что-то куда более высокоуровневое - жаба, эрланг, те или иные скриптовые решения - зависит от конкретной ситуации. Но никак не ассемблер или C.

Ответить | Правка | Наверх | Cообщить модератору

267. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от User294 (ok), 09-Мрт-11, 18:27

> Непосредственно загнать 4 байта в регистры вон той железяки - это примерно
> 0 целых хрен десятых % от трудоемкости общего кода ядра.
Угу, а код драйверов вы смотреть не пробовали? Там такого кода - хоть отбавляй, и драйвера - весьма существенный кусок ядра, собссно :)
> Решается минимальным тоненьким врапером над непосредственным доступом
> к физической памяти/регистрам/etc хоть на ассемблере. Который вылизывается
> до блеска специальным стадом котов. Все остальное - это самый обычный код.
Этот обычный код в основном занимается как раз довольно необычными низкоуровневыми задачами. Может я что-то и не понимаю в этой жизни, но общематематические и прикладные задачи (ака "обычный код") не являются целью ради которой делают ядра ОС. Ядра как раз по задумке именно прослойка между железом и прикладным софтом, не привязанным к железу и желательно особенностям низкоуровневой реализации конкретной ОС. Предлагаете делать врапперы в врапперах? А в тех врапперах не надо врапперов? :)
> В котором собственно и делают те самые неприятные ошибки самые обычные люди.
> И уже на этом уровне 'широкие возможности C' - это скорее геморрой нежели благо.
Ну так пишите программы работающие с юсб через юзермод на чемнить высокоуровневом, правда мне почему-то кажется что это будет не самым безгеморройным начинанием :)
> Никому в трезвом умен и здравом сознании не приходит в голову браться
> писать на C действительно сложный ответственный код в 21м веке.
Именно сложный - да, только странная какая-то цель: "написать сложный код". Код должен быть простым и прозрачным.
> Как минимум - выбор за C++. А зачастую и что-то куда более высокоуровневое
> - жаба, эрланг, те или иные скриптовые решения -
Ну так напишите на этом кернель, а я посмотрю на параметры и подумаю - надо оно мне, или в сад. На кой хрен мне враппер между моей программой и оборудованием писаный на жабе, а? Тем более что ява - затевалась для независимости от оборудования, по поводу чего она сама нуждается в враппере, ибо там "немного забыли" реализовать свои дрова для тех же юсб-звуковух и прочая :)
> зависит от конкретной ситуации. Но никак не ассемблер или C.
Ха, вы будете учить системщиков как им надо писать кернелы? Не, хренушки, так не катит. Давайте вы сделаете ваше крутое, правильное, и на чем вам там надо? И вот когда оно всех зарулит - тогда ваш тезис "никак не ассемблер или C" и будет доказан, имхо :). Только вот высокоуровневые сложные конструкции ИМХО не очень просто и быстро трансформируются в простые наборы байтов и даже битов с которыми работает железо, если что. А приколитесь, бывают железки которые хотят, допустим не 8 и не 16 битов. А 12 битов, например. Ничему не противоречит послать по сериальной шине именно 12 битов, а вовсе не 8 или 16. Интересно было бы посмотреть как вы 12-битные слова, нативные для железки будете в высокоуровневые абстракции упаковывать и какая будет скорость враппинга всего этого :).Особенно если чипмейкер не искал легких путей и сделал так что первые 9 битов - одно поле, а еще три - другое. Во вы там наврапаетесь то :)

Ответить | Правка | Наверх | Cообщить модератору

269. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от коксюзер (?), 09-Мрт-11, 18:53

> Угу, а код драйверов вы смотреть не пробовали? Там такого кода -
> хоть отбавляй, и драйвера - весьма существенный кусок ядра, собссно :)
Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :D
> Этот обычный код в основном занимается как раз довольно необычными низкоуровневыми задачами.
На той же Аде все эти низкоуровневые задачи решаются быстрее и надёжнее. :Р
> Может я что-то и не понимаю в этой жизни, но общематематические
:D
> и прикладные задачи (ака "обычный код") не являются целью ради которой
> делают ядра ОС. Ядра как раз по задумке именно прослойка между
Да-да, в [s]СССР[/s] ядре линукса алгоритмов нет. :)))
> железом и прикладным софтом, не привязанным к железу и желательно особенностям
> низкоуровневой реализации конкретной ОС. Предлагаете делать врапперы в врапперах? А в
> тех врапперах не надо врапперов? :)
Ну может вы что-то знаете, чего мы не знаем? Вот Аде, например, какие врапперы нужны? Они ведь нужны, да?
> Ну так пишите программы работающие с юсб через юзермод на чемнить высокоуровневом,
> правда мне почему-то кажется что это будет не самым безгеморройным начинанием
> :)
Ага, лишние апи, лишние баги в ядре... Тут уж без Релифа никуда. :D
> Именно сложный - да, только странная какая-то цель: "написать сложный код". Код
> должен быть простым и прозрачным.
Простым и прозрачным прям как опухшее монолитное ядро. :D
>> зависит от конкретной ситуации. Но никак не ассемблер или C.
> Ха, вы будете учить системщиков как им надо писать кернелы? Не, хренушки,
Ну так и Вирт тоже учит. Давайте Вирта попинаем за академичность и отрыв от практики - это уже становится модно. :)
> так не катит. Давайте вы сделаете ваше крутое, правильное, и на
> чем вам там надо? И вот когда оно всех зарулит -
Та гуано вопрос. 30 миллионов евро, и через 5 лет будет вам ядро.
> тогда ваш тезис "никак не ассемблер или C" и будет доказан,
Школоло. :Р Всех можно в контру зарулить, а ОС - они разные все, со своими достоинствами, недостатками и сферами применения. Я тут слышал тезис, согласно которому, обероны и системы на Аде, которые работают в критических промышленных и военных отраслях - это нифига не промышленный уровень. :) Промышленны - это видимо, когда много, везде, и хомячку видно. :Р
> имхо :). Только вот высокоуровневые сложные конструкции ИМХО не очень просто
> и быстро трансформируются в простые наборы байтов и даже битов с
И даже кубитов, чо уж там.
> которыми работает железо, если что. А приколитесь, бывают железки которые хотят,
Гыгы.

> допустим не 8 и не 16 битов. А 12 битов, например.
> Ничему не противоречит послать по сериальной шине именно 12 битов, а
> вовсе не 8 или 16. Интересно было бы посмотреть как вы
> 12-битные слова, нативные для железки будете в высокоуровневые абстракции упаковывать
Так 12-битные слова или байты, теоретический вы наш? :)
> и какая будет скорость враппинга всего этого :).Особенно если чипмейкер не
Враппинг!!1
> искал легких путей и сделал так что первые 9 битов -
> одно поле, а еще три - другое. Во вы там наврапаетесь
> то :)
Та не говори, заврапало уже врапать (врап-врап).

Ответить | Правка | Наверх | Cообщить модератору

280. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от тоже Аноним (ok), 09-Мрт-11, 23:16

> Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :D
Несмотря на XXI век, компьютер до сих пор включается в розетку и оперирует битами.
Действительно, чудовищно. Но вы не зацикливайтесь на этом, у вас-то все хорошо...

Ответить | Правка | Наверх | Cообщить модератору

283. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от paxuser (ok), 10-Мрт-11, 01:06

>> Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :D
> Несмотря на XXI век, компьютер до сих пор включается в розетку и
> оперирует битами.
> Действительно, чудовищно. Но вы не зацикливайтесь на этом, у вас-то все хорошо...
Да, у меня (как впрочем и у вас) дрова давно гоняют данные с/на железо в основном через прямой доступ к памяти, а портовый ввод-вывод присутствует кое-где и кое-как лишь для инициализации и переключения режимов + всякая мишура, вроде сенсоров, последовательных и параллельных портов. Но вы не зацикливайтесь на фактах... ;)

Ответить | Правка | Наверх | Cообщить модератору

265. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от коксюзер (?), 09-Мрт-11, 18:06

>> Ада.
> Ну и где операционки на ней и желающие на оной их писать?
В гугле.
> Не хочу ничего сказать, но все навороты типизации и излишние умничания
> компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуется
МЕШАТЬСЯ!!!!!111 8-***
> например загнать ровно 4 байта да еще в строго определенном endianess'е
Так спидфаг или не спидфаг? А то спидфаги выравнивают структуры даже на CISC-архитектурах (не имею ничего против, кстати). ;)
> в регистры вон той железяки. И заметьте, железяка хочет только так
> и никак иначе. На сях это даже относительно реально делать без
И заметьте, в Аде, в отличие от Си, в котором нет языковых средств безопасного программирования, есть языковые средства небезопасного оптимизированного программирования. Они там используются по выбору программиста и могут быть запрещены на уровне компилятора в рамках отдельных package, чтобы, например, не утруждать себя аудитом кода на предмет наличия неоправданных небезопасных оптимизаций. Вот где контроль, а не в этих ваших сях. :Р
> огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов
> там где они только мешаются.
Все задачи в мире сводятся к тем, которые удобны программисту на Си как раз в силу простоты типов и отсутствия наворотов, ага. ;)

Ответить | Правка | К родителю #248 | Наверх | Cообщить модератору

271. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от User294 (ok), 09-Мрт-11, 19:07

> В гугле.
В гугле обычный линух на дешевых серверах :P. Да-да, гуглить для вас будет это решето на говняном х86... :)))
> МЕШАТЬСЯ!!!!!111 8-***
Судя по тому что вменяемых операционок, готовых для использования до сих пор почему-то нет, видимо вы правы с усилением эмоций. Ну или почему все как идиоты пишут оси на сях когда вокруг уже несколько десятков лет как есть более правильные языки?
>> например загнать ровно 4 байта да еще в строго определенном endianess'е
> Так спидфаг или не спидфаг?
В идеале программа должна занимать как можно меньше места, работать как можно быстрее, потребляя как можно меньше памяти :))). Я не виноват что эти требования иногда противоречат друг другу :P.
> А то спидфаги выравнивают структуры даже на
> CISC-архитектурах (не имею ничего против, кстати). ;)
Как ни странно я тоже ничего против не имею. Если это не ведет к тому что вместо, допустим, мегабайта памяти жрется, скажем, 4. А то мало ли, линух работает и в железках где RAM всего 16 Мб бывает и никакого свопа, например. В общем все хорошо в меру.
> И заметьте, в Аде, в отличие от Си, в котором нет языковых
> средств безопасного программирования, есть языковые средства
> небезопасного оптимизированного программирования. Они там используются
> по выбору программиста и могут быть запрещены на уровне компилятора
> в рамках отдельных package, чтобы, например, не утруждать себя аудитом кода
> на предмет наличия неоправданных небезопасных оптимизаций. Вот где
> контроль, а не в этих ваших сях. :Р
Звучит неплохо. Только почему-то никто не пользуется адой, мир почему-то выбрал си. И дурные х86 с ископаемой системой команд и пачкой костылей. И почему-то я бы предпочел кернел где аудит все-таки сделали. А то если есть возможность "не утруждать себя аудитом кода", зная человеков я просто уверен что в итоге получится очередной энтерпрайзный крап где баг на баге и багом погоняет. Улет системы в панику а то и возможность сплойтом получить - явно не способствует тому чтобы плодить баги в коде, т.к. чревато :)
> Все задачи в мире сводятся к тем, которые удобны программисту на Си
> как раз в силу простоты типов и отсутствия наворотов, ага. ;)
Вы только представьте себе, а ответная сторона ака фирмвара того же юсб-девайса ... обычно тоже пишется на си, ну, может с кусочками асма (хардкорный вариант - на голом асме, но нынче желающих это делать уже не так много как раньше). Логично что взаимодействовать с ней удобнее всего из тех же сей получается :)

Ответить | Правка | Наверх | Cообщить модератору

273. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от paxuser (ok), 09-Мрт-11, 19:37

>> В гугле.
> В гугле обычный линух на дешевых серверах :P. Да-да, гуглить для вас
> будет это решето на говняном х86... :)))
Поставим ответ иначе: гугль знает.
>> МЕШАТЬСЯ!!!!!111 8-***
> Судя по тому что вменяемых операционок, готовых для использования до сих пор
Ну так сделайте. Линух вон сперва вылез из грязи в князи, а потом крупные игроки пришли. А вы хотите чтобы за вас кто-то что-то делал. А оно этим кому-то надо - делать то что надо ВАМ а не ИМ? :)
> почему-то нет, видимо вы правы с усилением эмоций. Ну или почему
Хомячку не видно, а они есть. ;)
> все как идиоты пишут оси на сях когда вокруг уже несколько
> десятков лет как есть более правильные языки?
Ну а почему все как идиоты сидят на винде когда вокруг уже несколько десятков лет есть BSD и линукс? Почему все как идиоты сидят на CISC-процессорах, когда вокруг давно есть RISC и VLIW? Почему все летают на дозвуковых самолётах и ездят на ЖД-поездах? Потому что привыкли, дёшево и сердито. Good enough.
> В идеале программа должна занимать как можно меньше места, работать как можно
> быстрее, потребляя как можно меньше памяти :))). Я не виноват что
> эти требования иногда противоречат друг другу :P.
Иногда программа должна быть надёжной и безопасной, написана на привычном и хорошо знакомом, выразительном и хорошо читаемом языке с нативной поддержкой параллельных вычислений, по которому на рынке труда есть спрос и предложение, за которым стоят крупные корпорации, заинтересованные в популяризации своего языка и платформы среди промышленников, военных, бизнеса, хомячков и геймеров. Кто виноват и доколе?
> Как ни странно я тоже ничего против не имею. Если это не
> ведет к тому что вместо, допустим, мегабайта памяти жрется, скажем, 4.
Это главное, да.
> А то мало ли, линух работает и в железках где RAM
> всего 16 Мб бывает и никакого свопа, например. В общем все
> хорошо в меру.
Ага, всё хорошо в меру всегда и везде. ;)
> Звучит неплохо. Только почему-то никто не пользуется адой, мир почему-то выбрал си.
Вот ответ на вопрос: почему-то! :) И всё встало на свои места! :)
> И дурные х86 с ископаемой системой команд и пачкой костылей. И
Действительно, глупость. Альтернатив-то полно в каждом магазине, и совместимость полная.
> почему-то я бы предпочел кернел где аудит все-таки сделали. А то
> если есть возможность "не утруждать себя аудитом кода", зная человеков я
Можно не проводить аудит на предмет конкретных недостатков => аудит не будут проводить вообще. Ага. Btw, его и сейчас никто не проводит, кроме единичных энтузиастов, пентестеров и криминала. ;)
> просто уверен что в итоге получится очередной энтерпрайзный крап где баг
> на баге и багом погоняет. Улет системы в панику а то
Где-то я это уже [s]слышал[/s] видел. ;)
> и возможность сплойтом получить - явно не способствует тому чтобы плодить
> баги в коде, т.к. чревато :)
Ага. Железная надёжность и высокий уровень ответственности за безопасность. Именно это мы сейчас и видим. Алсо, свобода - это рабство. ;)
> Вы только представьте себе, а ответная сторона ака фирмвара того же юсб-девайса
> ... обычно тоже пишется на си, ну, может с кусочками асма
> (хардкорный вариант - на голом асме, но нынче желающих это делать
> уже не так много как раньше). Логично что взаимодействовать с ней
> удобнее всего из тех же сей получается :)
Согласен, разница просто огромна: на сях я в порт или маппинг пишу/читаю, а на Аде и оберонах я в порти или маппинг пишу/читаю. Вы правы, ту мне возразить нечего.

Ответить | Правка | Наверх | Cообщить модератору

28. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от Аноним (-), 08-Мрт-11, 13:05

Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо этот путь не для вас, так вот вопрос, какие именно строки вы имеете ввиду, QString, CString, std::string или какие-то ещё?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

35. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 08-Мрт-11, 13:18

Поскольку это ядро, то очевидно не std::string ;)

Ответить | Правка | Наверх | Cообщить модератору

62. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Sw00p aka Jerom (?), 08-Мрт-11, 14:53

> Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо
> этот путь не для вас, так вот вопрос, какие именно строки
> вы имеете ввиду, QString, CString, std::string или какие-то ещё?
СТЛ ваш ни чем не лучше

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

83. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 16:31

> Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо
> этот путь не для вас, так вот вопрос, какие именно строки
> вы имеете ввиду, QString, CString, std::string или какие-то ещё?
А я бы на вашем месте изучил языки с более строгими системами типов, прежде чем кичиться формальным наличием выбора в рамках отдельно взятой проблемы (как будто других нет). Но очевидно, это путь не для вас.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

93. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от анон (?), 08-Мрт-11, 16:45

> А я бы на вашем месте изучил языки с более строгими системами
> типов, прежде чем кичиться формальным наличием выбора в рамках отдельно взятой
> проблемы (как будто других нет). Но очевидно, это путь не для
> вас.
Предлагаете писать ядро на лиспе?

Ответить | Правка | Наверх | Cообщить модератору

100. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 17:07

> Предлагаете писать ядро на лиспе?
То есть лисп в ваших глазах - это язык со строгой системой типов? :))

Ответить | Правка | Наверх | Cообщить модератору

113. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 17:57

хаскель?) окамл?)
уточните, на чем же нада писать ядра?)

Ответить | Правка | Наверх | Cообщить модератору

126. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от klalafuda (?), 08-Мрт-11, 19:33

> уточните, на чем же нада песать ядра?)
Очевидно Ада. На пару с Обероном.

Ответить | Правка | Наверх | Cообщить модератору

155. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Ytch (?), 08-Мрт-11, 20:49

>> уточните, на чем же нада песать ядра?)
>Очевидно Ада. На пару с Обероном.
Это просто бред или какая-то очень тонкая ирония?

Ответить | Правка | Наверх | Cообщить модератору

160. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 20:54

> Это просто бред или какая-то очень тонкая ирония?
А что, разве на Аде и оберонах не написано ни одного ядра?

Ответить | Правка | Наверх | Cообщить модератору

171. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от pavlinux (ok), 08-Мрт-11, 21:42

>> Это просто бред или какая-то очень тонкая ирония?
> А что, разве на Аде и оберонах не написано ни одного ядра?
неа

Ответить | Правка | Наверх | Cообщить модератору

178. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от gegMOPO4 (ok), 08-Мрт-11, 22:18

http://en.wikipedia.org/wiki/Oberon_(operating_system)

Ответить | Правка | Наверх | Cообщить модератору

183. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от pavlinux (ok), 08-Мрт-11, 22:44

> http://en.wikipedia.org/wiki/Oberon_(operating_system)
Исходники ядра можно?

Ответить | Правка | Наверх | Cообщить модератору

188. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от gegMOPO4 (ok), 08-Мрт-11, 22:59

Да, там свободная лицензия.

Ответить | Правка | Наверх | Cообщить модератору

194. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 08-Мрт-11, 23:31

>> http://en.wikipedia.org/wiki/Oberon_(operating_system)
> Исходники ядра можно?
ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/StdAlone/ не?

Ответить | Правка | Наверх | Cообщить модератору

197. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от pavlinux (ok), 08-Мрт-11, 23:50

>>> http://en.wikipedia.org/wiki/Oberon_(operating_system)
>> Исходники ядра можно?
> ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/StdAlone/ не?
Не, там бинарники и примеры.

Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

288. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от cobold (ok), 10-Мрт-11, 13:58

> http://en.wikipedia.org/wiki/Oberon_(operating_system)
Эта операционка была для Вирта самым большим фейлом в его жизни, IMHO. Крах идеи о том что можно писать академическим подходом вещи применимые на практике - вылизывать байты, когда память дешевеет дикими темпами; не заниматься абстракциями аппаратуры, когда целевая аудитория - пользователи персоналок, со всем уже тогда имевшимся зоопарком железа; совершенно не заботиться о usability пользовательских интерфейсов, хотя примеров удачных (и не очень) реализаций было уже достаточно. Знаете, у новичков такое порой случается: делать то что возможно, вместо того что требуется. Для Вирта это должен был быть конец карьеры.

Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

291. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от paxuser (ok), 10-Мрт-11, 19:17

>> http://en.wikipedia.org/wiki/Oberon_(operating_system)
> Эта операционка была для Вирта самым большим фейлом в его жизни, IMHO.
Действительно, фейл. Но не по части инженерных и потребительских качеств. Он долго артачился сделать исходники свободными, академическое сообщество энтузиастов не сколотил и не особенно, на сколько я знаю, старался продвигать свою систему и язык за пределами вуза.
> Крах идеи о том что можно писать академическим подходом вещи применимые
> на практике - вылизывать байты, когда память дешевеет дикими темпами; не
http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=689811 - там перечислены некоторые случаи применения оберонов на практике.
На базе паскаля была создана Ада, модула летала в космос уже в 80-ых. А крах идеи о том, что что-то можно писать "не академическим подходом", мы наблюдаем сегодня на примере юниксов и Си: проблемы с надёжностью, безопасностью, эффективностью разработки, плюс немасштабируемость выбранных архитектурных решений и потеря контроля за сложностью систем (тех самых моноядерных, одну из которых Торвальдс назвал раздутой и признался, что не видит путей решения этой проблемы).
> заниматься абстракциями аппаратуры, когда целевая аудитория - пользователи персоналок,
Ну да, других целевых аудиторий не бывает же.
> со всем уже тогда имевшимся зоопарком железа; совершенно не заботиться о
> usability пользовательских интерфейсов, хотя примеров удачных (и не очень) реализаций
Для своего времени интерфейс оберонов был весьма удобен. Да и не создатели ОС должны его развивать, а сообщество, о формировании которого Вирт как раз и не позаботился.
> было уже достаточно. Знаете, у новичков такое порой случается: делать то
> что возможно, вместо того что требуется. Для Вирта это должен был
> быть конец карьеры.
:) В качестве домашнего задания предлагаю подумать, почему на практике этот конец до сих пор не наступил. ;)

Ответить | Правка | Наверх | Cообщить модератору

127. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 19:33

> хаскель?) окамл?)
> уточните, на чем же нада песать ядра?)
Т.е. вы мне кагбе придлогаите передти от тролинга к розговору по сущиству?

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

147. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 20:36

Нет не предлагаю, т.к. по существу вам просто нечего сказать. Иначе б давно сказали)
А уж каким местом статическая типизация к новости про кернел, вообще непонятно.

Ответить | Правка | Наверх | Cообщить модератору

154. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 20:47

> Нет не предлагаю, т.к. по существу вам просто нечего сказать. Иначе б
> давно сказали)
Я говорил и не раз. Если вы считаете, что нет Тюринг-полных типобезопасных языков на которых были бы написаны реально применяемые ОС, это ваши проблемы.
> А уж каким местом статическая типизация к новости про кернел, вообще непонятно.
И при таком уровне внимания/понимания вы хотите, чтобы я распинался перед вами "по существу"? Сейчас всё брошу и начну, да.

Ответить | Правка | Наверх | Cообщить модератору

276. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 09-Мрт-11, 19:53

Ядро на Хаскеле - это интересно... Уж оно-то будет отлично параллелизоваться, быть страшно оптимальным и типобезопасным, но я что-то не знаю осей на Хаскеле. Жааль

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

44. "Взлом Linux через подключение USB-устройства стал реальность..." –17 +/–

Сообщение от Толстый (ok), 08-Мрт-11, 13:47

хехе, красноглазое быдло заминусовало правильный пост. Не только строки но и массивы в целом в С - это epic fail. D к примеру сделал тоже все правильно, массивы представляют собой структуру, содержащую указатель и длину массива.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

53. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от Udzhen (ok), 08-Мрт-11, 14:11

Что Вам мешает написать собственную реализацию?
Вот к примеру как выглядят строки в ядре Nt:
typedef struct _UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
} UNICODE_STRING;
typedef UNICODE_STRING *PUNICODE_STRING;

Ответить | Правка | Наверх | Cообщить модератору

81. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Толстый (ok), 08-Мрт-11, 16:20

> Что Вам мешает написать собственную реализацию?
> Вот к примеру как выглядят строки в ядре Nt:
> typedef struct _UNICODE_STRING {
>     USHORT Length;
>     USHORT MaximumLength;
>     PWSTR  Buffer;
> } UNICODE_STRING;
> typedef UNICODE_STRING *PUNICODE_STRING;
Вот именно, у каждого Васи своя реализация, несовместимая с реализацией Пети. А еще есть алгоритмы которые надо дублировать для контейнеров и строк.

Ответить | Правка | Наверх | Cообщить модератору

122. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от Udzhen (ok), 08-Мрт-11, 18:52

Ну так вперед! Докажите миру что Ваша реализация безопасней, быстрей и удобней!
Все Вам только спасибо скажут...

Ответить | Правка | Наверх | Cообщить модератору

129. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 19:40

> Ну так вперед! Докажите миру что Ваша реализация безопасней, быстрей и удобней!
Всё уже реализовано и доказано.
> Все Вам только спасибо скажут...
Нет, "все" будут жаловаться на необходимость изучить новое, на непривычное, на отсутствие массового рынка труда, на Отсутствие Контроля и т.п.. Хотят есть кактус, пусть едят.

Ответить | Правка | Наверх | Cообщить модератору

91. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 16:42

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

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

106. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 17:18

>> D к примеру сделал тоже все правильно, массивы представляют собой структуру, содержащую указатель и длину массива.
> Да, это помогает избежать сегфолта, разменивая его на логические ошибки, вот только
> их отлаживать еще труднее.
> Ну и результате имеем неустранимый оверхед на рантайм-проверку границ массива.
Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома, сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на Си делали? Нет. Зато пафоса и апломба - вагон.

Ответить | Правка | Наверх | Cообщить модератору

114. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 17:58

> Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома,
> сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на
> Си делали? Нет.
А вы, простите, видели, что я делал а что нет?)
Зато баттхерта и агрессии у вас - вагон)

Ответить | Правка | Наверх | Cообщить модератору

134. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 19:54

>> Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома,
>> сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на
>> Си делали? Нет.
> А вы, простите, видели, что я делал а что нет?)
Вот я и спрашиваю: вы видели, делали? Если нет, к чему эти юления со смайликами?

> Зато баттхерта и агрессии у вас - вагон)
Батхёрт действительно есть, но не по вашей милости. Мне с поделиями на Си ещё работать и работать. Благо, не только с ними. Агрессии? Вы себе льстите.

Ответить | Правка | Наверх | Cообщить модератору

148. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 20:37

> Батхёрт действительно есть, но не по вашей милости. Мне с поделиями на
> Си ещё работать и работать.
Если вы такой умный и знаете как надо а как ненадо, почему работаете на работе, которая вызывает у вас баттхерт?

Ответить | Правка | Наверх | Cообщить модератору

152. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 20:42

> Если вы такой умный и знаете как надо а как ненадо, почему
> работаете на работе, которая вызывает у вас баттхерт?
Потому что других ОС у рынка для меня нет.

Ответить | Правка | Наверх | Cообщить модератору

202. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 09-Мрт-11, 02:06

> Вот я и спрашиваю: вы видели, делали?
Вы его не спрашивали, а предположили заранее. Надменность - не лучший способ доказать правоту.

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

206. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 09-Мрт-11, 02:58

>> Вот я и спрашиваю: вы видели, делали?
> Вы его не спрашивали, а предположили заранее. Надменность - не лучший способ
> доказать правоту.
Не лучший, но любые попытки доказать правоту тут как правило тщетны (я уже пытался, в комментариях к другим новостям).

Ответить | Правка | Наверх | Cообщить модератору

272. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от User294 (ok), 09-Мрт-11, 19:14

> сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на
> Си делали? Нет. Зато пафоса и апломба - вагон.
Ну вон quicklz - одна и та же либа, при том авторами писаны реализации на сях, сишарпе и яве. Бенчмарки можно прямо на их же сайте и посмотреть. Почему-то ява и дотнет стабильно в 2.5 - 3 раза тормознее в этой задаче, несомненно критичной к скорости (либа позиционируется как чемпион по скорости). Наверное, рантайм проверки как раз и делают свое черное дело - подумал Штирлиц. Ну, алгоритм то реализуется одинаковый, блин?! И вообще, почему-то гуры от компрессии советуют начинающим, которые прутся с своими чудо-велосипедами на C# пойти выучить си++, если конечно те хотят чтобы их архивером кто-то еще и пользоваться бы стал хоть немного а параметры (время работы vs степень сжатия) стали бы сравнимы с архиваторами подобного типа. Это наверное вовсе не потому что разница в несколько раз появляется от простой замены сишарпа на си/си++, без изменения самого алгоритма. Ага... :)

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

275. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от paxuser (ok), 09-Мрт-11, 19:45

> Ну вон quicklz - одна и та же либа, при том авторами
> писаны реализации на сях, сишарпе и яве. Бенчмарки можно прямо на
> их же сайте и посмотреть. Почему-то ява и дотнет стабильно в
> 2.5 - 3 раза тормознее в этой задаче, несомненно критичной к
Значит и Ада сольёт в 3 раза. Тут к гадалке не ходи. В ней же строки тоже немутабельные, и рантайм-проверок(с)тм(r) полно.
> то реализуется одинаковый, блин?! И вообще, почему-то гуры от компрессии советуют
> начинающим, которые прутся с своими чудо-велосипедами на C# пойти выучить си++,
Советуют, да.
> если конечно те хотят чтобы их архивером кто-то еще и пользоваться
Почему-то, ага.
> бы стал хоть немного а параметры (время работы vs степень сжатия)
> стали бы сравнимы с архиваторами подобного типа. Это наверное вовсе не
> потому что разница в несколько раз появляется от простой замены сишарпа
> на си/си++, без изменения самого алгоритма. Ага... :)
Ну дык. Алсо, "язык программирования Ада" - сразу видно, что его делали мелкософт, оракл, RIAA, масоны и Гитлер. Будет тормозить, просить денег и зигу кидать, это ж очевидно.

Ответить | Правка | Наверх | Cообщить модератору

55. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от анон (?), 08-Мрт-11, 14:31

Кто вам мешает сделать
struct my_str {
    char *ptr;
    size_t len;
};
и писать надежно, безопасно, ънтерпрайзно(с)?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

78. "Взлом Linux через подключение USB-устройства стал реальность..." –4 +/–

Сообщение от Толстый (ok), 08-Мрт-11, 16:16

ты очень умный, только почему тогда никто этого не сделал, а вместо этого мы имеем целый зоопарк реализаций контейнеров?

Ответить | Правка | Наверх | Cообщить модератору

84. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от анон (?), 08-Мрт-11, 16:32

> ты очень умный, только почему тогда никто этого не сделал, а вместо
> этого мы имеем целый зоопарк реализаций контейнеров?
Это сделала например майкрофост в MFC да и много где еще.
Что значит "никто не сделал" и тут же "зоопарк реализаций"? Противоречишь сам себе.

Ответить | Правка | Наверх | Cообщить модератору

86. "Взлом Linux через подключение USB-устройства стал реальность..." –3 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 16:34

> Это сделала например майкрофост в MFC да и много где еще.
> Что значит "никто не сделал" и тут же "зоопарк реализаций"? Противоречишь сам
> себе.
Ура, он противоречит сам себе! Наличие проблемы заретушировано претензиями к оппонентам! Всё замечательно!

Ответить | Правка | Наверх | Cообщить модератору

242. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от Аноним (-), 09-Мрт-11, 14:16

> Ура, он противоречит сам себе! Наличие проблемы заретушировано претензиями к оппонентам! Всё замечательно!
Проблема у тебя в голове.

Ответить | Правка | Наверх | Cообщить модератору

85. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 16:33

> Кто вам мешает сделать
> struct my_str {
>     char *ptr;
>     size_t len;
> };
> и писать надежно, безопасно, ънтерпрайзно(с)?
Литерал этого типа в студию, для начала.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

87. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 16:34

> Литерал этого типа в студию, для начала.
Что еще за "литерал типа"?
В str указатель, в len длина строки, что непонятного?

Ответить | Правка | Наверх | Cообщить модератору

101. "Взлом Linux через подключение USB-устройства стал реальность..." –2 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 17:09

>> Литерал этого типа в студию, для начала.
> Что еще за "литерал типа"?
> В str указатель, в len длина строки, что непонятного?
С вами - всё предельно ясно.

Ответить | Правка | Наверх | Cообщить модератору

117. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 18:06

> С вами - всё предельно ясно.
Ок!

Ответить | Правка | Наверх | Cообщить модератору

125. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от gegMOPO4 (ok), 08-Мрт-11, 19:22

struct my_str s = { "abc", 3 };

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

128. "Взлом Linux через подключение USB-устройства стал реальность..." –2 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 19:36

> struct my_str s = { "abc", 3 };
Ну вот, вычисление длины строки "на глазок" и ошибка на единицу в простейшем примере. Браво.

Ответить | Правка | Наверх | Cообщить модератору

133. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от gegMOPO4 (ok), 08-Мрт-11, 19:52

Чтобы не морочить себе голову и не ошибиться, можно использовать простой макрос.
#define MY_STR(L) { L, sizeof(L)-1 }
struct my_str s = MY_STR("abc");

Ответить | Правка | Наверх | Cообщить модератору

136. "Взлом Linux через подключение USB-устройства стал реальность..." –2 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 20:06

> #define MY_STR(L) { L, sizeof(L)-1 }
> struct my_str s = MY_STR("abc");
Это феерический мрак. sizeof(L) вернёт количество элементов в массиве, включая терминирующий '\0'. У len тип size_t, и хранит он размер массива, а не индекс последнего элемента. Единицу зачем отнимаете?

Ответить | Правка | Наверх | Cообщить модератору

142. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от gegMOPO4 (ok), 08-Мрт-11, 20:28

Что вас удивляет? Что строковые литералы в Си неявно содержат терминирующий NUL? Что поэтому sizeof строкового литерала на 1 больше длины строки?

Ответить | Правка | Наверх | Cообщить модератору

149. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 20:37

> Что вас удивляет? Что строковые литералы в Си неявно содержат терминирующий NUL?
> Что поэтому sizeof строкового литерала на 1 больше длины строки?
Меня удивляет, что в ответ на замечание об ошибке на единицу вы написали эквивалентный по семантике макрос, а на тему "индекс последнего элемента vs. размер массива" начинаете "недоумевать" только сейчас.
Особенно это странно в колее разговора о strl-функциях, коим в size передаётся размер массива, включая '\0', в чём и заключается их главное отличие от strn-функций. И честно говоря, я уверен, что сейчас вы просто отмазываетесь, не желая признать за собой типичную ошибку.

Ответить | Правка | Наверх | Cообщить модератору

159. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от gegMOPO4 (ok), 08-Мрт-11, 20:54

Я написал, как избежать ошибки в подсчёте числа символов. Да, теперь я вижу в чём была ваша ошибка -- вы почему-то считаете, что длина строки на единицу больше количества символов, содержащихся в ней.
Функции strl* принимают размер буфера, который содержит строку и терминирующий NUL. Его размер должен быть по крайней мере на единицу больше предполагаемой длины строки.

Ответить | Правка | Наверх | Cообщить модератору

166. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 21:20

> Я написал, как избежать ошибки в подсчёте числа символов. Да, теперь я
Какой ошибки? Давайте по порядку.
Если следовать вашей логике, по которой в len показанного структурного типа должна записываться длина строки без учёта '\0', то мой комментарий, на который вы ответили, был ошибочен весь.
Если так, вы могли бы мне возразить, предположив, что автор структурного типа предлагает хранить в len именно длину строки. Но вы этого не сделали.
Вы предложили семантически эквивалентный макрос, который, по вашим словам, помог бы "избежать ошибки в подсчёте числа символов". То есть, прочитав мой комментарий, вы согласились с наличием ошибки в приведённом литерале... Которую теперь не считаете ошибкой?
Так была ли ошибка? Вот эта непоследовательность и склоняет меня к мысли, что вы просто юлите.
> вижу в чём была ваша ошибка -- вы почему-то считаете, что
> длина строки на единицу больше количества символов, содержащихся в ней.
Нет. Я считаю, что в len должен храниться размер массива символов, включая '\0', поскольку в операциях со значениями размеров строк без учёта '\0' чаще допускаются ошибки. И авторы strl-функций со мной согласны. К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты.
> Функции strl* принимают размер буфера, который содержит строку и терминирующий NUL. Его
> размер должен быть по крайней мере на единицу больше предполагаемой длины
> строки.
По-моему, теперь вы делаете вид, что терминирующий '\0' не является частью строки в Си: "строку и терминирующий NUL" - если это ваша изначальная точка зрения, то почему она такая противоречивая и идёт в разрез со стандартной терминологией?

Ответить | Правка | Наверх | Cообщить модератору

181. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от gegMOPO4 (ok), 08-Мрт-11, 22:39

Признаюсь, я неправильно понял ваш первый комментарий. Показалось, что вы намекаете на возможность ошибки в такой записи. То, что вы будет оспаривать, что длина строки из трёх символов равна трём, мне и в голову не пришло. Да, ваш комментарий ошибочен весь.
> Нет. Я считаю, что в len должен храниться размер массива символов, включая '\0', поскольку в операциях со значениями размеров строк без учёта '\0' чаще допускаются ошибки. И авторы strl-функций со мной согласны.
Это исключительно ваши личные убеждения. И авторы strl-функций с вами не согласны -- третий аргумент называется size, а не len. Не говоря уже о том, что ASCIIZ-строки к данному представлению вообще не имеют отношения.
> К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты.
Да, и поэтому при представлении строки как указателя на массив символов и длины он не нужен.
> По-моему, теперь вы делаете вид, что терминирующий '\0' не является частью строки в Си: "строку и терминирующий NUL" - если это ваша изначальная точка зрения, то почему она такая противоречивая и идёт в разрез со стандартной терминологией?
Да не является. NUL не часть строки в Си, а ограничивающий её символ. Моя точка зрения вполне последовательна и согласуется со стандартной терминологией, как Си, так и общекомпьютерной.

Ответить | Правка | Наверх | Cообщить модератору

196. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 23:43

> Признаюсь, я неправильно понял ваш первый комментарий. Показалось, что вы намекаете на
> возможность ошибки в такой записи. То, что вы будет оспаривать, что
> длина строки из трёх символов равна трём, мне и в голову
К чему эти абсурдные инсинуации? Вы прекрасно понимаете, что я имел ввиду. В len должен храниться размер массива символов с терминирующим '\0', точка.
> не пришло. Да, ваш комментарий ошибочен весь.
С вашей точки зрения. С моей, структурный строковый тип без нуль-терминации - ни с чем не совместимый нонсенс, который способствует ошибкам переполнения на единицу и создаёт неадекватные трудности при работе с библиотечными функциями, которые принимают нуль-терминированные строки.
> Это исключительно ваши личные убеждения. И авторы strl-функций с вами не согласны
> -- третий аргумент называется size, а не len. Не говоря уже
Они со мной "не согласны" только в названии аргумента, а вы просто юлите.
> о том, что ASCIIZ-строки к данному представлению вообще не имеют отношения.
К какому данному представлению? К структурному? В параллельном мире могут не иметь, а в реальном, если вы делаете свой, более безопасный строковый тип, потрудитесь обеспечить простоту его применения при работе с библиотеками. Жду возражений!
>> К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты.
> Да, и поэтому при представлении строки как указателя на массив символов и
> длины он не нужен.
Я хотел сказать, что реализовать строковый структурный тип, совместимый и с wide-кодировками, и с нуль-терминированными строками в Си практически невозможно. Но меня интересует другое.
Вы что, считаете, что структурный строковый тип не должен быть совместим с нуль-терминированными строками?
> Да не является. NUL не часть строки в Си, а ограничивающий её
> символ. Моя точка зрения вполне последовательна и согласуется со стандартной
Нулевой байт не является частью нуль-терминированной строки, я вас правильно понял?
> терминологией, как Си, так и общекомпьютерной.
Можете назвать источник такой терминологии, что-нибудь для примера?

Ответить | Правка | Наверх | Cообщить модератору

233. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от arturpub (ok), 09-Мрт-11, 11:14

В len обычно хранят длину строки, а размер массива обычно называют size. Для примера: strlen("abc") == 3, хотя sizeof("abc") == 4. Т.о. хоть нулевой символ и является частью строки, считается, что в ее длину он не входит. По-моему, именование len vs size вполне естественно и интуитивно понятно. Существуют и необычные случаи, но для меня очевидно, что предложенная структура подразумевает хранение ASCIIZ и ее длины в терминах strlen().

Ответить | Правка | К родителю #196 | Наверх | Cообщить модератору

256. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от коксюзер (?), 09-Мрт-11, 17:17

> В len обычно хранят длину строки, а размер массива обычно называют size.
> Для примера: strlen("abc") == 3, хотя sizeof("abc") == 4. Т.о. хоть
Вы мне ещё букварь почитайте по слогам, в едином дидактическом порыве.
> нулевой символ и является частью строки, считается, что в ее длину
> он не входит. По-моему, именование len vs size вполне естественно и
А по-моему, вполне естественно хранить не len, а size, независимо от его названия. Особенно, предлагая определение типа в контексте разговора о strl-функциях и проблеме со строками. Но я, кажется, понял, почему собеседники завели этот нелепый спор о совершенно вторичных названиях...
> интуитивно понятно. Существуют и необычные случаи, но для меня очевидно, что
> предложенная структура подразумевает хранение ASCIIZ и ее длины в терминах strlen().
И знаете, почему? Похоже, что безопасные строковые типы им в действительности не нужны. Почему не нужны - вопрос отдельный, но такое отношение позволяет им всерьёз рассуждать о структурном типе, не совместимом с ASCIIZ. И именно поэтому они выдвинули формальное решение, не удосужившись, похоже, даже представить, насколько оно жизнеспособно в реальном мире.
Вам очевидно, что структурный тип должен хранить указатель именно на ASCIIZ-строку? Замечательно! Хоть кому-то очевидно.

Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

286. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от arturpub (ok), 10-Мрт-11, 13:12

> Вы мне ещё букварь почитайте по слогам, в едином дидактическом порыве.
Вы просили пример, вот я и подумал, что созвучия разбудят вашу интуицию.
> И знаете, почему? Похоже, что безопасные строковые типы им в действительности не
> нужны. Почему не нужны - вопрос отдельный, но такое отношение позволяет
Ничего за них сказать не могу, может так, а может и эдак.
Лично я не приверженец си/++, но от сожалений о том что "все идиоты" никто мудрее не станет, и писать что-то на стандартных сях ни у кого необходимости не отпадет. Поэтому необходимо, так сказать, знать врага в лицо и разговаривать на его языке; вовремя не отличил сайз от лена -- попал на буфер-оверфло или еще на что-нибудь. По мне так вообще печально, что я вместо компилятора выбираю битовые паттерны для своих данных.

Ответить | Правка | К родителю #256 | Наверх | Cообщить модератору

290. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от paxuser (ok), 10-Мрт-11, 18:58

> Вы просили пример, вот я и подумал, что созвучия разбудят вашу интуицию.
Не просил. Мне всё равно, как называется атрибут, главное - что он хранит. В случае массивов size и length вообще синонимы.
> Лично я не приверженец си/++, но от сожалений о том что "все
> идиоты" никто мудрее не станет, и писать что-то на стандартных сях
Идиотами я никого не называл и не считаю. В банальных ошибках подозревал, но вариант с безразличием скорее всё расставил по местам.

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

299. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от arturpub (ok), 11-Мрт-11, 11:42

> Не просил. Мне всё равно, как называется атрибут, главное - что он
> хранит. В случае массивов size и length вообще синонимы.
Ну даете, блин.. )
зы: посоветуйте плиз что-нибудь из цикла "Ада за 3 дня не для тупых", я как-то брался, но тогда домашнего интернета в этой стране еще не было, а теперь времени не вагон.

Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

300. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от paxuser (ok), 11-Мрт-11, 12:08

> Ну даете, блин.. )
Я изначально говорил о размерах массивов, а не длинах строк. Умеющий читать, да учёл.
> зы: посоветуйте плиз что-нибудь из цикла "Ада за 3 дня не для
> тупых", я как-то брался, но тогда домашнего интернета в этой стране
> еще не было, а теперь времени не вагон.
По 2005-ой есть хороший викибук: http://en.wikibooks.org/wiki/Ada_Programming
Квадратные книги видел только по 95-ой, не проникся. Плюс RM не для тупых: http://www.adaic.org/resources/add_content/standards/05aarm/...

Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

301. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от arturpub (??), 11-Мрт-11, 17:07

> По 2005-ой есть хороший викибук: http://en.wikibooks.org/wiki/Ada_Programming
> Квадратные книги видел только по 95-ой, не проникся. Плюс RM не для
> тупых: http://www.adaic.org/resources/add_content/standards/05aarm/...
Сенкс, а то как раз пятница свободная выдалась.

Ответить | Правка | К родителю #300 | Наверх | Cообщить модератору

144. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от анон (?), 08-Мрт-11, 20:29

> Это феерический мрак. sizeof(L) вернёт количество элементов в массиве, включая терминирующий
> '\0'. У len тип size_t, и хранит он размер массива, а
> не индекс последнего элемента. Единицу зачем отнимаете?
Если у вас есть голова, попробуйте воспользоватся ей. Тогда, может, дойдет, что именно из-за \0 и отнимаем единицу. Т.к. в нем нет нужды раз уж мы указываем длину строки.
Если вы и так все знаете, к чему эти "покажите литералы" и т.п.? Хочецца посамоутверждаться?

Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

169. "Взлом Linux через подключение USB-устройства стал реальность..." –3 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 21:35

> Если у вас есть голова, попробуйте воспользоватся ей. Тогда, может, дойдет, что
> именно из-за \0 и отнимаем единицу. Т.к. в нем нет нужды
> раз уж мы указываем длину строки.
В литерале '\0' в конце строки есть, почему в len он учитываться не должен? И правильно ли я вас понял, вы предлагаете сделать структурный строковый тип несовместимым с нуль-терминированными строками, работая с размерами по образу и подобию strn-функций? Какой оригинальный и жизнеспособный замысел! Алсо, ваш литерал с подсчётом количества символов на глазок - это смех и слёзы. Хоть бы макрос предложили, как другой товарищ тут.
> Если вы и так все знаете, к чему эти "покажите литералы" и
> т.п.? Хочецца посамоутверждаться?
То есть, армия хамоватых ура-апологетов бездарного Си у меня не может вызывать иных эмоций, кроме желания самоутвердиться? Да вы по себе судите, неуважаемый.

Ответить | Правка | Наверх | Cообщить модератору

139. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 20:24

Есть тут ошибка или нет, можно сказать только взглянув на функции, работающие с этой структурой.

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

141. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от коксюзер (?), 08-Мрт-11, 20:26

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

Ответить | Правка | Наверх | Cообщить модератору

145. "Взлом Linux через подключение USB-устройства стал реальность..." +1 +/–

Сообщение от анон (?), 08-Мрт-11, 20:30

> Я ждал этой отмазки, но она не катит, поскольку собеседник отвечал на
> моё замечание об ошибке на единицу. Его макрос совершает ровно ту
> же ошибку.
Где там ошибка-то? Строка из 3 (трех!) элементов, нулл не нужен т.к. указываем непосредственно длину.

Ответить | Правка | Наверх | Cообщить модератору

243. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 09-Мрт-11, 14:23

>> Кто вам мешает сделать
>> struct my_str {
>>     char *ptr;
>>     size_t len;
>> };
>> и писать надежно, безопасно, ънтерпрайзно(с)?
> Литерал этого типа в студию, для начала.
my_str s = MY_STR("RTFM!");

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

59. "Взлом Linux через подключение USB-устройства стал реальность..." +5 +/–

Сообщение от СуперАноним (?), 08-Мрт-11, 14:48

>EPIC FAIL C/C++
Попроси разработчиков ядра FreeBSD, пусть они его на жабе перепишут :))

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

60. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Sw00p aka Jerom (?), 08-Мрт-11, 14:50

+1
чт оприкольно - они не хотят это изменять
мол какая разница проверку сделает программист или данная проверка уже будет в самой функции - ГОВНО ПОДЕЛИЕ - нету уже доверие всяким стандартным библиотекам

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

94. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от анон (?), 08-Мрт-11, 16:47

> чт оприкольно - они не хотят это изменять
> мол какая разница проверку сделает программист или данная проверка уже будет в
> самой функции - ГОВНО ПОДЕЛИЕ - нету уже доверие всяким стандартным
> библиотекам
Чем будет лучше, если библиотека проверит и обнаружит обращение за границы массива?
Да, по сегфолту не упадем, но ошибка может аукнутся в другом месте.

Ответить | Правка | Наверх | Cообщить модератору

102. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 17:10

> Да, по сегфолту не упадем, но ошибка может аукнутся в другом месте.
Действительно, ну чем DoS лучше полной компрометации? Да ничем.

Ответить | Правка | Наверх | Cообщить модератору

132. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от FFASM (?), 08-Мрт-11, 19:49

Вот почему OpenBSD написали ядро на C и особых проблем не ощущают? На мой взгляд действует прицнип: новичёк, руки кривые? Не лесь в C/C++.
Чем более низкоуровневый язык, тем больше он даёт свободы реализации алгоритма так, что бы он работал максимально быстро. К примеру на практически любом ассемблере есть множество инструкций, которые не имеют нормальных аналогов в C.
Короч если руки кривые, предоставь возможность компилятору/инторпритатору следить за тобой.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

135. "Взлом Linux через подключение USB-устройства стал реальность..." –1 +/–

Сообщение от klalafuda (?), 08-Мрт-11, 19:55

> Вот почему OpenBSD написали ядро на C и особых проблем не ощущают?
Джо ты? Тебя так до сих пор и не поймали?

Ответить | Правка | Наверх | Cообщить модератору

213. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от User294 (ok), 09-Мрт-11, 05:00

> Джо ты? Тебя так до сих пор и не поймали?
Напишите востребованную ОС с непозорными параметрами на чем-то еще, фигле. Кто-то не дает?

Ответить | Правка | Наверх | Cообщить модератору

245. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от klalafuda (?), 09-Мрт-11, 15:05

> Напишите востребованную ОС с непозорными параметрами на чем-то еще, фигле. Кто-то не дает?
Зачем? Мне и линуксы вполне хватает.

Ответить | Правка | Наверх | Cообщить модератору

140. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 08-Мрт-11, 20:24

> Вот почему OpenBSD написали ядро на C и особых проблем не ощущают?
http://openbsd.org/images/hackathons/c2k10.gif
> На мой взгляд действует прицнип: новичёк, руки кривые? Не лесь в
> C/C++.
Это пройдёт.
> Чем более низкоуровневый язык, тем больше он даёт свободы реализации алгоритма так,
> что бы он работал максимально быстро. К примеру на практически любом
> ассемблере есть множество инструкций, которые не имеют нормальных аналогов в C.
Скорость - не единственное требование к программам. К тому же, не все классы оптимизаций доступны компиляторам С/С++, дающим на выходе код с традиционным рантаймом. Например: http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-c...
> Короч если руки кривые, предоставь возможность компилятору/инторпритатору следить за
> тобой.
И много вы знаете совершенных людей с абсолютно прямыми руками, которые никогда не ошибаются?

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

185. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 08-Мрт-11, 22:50

> классы оптимизаций доступны компиляторам С/С++, дающим на выходе код с традиционным
> рантаймом.
Да, да, да. JIT в теории может, блабла. На практике - а хрен там. Вот когда ядра, библиотеки и все остальное критичное к скорости будут писать на питонах, явах и прочих мегатормозилах - тогда и приходите.

Ответить | Правка | Наверх | Cообщить модератору

203. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 09-Мрт-11, 02:13

> Скорость - не единственное требование к программам.
Почему микроядро еще не везде где можно?
Почему ядра ОС, игры с графикой, рендеры, матсофт и т.п. не пишут на безопасных языках? (маргинальных примеров не надо)

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

208. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от коксюзер (?), 09-Мрт-11, 03:08

>> Скорость - не единственное требование к программам.
> Почему микроядро еще не везде где можно?
> Почему ядра ОС, игры с графикой, рендеры, матсофт и т.п. не пишут
> на безопасных языках? (маргинальных примеров не надо)
А кто из крупных игроков на рынке стоит за этими микроядрами, безопасными языками, кто тратит ресурсы на создание и развитие инфраструктуры? Никто. А ядра ОС на безопасных языках пишут.

Ответить | Правка | Наверх | Cообщить модератору

214. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от User294 (ok), 09-Мрт-11, 05:12

> А кто из крупных игроков на рынке стоит за этими микроядрами,
Крупные игроки приходят когда видят что получилась нужная штука, лучше других, т.е. пахнет профитом. У микроядер своих проблем хватает и потому они остались нишевой штукой, а практически жизнеспособные системы почему-то сплошь и рядом монолиты да гибриды.
> безопасными языками,
Ну да, майкрософт и оракль - незначительные конторки с их явами и дотнетами. Мелочевка.
> кто тратит ресурсы на создание и развитие инфраструктуры? Никто.
Ну так тратьте. Линух вон сперва вылез из грязи в князи, а потом крупные игроки пришли. А вы хотите чтобы за вас кто-то что-то делал. А оно этим кому-то надо - делать то что надо ВАМ а не ИМ? :)
> А ядра ОС на безопасных языках пишут.
Да, а еще 100500 лет про микроядра орали, да толку то?

Ответить | Правка | Наверх | Cообщить модератору

218. "Взлом Linux через подключение USB-устройства стал реальность..." +2 +/–

Сообщение от коксюзер (?), 09-Мрт-11, 05:58

> Крупные игроки приходят когда видят что получилась нужная штука, лучше других, т.е.
> пахнет профитом. У микроядер своих проблем хватает и потому они остались
> нишевой штукой, а практически жизнеспособные системы почему-то сплошь и рядом монолиты
> да гибриды.
Ага, это даже доказательства не требует. Оно же очевидно.
>> безопасными языками,
> Ну да, майкрософт и оракль - незначительные конторки с их явами и
> дотнетами. Мелочевка.
Ну да, тред можно не читать, главное - к знакомы словами прицепиться и ляпнуть что-нибудь.
>> кто тратит ресурсы на создание и развитие инфраструктуры? Никто.
> Ну так тратьте. Линух вон сперва вылез из грязи в князи, а
Ну так трачу, представьте себе.
> потом крупные игроки пришли. А вы хотите чтобы за вас кто-то
Да, хочу.
> что-то делал. А оно этим кому-то надо - делать то что
> надо ВАМ а не ИМ? :)
Больше капса, больше смайликов, вы не стесняйтесь. Главное ведь - забыть, что я отвечал на чужой вопрос, а не в жилетку плакался.
>> А ядра ОС на безопасных языках пишут.
> Да, а еще 100500 лет про микроядра орали, да толку то?
Дофига толку. Самолёты на них работают, ракеты, космические корабли, судоходство и прочая промышленность, телекомы. Но это всё х#ита, конечно же. На ведь писюках нет? Нет. Ну и слив защитан мне, да.
P.S.
И кагбе можно даже не замечать, что за микроядра я не агитировал. Не это ведь в троллинге главное, ага.

Ответить | Правка | Наверх | Cообщить модератору

253. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от User294 (ok), 09-Мрт-11, 16:58

> Ага, это даже доказательства не требует. Оно же очевидно.
Хорошо, ну так крупные игроки добровольно  (!!!) выбрали то что им пришлось по вкусу. А вы, собссно, кто чтобы с кого-то что-то требовать с нахрапом? Если вы полагаете что сможете лучше - докажите делом, тогда, может быть, и остальные подтянутся. Если, конечно, их понятия о "лучше" совпадут с вашими (что совсем не факт, но шансы есть). А если вы будете указывать другим как и что им следует делать - они как максимум не очень вежливо оббъяснят вам куда вам следует пройти.
> Ну да, тред можно не читать,
Да вы тут гранд-мастеры троллинга :) надо ж столько флуда вывалить из-за одной тупой уязвимости в драйвере, которая эксплуатируется путем вырезания гланд через жопу автогеном, пардон. Но ведь реальная опасность дыры ("наиболее элитные перцы с наклонностями шпионов может и поимеют десяток-другой локалхостов") - это ж не важно, да? Главное поистекать говном какой плохой си, какие пи...сы на нем пишут столь парашные операционки и прочая. Я вижу ровно 1 проблему: вы забыли предложить миру вашу операционку, лучше. Без сей и пи...сов, зато с шахматами и поэтессами. Поэтому все как лохи и лузеры пользуются тем что есть и работает. Достаточно неплохо работает. Не идеально, но свои задачи выполняет. А идеального софта почему-то вообще не бывает :)
> главное - к знакомы словами прицепиться и ляпнуть что-нибудь.
А эти слова случайно были не "си", "Linux" и "уязвимость"? Ну или какого тут поднялся такой многостраничный троллинг? :)
> Ну так трачу, представьте себе.
Я рад за вас, все дела. Вам надо - вы и упираетесь, все честно. А в лично моем понимании, надежная система должна быть прежде всего простой как топор. Товарисч D. J. Berstein вон делом доказал что на си можно написать надежную программу. Кстати его понятия о надежности вообще не привязаны к языку - он вообще рассмотрел надежность программ, причины багов (в частности, проблем секурити) и как можно минимизировать оные. Почему-то ему си при этом нифига не помешал. В этом плане современное железо с даташитами на сотни страниц а то и больше - оставляет желать лучшего, вообще-то. В нем тоже багов - есть.
>> потом крупные игроки пришли. А вы хотите чтобы за вас кто-то
> Да, хочу.
Хотеть не запретишь. Хотите себе. Имхо долго и не факт что успешно будете хотеть.
> я отвечал на чужой вопрос, а не в жилетку плакался.
А по стилю больше похоже на плач несмеяны. Добро пожаловать в реальный мир, мир акул бизнеса, костылей и подпорок. Простите пожалуйста что ваши кульные теоретические концепты которые где-то там в теории могли бы хорошо делать что-то, тут никому нафиг не нужны, никто за это не платит и прочая. Как максимум тут вы можете рассчитывать на ваш энтузазизм, голову и пару рук. Если сильно повезет - может сумеете сколотить команду единомышленников, а один из миллиона через ...цать лет может даже и найдет инвестора который купится на красивые спичи. Но это не гарантировано, а кроме того, акул-инвесторов не интересуют все эти ваши концепции, их интересуют конкретные результаты, которые профит приносят. А как оно там внутри сделано - им вообще насрать, вы прикиньте? :). И горе вам если вы сорвете сроки, не сможете сделать то что обещали и прочая - вазелина понадобится много.
> Дофига толку. Самолёты на них работают,
А конкретные модели самолетов - осилите? А то я читал как у какого-то из боингов сделано - там ни про какие микроядра почему-то ни звука. Зато звуки про резервирование, юзание 2 разных архитектур процессоров, реализацию 1 и того же алгоритма 2-я разными командами програмеров, на 2 разных языках + сравнение результата вычислений обоих компьютеров, етц, етц. Ну в общем чтобы не могла возникнуть ситуация когда оба компьютера словят синхронно один и тот же баг и он останется не замечен, возможно с достаточно неприятными последствиями. Вот это я понимаю - чуваки настроены на то чтобы баги не пролезли + автоматическое обнаружение оных. Я также в курсе систем которые голосуют на уровне железа по принципу "2 из 3" например, так что бажный модуль может быть вычислен.
> ракеты, космические корабли,
Почему-то в них обычно стараются применять довольно примитивные процессоры. Наверное потому что радиация и все такое, а чем сложнее проц - тем он нежнее к таким вещам и более склонен к сбоям, в нем более вероятны ошибки и прочая (никогда не пробовала почитать Errata на современные процы? Там жесткач полнейший, только его видят сильно некоторые :D). А на простом проце - обычно крутится нечто сильно кастомное, под задачу. У простого проца пардон даже системы деления привилегий может не быть. Ну и накукуй там микроядра? Там обычно простая как топор фирмварина которая выверена до битика и делает свою задачу.
> судоходство и прочая промышленность, телекомы.
Ой, почему-то в реально критичных к отказу местах стоят простые чипы, быстро реагирующие на события, а желательно и вообще аппаратные защиты, т.к. софт и 100% надежность - очень трудносовместимые понятия. Простые - потому что чем сложнее чип, тем он глючнее, менее предсказуем, в нем больше багов (да, в чипах тоже бывают баги, google://Errata если что). У простого чипа - и фирмварина простая как топор. Собссно микроядро - всего лишь выносит сложность из ядра в другие куски системы, а в целом сложность системы особо не падает. Как максимум можно собрать простую систему которая ничерта не умеет. Только что с ней потом делать на серверах и прочая? Ну, я знаю ровно 1 применение на серверах и десктопах: назвать это гипервизором и изолировать друг от друга более сложные ОС. Но сложность систем никуда не девается и баги остаются, ессно, просто они изолированы и локализованы :)
> Но это всё х#ита, конечно же. На ведь писюках нет?
А знаете, если вы въе в стену на вашем авто и надо срочно вам подушку безопасности надуть, чтоб вы не выпорхнули в стекло и не размазались по стене - почему-то надувать ее, спасая вашу жо, будет в общем случае примитивный проц-"таракан" с датчиком и с не менее примитивной фирмвариной, чуть ли не единственной целью существования которого является именно это действо. И фирмварина примитивна и вылизана до битика, потому что если юзер вылетит в лобовое стекло - как-то нехорошо получится, да? А отсуствие многозадачности намекает на то что не надо ни защищаться от остальных задач, ни делить с ними время. Сложность системы падает в десятки раз. Вот тогда уже начинает идти разговор о какой-то там надежности решений, частью которых является софт. А пишут этот софт почему-то на асме и сях. Таких небезопасных, пля...
> Нет. Ну и слив защитан мне, да.
Слив вам засчитан за то что существует например уйма мелких процов в критичных к отказу местах ... запрограмленых на этих самых жутко небезопасных сях и асме. При том баги в фирмваре оных - скорее исключение чем правило. Потому что цена ошибки - соответствующая, и делается все возможное чтобы ошибок просто не было. Потому что внезапное надувание подушки без причины - как минимум очень неприятный сюрприз с риском для здоровья, а профукивание момента когда ее надо надуть - и вовсе может означать что юзер просто сыграет в ящик.
> P.S.
> И кагбе можно даже не замечать, что за микроядра я не агитировал.
Угу, вы в основном просто набрасывали на вентилятор что линуксы - говно, си - отстой, только все это очень напоминает анекдот про цирк и "все клоуны - пи..сы!" :)
> Не это ведь в троллинге главное, ага.
Да уж! Так, глядя сколько тут натроллили из-за уязвимости которую можно поюзать только с спецжелезкой при физическом доступе к компу. Не, мне правда интересно, хотя-бы сотню компов на планете за следующие пару месяцев так сломают? :)

Ответить | Правка | Наверх | Cообщить модератору

284. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от paxuser (ok), 10-Мрт-11, 02:56

Ооо, какая знатная простыня! И как же я тебя пропустил, дорогая... Сейчас накатаю ответную.
>> Ага, это даже доказательства не требует. Оно же очевидно.
> Хорошо, ну так крупные игроки добровольно  (!!!) выбрали то что им
> пришлось по вкусу. А вы, собссно, кто чтобы с кого-то что-то
> требовать с нахрапом? Если вы полагаете что сможете лучше - докажите
А я с кого-то что-то требую? :) Нет. Но я догадываюсь, откуда растут ноги у таких упрёков: когда напоминаешь людям о недостатках их выбора/результатов работы/предмете обожания, они ищут хоть какой-то повод дать ответ по системе "сперва добейся" и "с чего вы взяли, что вам кто-то что-то обязан?". ;)
Алсо, не хотите обосновывать, так и говорите. ;)
> делом, тогда, может быть, и остальные подтянутся. Если, конечно, их понятия
> о "лучше" совпадут с вашими (что совсем не факт, но шансы
"Сперва добейся, потом критикуй!" (ц) ;)
> есть). А если вы будете указывать другим как и что им
> следует делать - они как максимум не очень вежливо оббъяснят вам
> куда вам следует пройти.
О, да! К "другим" даже с готовыми патчами обращаться - дело неблагодарное в большинстве случаев. Ибо политика + нежелание брать на себя труд по изучению и сопровождению кода "ради какой-то там безопасности". ;)
> Да вы тут гранд-мастеры троллинга :) надо ж столько флуда вывалить из-за
Дык! ;)
> одной тупой уязвимости в драйвере, которая эксплуатируется путем вырезания гланд через
> жопу автогеном, пардон. Но ведь реальная опасность дыры ("наиболее элитные перцы
> с наклонностями шпионов может и поимеют десяток-другой локалхостов") - это ж
> не важно, да? Главное поистекать говном какой плохой си, какие пи...сы
Конечно, не важно. Троллинг начался с поста iZEN про C/C++, а новость - кого она волнует вообще? :D
> на нем пишут столь парашные операционки и прочая. Я вижу ровно
> 1 проблему: вы забыли предложить миру вашу операционку, лучше. Без сей
Я над этим работаю. ;)
> и пи...сов, зато с шахматами и поэтессами. Поэтому все как лохи
> и лузеры пользуются тем что есть и работает. Достаточно неплохо работает.
Собственно, операционки лучше уже предложил и Вирт сотоварищи, и папы юникса, но воз и ныне там. Ибо The Old Stuff Is Just Good Enough.
> Не идеально, но свои задачи выполняет. А идеального софта почему-то вообще
> не бывает :)
Потому что гладиолус же.
>> главное - к знакомы словами прицепиться и ляпнуть что-нибудь.
> А эти слова случайно были не "си", "Linux" и "уязвимость"? Ну или
> какого тут поднялся такой многостраничный троллинг? :)
Вот я и говорю: слова знакомые. ;)
>> Ну так трачу, представьте себе.
> Я рад за вас, все дела. Вам надо - вы и упираетесь,
> все честно. А в лично моем понимании, надежная система должна быть
> прежде всего простой как топор. Товарисч D. J. Berstein вон делом
> доказал что на си можно написать надежную программу. Кстати его понятия
Да что ви говорите? "Надёжные программы" товарища Бернштейна даже TLS/SSL благоразумно не реализуют самостоятельно, отдавая на откуп внешним библиотекам. И правильно. Ибо когда весь из себя изолированный процесс ломают через дыру в OpenSSL и крадут приватный ключ, вся TLS плавно накрывается медным тазом, позволяя взломщикам тихо-мирно вклиниться в канал где-нибудь между сервером и клиентом, утянуть реквизиты через MitM и получить доступ к ящикам жертв без более глубокой компрометации системы. Товарищу Сирайнену тот же упрёк, в т.ч. по части недосказанности.
Вспомним также, что модель безопасности программ товарисча Бернштейна построена на разделении привилегий, которое "гарантированы" чем? Ничем, кроме дырявых монолитных вёдер современных ОС - тех самых, которые "достаточно неплохо работают". Компрометация любого из непривилегированных процессов (товарищ Гунинский вам напомнит об одной из таких возможностей, имевшихся ранее) открывает возможность к относительно незатратной компрометации всей системы. Но в изъянах ядра ОС товарисч Бернштейн, конечно же, не виноват. Он всего лишь сделал несколько наивных допущений при проектировании своих систем, о которых совершенно случайно забыл предупредить ещё более наивную публику. ;)
Хотите ещё об этом поговорить? ;)
> о надежности вообще не привязаны к языку - он вообще рассмотрел
> надежность программ, причины багов (в частности, проблем секурити) и как можно
> минимизировать оные. Почему-то ему си при этом нифига не помешал. В
Ага, совсем не помешал. Кстати, на ассемблере и тем более на фортране можно писать такие системы, и ни один из языков - подумать только! - ни разу тому не помешает. ;) О КПД вопрос отдельный. Кстати, вы лично задумывались над ответом на него? ;)
> этом плане современное железо с даташитами на сотни страниц а то
> и больше - оставляет желать лучшего, вообще-то. В нем тоже багов
> - есть.
Причём, баги в основном в части управления памятью и привилегиями. Но мы не будем показывать пальцем на человека, надёжность архитектурных решений которого, скажем так, не вполне зашкаливает в свете потенциального наличия таких багов (хотя это был Бернштейн). ;)
>>> потом крупные игроки пришли. А вы хотите чтобы за вас кто-то
>> Да, хочу.
> Хотеть не запретишь. Хотите себе. Имхо долго и не факт что успешно
> будете хотеть.
Вредно не хотеть, я бы сказал.
>> я отвечал на чужой вопрос, а не в жилетку плакался.
> А по стилю больше похоже на плач несмеяны. Добро пожаловать в реальный
> мир, мир акул бизнеса, костылей и подпорок. Простите пожалуйста что ваши
Ой, я-то думал, в сказку попал! :D
> кульные теоретические концепты которые где-то там в теории могли бы хорошо
http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html - где-то там. В теории, ага.
- делать что-то, тут никому нафиг не нужны, никто за это не
+ делать что-то, тут хомячкам нафиг не нужны, и они за это не
Fixed. ;)
> энтузазизм, голову и пару рук. Если сильно повезет - может сумеете
> сколотить команду единомышленников, а один из миллиона через ...цать лет может
> даже и найдет инвестора который купится на красивые спичи. Но это
Всё это происходит, вы просто не в курсе.
> не гарантировано, а кроме того, акул-инвесторов не интересуют все эти ваши
> концепции, их интересуют конкретные результаты, которые профит приносят. А как оно
Венчурного инвестирования не существует, я вас правильно понял? :)
> там внутри сделано - им вообще насрать, вы прикиньте? :). И
Насрать хомячкам. Инвесторов, как вы сказали, интересуют результаты. И бизнес-планы по их достижению тоже, как ни странно.
> горе вам если вы сорвете сроки, не сможете сделать то что
> обещали и прочая - вазелина понадобится много.
Вы путаете кредитование и инвестирование. Но вообще, посыл понятен и не нов. ;)
>> Дофига толку. Самолёты на них работают,
> А конкретные модели самолетов - осилите? А то я читал как у
> какого-то из боингов сделано - там ни про какие микроядра почему-то
> ни звука. Зато звуки про резервирование, юзание 2 разных архитектур процессоров,
http://archive.adaic.com/projects/atwork/boeing.html - там на Аде всё. ;)
>> ракеты, космические корабли,
> Почему-то в них обычно стараются применять довольно примитивные процессоры. Наверное потому
Расскажите это создателям марсохода Spirit, большая часть софта которого на джаве написана. ;) Вот где она тормозит-то зверски, должно быть! :)
> что радиация и все такое, а чем сложнее проц - тем
> он нежнее к таким вещам и более склонен к сбоям, в
> нем более вероятны ошибки и прочая (никогда не пробовала почитать Errata
> на современные процы? Там жесткач полнейший, только его видят сильно некоторые
> :D). А на простом проце - обычно крутится нечто сильно кастомное,
> под задачу. У простого проца пардон даже системы деления привилегий может
> не быть. Ну и накукуй там микроядра? Там обычно простая как
> топор фирмварина которая выверена до битика и делает свою задачу.
http://kronos.ru/about/koltashev - даже в СССР 80-ых годов софт для космоса писали на модуле. :Р Ну и расскажите теперь, как выверенные битики бороздят просторы бортовой электроники. ;)
>> судоходство и прочая промышленность, телекомы.
> Ой, почему-то в реально критичных к отказу местах стоят простые чипы, быстро
> реагирующие на события, а желательно и вообще аппаратные защиты, т.к. софт
В реально критичных к отказу и _сложных_ системах стоят вполне себе процессоры общего назначения на пару с этими вашими ПЛИС, и работает это на каком-нибудь эрланге. Гуглите Ericsson AXD-301 для примера. Та же циска давно ставит ОС на базе QNX6 (микроядро, которое медленное и никому не нужное) на свои старшие модели.
Короче, слив защитан. :Р
> и 100% надежность - очень трудносовместимые понятия. Простые - потому что
А вы не путайте надёжность и отказоустойчивость, и всё встанет на свои места.
> чем сложнее чип, тем он глючнее, менее предсказуем, в нем больше
> багов (да, в чипах тоже бывают баги, google://Errata если что). У
Например, некоторые надёжные чипы описывают на Haskell'е, с формальным доказательством соответствия спецификации и последующей трансляцией в императивные HDL. Но вы, кажется,  рассказывали о процессорах для хомячков и ынтерпрайза... Я вас слушаю. :)
> простого чипа - и фирмварина простая как топор. Собссно микроядро -
> всего лишь выносит сложность из ядра в другие куски системы, а
> в целом сложность системы особо не падает. Как максимум можно собрать
Ложь и провокация. ;) Возрастает отказоустойчивость - раз. Радикально уменьшается количество блокировок и разделяемых данных, и, как следствие, сложность - два.
> простую систему которая ничерта не умеет. Только что с ней потом
> делать на серверах и прочая? Ну, я знаю ровно 1 применение
Вы загнали меня в тупик!!!1 Что же делать???7777
> на серверах и десктопах: назвать это гипервизором и изолировать друг от
> друга более сложные ОС. Но сложность систем никуда не девается и
Блокировки и разделяемые данные - они никуда не деваются? Или деваются они, но не сложность? Я вас правильно понял? ;)
> баги остаются, ессно, просто они изолированы и локализованы :)
Баги остаются там, где остаётся Си. Та же Ада позволяет радикально сократить их количество практически даром. И "просто" изолированы и локализованы, ага.
>> Но это всё х#ита, конечно же. На ведь писюках нет?
> А знаете, если вы въе в стену на вашем авто и надо
> срочно вам подушку безопасности надуть, чтоб вы не выпорхнули в стекло
> и не размазались по стене - почему-то надувать ее, спасая вашу
> жо, будет в общем случае примитивный проц-"таракан" с датчиком и с
Ну так это потому, что надувалке многоядерный суперскаляр вообще никуда не фпилсо.
> не менее примитивной фирмвариной, чуть ли не единственной целью существования которого
> является именно это действо. И фирмварина примитивна и вылизана до битика,
Да-да, вылизанные битики. ;)
> потому что если юзер вылетит в лобовое стекло - как-то нехорошо
> получится, да? А отсуствие многозадачности намекает на то что не надо
> ни защищаться от остальных задач, ни делить с ними время. Сложность
А какие там остальные задачи? Музыку играет и в похоронное бюро звонит? :D
> системы падает в десятки раз. Вот тогда уже начинает идти разговор
> о какой-то там надежности решений, частью которых является софт. А пишут
> этот софт почему-то на асме и сях. Таких небезопасных, пля...
Да-да, и в боингах, и в спутниках - один сплошной Си. ;)
>> Нет. Ну и слив защитан мне, да.
> Слив вам засчитан за то что существует например уйма мелких процов в
> критичных к отказу местах ... запрограмленых на этих самых жутко небезопасных
> сях и асме. При том баги в фирмваре оных - скорее
Тут кагбе выяснилось, что слив засчитан вам за Боинг и космос как минимум. ;)
> исключение чем правило. Потому что цена ошибки - соответствующая, и делается
> все возможное чтобы ошибок просто не было. Потому что внезапное надувание
> подушки без причины - как минимум очень неприятный сюрприз с риском
> для здоровья, а профукивание момента когда ее надо надуть - и
> вовсе может означать что юзер просто сыграет в ящик.
Вы так превозносите надёжность и значимость элементарных программулек на Си. Идите в отдел пропаганды едра, им нужны таланты. :) Алсо, там ПЛИСы и ASICи, а ваш Си и рядом не лежал. :Р
> Угу, вы в основном просто набрасывали на вентилятор что линуксы - говно,
> си - отстой, только все это очень напоминает анекдот про цирк
> и "все клоуны - пи..сы!" :)
Вы тоже нонанабрасывали. Только я обосновал, а вы - нет. :D
>> Не это ведь в троллинге главное, ага.
> Да уж! Так, глядя сколько тут натроллили из-за уязвимости которую можно поюзать
> только с спецжелезкой при физическом доступе к компу. Не, мне правда
> интересно, хотя-бы сотню компов на планете за следующие пару месяцев так
> сломают? :)
Да-да, именно из-за этой уязвимости. Других нет. ;)

Ответить | Правка | Наверх | Cообщить модератору

184. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 08-Мрт-11, 22:47

> EPIC FAIL C/C++.
Имейте совесть! В вашей яве дыры безопасности чинят ДЕСЯТКАМИ в каждом релизе. Сначала перепишите вашу яву на ней самой а потом будете набрасывать. А то пилить сук на котором сидишь - это типичная изеновщина!

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

254. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от iZEN (ok), 09-Мрт-11, 17:04

>> EPIC FAIL C/C++.
> Имейте совесть! В вашей яве дыры безопасности чинят ДЕСЯТКАМИ в каждом релизе.
Пруф или не было!
> Сначала перепишите вашу яву на ней самой а потом будете набрасывать.
The Maxine Virtual Machine Project: http://labs.oracle.com/projects/maxine/
> А то пилить сук на котором сидишь - это типичная изеновщина!
Чегоооо?

Ответить | Правка | Наверх | Cообщить модератору

255. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Andrey Mitrofanov (?), 09-Мрт-11, 17:12

>>> EPIC FAIL C/C++.
>> А то пилить сук на котором сидишь - это типичная изеновщина!
> Чегоооо?
Он конечно же имел в виду, что ты ещё не дописал корректнес-прувер Си[++]-кода на своём Джавве, не доказал _его корректность и не прочекал свои обозаемые бизди коре^Wбеиз систем и джавве веэм.
Ваш К.О.

Ответить | Правка | Наверх | Cообщить модератору

232. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Аноним (-), 09-Мрт-11, 11:01

Ждём от тебя ОС на паскакале, а также компилятор умеющий все те же платформы и оптимизации что и хотя бы gcc.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

282. "Взлом Linux через подключение USB-устройства стал реальность..." +/–

Сообщение от Алексей (??), 10-Мрт-11, 00:54

Согласен. А Java не подходит для написания ядра операционных систем.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Взлом Linux через подключение USB-устройства стал реальность..."	–27 +/–
Сообщение от iZEN (ok), 08-Мрт-11, 11:54
Ещё одно доказательство того, что строки неизвестной длины с завершающим нулём в качестве признака конца данных этого типа данных, никуда не годятся — паскалевский тип строки с указанием точной длины в заголовке безопасный и предсказуемый. EPIC FAIL C/C++.
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Взлом Linux через подключение USB-устройства стал реальность..."	+11 +/–
	Сообщение от klalafuda (?), 08-Мрт-11, 11:58
	Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от follow_me (?), 08-Мрт-11, 14:56
	И в Java нет , и что с того ? Недавно оба засветились с переполнениями базовых типов. Нет совершенных систем, ошибки можно найти везде. А по поводу топика - не более чем локальная уязвимость с повышением привилегий, только тяжелее в реализации по сравнению с прочими уязвимостями такого рода
	Ответить \| Правка \| Наверх \| Cообщить модератору


	130. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от FastDuck (?), 08-Мрт-11, 19:45
	> И в Java нет , и что с того ? Недавно оба засветились с переполнениями базовых типов. Нет совершенных систем, ошибки можно найти везде. Вы про баг с плавающей запятой? Переполнения нашли в реализации интерпретатора PHP, а не в пользовательских приложениях как в этом случае. К тому же, код интерпретатора PHP написан C. Вообще, в случае Java/PHP и им подобных достаточно исправить переполнение в сам компиляторе/интерпретаторе, в случае C вся ответственность ложиться на плечи разработчиков приложений. Панацеи пока нет, а хотелось бы - лично я вижу решение в мощном безопасном рантайме (минимиизирует ошибки на низком уровне) и мощной системе типов (минимизирует ошибки на всех уровнях).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	175. "Взлом Linux через подключение USB-устройства стал реальность..."	+5 +/–
	Сообщение от MiG (?), 08-Мрт-11, 22:07
	C/C++ изначально создавались как языки сочетающие в себе высокий уровень программирования и низкоуровневую эффективность. Ответственность за содеянное лежит на программисте. Хочешь быстро ехать - отключай ABS, ESP, traction control и пр.. Новичок разобъётся, профессионал даст нужный результат. В конце концов если молотком ударил по пальцу, то виноват не инструмент. ;-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	201. "Взлом Linux через подключение USB-устройства стал реальность..."	–2 +/–
	Сообщение от anonymous vulgaris (?), 09-Мрт-11, 01:21
	> C/C++ изначально создавались как языки сочетающие в себе высокий уровень программирования и низкоуровневую эффективность. Я понимаю что историю сейчас знать ни к чему, но вообще то C лепился кое-как чтоб было хоть чуть получше ассемблера. Ну и чтоб можно было работать на компе с 8 кБ ОЗУ (отсюда и так называемый лаконичный синтаксис). Ну а C++ лепился кое-как чтоб было чуть получше С.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	64. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от Аноним123321 (ok), 08-Мрт-11, 15:01
	> Ну а в PHP даже указателей нет. но при этом в PHP забыли сделать слабые ссылоки (weak ref)... о боже -- этоже ЛОЛ:-D таким образом PHP обречён на _цыклические_ ссылочные _сильные_ связи :-) :-) :-) [что совершенно не важно если приложение не должно жить более чем пару десятков милисекунд. поэтому всем php-web-программистом пофиг на отсутствие weak refs :-), а вот написать долгоиграющщую не-web-программу уже не получится :-)]
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	121. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от rshadow (?), 08-Мрт-11, 18:41
	Языки из разных категорий. Сравнивать их может только новичек в программировании =)
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	237. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от Аноним (-), 09-Мрт-11, 12:20
	Кто такие новичеки?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	193. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от Аноним (-), 08-Мрт-11, 23:30
	>Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю.. Оберон - наше всё!
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	287. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от cobold (ok), 10-Мрт-11, 13:28
	> Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю.. Это Вам наверное в PHP порушенные поинтеры не встречались, а мне как-то довелось с ними пободаться - когда по ходу встроенной функции по какой-то причине генерируется warning, изза этого переаллоцируется стек, а локальные переменные уже хранят указатели на прошлый stack frame. Вот результаты скрипта потом весело выглядят :) Да, в 5.3 это исправили.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	9. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от доброжелатель (?), 08-Мрт-11, 12:11
	Ок, для успешной индексации строк с over 2 млрд. символов всегда надо будет хранить лишних 4 байта, для любой строки, удачи !
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	11. "Взлом Linux через подключение USB-устройства стал реальность..."	–3 +/–
	Сообщение от Аноним (-), 08-Мрт-11, 12:18
	> Ок, для успешной индексации строк с over 2 млрд. символов всегда надо > будет хранить лишних 4 байта, для любой строки, удачи ! да хоть 8 байт, хоть 32-а, это один фиг лучше, чем рут полученный через переполнение.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от Аноним (-), 08-Мрт-11, 12:22
	Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один байт это нормально?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от iZEN (ok), 08-Мрт-11, 12:40
	Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы кодирования длины произвольной последовательности. И лучше, чтобы оно всё-таки было в заголовке данных, а не в конце в виде завершающего нуля, чтобы ядро не занималось счётом байтов и динамическим перевыделением памяти под неизвестное число байтов, пока не будет считан последний байт строки, а заранее знало, сможет оно вместить всю строку в доступную память или нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от Аноним (-), 08-Мрт-11, 13:15
	> есть алгоритмы кодирования длины произвольной последовательности. Это дополнительная сложность и время. Спорный оверхед, в общем. Может где-то и нужно, в большинстве применений - нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	192. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от Аноним (-), 08-Мрт-11, 23:17
	>> есть алгоритмы кодирования длины произвольной последовательности. > Это дополнительная сложность и время. Спорный оверхед, в общем. Может где-то и > нужно, в большинстве применений - нет. а перераспределение памяти и поиск конца строки это не лишние ресурсы?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Взлом Linux через подключение USB-устройства стал реальность..."	+5 +/–
	Сообщение от cmp (ok), 08-Мрт-11, 14:26
	Проще разработать 1024битную архитектуру с sizeof(int) == 1024, запихать туда 2^1024 ОЗУ и не парится храня там ежесекундные снапшоты вселенной.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	209. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от User294 (ok), 09-Мрт-11, 03:09
	> Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы > кодирования длины произвольной последовательности. ... только парсить долго :) а теперь представь что тебе придется рюхать миллион таких полей? А миллиард не хочешь? Не как тупо 1 регистровую операцию, как раньше, что быстро, а как целая уйма хитрых операций с регистрами и прочая, т.к. проц не умеет нативно работать с таким представлением.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	210. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от коксюзер (?), 09-Мрт-11, 03:30
	>> Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы >> кодирования длины произвольной последовательности. > ... только парсить долго :) а теперь представь что тебе придется рюхать Что парсить? Как рюхать? > миллион таких полей? А миллиард не хочешь? Не как тупо 1 Да чо уж там, берите сразу триллион - он в тыщу раз внушительнее миллиарда звучит. > регистровую операцию, как раньше, что быстро, а как целая уйма хитрых > операций с регистрами и прочая, т.к. проц не умеет нативно работать > с таким представлением. Так бы и написали: "Все это очень сложно и очень затратно. Правда-правда."
	Ответить \| Правка \| Наверх \| Cообщить модератору


	215. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от User294 (ok), 09-Мрт-11, 05:27
	>> ... только парсить долго :) а теперь представь что тебе придется рюхать > Что парсить? Как рюхать? Я так понимаю что изен про кодирование интегеров с переменной длиной или типа того. Бывает такое, можно и правда закодировать интегер произвольного диапазона более компактно чем обычно. И такое кодирование часто попадается в транспортных протоколах двинутых на компактности любой ценой :). Расплатой за это обычно является некоторая геморность парсинга всего этого - на реконструкцию интегера из такой конструкции требуется несколько лишних операций. Одно дело погрузить в регистры проца число "как есть" и другое - пачка хитрых преобразований чтобы понять какой реально размер у variable-length integer и получить его в нормальном виде понятном процу. В итоге выигрывается в занимаемом числом месте (в байтах) - малые числа получаются короче. Но проигрывается в трудоемкости разбора этого представления. >> миллион таких полей? А миллиард не хочешь? Не как тупо 1 > Да чо уж там, берите сразу триллион - он в тыщу раз > внушительнее миллиарда звучит. А тут все просто: вы не заметите 10 микросекунд вместо 1. Зато вы легко заметите 10 часов вместо 1 часа. Хотя в обоих случаях разница в все те же 10 раз, совершенно одинаковые ;) > Так бы и написали: "Все это очень сложно и очень затратно. Правда-правда." Ну одно дело тупо затолкать число в регистры (в лучшем случае аж 1 команда проца будет), а другое varibale-length кодирование сперва расколупать для этого :). Как бы будет некоторая разница в числе команд которые потребны для одного и того же действа - некое число доступно теперь процу для обработки в виде который был изначально задуман :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	220. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от коксюзер (?), 09-Мрт-11, 06:07
	> Я так понимаю что изен про кодирование интегеров с переменной длиной или > типа того. Бывает такое, можно и правда закодировать интегер произвольного диапазона > более компактно чем обычно. И такое кодирование часто попадается в транспортных > протоколах двинутых на компактности любой ценой :). Расплатой за это обычно Он вообще-то о строках, как я понял. В нормальных языках это происходит просто: вы параметризуете строковый тип максимальным размером строки, а компилятор выбирает, сколько байт под величину размера выделить. Не говоря о наличии возможности работать с нуль-терминированными строками и прочей ересью, если приспичило. > А тут все просто: вы не заметите 10 микросекунд вместо 1. Зато > вы легко заметите 10 часов вместо 1 часа. Хотя в обоих > случаях разница в все те же 10 раз, совершенно одинаковые ;) Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах всё не так очевидно, как в листинге ассемблера. Хотите узнать оверхед, надо профилировать, а не спекулировать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	246. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от User294 (ok), 09-Мрт-11, 15:31
	> Он вообще-то о строках, как я понял. Я так понял что он предлагал хранить длину строки как variable length integer? > В нормальных языках это происходит просто: вы параметризуете строковый тип > максимальным размером строки, а компилятор выбирает, сколько байт под > величину размера выделить. А при нужде интероперабельно с остальными слить это на диск в файл или передать по сети в предсказуемом виде, который потом ремота/другая программа сможет распарсить без привязки к языку, платформе, етц - мы жесточайше факаем мозг, делаем не слишком тривиальные преобразования и что там еще, в общем как обычно. Известное дело, ага. Не, ну можно конечно себе поднасрать на ровном месте, затребовав сложную сериализацию-десериализацию, но это похоже на создание себе проблем сначала, а потом героическую борьбу с ними. Нахрена бы? :) > Не говоря о наличии возможности работать с нуль-терминированными строками > и прочей ересью, если приспичило. Ну, эта ересь как-то исторически прижилась, поэтому она есть. Если так придираться, UTF-8 с его переменным числом байтов на символ - тоже не подарок, только вот кодировать каждую букву как 32 или более битов ради того чтобы японцы/китайцы могли свои иерглифы пропихивать - жирновато будет, не? :) > Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах > всё не так очевидно, как в листинге ассемблера. Ессно, зависит от, но в общем случае чем больше инструкций, обращений к памяти и прочая - тем дольше они выполняются. И чем жирнее код - тем меньше шансов что он целиком попадет в кеш и резко выиграет в скорости. > Хотите узнать оверхед, надо профилировать, а не спекулировать. Ну да, всякие там жабисты любят дрюкаться с профайлером: их софт вечно тормозит, поэтому они зеленеют в профайлерах намного больше чем сишники/сиплюсплюсники, я это заметил, ыгы :))). И главное почему-то никто не пишет критичные к скорости программы на этих ваших крутых и правильных языках. Почему-то игры, сжатие, шифрование, кодеки, ну 3D и прочая навернутая математика которую надо в реалтайме успевать - все как одно на сях или плюсах. Хотя казалось бы JIT дает кучу теоретических преимущесв и что там еще. Обычно умудряются эти преимущества легко похерить кучей рантайм проверок, излишне задрюканными сущностями типа "интегер - это объект" и прочими наворотами.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	261. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от iZEN (ok), 09-Мрт-11, 17:31
	>> Он вообще-то о строках, как я понял. > Я так понял что он предлагал хранить длину строки как variable length integer? Грубо говоря, я предложу такую структуру: struct String { len_of_len; //длина поля длины в байтах len_of_data;//поле длины строки в символах data;//ссылка на контейнер данных перечислимого типа [1...len_of_data] } Плюсы такой структуры: + независимость структуры от базовых типов short, int, long, ограничивающих длину строки и отсутствие избыточности служебной информации для коротких строк; + элементы данных строки счётны от 1 до len_of_data без нужны вычислять конец строки и идиотского "нулевого элемента", принятого в C для элементов массива (по-мне, так символы в строке — это не массив!); + контейнер данных может поддерживать любой доступ к элементам строки (хранить разреженные строки, например), но перечислимость [1...len_of_data] элементов должен обеспечивать — это даёт нам гибкость в абстрагировании от конкретной реализации контейнера.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	264. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер (?), 09-Мрт-11, 17:52
	>> Он вообще-то о строках, как я понял. > Я так понял что он предлагал хранить длину строки как variable length > integer? >> В нормальных языках это происходит просто: вы параметризуете строковый тип >> максимальным размером строки, а компилятор выбирает, сколько байт под >> величину размера выделить. > А при нужде интероперабельно с остальными слить это на диск в файл Трололо, придумаем проблему и выделим ей абзац в нашей простыне. > или передать по сети в предсказуемом виде, который потом ремота/другая программа Ха, данные по сети всегда передаются с таким оверхедом по заголовкам, что сравнивать его с 32/64-битной величиной длины строки - вообще срам. ;) > сможет распарсить без привязки к языку, платформе, етц - мы жесточайше > факаем мозг, делаем не слишком тривиальные преобразования и что там еще, Это всё чушь. Поточная сущность ввода-вывода позволяет подставить любые заголовки до или после строк. Хоть терминировать '\0', хоть записать размер в беззнаковое целое - как угодно. А уж вес этих операций делает любые разговоры об оверхеде на пару-тройку операций с двойным словом просто неприличными. Это всё троллинг. iZEN вообще всех затроллил - начал тред и сел смотреть на массакр. :) > в общем как обычно. Известное дело, ага. Не, ну можно конечно Угу, да. Не, ну конечно же можно. > себе поднасрать на ровном месте, затребовав сложную сериализацию-десериализацию, но это > похоже на создание себе проблем сначала, а потом героическую борьбу с > ними. Нахрена бы? :) Вот именно, нахрена бы? > Ну, эта ересь как-то исторически прижилась, поэтому она есть. Если так придираться, Вы уже определитесь, вам ASCIIZ-строки не нравятся или их альтернативы? ;) > UTF-8 с его переменным числом байтов на символ - тоже не Вот уж где оверхед, так это парсинг не-ASCII текста в UTF-8! Правда, даже этот оверхед в большинстве случаев ничего не решает, и мы тут просто троллим порожняком. > подарок, только вот кодировать каждую букву как 32 или более битов Кодировать! О, кошмар! О, ужас!!!1 Бегом переходить на UTF-8 за полчаса - уж там-то, наверное, кодирования нет. ;) > ради того чтобы японцы/китайцы могли свои иерглифы пропихивать - жирновато будет, > не? :) Гы. Лол. >> Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах >> всё не так очевидно, как в листинге ассемблера. > Ессно, зависит от, но в общем случае чем больше инструкций, обращений к Тролололо в общем случае. > памяти и прочая - тем дольше они выполняются. И чем жирнее > код - тем меньше шансов что он целиком попадет в кеш > и резко выиграет в скорости. И чем дольше, тем жирнее, ага. ;) > Ну да, всякие там жабисты любят дрюкаться с профайлером: их софт вечно > тормозит, поэтому они зеленеют в профайлерах намного больше чем сишники/сиплюсплюсники, > я это заметил, ыгы :))). И главное почему-то никто не пишет > критичные к скорости программы на этих ваших крутых и правильных языках. Потому что пока правильные языки проектировались с учётом требований и обязывали производителей компиляторов к стандартизации для применения торговых марок-названий языка, академическое сообщество весело и задорно клепало экосистему Си-подобных языков, включая ОС, и её апологетов, привлекая внимание индустрии к тому, что уже освоено и "is just good enough". > Почему-то игры, сжатие, шифрование, кодеки, ну 3D и прочая навернутая математика > которую надо в реалтайме успевать - все как одно на сях На ассемблере. > или плюсах. Хотя казалось бы JIT дает кучу теоретических преимущесв и Или фортране. Алсо, спидфаг детектед. > что там еще. Обычно умудряются эти преимущества легко похерить кучей рантайм > проверок, излишне задрюканными сущностями типа "интегер - это объект" и прочими > наворотами. Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок, которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть).
	Ответить \| Правка \| К родителю #246 \| Наверх \| Cообщить модератору


	268. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Dvorkin (??), 09-Мрт-11, 18:43
	> Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок, > которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ > и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть). я бы посмотрел, как мир бы тужился с виндоус и линукс на джаве или питоне, спидфаги, говоришь, хреновы?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	270. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер (?), 09-Мрт-11, 18:54
	>> Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок, >> которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ > и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть). > я бы посмотрел, как мир бы тужился с виндоус и линукс на > джаве или питоне, > спидфаги, говоришь, хреновы? Когда я пишу "другие низкоуровневые языки", обвиняют в отсутствии конкретики, когда пишут "Ада", переводят разговор на джавы и питоны. Что за жизинь, э! ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от caps (?), 08-Мрт-11, 12:40
	Удивительно, но в ядре "вражеской" системы от МС этот тип строк используется повсеместно. Наверняка там работают тупые придурки, которые для безопасности пространства ядра бездарно тратят целых 2 байта на строку. (там для длины строки используется word тип)
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	103. "Взлом Linux через подключение USB-устройства стал реальность..."	+8 +/–
	Сообщение от test (??), 08-Мрт-11, 17:10
	Ну и как, сильно безопасное получилось?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	104. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от коксюзер (?), 08-Мрт-11, 17:14
	> Ну и как, сильно безопасное получилось? Несильно, ибо строки не единственная и даже не самая серьёзная проблема си.
	Ответить \| Правка \| Наверх \| Cообщить модератору