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

"Уязвимость в механизме ucount ядра Linux, позволяющая повысить свои привилегии"	+/–
Сообщение от opennews (??), 31-Янв-22, 12:06
В ядре Linux в коде обработки ограничений  rlimit в разных пространствах имён  идентификаторов пользователей (user namespaces) выявлена уязвимость (CVE-2022-24122), позволяющая повысить свои привилегии в системе. Проблема проявляется начиная с ядра Linux 5.14 и  будет устранена в обновлениях 5.16.5 и 5.15.19. Стабильные ветки Debian, Ubuntu, SUSE/openSUSE и RHEL проблема не затрагивает, но проявляется в свежих ядрах Fedora и Arch Linux... Подробнее: https://www.opennet.me/opennews/art.shtml?num=56610
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 31-Янв-22, 12:06	–8 +/–
Ну что, кто-нибудь ещё скажет что-нибудь после такого о превосходстве Сишников? То-то же! Раст всем голова.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #14, #90

2. Сообщение от Урри (ok), 31-Янв-22, 12:08	+1 +/–
Для сишечки тоже есть умные указатели. Например, https://github.com/Snaipe/libcsptr Но в ядре их не используют.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #7, #8, #47, #50, #110

3. Сообщение от Урри (ok), 31-Янв-22, 12:08	+11 +/–
Я тебя даже плюсанул. Вполне неплохой наброс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #26

4. Сообщение от макпыф (ok), 31-Янв-22, 12:08	+/–
> user namespace Второй ebpf
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #35, #61

5. Сообщение от Аноним (10), 31-Янв-22, 12:10	–1 +/–
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory CONFIG_USER_NS=y что надо включить?
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Аноним (6), 31-Янв-22, 12:11	–1 +/–
Умные указатели для неумных людей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #12

7. Сообщение от Аноним (1), 31-Янв-22, 12:12	+/–
Ну это опционально, а нужно чтобы принудительно было, чтобы нельзя было забыть что-то где-то. Максимум компиляторногг контроля
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #39

8. Сообщение от Аноним (8), 31-Янв-22, 12:13	+2 +/–
ну нафиг, если они такие умные то рано или поздно выйдут из под контроля и образуют скайнет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #11

9. Сообщение от Аноним (6), 31-Янв-22, 12:13	–5 +/–
>Проблема проявляется начиная с ядра Linux 5.14 >linux-image-generic/impish-updates,impish-security,now 5.13.0.27.37 amd64 [установлен, автоматически]
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

10. Сообщение от Аноним (10), 31-Янв-22, 12:15	+1 +/–
отключается в отличие от, как я понял проблема в очередной раз притянута за уши и в данном случае речь просто об ошибке в ядре из-за недостаточно качественно проведённой работы по рефакторингу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #13, #16

11. Сообщение от Жироватт (ok), 31-Янв-22, 12:17	+/–
"Ты чё, умный дох*я? А, указатель? Память есть? А если найду?"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #28

12. Сообщение от ilyafedin (ok), 31-Янв-22, 12:21	+17 +/–
Умные люди, видимо, получают use-after-free уязвимости
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #81

13. Сообщение от макпыф (ok), 31-Янв-22, 12:33	–1 +/–
всм? оба отключаются. Я про решетo, половина уязвимостей в ядре - ebpf и userns P.S. Почему ворд вильтер агрится на "решетo"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #21, #65

14. Сообщение от Аноним (14), 31-Янв-22, 12:34	–5 +/–
Головка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #57

15. Сообщение от Аноним (46), 31-Янв-22, 12:34	–5 +/–
Вот и разбиваются доводы Военов АнтиРастового Сопротивления о суровую реальность и кучи уязвимостей. Не могут даже ucount безопасно отрефакторить, отличный язык. JavaScript получше будет.
Ответить | Правка | Наверх | Cообщить модератору

16. Сообщение от Аноньимъ (ok), 31-Янв-22, 12:38	+/–
>речь просто об ошибке в ядре Всего-то на всего. Тьфу ерунда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #23

17. Сообщение от Аноним (17), 31-Янв-22, 12:44	–1 +/–
А вы спрашиваете, зачем стейбл во времена блидинг эджей.
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от Шарп (ok), 31-Янв-22, 12:44	–2 +/–
>use-after-free пикачу^Wrust - я выбираю тебя!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31, #36

21. Сообщение от Аноним (10), 31-Янв-22, 12:49	+1 +/–
как отключить ebpf в актуальном ядре?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #22, #40

22. Сообщение от макпыф (ok), 31-Янв-22, 12:52	+/–
> как отключить ebpf в актуальном ядре? # CONFIG_BPF_SYSCALL is not set # CONFIG_BPF_JIT is not set CONFIG_BPF как я понял ни на что не влияет Алсо, в актуальном ядре оно запрещено непривелигерованным пользователям
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #24

23. Сообщение от Аноним (10), 31-Янв-22, 12:54	+/–
Если бы кое-кто выполнял работу более аккуратно, этого можно было бы избежать. Или если бы другой кое-кто проследил, что ожидаемая и предсказуемая ошибка не была допущена. Не стоит стигматизировать удобные механизмы из-за банального раздолбайства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

24. Сообщение от Аноним (10), 31-Янв-22, 12:55	+/–
Это не ebpf. В выводе видно на что он влияет, но он тоже не отключается больше CONFIG_BPF=y # CONFIG_BPF_SYSCALL is not set CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y # CONFIG_NETFILTER_XT_MATCH_BPF is not set # CONFIG_BPFILTER is not set # CONFIG_BPF_JIT is not set CONFIG_HAVE_EBPF_JIT=y
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #27

26. Сообщение от Аноним (26), 31-Янв-22, 12:58	+9 +/–
Такой неплохой наброс можно писать под каждой новостью про очередную сишную дыру. То есть минимум раз день.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #38

27. Сообщение от макпыф (ok), 31-Янв-22, 13:00	+/–
> Это не ebpf. cbpf мертв, не помню удалили его полностью или нет, но всегда используется ebpf > CONFIG_BPF=y Инклюдит мейкфайл bpf > # CONFIG_BPF_SYSCALL is not set Это оно как раз > CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y > CONFIG_HAVE_EBPF_JIT=y Это значит что архитектура поддерживает ebpf jit > # CONFIG_NETFILTER_XT_MATCH_BPF is not set > # CONFIG_BPFILTER is not set > # CONFIG_BPF_JIT is not set Эти забыл, да. > он тоже не отключается больше Все норм отключается, и на мастере, и на next, и на 5.16
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #34

28. Сообщение от Аноним (8), 31-Янв-22, 13:00	+/–
память как бы не его, он на неё показать токмо и может
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #30

30. Сообщение от bOOster (ok), 31-Янв-22, 13:06	+/–
> память как бы не его, он на неё показать токмо и может Ну это с какой стороны посмотреть. Умные указатели еще и для того чтобы память не освобождалась несколько раз. Так что можно сказать что указатель данную память забирает на себя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

31. Сообщение от Аноним (14), 31-Янв-22, 13:10	+3 +/–
А C# уже всё, не в моде?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #89

34. Сообщение от Аноним (10), 31-Янв-22, 13:17	+/–
Раньше можно было убрать любые упоминания(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

35. Сообщение от Аноним (35), 31-Янв-22, 13:18	+/–
первый. Лет десять уже этой попытке сделать чтоб вот любой юзер был как рут, но не совсем. На пол-шишечки. Опыт винды (где это даже не считается уязвимостью) ничему не научил. Вернее, научил все тому же - "мне двойное то же самое что тому джентльмену!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

36. Сообщение от Аноним (36), 31-Янв-22, 13:20	+1 +/–
А что не питон?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

38. Сообщение от Урри (ok), 31-Янв-22, 13:29	+4 +/–
И это хорошо! Приятно начинать день с чашечки вкусного кофе и приятных набросов на опеннете. После чего, наконец проснувшись подняв себе настроение, можно и за кодинг на сишечке браться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #41

39. Сообщение от Урри (ok), 31-Янв-22, 13:31	+/–
Не компиляторного. А со стороны непрерывной интеграции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #56

40. Сообщение от Аноним (26), 31-Янв-22, 13:31	+1 +/–
>  как отключить ebpf в актуальном ядре? Нафига? Удобная же штука. Можно создавать правила фильтрации айпишников на контрольную группу, практически per-appliaction firewall. А вот для не-рута надо запрещать, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #96

41. Сообщение от Аноним (26), 31-Янв-22, 13:32	+7 +/–
С мыслью "этому миру нужно больше дыр".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #46, #95

43. Сообщение от НяшМяш (ok), 31-Янв-22, 13:40	+3 +/–
Наконец-то настоящий эксперт опеннета. Пользуется неподдерживаемым ядром без единого патча и гордится этим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #66

45. Сообщение от Fracta1L (ok), 31-Янв-22, 13:48	–2 +/–
> продолжали использоваться после освобождения выделенной для них памяти (use-after-free) Захохотал
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #54, #109

46. Сообщение от Аноним (46), 31-Янв-22, 14:03	+/–
До слёз ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

47. Сообщение от Ordu (ok), 31-Янв-22, 14:07	+13 +/–
Там же только uniq_ptr и shared_ptr, причём со всеми граблями C++'овых аналогов, типа "никаких гарантий". Например, uniq_ptr может быть NULL, то есть просто взять и разадресовать его, не проверяя на NULL -- это лишь до первого бага, который положит NULL туда, где NULL быть не должно. Более того, насколько я вижу, эти указатели реализованы на _рантайм_ проверках, и более того эти рантайм проверки должны выполняться клиентским кодом. То есть, не, он может не проверять, и в случае ошибки в коде получит в рантайме разадресацию NULL с вытекающим из неё сегфолтом. Это _динамическая_ типизация в статически типизированном языке. В C++ тоже с этим проблемы вылезают[1]. Более того, если присмотреться[2], то проблема вытекает из свойств C и C++, которые делают невозможной move-семантику с compile-time проверками на то, что значение было перемещено, и поэтому программист, реализуя move constructor _вынужден_ обеспечивать своему типу специальное значение, которое семантически можно описать фразой "value was moved out, nothing to see here, go away", чтобы это значение можно было бы проверить в рантайме. А это означает, что uniq_ptr будет by design иметь значение NULL, и значит что если разадресовывая его ты забыл проверить на NULL, то значит ССЗБ. [1] https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/ [2] https://www.thecodedmessage.com/posts/cpp-move/ И это фундаментальная проблема, которая делает "умные" указатели бессмысленными в C и C++. Они не столько предотвращают ошибки, сколько снимают часть бойлерплейта, необходимого для того, чтобы избежать ошибок, и таким образом заметают потенциальные проблемы под ковёр, делают их менее заметными. Именно поэтому в ядре использовать uniq_ptr невозможно: в ядре всё в принципе по-возможности делается явным, чтобы было видно что происходит. Ядро пишется на C, и идеология написания кода ядра заточена под C: на компилятор нельзя полагаться, можно полагаться только на себя. Чтобы понять это, я могу порекомендовать Торвальдса, кормящего C++ тролля[3], где его ключевой тезис сводится к: C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me    that STL and especially Boost are stable and portable is just so full    of BS that it's not even funny) - inefficient abstracted programming models where two years down the road    you notice that some abstraction wasn't very efficient, but now all    your code depends on all the nice object models around it, and you    cannot fix it without rewriting your app. [3] https://harmful.cat-v.org/software/c++/linus То есть всё сводится к тому, что пока C++ подход работает, всё хорошо, но когда он не работает, ты впарываешься в infinite amounts of pain и в rewriting your app. А подход C++ не работает довольно часто, потому что он не устраняет ни одной проблемы C, он лишь декорирует их кружевами, позволяя в 90% случаев делать вид, что это не баг, а фича. Но в оставшихся 10% тебя ждут те самые infinite amounts of pain. И смарт-поинтеры, реализованные в C, не нужны в ядре по той же самой причине. Они не снимают ни одной проблемы: тебе точно так же придётся своими глазами следить за тем, чтобы не разадресовать нечаянно указатель, который был куда-то перемещён. Сама операция перемещения dst←src, с последующим обнулением src, будет чуть проще записываться, но следить за тем, чтобы не обращаться к src после перемещения ты точно так же будешь глазами. А каждый твой фейл будет приводить к рантайм краху. Это не делает программирование проще: проследить глазами за обнулением src проще, чем за тем, чтобы он потом не использовался. А если пытаться сделать всё хорошо и статически проверять все эти uniq_ptr, дабы не выносить проверки в рантайм, то: > if you try to statically detect such situations, you end up with Rust.[4] [4] https://www.foonathan.net/2017/09/destructive-move/ Упс. И статические анализаторы не спасут C и C++, потому что эти языки не кодируют в своих API тех допущений, которые необходимы этим API для работы. Теоретически можно было бы API дополнять комментами (примерно как в некоторых динамических языках запиливают статическую типизацию, описывая типы в комментах), но хмм... я не уверен, что это сработает. Теоретически -- да, должно быть возможно, но практически, мы получим две одновременно действующие системы типов, и я подозреваю, это кончится таким уродством и ногу-сломишь-в-этом-коде, что нахрен никому не нужно. Проще лишнюю рантайм проверку вставить, и выкинуть панику если NULL оказался там, где его быть не должно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #51, #58, #77, #84, #88

48. Сообщение от Аноним (46), 31-Янв-22, 14:08	+/–
Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживает use-after-free? Погонять на устройствах, отловить такие баги, часть хотя бы. Походу дела ядро вообще не тестируют. Вроде что-то похожее использует в Zig.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #55, #112

49. Сообщение от Анонн (?), 31-Янв-22, 14:11	+2 +/–
Йохохо, всего два дня прошло с предыдущей дыры, а тут уже новая подоспела. И опять повышение привилегий, и опять налажали с памятью. Стабильность признак мастерства!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #53

50. Сообщение от Анонн (?), 31-Янв-22, 14:15	+/–
А толку что есть? Их все равно никогда (при жизни Линукса, по крайней мере) не затащат в ядро. Проект новье (вроде с 2016 года, но не точно). Не обкатано, не проверено. Еще и по MIT License. PS: О, неужели до сишников таки дошло что автоматическое управление памятью это хорошо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #85

51. Сообщение от Аноним (51), 31-Янв-22, 14:44	+7 +/–
Как поставить 100 плюсов?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

53. Сообщение от Аниме (?), 31-Янв-22, 14:46	+/–
Растовчане то так не могут, что за неудачники
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #64

54. Сообщение от Аноним (55), 31-Янв-22, 14:48	–1 +/–
> Redox is a Unix-like Operating System written in Rust Да, я тоже посмеялся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #71

55. Сообщение от Аноним (55), 31-Янв-22, 14:50	–2 +/–
> Походу дела ядро вообще не тестируют. Ядро тестируют на пользователях, это официальная позиция корпораций-разработчиков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

56. Сообщение от Аноним (1), 31-Янв-22, 14:59	+/–
Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль. Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #59, #68

57. Сообщение от DD (??), 31-Янв-22, 14:59	+/–
Вертеть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

58. Сообщение от Аноним (1), 31-Янв-22, 15:08	+/–
Браво за детальный ответ, сударь!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

59. Сообщение от Урри (ok), 31-Янв-22, 15:14	–5 +/–
> Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль. Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда. Я бы вообще просто по фразе "CI - костыль" выпинывал из профессии назад в то ПТУ, где оного персонажа учили, на второй год. > Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход Это корректный код? float sine(float x) {   return cos(x); } а это? float enis(float x) {   return cos(x); } Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #62

60. Сообщение от псевдонимус (?), 31-Янв-22, 15:16	–1 +/–
И снова неймспейсы. Эта музыка будет вечной.
Ответить | Правка | Наверх | Cообщить модератору

61. Сообщение от псевдонимус (?), 31-Янв-22, 15:23	+/–
Первый хронологически.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

62. Сообщение от Аноним (1), 31-Янв-22, 15:24	+1 +/–
> Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда Да понятно дело, но ведь это обусловлено несовершенствами наших языков > Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии? По содержательным вещам - пишется спецификация и доказывается. Пример - seL4 Что же касается темы Си, Раста и всего такого - если можно вложить доп проверки, почему не вложить? Си пропустит такой кусок кода int * x; if <somecond> { int tmp = 1; x = &tmp; } хотя он явно не корректен и поймать это легко. Что Раст и делает и не допускает такой код
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #67

63. Сообщение от RAMbug (?), 31-Янв-22, 15:32	+5 +/–
И снова перекидывания фекалиями фанатиков раста и сишечки. Дело не в том, что какой-то из этих языков лучше или хуже, а в том, что ядро Linux — это 30-летний поток монолитного говнокода без какого-либо намёка на продуманную архитектуру и контроля за качеством.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #98

64. Сообщение от DD (??), 31-Янв-22, 15:38	+/–
Янукович & Co?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

65. Сообщение от Аноним (65), 31-Янв-22, 15:57	+/–
> P.S. Почему ворд вильтер агрится на "решетo" Если бы вы увидели список всего, на что агриться это чудо, то вы бы истерично смеялись, потом плакали, потом опять плакали... Просто примите пожалуйста, что на опеннете правила фильтрации "очень особенные", и не вдавайтесь в подробности и не зацикливайтесь, а то ещё больше будет мнений, что создавали это чудо также "особенные", со своим видением мира! Проще пользоваться с поправкой на это, чем пытаться вникнуть, разобраться и тем более что-то исправить, даже обсуждение этого ни к чему хорошему не приводит, а нервные клетки не восстанавливаются, разумнее принять и продолжать пользоваться как есть не думая о "красно***ой обезьяне"!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

66. Сообщение от Аноним (65), 31-Янв-22, 16:01	+3 +/–
> Наконец-то настоящий эксперт опеннета. Пользуется неподдерживаемым ядром без единого > патча и гордится этим. Актуальные бунту ядра поддерживаются самой канониклой, а вот насколько эта сикурити-поддержка качественная, это уже другой разговор, не нужно ссылаться на то, что ядра бунт уже EOL в kernel.org, что у Debian подобная практика имеется, что у красношляпы. Я удивлён, что вы про это не знали, или если это такой наброс с вашей стороны, также удивлён, вроде такой сурьёзный мужчина?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #93

67. Сообщение от Урри (ok), 31-Янв-22, 16:08	–1 +/–
> Да понятно дело, но ведь это обусловлено несовершенствами наших языков Берите шире - Вселенной. И это не стеб и не сарказм. > если можно вложить доп проверки, почему не вложить? Если при этом не ломать работающее, конечно же. Или вы так не думаете? > Что Раст и делает и не допускает такой код За цену этого "не допускает" не хотите поговорить? Ну то-есть как бы за все надо платить, не так ли? Или не важно? Я вот, например, от такого кода очень легко избавлюсь с помощью специального инструментария, называемого статическими анализаторами. При этом у меня остается свобода написания высокоскоростного кода. А у вас не остается. Вот если я предложу ради безопасности вашего ребенка (машина не собьет, маньяк не зарежет) поместить его навечно в дурку - вы согласитесь? Я думаю - нет. Вот и тут так же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #69, #73

68. Сообщение от анонимус (??), 31-Янв-22, 16:22	+/–
не обязательно. логика простая - чем раньше обнаружена ошибка, тем ее дешевле править. так просто дешевле их править, но при строгом ci тоже вполне можно ловить большую часть. и на хрусте тоже надо писать тесты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #70

69. Сообщение от Аноним (69), 31-Янв-22, 16:37	+/–
> При этом у меня остается свобода написания высокоскоростного кода. > А у вас не остается. Почему? Абстрактные рассуждения про цену звучат, конечно, классно, но где конкретные примеры того, что Раст даёт сильную просадку по производительности именно из-за запрета того или иного кода?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #79

70. Сообщение от Аноним (69), 31-Янв-22, 16:38	+1 +/–
Не спорю, но чем больше у нас проверок на ранних этапах, тем лучше. Надеяться только на CI - уже попахивает костылищем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

71. Сообщение от Аноним (-), 31-Янв-22, 16:43	+/–
>> Redox is a Unix-like Operating System written in Rust > Да, я тоже посмеялся. Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала приплетают раст, чтобы затем дружно и мощно пук^W "защитить Голактеку от Ржавого Вторжения"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #92

72. Сообщение от самокатофил (?), 31-Янв-22, 16:50	–1 +/–
Растаманьки, скажите, а правда что в расте невозможен use after free по определению? :-) lynx -dump 'https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust' | grep -A1 -B1 'use-after-free' --color
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #91

73. Сообщение от Анонн (?), 31-Янв-22, 17:23	+1 +/–
Цена чего? Покажи пример большого оверхеда. Ты можешь завернуть критический участок в ансейф, написать "мамкой клянусь тут нет race" и говнокодить как хочешь. Просто тебе попросят это доказать. Можешь сделать вставку на асме. Делается так же элементарно (и тоже разумеется unsafe) Если цена отсутствия всяких хардблидов или получений рута - отправить на пенсию пару старперов-неосиляторов, то это не большая цена. Тебя не ограничивают ни в чем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #82

77. Сообщение от Аноним (46), 31-Янв-22, 17:28	+/–
А ещё C++ абстракции не бесплатны. Например инициализация памяти с помощью конструкторов, которые вызывают конструкторы member-членов, которые вызывают ... ну вы поняли. Вместо того чтобы инициализировать кусок памяти разом и туда запихнуть весь layout структуры. В Zig отказались от (супер)быстрого pattern-matching. Потому что if else всё равно быстрее (до 10 раз). И компиляторы не способны в оптимизацию таких случаев как более простые и понятные конструкции. Поэтому до сих пор С быстрее С++. И, конечно, абстракции С++ текут. Например деструктор (и в нём надо защищаться от exception, использовать try / catch, и ... дальше у Майерса почитать). Получается лютый говнокод.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

79. Сообщение от Урри (ok), 31-Янв-22, 17:29	–2 +/–
> где конкретные примеры того, что Раст даёт сильную просадку по производительности Узковато мыслите. Добавьте сюда "цена разработки" и "цена сопровождения".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #83

81. Сообщение от Аноним (81), 31-Янв-22, 17:33	–1 +/–
На раст уже редох написали. Ага, дайте две.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

82. Сообщение от Урри (ok), 31-Янв-22, 17:53	–1 +/–
> Цена чего? Разработки и сопровождения. > Ты можешь завернуть критический участок в ансейф ... > ... Просто тебе попросят это доказать. ... > ... Тебя не ограничивают ни в чем. у вас, растоманов, совсем каша в голове. Я так и не понял - раст не дает говнокодить или никак не препятствует? И чем это отличается от С, где точно так же можно говнокодить, а можно и нет. Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе? В чем плюс то? В том, что можно мозги не включать? > отправить на пенсию пару старперов-неосиляторов Написал человек, не понимающий разницу между компилятором и анализатором. Ну куда уж нам, старперам, осилить такой уровень глупости и скудоумия. При всем старании не получится (разве что уже когда маразм придет).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #86, #87, #99

83. Сообщение от Аноним (69), 31-Янв-22, 18:00	+/–
Так снижается же цена сопровождения наоборот, по сравнению с "опасной процедурой на встроенном ассемблере, экономящей 50-100 раз время выполнения"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

84. Сообщение от Урри (ok), 31-Янв-22, 18:01	+1 +/–
Но я как бы и не говорил что умные указатели - серебряная пуля. Любой задаче, само собой, свои решения. Отличный ответ, без сомнения. За исключением некоторых моментов: > То есть всё сводится к тому, что пока C++ подход работает, всё хорошо, но когда он не работает, ты впарываешься в infinite amounts of pain и в rewriting your app. Это онтосится ко всем языкам и парадигмам программирования без исключений. > А подход C++ не работает довольно часто, А вот это совершенно не так. Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого. > позволяя в 90% случаев делать вид, что это не баг, а фича. И снова аргумент разбивается о реальность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #111

85. Сообщение от Урри (ok), 31-Янв-22, 18:03	–2 +/–
> PS: О, неужели до сишников таки дошло что автоматическое управление памятью это > хорошо? Сишники, вообще-то, знают когда автоматическое управление памятью хорошо, а когда плохо. Для хорошо у них даже куча реализаций GC есть. https://github.com/mkirchner/gc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

86. Сообщение от Аноним (69), 31-Янв-22, 18:06	+1 +/–
> Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе? Ниже Ordu писал о проблеме - проблема в семантике Си, в которой очень многое, с теми же умными указателями, возможно выполнять только в рантайме вместо компайл тайма. Если бы в Си была куда строже семантика, с куда более строгим отношением к UB, тогда дело иное. Вот потому анализатор и должен быть в компиляторе, и язык должен иметь куда более строгое отношение к UB и подобной ерундистике
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

87. Сообщение от Анонн (?), 31-Янв-22, 18:21	–1 +/–
Ну и где примеры высокой цены "Разработки и сопровождения" на расте? То что научиться писать на Си можно  ̶л̶ю̶б̶у̶ю̶ ̶о̶б̶е̶з̶ь̶я̶н̶у̶  студента пту мы знаем. А вот найти крутого Си программера - ой какая проблема, потому что даже мЭтры из ядра линя лажают на таких простых вещах. А у раста входной порог выше - не каждый сишник осилит ownership и borrowing. Зато потом существенно меньше багов с памятью. > Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе? Ну сменишь ты компилятор, даже заставишь это даже компилироваться, а потом внезапно окажется что его разрабы по-другому реализовали серые места стандарта и твой результат изменился на противоположный. Прекрасно ведь! А плюс в том, что тебе на этапе компиляции рассчитывается владение и заставляют или исправить баги, или явно сообщить что ты гарантируешь это. Раст не дает говнокодить втихаря. В отличие от... Есть прекрасная вещь - Clang Static Analyzer, который на минуточку является часть clang. И что? > Написал человек, не понимающий разницу между компилятором и анализатором. Фиг его знает где ты это прочел, но спишем уже на старческий маразм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

88. Сообщение от Аноним (88), 31-Янв-22, 18:26	+/–
Ладно крах при разименовывании NULL. Но от "что позволяло добиться выполнения своего кода на уровне ядра." как-то можно принципиально избавиться в таких случаях?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

89. Сообщение от Аноним (88), 31-Янв-22, 18:29	+/–
Будето там такого нельзя. При желании тоже можно звать объект после вызова деструктора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

90. Сообщение от Аноним (90), 31-Янв-22, 18:30	–1 +/–
"Безопасный язык" только предотвращает ситуации, от которых всё падает. Это значит, что у раста баги будут менее заметны, поэтому для их выявления придётся больше думать и серъёзнее анализировать код. И так как мышление становится пережитком прошлого -- как легко видеть из ситуации с растохайпом -- то бэкдоры служить будут сильно дольше, а внедрение их обойдётся значительно дешевле. Поэтому раст выгоден. Поэтому хайп будет нарастать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #104

91. Сообщение от Аноним (-), 31-Янв-22, 19:04	–2 +/–
у растенек все течёт, но это безопасно. ведь порчи данных не будет, будет постоянный отказ в обслуживании или автоподрыв ракет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #101

92. Сообщение от самокатофил (?), 31-Янв-22, 19:16	–2 +/–
>>> Redox is a Unix-like Operating System written in Rust >> Да, я тоже посмеялся. > Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала приплетают > раст, чтобы затем дружно и мощно пук^W "защитить Голактеку от Ржавого > Вторжения"? >"Redox is not correct, secure, or documented. It does a lot of things in a cavalier, leave it up to the application, manner. Applications can malloc and forget to free, Redox will not clean this up. Applications can access missing memory or kernel memory, Redox does not care. All applications run in Ring 0, and have all permissions. Some syscalls use vtables that rely on exactly the same struct defintions in userspace as kernel space. Syscalls cannot return values, except by writing them into a passed pointer. Memory allocation is done in the application, and uses a global memory allocation table that applications directly modify. None of its functionality is documented, outside of example source files." -- https://redox-os.org/ Гениально, Карл! С такими вводными не то чтобы use-after-free, я даже не знаю что в редохе считать багом. А учитывая что этому хелловорду даже CVE присваивать стыдно -- то можно с уверенностью сказать, что редох это флагман безопасности осестроения растаманек. :-D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #113

93. Сообщение от НяшМяш (ok), 31-Янв-22, 19:17	–1 +/–
> а вот насколько эта сикурити-поддержка качественная Меня смущает тот факт, что патч версия у Анонима (6) до сих пор 0, хотя на кернел.орг последний патч для этой версии был 9. И тут есть два варианта - либо они нарушают версионирование (что плохо), либо они не обновляют патч версии из апстрима (что тоже плохо). В общем, убунтыдебианы сами себе проблем создают, вместо того чтобы использовать LTS с кернел.орг > вроде такой сурьёзный мужчина?! Вот это уже обидно было. Был бы я серьёзным - не страдал бы фигнёй на опеннете xD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #94

94. Сообщение от mikhailnov (ok), 31-Янв-22, 20:01	–1 +/–
У убунты ядро всегда версии x.y.0, они много чего в него переносят, не поднимая 0, иначе бы их версия, допустим, 5.13.6 не соответствовала бы настоящей 5.13.6.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

95. Сообщение от malloc (?), 31-Янв-22, 20:05	+/–
Говори за себя, дыра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

96. Сообщение от макпыф (ok), 31-Янв-22, 20:27	+/–
> Нафига? Удобная же штука. Можно создавать правила фильтрации айпишников на контрольную > группу, практически per-appliaction firewall. Ну не всем и не всегда это требуется > А вот для не-рута надо запрещать, да. В принципе, в 5.16 так и сделано по дефолту
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

98. Сообщение от nvidiaamd (?), 31-Янв-22, 20:31	+1 +/–
И тут ты такой из-за угла с продуманной архитектурой. Что, нету? Странно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

99. Сообщение от Аноним (-), 31-Янв-22, 20:44	+1 +/–
> Написал человек, не понимающий разницу между компилятором и анализатором. Ну куда уж > нам, старперам, осилить такой уровень глупости и скудоумия. При всем старании > не получится (разве что уже когда маразм придет). - 1.2 The Structure of a Compiler 1.2.1 Lexical Analysis 1.2.2 Syntax Analysis 1.2.3 Semantic Analysis s 608 Most global optimizations are based on data-flow analyses, hich are algorithms to gather information about a program. The results of data-flow analyses all have the same form: for each instruction in the program, they specify some property that must hold every time that instruction is executed. ... For example, a constant-propagation analysis computes, for each point in the program, and for each variable used by the program, whether that variable has a unique constant value ... И правда, кто такие "Alfred V. Aho, Columbia University Monica S. Lam, Stanford University Ravi Sethi, Avaya Jeffrey D. Ullman" из "Compilers Principles, Techniques, & Tools", да супротив Урри, "Оупеннут Юниверсити"?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #100

100. Сообщение от Урри (ok), 01-Фев-22, 00:22	–3 +/–
Когда закончились аргументы, побежим размахивать "авторитетами". Слив засчитан, молодец.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #102

101. Сообщение от x3who (?), 01-Фев-22, 03:08	+1 +/–
> автоподрыв ракет Да ладно, всё решается избыточностью - запускаем, допустим, пять контейнеров, в каждом из которых независимо крутятся программы управления ракетой, написанные независимыми группами разработчиков  на расте, электроне, сиплюсплюсе, петоне и джаво. Сверяем сигналы управления, которые генерируют эти программы. Если, допустим, какой-то контейнер выдал на элерон №1 управляющий сигнал, на N% отличающийся от того, что выдало большинство сервисов, то перезапускаем проштрафившийся сервис, сигналы от остальных усредняем. Если кворума вообще никакого нет, т.е. все пять сервисов выдают сигналы с разбросом более N%, то отключаем нафиг всю эту халабуду и летим как деды летали - на резервном контроллере, запрограммированном на сишечке..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #115

102. Сообщение от Аноним (-), 01-Фев-22, 03:31	+/–
Когда Урри опять с умным видом пyкнул в лужу, демонстрируя незнание азов и _общепринятой_ терминологии и побежал размахивать "сливом".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

103. Сообщение от soup2 (?), 01-Фев-22, 08:32	+/–
Теперь будет Rust Kernel за место Linux Kernel xDDDDDDDD
Ответить | Правка | Наверх | Cообщить модератору

104. Сообщение от Аноним (104), 01-Фев-22, 10:21	+2 +/–
> Это значит, что у раста баги будут менее заметны, поэтому для их выявления придётся больше думать и серъёзнее анализировать код. Это значит что и у Си после вычесывания (удачи!) типичных ошибок переполнениями и т.п. (которых 70%), допущенных наСильниками, останется 30% ошибок, "для выявления которых придётся больше думать и серъёзнее анализировать код". Только еще хуже - в типичной Си-шной многопоточке еще дополнительный ворох нетривиальных проблем подбрасывается (всякие рэйс-кондишоны), в отличие от типичной многопоточки Раста с его понятием владения, по дефолту взаимодействием посредством передачи сообщений и пр. (хотя на Расте тоже можно при желании в сишном стиле написать, с разделяемыми между потоками данными и объектами синхронизации и поиметь тот же ворох проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код").
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #106

105. Сообщение от Аноним (105), 01-Фев-22, 13:04	–1 +/–
что-то в винде меньше дырок чем находят в linux kernel..
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #108

106. Сообщение от Аноним (-), 01-Фев-22, 17:34	–1 +/–
> (хотя на > Расте тоже можно при желании в сишном стиле написать, с разделяемыми > между потоками данными и объектами синхронизации и поиметь тот же ворох > проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код"). Ну вот! Видишь! И зачем тогда нужен этот ваш Раст? * пошел выкручивать из машины ненужные подушки и ремни безопасности вместе со смузихлебными ESC и ABS *
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #107

107. Сообщение от Аноним (104), 01-Фев-22, 17:57	+/–
так ведь "при желании"! Если есть желание "самоубиться" - пжалста! Но только наСильник будет пытаться упорно применять техники из Си в Расте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

108. Сообщение от Аноним (108), 02-Фев-22, 00:46	+/–
Вы не поверите - у винды исходники закрыты, поэтому приходится страдать и искать уязвимости в отладчиках и дизассемблерах с гораздо меньшей эффективностью, но гораздо более тяжёлыми последствиями. Вероятность того, что найдут zero day, который поставит раком половину планеты, как шифратор Petya через SMB протокол, сильно выше, чем в линуксе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

109. Сообщение от Аноним (14), 02-Фев-22, 21:07	+/–
Rust-то такого не позволяет. Он просто память не освобождает, потому и нет use-after-free.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #114

110. Сообщение от Прохожий (??), 03-Фев-22, 01:48	+/–
Q. Can I use this on a serious project ? A. Yes, but as this project has not been widely used, there might be some bugs. Beware! А ещё эта хрень зависит исключительно от одного свойства компилятора gcc, насколько я понял. То есть, для других компиляторов может не работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #117

111. Сообщение от Прохожий (??), 03-Фев-22, 02:55	–1 +/–
>Но я как бы и не говорил что умные указатели - серебряная пуля. Зато ты постоянно говорил, что умные указатели в плюсах - это так же эффективно и круто, как в Раст. Оказалось - нет. А ещё говорил, что сообщество Раст тупое. И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в плюсах, и твоей любимой сишечке на самом деле. Ну и кто тут идиот теперь? >Это онтосится ко всем языкам и парадигмам программирования без исключений Я давно заметил, думать и приходить к правильным выводам - не твой конёк. Это никак не относится к низкоуровневым языкам. От слова совсем. Разжевать или сам поймёшь, почему так? >Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого. Никто не знает, чего это стоило их авторам. Попадалась статья как-то, где один спец оптимизировал софт на крупной международной бирже. Ему одному в итоге удалось сделать на F# за полгода то, что десяток плюсовиков не могло сделать несколько лет. Скорость реакции софта выросла в несколько раз. Причина тормозов - излишняя сложность плюсов в местах, где нужна была высокая конкурентность вычислений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #116

112. Сообщение от anonymous (??), 03-Фев-22, 11:57	+/–
> Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживает use-after-free? Для этого нужно прогнать через всевозможные сценарии использования и окружения. Иначе можно и не поймать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

113. Сообщение от anonymous (??), 03-Фев-22, 12:02	+/–
> С такими вводными не то чтобы use-after-free, я даже не знаю что в редохе считать багом. Если не знаете -- это понятно. Но вы не увиливайте: там use-after-free много уже нашли или нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

114. Сообщение от anonymous (??), 03-Фев-22, 12:04	+/–
В смысле "не освобождает"? Вы про что? Можно так же ссылку на первоисточник? И напомню, что вы сказали про Rust, а не про Redox.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

115. Сообщение от www2 (??), 14-Фев-22, 07:50	+/–
Скорее всего получится ситуация "а вы друзья, как ни садитесь, всё в музыканты не годитесь" и ракета всё-таки полетит на резервном контроллере, запрограммированном на сишечке. Но в пресс-релизах будет только пятикратный кворум, встроенный кубернетес и прочее вот это вот всё. Иначе не получится распиливать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

116. Сообщение от Урри (ok), 14-Фев-22, 12:50	+/–
> А ещё говорил, что сообщество Раст тупое. Да. И продолжаю это говорить. А сообщество в каждой новости это подтверждает. > И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в > плюсах, и твоей любимой сишечке на самом деле. А ведь ты даже не понял что там написано, правда? > Ну и кто тут идиот теперь? Ты. >>Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого. > Никто не знает, чего это стоило их авторам. Я знаю. Я за свою жизнь поучаствовал в немалом количестве сложнейших проектов на С++, а уже скоро как большую часть этого времени даже составлял сметы и для самих проектов и для их сопровождения. > Ну и кто тут идиот теперь? #2 Ты. #2 > Попадалась статья как-то, где один спец оптимизировал ... за полгода то, что десяток плюсовиков > не могло сделать несколько лет. Вот. Ты даже не понимаешь что такое "программный продукт" и что нельзя переносить свой опыт хелловорлда на разработку больших сложных вещей. Статья ему попадалась... > Ну и кто тут идиот теперь? #3 Ты. #3 -- Видишь? Я был прав во всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #118

117. Сообщение от Урри (ok), 14-Фев-22, 12:52	+/–
Для растоманов все еще новость, что библиотеки могут быть разными. Я привел один из примеров библиотеки с умными указателями на С. Таких примеров можно найти десятки. Некоторые даже используются во внутренних кухнях больших проектов. Вон там выше аноним упрекал меня в том, что я утверждаю что сообщество растишек идиоты. Так вот, жизнь каждый раз это подтверждает. Как, например, прямо сейчас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

118. Сообщение от Прохожий (??), 16-Фев-22, 01:47	+/–
> Да. И продолжаю это говорить. > А сообщество в каждой новости это подтверждает. Не забывай в зеркало почаще смотреться. Ты гораздо хуже. >> И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в >> плюсах, и твоей любимой сишечке на самом деле. > А ведь ты даже не понял что там написано, правда? Я-то прекрасно понял. Там понимать особо нечего. Рантайм-проверку один типа специалист Урри пытался приравнять проверке на этапе компиляции. Сидиоты, они такие. > Я знаю. Я за свою жизнь поучаствовал в немалом количестве сложнейших проектов > на С++, В роли зрителя? Вряд ли это можно считать поводом для гордости. > а уже скоро как большую часть этого времени даже > составлял сметы и для самих проектов и для их сопровождения. А, так ты экономист-бухгалтер. С этого и следовало начинать. То, что ты создавал видимость активной работы, я не сомневаюсь. Но глядя на твои выперды на этом форуме и удручающе незнание предметной области, сильно сомневаюсь, что такая активность была сколь-либо эффективной. > Вот. Ты даже не понимаешь что такое "программный продукт" Тебе бы, дурачку, мне рассказывать про программные продукты. Я в этой индустрии уже второй десяток лет работаю с крупными клиентами по всему земному шарику. > Видишь? Вижу. Гнать подобных тебе "спецов" подальше из профессии ссаными тряпками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема